Loading ...
Sorry, an error occurred while loading the content.

Re: [scrumdevelopment] Re: Swarming, I just don't get it.

Expand Messages
  • Adam Sroka
    ... I don t disagree with any specific thing Ron or Laurent said, but I do think finishing stories by the end of the Sprint is a side effect and getting
    Message 1 of 62 , Jan 3, 2011
    • 0 Attachment
      On Mon, Jan 3, 2011 at 6:50 PM, agilejedi <agilejedi@...> wrote:
      >
      >
      >
      > --- In scrumdevelopment@yahoogroups.com, Adam Sroka <adam.sroka@...> wrote:
      >
      > >
      > > On Mon, Jan 3, 2011 at 1:40 PM, agilejedi <agilejedi@...> wrote:
      > > >
      > > >
      > > >
      > > > --- In scrumdevelopment@yahoogroups.com, 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.
      >

      I don't disagree with any specific thing Ron or Laurent said, but I do
      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.

      > >
      > > 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.
      >

      However, if one of you got it done alone no one else would know how
      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.
    • Ron Jeffries
      Hello, Seyit. Very well put! Thanks! On Friday, January 7, 2011, at 6:17:36 AM, you ... Ron Jeffries www.XProgramming.com Know what I pray for? The strength to
      Message 62 of 62 , Jan 7, 2011
      • 0 Attachment
        Hello, Seyit.

        Very well put! Thanks!

        On Friday, January 7, 2011, at 6:17:36 AM, you
        wrote:

        > Wouldn't you think if team used swarming "in a right fashion" (what ever it
        > is):

        > 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
        > other.



        Ron Jeffries
        www.XProgramming.com
        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
      Your message has been successfully submitted and would be delivered to recipients shortly.