Mel : Tasks - reading notes

One of the articles Chris sent out has a section on the creation of team norms. Norms are vital to the success of a team, especially a distributed one; they're the expectations people have and the unspoken assumptions they work with. Synchronizing assumptions at the start is important... and impossible, for the simple reason that when you begin work on a project, you don't know what you're going to do.

2.5 years into my Olin education, I now look back at the ambitious calendars and gannt charts from freshman year and laugh at how confident we were that we'd make them, and how much stress we went through when we started to slip from them. Times and plans and tasks will change. You can't let matters slip and slip and slip, but you can't plot out exactly what you will do a year from now. So how do you lay the ground rules and set tasks without unduly constraining your team?

Lay out assumptions and expectations, not timelines.

It's important to know why people are on a team, what they can offer, how much they want to put into it, and what they expect to get out of a project. What are you used to? What do you silently expect from others? Who likes to be bothered when anything goes wrong, and who'd rather be emailed? Who hates faxes? Who gets paranoid if they haven't heard back from someone in a week? What do you consider important, and what is crying wolf? Going around attempting to voice assumptions is a powerful thing. It's an awkward conversation at first, but it's great once you get going. I've been quite enlightened by these.

Practice test-first development.

In sofware, test-first development means that you write your tests first; that is, you write a program to test your program before you write the program you're testing. You create a way to determine whether your code is finished and successful. It's two birds with one stone; by creating a test case first, you've defined both your goals and a clear-cut way to tell whether you've reached them.

This applies to domains outside of software engineering as well. Everyone's got to agree on what the team is trying for, and everyone's got to agree on what it will mean to reach that goal and how you'll tell when you get there. Are you having outside evaluators come in? Who? Will you stop at n% optimization, x units, y happy customer letters?

You're looking for something that you can point to and say absolutely "we're there" or "we're not there." Something like "make inverted pendulum controller more stable" is open to debate. What's "more stable," and when are you stable enough? A better goal would be something like "inverted pendulum will stabilize itself for at least 5 seconds without outside intervention at least 7 times out of 10." You're either there or you're not.

Assign responsibilities, not roles.

The person responsible for the work getting done and the person doing the work are often the same person, but not always. Instead of telling people "you do this," tell them "make sure this happens." That leaves them open to find the best route to making sure whatever it is happens. Sometimes it's doing it themselves. Sometimes it's asking someone else to chip in. Sometimes it's hiring someone outside to do it for you. In other words, it's on your plate, but you don't have to eat it; just make sure your plate's clean by next week.

Use next-actions and milestones, not beancounting task lists.

"Master Yoda said I should be mindful of the future!"
"But not at the expense of the present. Be mindful of the living Force, young Padawan."
-Star Wars: The Phantom Menace

One of the most powerful concepts of the book Getting Things Done is that of the next action. Don't worry about all the thousands of things you'll need to do to reach your faraway goal. What is the next thing that needs to be done, right now, to get towards that goal? That - not the gazillions of future things - is the task you should assign.

Reply-all when norms are updated.

It's impossible to nail down norms, assumptions, calendars, and everything at the first meeting. You don't know each other, you haven't worked together, you've never done this before and you have no idea how it turns out. Great! Make sure everyone knows that. When you realize that a norm or a procedure isn't the way you think it ought to be, tell people. Make sure everyone's always on the same page; keep your brains in synch as much as possible. Keep those communication lines open.

There you go, Chris. 30 minutes of free association and development of the concepts in the readings. Much of the structure was taken from the third article with the name I can't find, but the analysis and thoughts are my own.