Re: Swarming, I just don't get it.
- --- In email@example.com, Adam Sroka <adam.sroka@...> wrote:
>That doesn't seem to be the same as other explanations. Not that the desire to increase quality isn't good. Increased consistency may not be a concern for me.
> On Mon, Jan 3, 2011 at 1:40 PM, agilejedi <agilejedi@...> wrote:
> > --- In firstname.lastname@example.org, Laurent Bossavit <laurent@> wrote:
> > >
> > > Does your team often get to the end of an iteration with more than one
> > > story unfinished? Then they will probably benefit from swarming. That
> > > simple.
> > Is this the general way to address unfinished stories?
> 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
>To me it was a confusion. I worked on some trivial aspect of the story and I had to constantly check in code and get new code and tell my team mates what I was doing because we were all in the same area, files, and classes. One of us could have easily done it all, with out any over head.
> 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.
I found it enjoyable though, but not efficient. It was nice sitting around chatting and making a lot of ruffling sounds and working together. It wasn't efficient.
Is there risk because one person does it. Sure, but not as much as people seem to make it. That is very little new under the sun, I can figure out anyone's code on the team and they can figure mine out. An inexperienced programmer can figure no one's out.
- 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