Peter Winston, of Project.net and ICS, stopped by today and dropped a hint for successful iterative development:  "Don’t put two tasks that depend on each other inside one iteration."  Because individuals don't get tangled up doing their own subtasks in sequence, I would amend that to say “don’t put a task in an iteration if it depends on someone else’s task in the same iteration."

This came out of a conversation about how to defeat the type of scaling problems described in the Mythical Man Month.  I’m claiming that the delays in bigger projects are caused by dependencies – one person waiting for something from another person, or in a worse case, 80 people waiting for something from 20.

Removing dependencies inside an iteration is a simple way to prevent yourself from getting surprised by this effect.  At the beginning of the iteration, each person gets a task or tasks that they know they have the materials to complete.  Voila.

This recommendation isn’t as obvious as it sounds.   Some things logically follow.

• Removing dependencies is a good thing.  We already knew that, but it doesn't hurt to be reminded.
  
  
• There is a speed limit that is determined by the number of dependencies, and your iteration cycle time.  If you have X dependencies in a critical path, it will take you at least X iterations to finish.  This is a pseudo-mathematical way to think about why, as Brooks would say, nine women can't make a baby in one month.
  
  
• I have seen two kinds "swim lane" charts for a task card wall.  In one type of chart, you put the "story" on the left side, and you can see the various subtasks to complete this story on the right side, hopefully swimming toward a completed status.  In another version, you put a developer on the left side, and you start the developer's tasks for the current iteration into the swimming lane.  If you use the story version, then you run the risk of having different developers for the different tasks that the story depends on.  If you believe that dependencies inside iterations cause problems, then you would avoid the story version of the swim lane chart, and you would use the developer version.
  
  
• If you fully subscribe to this theory, you want to have some non-blocked task for everyone.  If you want to maximize the speed of delivering a whole bunch of things, you increase the number of things you are working on at one time.  That way, you can always find something to work on that isn't blocked by anyone else.  This isn't intuitive, and it doesn't match the way that high performing teams usually work. Sometimes, they force themselves to work together on one hard thing.  So, it deserves further thought.