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

Re: don't start what you can't finish

Expand Messages
  • Phillip Cave
    Hi Alan, Examining the topic point – don t start what you can t finish and some of the discussion in this post … the principal behind kanban helps to
    Message 1 of 59 , Jan 18, 2009
    View Source
    • 0 Attachment

      Hi Alan,

      Examining the topic point – "don't start what you can't finish" and some of the discussion in this post … the principal behind kanban helps to achieve this by allowing us to monitor the flow of work and only start on an activity when we are ready to do so…if we have too many "analyze" activities in process and these start to stack up faster than we can complete them, we need to even out the flow of work and either stop analysis activity or do more "coding" and "testing" activity…

      Since kanban is a method for managing inventory – a signaling that tracks the flow of material…in our context here, stories and features.  How are our stories flowing through to completion … we don't start another story (or "activity" of a story – analyze, code, test, validate) until the last story is past the activity or complete … to further that context … the flow of work from one team member(s) to another and to the customer. 

      Speaking to the discussion of work in process in this post … yes, minimize WIP, but we must have some WIP … any process must be seeded with just the right amount otherwise your "production line" comes to a standstill – AKA Standard Work In Process (SWIP).

      And here we come to a fundamental difference with "traditional" product delivery and "agile" … the key element for SWIP – time …

      The measurement of time allows us to manage our ability to meet customer demand, allows for real time measurement of improvement efforts, and allows for measuring process health.  Kanban helps with time and flow. .. Lead time, cycle time, takt time

      One purpose for the time boxes in Agile is to create SWIP (to help manage our flow), another is to create short feedback loops with the customer (mistake proofing) … thus allowing us to define just the right amount of work and deliver value just in time.  So to only start what we can finish means pulling just the right amount of work through that we are reasonably assured we can complete within that time … and that hinges on our estimates and tracking our estimates for stories.

      When I think of kanban I think of a story being pulled from the backlog (because the signal tells me something is ready for me to pull and we have capacity), having as many team members working on it as necessary in order to get it to "done done" … if you have more people than necessary for the one story, start another one.   If your team has specialties (tester, analyst, coder), then it may be a matter of breaking work down into these buckets of activity to achieve that flow…just enough analysis to start coding, just enough coding in short increments (daily build/integration) so testers are not waiting...

      Illustrating… we may determine we can complete 5 stories as a team, and as a team we are pulling one story at a time and completing it together, pulling the next story when the first is complete or when some team members are ready to do so because they can no longer contribute to the first story.  If we get close to the end of the cycle, and the story points for remaining stories tell us we do not have enough time to complete the story for this cycle that is when we ask … do we pull in another smaller story … do we schedule the review with the customer now … or do we pull in an "analysis" story preparing for the next cycle of work … or do we do something else …

      Now back to time boxes for "mistake proofing", perhaps that something else is to simply flow our work – SWIP, and hold to time boxes to get the valuable, much needed feedback from the customer at set intervals … whatever is in a "done" state we review, whatever is in process we do not review, and we examine the SWIP with the customer to manage expectations and manage flow … holding enough of these review time boxes until we reach a release point.

      To me this is one way to address no longer worrying about starting what we can't finish … we always finish what we start … we just happen to review what was done every two weeks to get feedback, manage our SWIP and review our execution process to ensure we continue to focus on building quality into the process.

      Phillip Cave
      Velocity Partners

       

       

      --- In leanagilescrum@yahoogroups.com, "Alan Shalloway" <alshall@...> wrote:
      >
      > 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).
      >
      >
      > 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.