Nice post. I have the same feeling about swarming. According to lean it is better to have as little WIP as possible. But obviously 1 item is an extreme case and it is really tough exercise to make at least 4 people work on it together. 

What I found is that 2 developers is often the optimal mini-team for medium/large story.

Hi Michael—

Yes, the idea of swarming an entire team onto one backlog item is definitely aligned with the lean goal of minimizing work in process (WIP). It’s a great goal, but to see that we don’t need an entire team on just one product backlog item, consider what would happen if Toyota put all employees on one car at a time! They couldn’t even all get a physical hand on the car, let alone contribute simultaneously.

So, minimizing WIP doesn’t mean going to the extreme of everyone having to work on the same product backlog item / user story. It’s a great learning exercise that I use when coaching some teams, but I’m not aware of any teams I’ve worked with that should do it permanently.

Interesting. I’ve wrestled this topic too, and I’m glad to see that the pragmatic approach is (once again) the prefered.

How about cross-functional teams and the inability of team members then to help oneanother out (to any meaningful extent), i.e. where there’s a somewhat built-in inability to swarm? For example when you have a team with 3D Graphics Artists mixed with C++ Developers (like we do; we do computer games).

This lead to us taking a route where we not focus so much on what the ideal setup would be, but rather just do what works: i.e. live with 1-2 maybe sometimes 3 persons on a single item, and allow there to be more Work-in-Progress than what typically might “look good”.

Hi Richard—

I think you’re wise to do this. Teams should always focus on optimizing for their own situation. Minimizing work-in-process (WIP) is one goal an agile team should have; you are correct to point out that that minimum amount of WIP will be different for different domains and teams. A highly cross-functional team is likely to have more.

I have, however, seen a game team swarm everyone onto one story at a time for one iteration. It can be, as I was trying to point out, something useful as a drill or exercise that can help a team learn ways to work together, but it is not something to pursue forever in my opinion.

Love the post… I REALLY wish this was the problem in my environment.  I’m at the other end of the spectrum trying to convince the group (and management) that having each person run 2-3 items at once is not practical.  Imagine 8 people running with 20+ items in parallel all the time.

So… I’ve got to use the swarming argument in the other direction until we shift towards the middle.

Hi Kevin—

I’m glad you liked this post; thanks for letting me know.

I’ve often had success with what I call the Goldilocks argument. Generically it goes like this: “Look, in the past we’ve done too much of such-and-such [design, documentation, manual testing, etc.]. So in order to find out the right amount, I think we should deliberately try to do too little of such-and-such. Once we’ve experienced both sides—too much and too little—we’ll be able to figure out the right amount. So, let’s try a couple of iterations in which we deliberately do too little of that.” (note, you could be making this argument in the opposite direction)

What I find is that nine times out of ten when the team agrees to do “too little” they don’t even then go far enough. So, you may ask your team to agree with you that we “have too much work-in-process and can we try to cut it a little too far so we figure out what’s the right amount.” Maybe the team can agree that no one person will have more than 2 tasks in process concurrently. Or maybe they can agree that any task in process for more than 2 days gets a second person added to the task no matter what.

Here’s a surprisingly effective technique, too: If you’re using a task board, draw the “in process” column to be about the width of one index card or post-it. This acts as a subtle, unstated reminder to not have too much in process at a time. Oddly it helps. I’ve worked with teams and tracked how many items per person where in process at the start of the day. Doing something as simple as this created between a 10-20% drop in WIP for the teams I was with long enough to measure. Not a huge improvement but I’ll take any step in the right direction.

Great post.  At my current company we find that “pairing” up on specific stories has been very helpful.  The knowledge transfer has been fantastic, especially for new team members.  We’ve generally stayed away from having any more than 2 devs/story at any one time, and encourage our team members to only have 2 tasks in progress at one time.  It seems to have worked out nicely.

Thanks, Myles. This sounds like a very reasonable approach. I encourage teams to come up with rules like this for themselves. It is especially great later if the rules start to fade away and working this way just becomes part of how the team operates.

Mike,
I just got back from Scrum Gathering in Stockhoolm. I participated in an Open Space topic on “Lean.” Even though the question was whether there is a need for an iteration/sprint (a.k.a, time-boxing vs flow), we got into the discussion of swarming. The guys were suggesting that a team should do swarming. And some of us were suggesting that even if we wanted, for a team of 5-9 people, it would not be physically possible. It is good to see that you also agree with us…:-) In my experience, we typically use 2-3 people on a story- 1/2 developers primary to allow knowledge spreading (not pair programming) and a QA person who writes acceptance test scripts while developers are implementing the story.

Syed
ScrumPad

Nice post Mike.  Pragmatic as always.  I do like the concept of restricting teams to a single story for learning purposes.  But in the end, when a team is comfortable with an Agile approach they need to simply do what feels right.

Always good to come here to read your thoughts.  It is somehow very stabilizing.

Thanks, Tobias. I appreciate your kind words.

I’ve been a swarming advocate to drive closure.  Product managers often feel that chipping away at little bits of lots of things is more defensible because they can tell the customers that the work is “in development”.  This so-called advantage then becomes an obstacle to getting closure on “the most important thing”.  The downward spiral proceeds from here, long-lived branches and waste of call kinds proliferates.
The cure for us would be better story writing so all these little chunks are releasable but frequently, a suite of stories must be completed before something can be put in production.  For this reason, assuming developers can be effectively employed, I’m in favor of swarming to expedite ROI on development work and get production customer feedback as soon as possible.
Thanks for the post Mike.  This is a topic that highlights again that it is the sociology and not the technology that is often the toughest stuff to figure out.

Hi Doug—

Thanks for commenting on the post—and yes, indeed, it is almost always the social issues that challenge projects.

I completely agree with swarming in the case you describe. The keys for me are two-fold: (a) your comment that “assuming developers can be effectively employed” and (b) that you probably (let’s hope!) need to swarm in (let’s make this easy) five years.

Hey Mike,
great quality post - as ever!

I encourage new teams to swarm primarily so they can learn to focus and develop the attitude of taking small units of work to completion.

I have also seen teams swarm on collective design in very spontaneous ways too - and that also seems to be fairly valuable (for that team).

Tobias’ comment on let the team (after some experience) do what feels right also resonates with me, but I feel that certain good practices should be in place first…like:

maintaining the priority of the PBIs in the sprint - to make sure we deliver the most valuable first?

the team (within reason) all work on taking each PBI to ‘Done’ and then moving to the next - to minimise waste.

(must work on my verbosity!)

mike

In my opinion the Scrummaster should monitor if the progress on the overall iteration is hurting due to problems with people “getting in the way” of each other. What I do is to log it as an impediment (call it structural problem on user story X) and challenge the team to come up with creative solutions do effectively work togheter on the story.

If they cannot achive a solution that’s make us comfortable removing the impediment, one of the developers on the story will continue on less important stories (in the product backlogg perhaps) and I will report to the Product Owner that we have problems in the current iteration due to structural problems sharing a story/requirement among several people.

Most of the time the team will suprise you with a creative solution though.

Hi Mike,

Indeed this is a very informative post. To be honest, I couldn’t find too many resources on the same till I came across this post.

I have a question - my team was facing a difficult problem sprint on sprint with respect to bad requirements. The scenario was this - the user stories written by business analysts(who are our direct customer proxies) had serious shortcomings in the form of incomplete acceptance criteria.Also, since the user stories were not truly independent of each other, the collective impact also led to many hidden / implicit requirements which were not formally mentioned. This led to huge number of defects due to requirement miss.

After 3 bad sprints, the team itself hit upon a strategy.In the initial few days of the sprint, the team blocks a room (shutting off all external disturbance) and does what I would like to term as “requirement scrutiny”, 1 user story at a time. They collectively list down gaps and raise questions on a daily basis with the business analysts leading to heated debate and discussion but at the end of it all, we end up working on requirements which are well agreed upon. The result - we have had 2 very successful sprints with the defect count taking a clear nose-dive. My question is - can this be considered “swarming”?

Thanks for your time.

Hi Sainath—This sounds like it may be a good idea for your team since it’s working, but I wouldn’t call it “swarming.” Swarming is where everyone—all programmers, testers, analysts, designers, etc—all work on one story at a time. When they finish it, they work on the second, and so on. It forces a form of hyper-collaboration so that when the team reverts to working in a more “normal” way (say 2-3 stories in process for a 6-7 person team), team members can collaborate better because of what they learned while swarming.

Thanks for the response, Mike. That is indeed very clarifying.

What about swarming when a team has several applications to work on?

Hi Debra—
I don’t see what would change when the team works on several applications. Swarming is not generally a good idea as a permanent practice. It can be a great learning technique for a sprint or two. Whether the items the team works on one at a time come from one application or several wouldn’t seem to matter.