"agilejedi" has a question about the Agile practice of "swarming":
I don't see how having the entire team working on the same story is generally the best approach.I recognize that the practice of pair programming in XP has been a hard pill to swallow but now we have whole team programming? Is that what this really is?
In reply, Dave Rooney highlights what he considers to be the chief advantage of swarming:
Humans provably suck at multitasking, which manifests itself in a traditional process as "75% of the features are 80% done". Well, when it comes time to actually ship something, having 80% of the features 100% complete is much more valuable than 100% of the features 80% complete.The real model behind swarming is getting the team to focus on getting work that is valued by the business done. Get one thing 100% done, i.e. potentially shippable, before moving on to the next thing. The traditional model shows activity, this model shows progress.
Ron Jeffries gives essentially the same answer, but from an interesting perspective:
If you get to the end of an iteration with more than one unfinished story, that tells us that people were working on the most important of those stories ... and on the least important. It makes us think that a little more focus on the most important one might have gotten it done.
Adam Sroka wants to emphasize the quality aspects of swarming, however:
No. The purpose of swarming is not to address unfinished stories. The purpose of swarming is to increase quality and consistency by getting the whole team involved in a story as near to the beginning as possible.If you increase quality and consistency then as a side effect you learn how much you can do in a small increment of time. You can use that knowledge to estimate what you can get done over time and never take on more than you are reasonably confident you can finish.
The reason that quality and consistency are higher with swarming than with parallel work is that all of the skills and abilities of the entire team (including the customer) are brought to bear on a single item maximizing its chance for success. Of course, this only works for small teams that have learned to work well together, but for such teams it works extraordinarily well.
How many stories should be swarmed simultaneously by a team? Dave Rooney offers this rule of thumb about swarming:
Depending on the makeup of the team, you may be able to work on more than one item at a time. My rule of thumb is that the team should work on no more stories simultaneously than the number of QA people on the team. If that sounds inefficient, just watch the task board during a sprint and you should see many tasks pile up as the end of the sprint approaches. The poor QA person or people have to bust their behinds to get everything tested before the sprint is over. How do you deal with this? You have everyone on the team contribute to verifying that every piece of work is shippable. In other words, the teams swarms the work.