Re: [scrumdevelopment] Re: Swarming, I just don't get it.
- Hi Jedi,
> > Parallelizing work too much often kills a team's velocity.In one particular case I've seen this happen, the stories were broken
> Really? Or is it that tasks aren't broken down and sized to fit
> iterations because everyone is working in their queue and have lost
> interest in some time box?
down into tasks that seemed adequately sized.
What would happen, though, was something you could easily spot as a
dynamic pattern on the task board:
s1 XXXX | |
s2 YYYY | |
s3 ZZZZ | |
at the start (given the usual three columns, lines represent three
stories broken down into letter tasks), then
s1 XXX | X |
s2 YYY | Y |
s3 ZZZ | Z |
a few days later, as people started more than one story
simultaneously. By the end of the iteration you'd see
s1 | X | XXX
s2 | Y | YYY
s3 | ZZ | ZZ
and not much of a velocity. My recommendation was to give swarming a
try - not as a rigid rule, more as turning a dial in the direction of
putting more emphasis on getting stories done. The idea was to see
this instead by iteration's end:
s1 | | XXXX
s2 | | YYYY
s3 ZZZZ | |
Same number of tasks done, two more stories done.
> So this is the new approach to address the issue of splitting upIt's not so much a matter of splitting things up explicitly or not, or
> tasks smaller and smaller? Now we don't have to split it up and do
> the effort of splitting it up as if an individual were to work on
> it. We just size it at a higher level and then the team split it up
> when the get to it? So less planning?
when you split them up, or how big or small. As I see it, anyway. (You
make it sound as if my opinion is somehow representative of large
numbers of people's. Flattering, but unlikely.)
It's more a matter of preferring to get things finished over getting
things started. And it's a dial, not a binary thing.
- 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