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

Re: [leanagilescrum] Re: don't start what you can't finish

Expand Messages
  • Rob Park
    I certainly agree with getting anything already in progress to done-done before starting more. I ve used Kanban in the past to force the team to solve the
    Message 1 of 59 , Jan 19, 2009
    View Source
    • 0 Attachment
      I certainly agree with getting anything already in progress to done-done before starting more.  I've used Kanban in the past to force the team to solve the problem of how to more effectively "swarm" rather than say he's working on that so I'll start another story.  So obviously, I'm in favor of your notion of swarming... or at least pairing.

      However from your first post, "Using the time to write more test specs for upcoming stories, doing a little analysis, or cleaning up something that you've been meaning to do would be better"... that strikes me as waste.  Either your doing up-front work and why not just start the real story the "right" way?  Or your gold-plating something that was already done-done?  

      I've always considered some stories rolling from iteration to iteration healthy.  If there were none, I'm thinking someone must have been idle at the end... or working on non-priority work.  

      Of course for this to be healthy, the team must be delivering multiple stories to done-done per iteration.  Also, I never like to see the mini-waterfall effect of design-code-test within the iteration, which I've seen as the result of people trying to treat the timebox like a project schedule rather than just a timebox for measurement.

      .rob.

      On Mon, Jan 19, 2009 at 6:38 PM, Alan Shalloway <alshall@...> wrote:

      --- In leanagilescrum@yahoogroups.com, George Dinwiddie <lists@...>
      wrote:


      >
      > Alan Shalloway wrote:
      > > Both Kanban and Scrum are based on flow and managed by pull
      (ironic
      > > how this is so easily accepted now). Scrum has cross-functional
      > > teams, Kanban has cross-functional teams, but swarming doesn't
      > > typically occur.
      >
      > Alan, in this sentence, what do you mean by "swarming"? And are
      you
      > saying it doesn't typically occur in either Scrum or Kanban?
      >
      > - George
      >
      > --
      > ----------------------------------------------------------
      ----
      > * George Dinwiddie *
      http://blog.gdinwiddie.com
      > Software Development
      http://www.idiacomputing.com
      > Consultant and Coach
      http://www.agilemaryland.org
      > ----------------------------------------------------------
      ----
      >

      Team swarming means that more than one member of a team work together
      to get a story done. This avoids handoffs and gets things done much
      faster as well as potentially (hopefully) create synergy between the
      team members. Team swarming is Lean's equivalent of the work-cell.
      I tend to use swarming because I've been told that is a more
      understandable term. Teams don't typically swarm in their entirety -
      typically subsets of the team does. For example, a DBA, a dev and a
      tester may all get together to start, do, and test the story. Team
      swarming is one of the things I think is powerful about Scrum. You
      can't swarm on every story, but when you can - it's a good thing. Of
      course, the team(let) decides when to do this.

      Therefore, in Scrum, I think team(let) swarming is good. Now, Kanban
      is typically done in a way where things flow from one role to
      another. Therefore, in typical Kanban I don't think swarming
      occurs. But this doesn't mean you can't do team swarming in Kanban.
      I think you can have two general types of Kanban at the team level.
      The first is the normal (current) way of doing it where the work goes
      through the different stages and people pull (use Kanban) from the
      role before them. No swarming here. Hoewver, you could think to
      implement Kanban as having teams that pick up the work and swarm on
      it until it is done. This would be like iterationless Scrum, I guess.

      Kanban as developed by David Anderson, does more than just say how
      the team should manage their work (and, of course, inspect and adapt
      as all good development methods tell you to do). Since Kanban pulls
      from a list of product enhancements (extensions and new product work)
      it puts pressure on the product portfolio managers to work together
      to select the most important things to put in the pipeline.

      Scrum, in and of itself, does not do this (or at least, I have not
      seen this from type A Scrum).


      Alan Shalloway
      CEO, Net Objectives
      Achieving Enterprise and Team Agility


    • George Dinwiddie
      ... If the backlog items are largish, then I see no reason that a Kanban team wouldn t swarm over them. ... Either people are available to work on the story or
      Message 59 of 59 , Jan 22, 2009
      View Source
      • 0 Attachment
        Alan Shalloway wrote:
        > --- In leanagile@yahoogroups.com, George Dinwiddie <lists@...> wrote:
        >> Alan Shalloway wrote:
        >>> --- In leanagile@yahoogroups.com, George Dinwiddie <lists@> wrote:
        >>>> Alan Shalloway wrote:
        >>>>> --- In leanagilescrum@yahoogroups.com, George Dinwiddie
        > <lists@>
        >>>>> wrote:
        >>>>>
        >>>>>> Why can't you do it on every story? While most teams don't, I
        >>>>>> think it's possible on all but very tiny stories, which most
        >>>>>> teams don't have.
        >>>>> I like to swarm when you can, but a couple of reasons why you
        >>>>> can't:
        >>>>> 1) required people aren't available
        >>>>> 2) story content requires a linear approach
        >> >>
        >>>> Perhaps some actual examples would help. I don't think I've ever
        >>>> /really/ run into these situations, though often people jump to
        > such
        >>>> conclusions.
        >>> Type A scrum works off the product backlog. But the product
        > backlog
        >>> is only for one product. I have long said Scrum works fine for
        >>> this. I am talking about how to look at the problem of managing
        > all
        >>> of the products in an organization.
        >> OK. This conversation is getting a little confusing to me. When
        > you say,
        >>> Now, Kanban
        >>> is typically done in a way where things flow from one role to
        >>> another. Therefore, in typical Kanban I don't think swarming
        >>> occurs. But this doesn't mean you can't do team swarming in
        > Kanban.
        >>> I think you can have two general types of Kanban at the team
        > level.
        >>> The first is the normal (current) way of doing it where the work
        > goes
        >>> through the different stages and people pull (use Kanban) from
        > the
        >>> role before them. No swarming here.
        >> you specifically mentioned "at the team level."
        >>
        >> Do you intend that the team pulls work for a single product? Or
        > that
        >> the team pulls work for the highest priority item across all
        > products?
        >> Or that individuals pull work for the highest priority item across
        > all
        >> products? Or what?
        >
        > I meant Kanban at the team level by looking at the value stream from
        > the product backlog to the time the team produces the result. Kanban
        > often has a common backlog across products - and it's most effective
        > when it is used this way. But I was referring when Kanban teams pull
        > something from the product backlog.
        >
        >> In any event, if the team is pulling work, it seems to me to either
        >> be big enough to swarm over, or so tiny that we've devolved in
        >> having an omniscient project manager do a complete work breakdown
        >> and direct the workers as if they're just a pair of hands. But I'm
        >> only seeing these two possibilities at the moment. What is the
        >> third possibility that you're seeing?
        >
        > I thought I had said there were two types - not sure where you got I
        > said three. Remember, backlog items for a Kanban team doing
        > development (as opposed to support) are often bigger than items for a
        > Scrum team (since the sprint backlog can't contain more stuff than
        > you can do in a sprint - typically two weeks) while a Kanban cycle
        > can be much longer.

        If the backlog items are largish, then I see no reason that a Kanban
        team wouldn't swarm over them.

        >>>>> I like to swarm when you can, but a couple of reasons why you
        >>>>> can't:
        >>>>> 1) required people aren't available

        Either people are available to work on the story or it stops. If a
        largish story is completely blocked by the absence of one person, you've
        got an issue that probably blocks Lean, Agile, Scrum or Kanban. This is
        just no way for an organization of any size to work. Your statement,

        >>> Now, Kanban
        >>> is typically done in a way where things flow from one role to
        >>> another.

        indicates that the work process has devolved to an assembly line, with
        every bit of work involving a handoff from one person to another. This
        is a terrible way to work, in my experience. The worst effect is the
        communication loss and delays in those handoffs. Another effect is that
        doing this necessarily increases WIP, or else the other "stations" will
        be idle. Another subtle, but devastating effect is that the way work is
        done is almost impossible to change, since the workers have no control
        over the larger process, but only their "station" in the flow.

        >>>>> 2) story content requires a linear approach

        I find this one incredibly difficult to believe. I have never seen it,
        particularly for a largish story. I /have/ seen cases where people
        assume that they can only work on it in a linear fashion. This is
        merely ignorance, though.

        Anyway, that's the way it looks to me. Perhaps I'm misunderstanding
        your description of Kanban and why people normally can't or don't swarm
        on a story when using it.

        - George

        --
        ----------------------------------------------------------------------
        * George Dinwiddie * http://blog.gdinwiddie.com
        Software Development http://www.idiacomputing.com
        Consultant and Coach http://www.agilemaryland.org
        ----------------------------------------------------------------------
      Your message has been successfully submitted and would be delivered to recipients shortly.