I’ve been re reading David J. Anderson’s excellent book on Kanban, it’s an amazing text, full of great thinking that transcends both the agile and more heavy weight process camps. I’ve created a few diagrams in order to better internalize some of the concepts in the book.
one of the key themes of David J. Anderson's book is to categorize work by risk type and then associate it with a specific class of service, allowing software delivery professionals to manage risk, flow of work, and improve predictability of work output.
The idea is that not all work should be treated the same. Implicitly I think that most teams don't treat all work the same. Work being competed to handle an emergency is handled differently from regular features, which is treated differently from capacity upgrades. Organizations will try to prioritize this work differently,and try to allocate capacity as appropriate. The problem is that for many teams and organizations, these rules of work management are implicit, not well understood, and can oftenfollow the "work for the stakeholder who screams the loudest" anti pattern.
David, in his book on on Kanban, recommends that you:
- categorize the existing demand on the software delivery organization, at a minimum given understanding of the various risk and demand profiles of your work
- determine how much demand is allocated along each work type/risk profile
- have some simple policies in place that match types of demand to specific classes of service, with each class of service having a explicit work flow policy, and WIP limits, some examples include:
- compliance related work must be completed before regulations goes into effect (fixed date)
- emergency defects must be completed ASAP, dropping other work, and overriding WIP limits if necessary (silver bullet), typically very few silver bullets are worked on at the same tim
- training, and refactoring work have the lowest priority, and can be dropped to handle fixed date or silver bullet items (intangibles)
- ordinary new features and bugs are finished in a first come research bases (regular work)
- model your system of work, otherwise knows as a value stream , determining hand off points, queues, co location of teams, and types of inventory
- Set up an input cadence where an input queue for all new work will be refreshed by the business. Likewise setup an output cadence determining the timing when all ready work will be released to production
- set target completion SLAs for each service class, for instance a silver bullet item might have a target of 5 day completion 100% of the time, a intangible might have 60 day completion date 50% of the time.
- Connect your class of service policies and work types to the value stream, letting the policies dictate how work flows through your system, don’t be afraid to experiment with class of services, wip limits, and other policies, you won’t get it right the first time!
- measure actual performance of the system, as well as demand over time. How are you doing compared to your targets? How much regulation vs emergency demand is coming through your system
adjust targets, hopefully for the better over time, but at the beginning you may need to go backwards to reflect the reality of capacity
While the above may seem daunting, in terms of overhead, and management complexity, I would ask readers considering this should take into account the amount of overhead that goes into management of software delivery using traditional methods. Also a significant amount of overhead in managing large-scale agile project when you have multiple teams trying to coordinate with each other. IMHO taking the time to model, manage and measure the system of work is much better stand of "process overhead" and can provide real insight into how could can optimize how work is being completed.
.
