Tuesday, June 09, 2009

Kanban Tool Product Owner Cheat Sheet

So you are one of the many Kanbandwagon riders and your job is product owner prioritizing the feature list for your new Kanban management tool! Excellent! I commend your efforts. I love that there are so many new initiatives to create tooling for the growing band of Kanban adopters.

I do worry that there isn’t sufficient understanding of what it takes to make a proper Kanban tool. So far only one of the many startup initiatives have actually approached me and asked me to critique their offering or their feature set. I worry that many might be creating features already available in products like Mingle and Team Focus. So here is my product owner cheat sheet of what I consider the necessary features to make a truly compeling Kanban tool.

[Updated June 10th: Eric Willeke points out I missed a few important features]

1. Flexibility in workflow design
2. Flexibility in reporting
3. Canned reports should include cumulative flow & cycle time spectral analysis and both should allow defined start and end dates and shouldn’t be tied to releases
4. WIP Limits across steps in the workflow
5. WIP Limit over-ride with audit trail
6. Swimlane support
7. Colored card support
8. Decorate cards with icons
9. Hierarchical work item / card support with two tiered display. [Eric Willeke: Hierachy should be deeper then 2 levels] [DJA: I haven’t seen a Kanban team need more than two levels but I can envisage 3 levels a la FDD]
10. Allow swimlanes to be assigned to hierarchical support, class of service or work item type
11. Allow color to be assigned to class or service or work item type
12. Allow icon decoration to be assigned to class of service or work item type
13. Allow person cards to be stacked on work cards [Eric Willeke] [DJA: This is one I missed and should have included]
14. Support for target cycle time per class or service and status reporting on due date performance and likelihood of due date achievement - highlighting of time remaining or time expired
15. Allocation of WIP limits across swimlanes and colors of cards i.e. allocation of WIP limits across classes of service and work item types
16. WIP limits on two tiered hierarchies

Nice to have features

1. Support for SPC charts on WIP, velocity and cycle time
2. Animated replay
3. Enforced class of service pull policies i.e. system should highlight which item should be pulled next
4. Simulation - ability to predict which release a particular card will be delivered in
5. Canned report for daily-delta, showing what changed since yesterday [Eric Willeke]
6. Ability to host multiple boards, representing different teams on different projects sharing product level goals i.e. a program rolling up together with some dependent integration [Eric Willeke]
7. On-screen policy definitions, configurable by project/initiative/value-stream describing rules and classes of service [Eric Willeke]

Now I suspect this list should keep the 4 contenders we’re tracking busy for the next couple of quarters Technorati tag: David+Anderson, Agile+Management, Agile, Lean, Kanban, Software+Engineering, Project+Management

Managing WIP isnt the same as Limiting WIP: Part 2

In Part 1 of this article I talked about how the evidence from the feature sets of popular Agile project management tools makes it evident that first generation Agile methods did not provide any guidance on limiting WIP or implementing a pull system. In part 2 I’d like to look at how Agile methods manage WIP and how this relates to Lean.

Again, some folks have argued that early Agile methods implement pull systems. They point to iteration planning as evidence for this. There is an argument that suggests that a strictly prioritized product backlog is “pulled” into an iteration in a batch transfer. The batch size is based on a velocity metric. The velocity for an iteration suggests the capacity of the team.

The problem I have with this definition and why I don’t believe it represents a true pull system in the Lean sense is that the batch transfer size - some number of story points or stories - is generally based on historical data for throughput (velocity measured at the iteration boundary level) and not on a fixed quantity. Yesterday’s weather does not represent a fixed quantity. A rolling average of 3 recent iterations doesn’t represent a fixed quantity. Some estimate of ideal hours does not represent a fixed quantity.

However, it could be argued that pull systems don’t need a fixed quantity what they require is a balanced quantity.

Again, it’s hard to justify any of the Agile estimation & planning techniques against this measure. There is just too much empirical evidence that too many Agile teams miss their iteration/sprint commitments. There are too many tails of heroic efforts in the last few days of a sprint to insure the team made it. There are too many stories of product owners of business representatives negotiating over estimates and sizing. The Agile ideal that the team estimate the stories is all very well but how many teams work in a world where they get to decide this in isolation?

Then there are more fine-grained issues. How many teams actually have a properly prioritized backlog? And what happens when something new and more important comes up? Do teams truly keep that Sprint commitment and refuse to take on new work? What happens to the backlog? How many teams actually have the dysfunction of 3 sprints worth of backlog in progress because one is in analysis fleshing out the stories, while yet another is in development, while another is in system test? While this is not the prescribed way to Scrum or XP it is often a reality.

But for me the most compelling reason why first generation Agile methods are not pull systems, is quite simply that the level of granularity is the sprint and that the method of development is in essence craft without hand-offs. While I have no problem with the notion of craft development, methods such as XP said little to nothing about how requirements were fleshed out or how to handle system integration testing and other forms of (often required) validation. A true WIP system limits the quantity of customer valued work at each stage in the value-stream. In the Lean sense of pull making an attempt to manage the size of a single batch transfer does not constitute a pull system.

On the other hand, I do feel that Agile methods manage WIP and some do it better than others. Some leave the method of managing WIP as an exercise for the implementing team and this leads to variability in results. It is for example, quite reasonable that an XP team agrees that each pair of developers will work on only one story at a time. If they have a sprint backlog of 10 stories and 3 pairs then 3 stories would be in progress at a time - at least until one becomes blocked. Setting these kind of policies or guidelines is clearly managing WIP. Iteration planning and estimation using historical data for velocity and trying hard not to over-commit to an unreasonable plan is clearly managing WIP. Agile methods did focus on WIP and encourage the managing of it. This was a revolution. Traditional project management pays no attention to quantities of WIP. However, the early Agile guidance failed to recognize the value of managing WIP. No Agile methods recommended tracking the quantity of WIP as a metric. It wasn’t until 2002 that this was even suggested and many years later before it was an accepted practice in the general community.

Managing WIP is not limiting WIP. An Agile team can be managing WIP but still find itself with a lot of WIP both within sprints and across sprints. The behavior on a team doing Kanban, proactively limiting WIP, is notably different. The WIP limit causes them to “stop the line” and pursue root cause analysis and elimination. Kanban teams suffer stop/go behavior and ragged flow much more than Agile teams until the number of impediments is reduced. The WIP limit creates a reaction outside the immediate development team and has been seen to modify behavior way beyond the sphere of control of the typical Agile manager. Business groups produce better articulated, clearer, better prioritized requirements. The organization gets good at escalation and issue resolution. Flow and throughput become the focus rather than commitments and heroics. Limiting WIP creates desirable behavior across the organization and leads to accelerated high maturity, higher productivity, shorter cycle times and higher quality as a general observation.

It’s clearly a thin line between small batch tranfer push and small batch transfer pull. There are clearly some Agile teams that do have a sufficiently trusting relationship with their upstream partners and they are pulling small batches of work into iterations. However, to be using a full pull system, pull signaling should be working at the individual piece level - at the story level - within the sprint. Some Agile teams may achieve this but that’s because they evolved it through their own knowledge, learning, experience and reaction to their circumstances, not because the textbook told them to. They evolved to pull because they are good. Good teams will always be improving and trying new things.

Learning to manage WIP through the early part of this decade brought me to the understand why it was a good and useful technique. Limiting WIP throughout the lifecycle (or valuestream) starting in 2004 with the XIT team at Microsoft was the next logical step. For me it was a logical progression. Managing WIP led to limiting WIP. Limiting WIP was simpler and easier from a management perspective but much harder to achieve from an organizational maturity and collaboration perspective. I wish others could evolve to this understanding. Recognize that they learned to manage WIP and learned its value and that they now see the value in going further and limiting WIP and implementing a full pull system. What is the value in getting defensive and trying to rewrite history? Technorati tag: David+Anderson, Agile+Management, Agile, Lean, Kanban, Software+Engineering, Project+Management, Lean

Managing WIP isnt the same as Limiting WIP: Part 1

Recently, with the growth of blog and Twitter traffic about Kanban, there have been several people who’ve come forward with commentary to the effect that “we’ve been doing that all the time.” Some have left comments on this site. Some have replied on Twitter. Some have blogged.

While I have no doubt that there are teams out there who spontaneously decided that it would be a good idea to set a WIP limit and perhaps to go further and to signal the pull of new work based on completion of existing work, and that they added this concept to their existing implementations of XP or Scrum (or both), this does not mean that XP or Scrum always suggested this. They didn’t!

To determine the truth of this we only need to look at the feature sets of the popular tools for managing eXtreme Programming and Scrum such as Rally, VersionOne, ScrumWorks, Mingle and very new tools like Borland Team Focus, to discover that not a single one of these tools allows you to set an explicit WIP limit. None of them provide a pull signal to start new work. Very few of them are even capable of reporting the quantity of work-in-progress.

It is fair to say that Agile methods have encouraged the management of work-in-progress though some methods such as FDD have made this management much more explicit. Stephen Palmer will talk about encouraging the team not to start too many things and to focus on finishing work as early as 1998. However, neither he nor I made the leap to setting an explicit limit or target for WIP. As we learned more about the value of managing WIP, we introduced concepts to encourage and enable it, such as the use of Cumulative Flow Diagrams (a.k.a. Burn Up charts) first posted to the FDD web site in 2002 by me. The Agile Management book appeared in 2003 and the manuscript of an earlier draft was available in 2002 to subscribers to the Yahoo! group. During 2003, I realized that you could influence quality, cycle time, velocity and predictability of the iteration outcome by explicitly managing WIP. I started to focus the team on the WIP and the visualization of the cumultative flow diagram. It was several years later before the Agile tool vendors added Cumulative Flow to their products. What stimulated this was elements of the Scrum and XP community preferring “Burn Up” to “Burn Down.” Some had read about cumulative flow on this blog, or in the book or seen me or others present the technique at various conferences. This generated demand and the market responded.

So by 2005 many folks in the Agile community were appreciating the value of managing WIP but they still weren’t limiting WIP.

Another aspect of Agile methods we can look at is how they handle impediments or blocking issues. The early Agile literature didn’t have a lot to say on this but pointed out that impediments should be raised at a morning standup meeting, or scrum. Again the tools tell the real tale of reality. Very few Agile tools treat impediments or issues as first class work items. Earlier tools such as ScrumWorks only allowed items to be marked as blocked. They did not allow any tracking of the issue behind the block or for any escalation path to be implemented or tracked.

If there had been a real focus in the early Agile literature on blocking issues, impediment removal and their relationship to Lean flow then the tools would have implemented these features.

Meanwhile, Agile teams encountering an impediment would generally mark a story as blocked and go on to another one.

This is not the behavior you would expect on a Kanban team truly limiting WIP. Because the WIP limit will have been reached, an impediment causes idle time. The only course of action available to maintain flow is to pursue the impediment, track down its cause and resolve it. In a truly WIP limited process impediment removal is paramount.

So for those who would claim that Scrum and XP limit WIP and pull new work, such as Stephan Schmidt, I would point them to the feature sets of existing Agile tools. These tools do not impliment WIP limits, pull signalling nor are they particularly good at issue management and resolution. Recently, there are 4 new entrants to the Agile tools market. All of them producing WIP limiting Kanban tools including the same Mr. Schmidt. If earlier Agile methods had been truly WIP limited pull methods then tools from encumbent vendors would already reflect this. As a result there would be no market for new entrants such as CodeMonkeyism, AgileZen, LeanKit and RadTrack. More thoughts on managing WIP versus limiting WIP tomorrow… Technorati tag: David+Anderson, Agile+Management, Agile, Lean, Kanban, Software+Engineering, Project+Management, Lean

Kanban Blogosphere Roundup June 9th

New material on Kanban just keeps flowing. I’m seeing Kanban trending in Twitter to between 5 and 10 tweets per hour. Meanwhile, over night Nicole Kohari posted her second blog about Kanban and how she believes it helps teams form shared mental models around their work and their collaboration. I really agree with her observations. I see enhanced collaboration and higher levels of social capital amongst teams using Kanban and I believe that an underlying element enabling this must be a stronger shared mental model. If I have feedback it’s that Nicole’s article is strong on the problem statement and background but rather weak in the conclusions and observations. While she clearly believes that Kanban card walls improve the mental model shared across the team, I would like to have see some research and quantitative data that actually proves this postulation. It’s always nice to move beyond empirical evidence and get to scientific conclusions.

Stephan Schmidt has entered the race to provide a kanban application. His approach is to put the whole Kanban app in a single HTML file.

Next up, Henrik Martensson has been following the Yahoo! group thread on defining Kanban and warns that we shouldn’t stray to far away from Taiichi Ohno’s orginal definition. I largely stayed out of this discussion. By linking to Henrik’s article I am not necessarily advocating his point of view. I’m raising awareness. Similar to Kenji Hiranabe’s earlier articles on InfoQ Kanban Applied to Software Development: From Agile to Lean and the earlier one Visualizing Agile Project Using Kanban Boards, I am not convinced that we need to read too much into manufacturing implementations. Manufacturing has its own context, risk profile and domain specific nature. Software development is different. I wouldn’t expect a kanban solution for software to be the same as a kanban solution for manufacturing. Applying the same principles to two different domains should produce different results. So I continue to caution the notion that we try to analogously map from manufacturing.

Finally, Jon Stahl posted his Scrumban: Kanban & Agile presentation slides for us all to share. Technorati tag: David+Anderson, Agile+Management, Agile, Lean, Kanban, Software+Engineering, Project+Management