This post originated from an RSS feed registered with Agile Buzz
by Mark Levison.
Original Post: Kanban Portfolio View – continued
Feed Title: Notes from a Tool User
Feed URL: http://feeds.feedburner.com/NotesFromAToolUser
Feed Description: Thoughts about photography, software development, reading, food, wine and the world around us.
(Continued from Kanban Portfolio view and the 3 core rules. This is the conclusion of Part 2 in the Scrum Alone is Not Enough series.) 2. Limit Work In Progress We know from queuing theory, psychology of multi-tasking, and empirical evidence (Rally study, my summary of the Rally Study) that more Work in Progress means less work gets done overall. This leads to the second Kanban rule: Limit Your Work in Progress. Work that hasn’t been deployed, shipped, or otherwise delivered to a customer has no real value. Value is only realized when the work is available for use by the customer. The simplest way to Limit Your Work in Progress is to just watch for a few weeks how much work exists in each column. Make this your initial WIP (Work In Progress) Limit. The idea is that we shouldn’t start new work before the existing work gets to done. Once each column has a WIP limit and the columns fill up, then we’re forced to move downstream to help get the most downstream work to truly done. In the context of the Bookstore: In the above example, both John and Sarah’s development Teams have no problem staying within their WIP limits of one. However, so much work has been done in the past week that the Online Help Team is swamped and falling behind. Improvements we make at the development Team level at this stage would just serve to build out more product that doesn’t have online help. Instead, Team members from these Teams should volunteer to take on Online Help related work as part of their Sprint Commitment until the issue is solved. If this is a persistent problem, the organization needs to consider a more systemic fix – either finding more people to create the online help, or to include the online help in the Sprint level Definition of Done. Measure and Improve The third and final core Kanban rule. Too often we focus our energy improving the productivity of the development teams even when that won’t change the amount of value delivered to the customer. A simple test: will doubling the productivity of a development team double the amount of value delivered to the customer? If not, then the development team isn’t what needs to improve first. Kanban affords us many opportunities to measure so we can know where to focus our energy to get the best improvement. The trick is to use these measurements judiciously. · Cycle Time – measures the moment the team starts work on a request until it’s delivered to production. · Lead time – measures the moment that a request comes from the customer until it’s delivered. Which to measure first? In many cases, all we control is the Cycle Time. Unfortunately, if this isn’t the major source of delay, then improving productivity here won’t make a major difference to the customer. Lead Time is what the customer really sees, as their request enters the system and emerges sometime later. The measurements (often shown via a Cumulative Flow Diagram) show us where our limited improvement energy is most likely to bear fruit. In the example above, we can see the bottleneck (online help) is downstream of our development teams. We have already determined by looking at the WIP that making a significant change in the productivity of our development teams wouldn’t make any real difference in how quickly the customer received working software. So the challenge now is identifying that and determining how to get the value to the user quickly. In many situations I encounter, there is a formal signoff before the application is deployed. In others, there is formal notification procedure to the end users. If this signoff or notification only happens once every four weeks, then the average item waits an additional two weeks after work on it is completed, while accruing no additional value. While these waits can’t be wholly eliminated, the simplest thing to do is have them happen more frequently. Instead of once every four weeks, make it weekly. This cuts the average delay from two weeks to three days. Still not perfect, but tolerable if signoffs are required. Once we’ve made our first improvement, wait for a few weeks, gather more data, and measure again. In the case of the SmallestOnlineBookStore we can also see that Ideas are taking from ten to twenty weeks to get from the proposed stage to part of the Common Product Backlog. (The picture below shows an unrealistically smooth development and deployment process.) This time it’s clear that if we doubled the productivity of the development Team, we would double the value delivered to the customer, so in this case improving the Team’s capacity will help. Warning – don’t confuse a CFD (Cumulative Flow Diagram) or other measurement with the real world. A measurement is just a hint to go find out what is really happening. In the world of Lean and Toyota, this is called a Genchi Genbutsu. Take a walk and talk to the people doing the work. Find out what is really going on. Once we understand what our basic Kanban system is telling us, it often helps to track additional information by categorizing as follows: · Production Support/High Priority Work · Work for Other Teams · Interruptions Production Support/High Priority Work A team that has a product live in the field might have to handle production support. When that happens our goal is to resolve the issue but also highlight the cost of handling additional work. In the long run the team need to reduce the defects that result in production support problems. Agile Engineering techniques (an upcoming post) will highlight approaches to solving this problem. Working for/with Other Teams When working in a multi-team environment we have to accept that some portion of each team’s time will be set aside to help their peers, even though this work won’t directly advance the features on our own Products. When we use Feature Teams we lessen […]
Previous Topic
