Re: [scrumdevelopment] Re: Swarming, I just don't get it.
- On Mon, Jan 3, 2011 at 6:50 PM, agilejedi <agilejedi@...> wrote:
>I don't disagree with any specific thing Ron or Laurent said, but I do
> --- In email@example.com, Adam Sroka <adam.sroka@...> wrote:
> > 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
> > possible.
> 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.
think finishing stories by the end of the Sprint is a side effect and
getting stories done with consistently high quality is the goal. In
the end Sprints are arbitrary time boxes, and unless the end of Sprint
date happens to correspond to some meaningful business event it is an
arbitrary date too.
There are a number of reasons why it is important to take on less at a
time in order to ensure quality and consistency. These can be boiled
down to the mathematics of uncertainty and queues, but it is not
necessarily to understand this in detail to take advantage of it for
your team. In the end it is a risk management strategy and it is about
making sure that a reasonable number of items are highly successful
and the defect rate is as near to zero as possible.
> >However, if one of you got it done alone no one else would know how
> > 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.
> 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.
they did it. There might be advantages to knowing how your teammate
does something. There might be something you could contribute that she
didn't thing of.
You could view those coordination costs as overhead, and they do add
up (That's the reason this only really works for small teams.) Still,
some of us have been doing it for a while and found the benefits to
outweigh the costs. I am not aware of any better way to get everyone
on the team to know what is going on and how to contribute. I am not
aware of any better way to develop the total flexibility to change
directions as needed. If you and your business value these things it
is worth learning, but maybe that is not the case for you.
> 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.There is a difference between being busy and being efficient. I am
willing to bet that what you perceive as efficiency is really whether
you think you are busy or not (And you extrapolate from that that the
rest of your team is just as busy as you are.) The only way to prove
it would be to measure the throughput both ways and find out.
> 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.Agreed, and in the environment that you are in it may be that the
benefits don't outweigh the risks. Maybe you don't actually need to
know how the entire system works right now. Maybe it is good enough
that you could find out at some point if you needed to.
- 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