One of the hot topics in the corridors at the recently concluded Agile 2007 conference was the inevitable question, what’s next? That is, what lies beyond the basic adoption of Scrum and XP practices? The discussion around post-Agile came to my attention at the conference, but seems to have been going on for some months. The market share for agile methods is largely dominated by Scrum and eXtreme Programming (XP). Scrum is aided in its spread by enthusiasm for Scrum training and the Certified ScrumMaster certification. Developers have long enthused about XP. But, once organizations have adopted Scrum or teams have adopted XP, what’s next in their continuous improvement progression?
For quite some time, along with the Poppendiecks and others in the Agile community, Arlen Bankston and I have been advocating for applying Lean principles to Agile methods, especially at the program and enterprise level. We have had great success in scaling Agile methods by doing so. Now, with more organizations adopting Agile, and with the growing body of Agile experts in the industry, this push seems to be reaching critical mass. One indication — there were multiple sessions at Agile 2007 devoted to this topic. Okay, sounds good in general, but how about some specifics?
Earlier this month, I had the privilege of spending some time with David Anderson and Rick Garber of Corbis, learning about the system they have implemented, a Kanban System for Sustaining Engineering (KSEE). This Kanban implementation utilized a floating pool of resources, delivered a release every two weeks, against a service level agreement of 28 days lead time, and demonstrated 10% resource utilization. A couple of the unique techniques that I saw there that could be the next step for XP and Scrum teams looking to improve are:
- Input-Output Decoupling. Corbis’ KSSE decouples lead time for delivery from the iterative delivery cadence. Put simply, this means that not every user story or task that goes into a Sprint is scheduled to be delivered at the end of that Sprint. On Scrum teams, the Product Owner prioritizes user stories in the Sprint Backlog and the delivery team commits to delivering the story at the end of the Sprint. But what if the story is very large and cannot be implemented within the Sprint cycle? Conventional Agile wisdom says that it will be re-prioritized by the Product Owner for the next Sprint and will be delivered then. But some complex tasks stubbornly show up in Sprint planning meetings over and over again. The KSEE does not treat these tasks as anomalies. Rather it acknowledges that some very complex tasks might span Sprints and simply allows them to flow through the delivery pipeline.
- Kanban limits. The kanban limit is an empirical way to impose a cap on Work-in-Process (WIP). Limiting WIP is a key Lean technique used to reduce or eliminate waste. Instead on building up large queues of work waiting to worked on, work in each stage of the delivery pipeline is limited to a number of items. This number is evolved empirically, based on the capacity of the delivery team(s). The kanban limit for the KSSE’s system is 20 cards, divided into different stages in the process – systems analysis, development, test, build/merge, deployment. In addition, they allow for 3 extra bugs to be anywhere in the system. This separate kanban limit of 3 bugs allows them to burn down the bug backlog using slack resources.
In sum, Corbis’ KSSE system applies Lean principles to manage WIP in a structured way, and it accommodates large, complex tasks by decoupling them from the iterative delivery cadence. A word of warning — the latter needs to be applied very, very selectively so that teams don’t use it as an excuse to backslide into scope-based delivery.
Organizations looking to leverage their investment in Agile methods should also consider the work we’ve done with Lean-Agile Program Management Offices (PMOs). We applied Lean principles to the PMO and evolved a set of practices for organizations to effectively manage portfolios of multiple agile and non-agile projects.
