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

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

Expand Messages
  • Ron Jeffries
    Hello, Alan. On Sunday, January 18, 2009, at 12:32:16 PM, you ... Yes. However, it would surely happen with very high probability that some story wouldn t be
    Message 1 of 59 , Jan 18, 2009
    View Source
    • 0 Attachment
      Hello, Alan. On Sunday, January 18, 2009, at 12:32:16 PM, you
      wrote:

      > Well, first, let's assume you have some small stories (1-3 story
      > points). That means that we're not talking about a lot of work here
      > anyway. But let's say the stories are bigger. What'll happen if you
      > half code something? You now have bleed-over (incomplete stories into
      > the next sprint). If you already have bleed-over, adding to it is not
      > a good idea and I'd rather the dev help close other stories that would
      > otherwise bleed over into the next sprint. Work in process has a
      > negative effect. We want to lower it and certainly not add to it.

      > If you are willing to start things without finishing others then you
      > don't have enough focus on completing things.

      Yes. However, it would surely happen with very high probability that
      some story wouldn't be done at the end, if we were all working at
      our standard pace and quality level. Still supposing that we are
      working to our standards, then to avoid partially done stories it
      would be necessary not to start them, leaving a sort of work gap at
      the end of the Sprint.

      (Now in practice, of course, there is always something to be done,
      so in practice, we can be productive without starting a new story to
      be left incomplete. I'm trying to analyze down to the metal here. In
      that case there would be time spent not working.)

      On the other hand, suppose we do start the story and the Sprint
      ends. One might argue "So what," we have weekends all through the
      Sprint and no one worries much about carrying a story over a
      weekend. There's always work in progress, and in fact if stories are
      all of the same size, there is always exactly the same amount of
      work in progress. The Sprint carry-over is no different.

      With one exception: what if the Product Owner rules the story as no
      longer being important enough to finish? Seems to me that this is
      unlikely, since it was important enough to get scheduled just a
      couple of weeks ago, and to be started just a couple of days ago.


      Mind you, I don't like this answer. I think it is a slippery slope,
      and that in practice there is probably always something to clean up
      that will let us keep to the standard that stories are always either
      not started, or done. That seems a good standard to me.


      And then there is the kanban approach. No Sprint at all, things
      released when ready. To the extent that kanban is some advanced kind
      of Scrum / Lean / Agile way of doing things, then starting stories
      that might not finish by end of Sprint might actually be a step onto
      that better path.

      Ron Jeffries
      www.XProgramming.com
      www.xprogramming.com/blog
      Speak the affirmative; emphasize your choice
      by utterly ignoring all that you reject. -- Ralph Waldo Emerson
    • 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.