Re: [scrumdevelopment] Re: Swarming, I just don't get it.
- On 03/01/2011 9:25 PM, agilejedi wrote:
> It is overcomplicated, but really it is ill defined. Swarming wasSome somewhat random thoughts...
> introduced to me as an approach that is superior and shows maturity
> and that everyone works on one story until it is done. Sounded wrong
> to me. Like there was no association of the activity to a goal of
> delivering. Just showing off how well we can work together. Who are we
> showing off to? I don't know.
Swarming, like pair programming, is something that I've done many times
over my career long before I knew it had a name - when you have a tough
problem, throw a bunch of brains at it. I just didn't necessarily do it
all the time.
When I'm coaching teams, I don't immediately introduce swarming until I
see there's a need for it. Sometimes a team is able to simply switch
from a traditional model to an iterative, incremental model with no
problem. More often, though, teams are used to starting all sorts of
work simultaneously and trying to push it all along in parallel. 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.
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.
- Hello, Seyit.
Very well put! Thanks!
On Friday, January 7, 2011, at 6:17:36 AM, you
> Wouldn't you think if team used swarming "in a right fashion" (what ever itRon Jeffries
> 1. Majorty might learn how to read the syntax of generics,
> 2. "The vocal, big mouthed, team idiot", might realize he's not the boss and
> should get well with the whole team or he needs to get the .... out,
> 3. The lesser mind can learn something from the better one.
> My team doesn't use swarming and also I don't have any first hand experience
> on that. But considering the examples you have, and definition of swarming,
> it seems actually teams you describe might give it a try.
> Proposition 1: Two minds are always better than one, if they are combined in
> the right fashion. So you might be doing it wrong.
> Proposition 2: Given two minds, it's not proven there exists a pattern to
> find which one is better. So it doesn't matter if one is better than the
Know what I pray for? The strength to change what I can, the inability to
accept what I can't and the incapacity to tell the difference. --Calvin and Hobbes