James Shore: Successful Software - The Diigo Meta page

• 11 May 09
  

  Gerry

  Good overview, including when to use, like for support teams.

  kanban

• 08 Apr 09
  

  juha riissanen
  • What Toyota was really trying to accomplish was "one-piece flow." One-piece flow
    means manufacturing items one at a time rather than in batches. It creates
    flexibility, improves productivity, eliminates waste, increases throughput, cuts
    time to market, reduces the impact of error, and reduces the cost of inventory.
    It's a Good Thing.
  • But the ideal is still one-piece flow: working on just one item at a time, with
    no inventory waiting
  • 5 more annotations...
  • • The challenge is to develop a learning organization that will find ways to
      reduce the number of kanban and thereby reduce and finally eliminate
      the inventory buffer... So kanban is something you strive to get
      rid of, not to be proud of.
    • That's why I prefer Arlo's approach to David Anderson's. By using the Extreme
      Programming approach of simultaneous phases, everyone on the team works on one
      MMF and gets it to done, then they work on the next. Work-in-progress inventory
      is reduced to the absolute, bare minimum: just one MMF. (Beat that, Toyota!) By
      doing this, we create flexibility, improve productivity, eliminate waste,
      increase throughput, and do all of the other wonderful things that one-piece
      flow gets you
    • The good thing about Kanban systems is that they really do a great job of
      eliminating waste. They eliminate iteration planning, they react extremely well
      to changing needs, and they work well in chaotic environments. The theory behind
      them is sound, and if you are a fan of Lean ideas, then using a Kanban system
      will seem like a no-brainer.
    • I'm also concerned that Kanban will be too advanced for teams new to Agile
      planning. One of the great things about iterations is that they're timeboxed. At
      the end of the week (or month), time's up! You're done. Many teams struggle with
      this. They have trouble getting to "done done" and the
      timebox helps them recognize and eventually fix the problem. Timeboxes also
      prevent scope creep and they also force important trade-off decisions to be
      made. Overall, they're an excellent tool for improving the team's
      self-discipline, and Kanban systems don't seem like they'll provide those
      benefits.

    • So, should your team use iterations or a Kanban system? Here's my
      criteria:

      
      
      • 
        

        If your team is new to Agile planning, use iterations. Be super-disciplined
        about getting everything "done done" each
        iteration, using slack, and achieving a
        stable velocity so you can consistently make and meet iteration commitments.
        This will force your team to learn important lessons about how Agile works.

        
        
      • 
        

        If you're producing a new product or a significant new release of an existing
        product, use iterations. Create a vision, do release
        planning, get a good product manager, and make sure he's heavily
        involved. Your goal is to create a compelling product with significant
        value, and you'll benefit from a gestalt view of the product and the predictability
        iterations provide.

        
        
      • 
        

        If you're in an environment where the feature backlog is constantly in flux
        or hard to predict, particularly if you can release the software on a whim, try
        the Kanban system. Entrepreneurial environments, maintenance of mature products,
        and recent releases are all examples of environments with unpredictable
        backlogs. The Kanban system will convert that chaos into a smooth, constant
        flow.

      
      

      And if none of these categories seem to fit, go ahead and give the Kanban
      approach a try. You'll learn something new and hopefully have fun doing it.
      There's a lot of potential here, and I don't think we've explored all of the
      options. Try it! Let us know how it works out.

• 27 Jan 09
  

  Yuval Yeret

  kanban

  • 

    • 

      Yuval Yeret on 2009-01-27

      need to understand how it can work when there are multiple small teams eating up a single backlog of a single product (e.g. modules in the product). not an ideal agile team in any case, but stuck with one.

  • he team takes a story from the backlog, develops it, and ships it as soon as it is done. Then they take the next story from the backlog, develop it, and ship that story. Work is shipped as soon as it's ready, and the team only works on one story at a time.

    
    
    

    That's the ideal, anyway. Approaches differ

  • 17 more annotations...
  • • A small backlog is good because it limits the amount of time an MMF can wait, which prevents them from getting stale.
    • David Anderson doesn't use simultaneous phases, so his MMF-equivalents have to travel through multiple stages: Engineering Ready Queue, Systems Analysis, Development, Build, Test, Release Ready, and In Production. This means that his team works on multiple MMFs at a time, which leads to a need for complex configuration management

    • The team brainstorms and tracks the tasks required to complete the current MMF only. As tasks are completed, they're removed from the board; as new tasks are discovered, they're added. When all the tasks are done, either the MMF is done or the team has forgotten something.

      
      
      

      Once the MMF is done and the on-site customers have approved it, the software is released. The MMF is taken off the queue and development starts on the next MMF.

    • There's no estimating of tasks or MMFs in this approach. Instead, you use what Arlo calls "Disney Line Planning": "Your wait from this point will be XXX days." In other words, you measure the typical time it takes to complete an MMF, from start to finish, and extrapolate to various points in the queue. Since MMFs can vary in size, this is a rough projection, not a commitment.
    • If there's an emergency, a support request, or some other urgent need, there's an empty slot on the board marked "Urgent." The team can put an MMF in that slot at any time without having to go through the regular backlog queue. The team strives to finish urgent items quickly, and they try to keep the slot empty and available at all times.
    • If the "Urgent" slot is full and another urgent item appears, it has to be added to the backlog queue
    • As with other Agile approaches, the team is expected to fix bugs before the MMF is done. If bugs are found afterwards, the fixes are scheduled with a new MMF. If a bug needs to be fixed immediately, the team uses the "Urgent" slot.
    • The good thing about Kanban systems is that they really do a great job of eliminating waste. They eliminate iteration planning, they react extremely well to changing needs, and they work well in chaotic environments.
    • ne of the great things about iterations is that they're timeboxed. At the end of the week (or month), time's up! You're done. Many teams struggle with this. They have trouble getting to "done done" and the timebox helps them recognize and eventually fix the problem. Timeboxes also prevent scope creep and they also force important trade-off decisions to be made. Overall, they're an excellent tool for improving the team's self-discipline, and Kanban systems don't seem like they'll provide those benefits.
    • In the field, I've seen Kanban work best in chaotic environments where upcoming features don't have much in common. I don't think it's a coincidence that the initial examples of Kanban come from those sorts of environments. David Anderson's team was responding to change requests. Arlo Belshee's team worked in a start-up, where frequent, entrepreneurial shifts in direction are commonplace. One team I worked with used a Kanban system to respond to post-release change requests, but plans to switch back to iterations once they start planning their next release
    • f your team is new to Agile planning, use iterations. Be super-disciplined about getting everything "done done" each iteration, using slack, and achieving a stable velocity so you can consistently make and meet iteration commitments. This will force your team to learn important lessons about how Agile works.
    • f you're producing a new product or a significant new release of an existing product, use iterations
    • If you're in an environment where the feature backlog is constantly in flux or hard to predict, particularly if you can release the software on a whim, try the Kanban system. Entrepreneurial environments, maintenance of mature products, and recent releases are all examples of environments with unpredictable backlogs. The Kanban system will convert that chaos into a smooth, constant flow
    • think four factors contribute to the number of MMFs in flight:  
       
      1- The team size (larger -> increase MMFs in flight)  
      2- The size of the MMF (smaller -> increase MMFs)  
      3- The team's ability to work on the same feature concurrently (better -> reduce MMFs)  
      4- The granularity of the design (smaller classes -> reduce MMFs)  
    • One card per pair seems way too high, and indicates to me that there's lots of room for improvement with that team's engineering practices.  
    • I work with Arlo. The idea of "everybody on one MMF" is a principle more than an iron rule. We try to work on the top MMF and, being programmers, divide it into "threads". When possible, we "swarm" the MMF. As often as not, though, we have more pairs than threads, so other tasks get pulled into the working area.
    • For me kanban is a different approach to change. I've given up asking teams to learn new behavior and to "transition" them to a new way of working via training and imposition of positional power. For me kanban is about mapping the value stream as it exists, putting a pull system constraint around it and making the workflow visually transparent and gathering data from which meaningful reports are generated.
       
• 10 Nov 08
  

  jmbeas
  • I like the idea of Kanban systems, but I'm not sure they're appropriate for everyone. This might just be unfamiliarity: I have a lot more experience with the old-fashioned iteration-based approach.
  • The good thing about Kanban systems is that they really do a great job of eliminating waste. They eliminate iteration planning, they react extremely well to changing needs, and they work well in chaotic environments.
  • 2 more annotations...
  • • I'm also concerned that Kanban will be too advanced for teams new to Agile planning. One of the great things about iterations is that they're timeboxed.
    • They have trouble getting to "done done" and the timebox helps them recognize and eventually fix the problem. Timeboxes also prevent scope creep and they also force important trade-off decisions to be made. Overall, they're an excellent tool for improving the team's self-discipline, and Kanban systems don't seem like they'll provide those benefits.
• 17 Oct 08
  

  Mark Freund

  _to_read

• 16 Oct 08
  

  Eddie Osh

  softwareengineering

Public Stiky Notes

• 
  Yuval Yeret on 2009-01-27
  need to understand how it can work when there are multiple small teams eating up a single backlog of a single product (e.g. modules in the product). not an ideal agile team in any case, but stuck with one.

Would you like to comment?

Join Diigo for a free account, or sign in if you are already a member.