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

don't start what you can't finish

Expand Messages
  • Alan Shalloway
    I got a great question from someone off-line. I would be interested in hearing if others get this question and if you have other ways of explaining this
    Message 1 of 59 , Jan 18, 2009
    View Source
    • 0 Attachment
      I got a great question from someone off-line. I would be interested in
      hearing if others get this question and if you have other ways of
      explaining this (other than just saying "XX/YY says to").

      I had made a comment that you shouldn't start a story in an iteration
      that you don't think you can finish. Presumably this is a story that
      was committed to be done within the sprint but is now very close to the
      end of the sprint and you are behind a bit. In other words, why not
      close out the last couple of days with partially done work. On the
      other hand, maybe you can squeeze in a little bit of the next sprint in
      here and get a jump start on things (assuming you know what's coming
      up).

      Here is my reasoning.

      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.

      When there is already bleedover not starting new stories should be a no-
      brainer in that you should focus on getting already in process stories
      to a done-done state. But when there isn't, I still don't like
      incomplete things. 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.

      Comments?

      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.