Share this
by Carl Weller on 13 March 2019
In my previous post Introducing Lean thinking to DevOps I showed how Lean thinking, particularly establishing a pull system through work in progress (WIP) limits, can fully align the delivery capability of your DevOps team(s) with the ability of business to accept change.
Something that was implicit in the diagram from that previous post is a "classes of service" approach to managing workflow common in mature Kanban teams. The team board is set up such that each type of work has its own WIP limit, ensuring that the work the team does is well-balanced and, in total, allows a functioning pull system. In the diagram below each class of service has been assigned a different colour ticket, but swim-lanes are just as effective.
Classes of service allow you to treat different types of work appropriately. Most teams have the following four types of work, each with its own challenges:
- Expedite or urgent work (often production incidents)
- Date-driven or fixed-date work (often project related and actively risk-managed)
- Standard work that needs to be efficiently prioritised and progressed through the system (often supported by an economic model such as cost of delay)
- Improvement or intangible work (that needs to be done in the mid-term to drive improvement).
A typical DevOps team will not just be developing and deploying change, it will be supporting the same system in operations. This introduces a variability in workflow and work type that Scrum-based Agile is less suited for.
Why? Because Scrum works by chaining small time-boxed 'containers' of scope one after the other. That is the purpose of the sprint or iteration, and it is the purpose of the rules around sprint planning and sprint review. The working model is effectively that you (as the customer) can give the team new work at the start of each iteration, but then the team must be allowed to focus on delivery. You get your next chance to set priorities at the next sprint planning meeting.
Trying to change the work of the team mid-sprint actually breaks down the control framework of Scrum and would make velocity a less useful measure.
A compromise position would be to split off a percentage of the team's available capacity for BAU and bring less work into each sprint. Easy to say in principle, hard to do in practice, especially if the demand-driven work is 'lumpy' in its arrival patterns.
In comparison, Lean does not dictate a cadence for planning and releasing. Nor does it tie planning to workflow management at all, you simply have a "replenishment meeting" whenever the input queue of new work is starting to run down. This avoids premature commitment of work and allows for dealing with different classes of service more responsively.
With a flow-based system the main concerns are that the team doesn't run out of work and that the work is of the right priority and type. This is most easily done by allowing the natural pull of work through the system to send a signal that it is time to replenish the input queue and then using economic models to set priorities. The team simply grabs the next highest priority work item from the "Next" column.
By spending less time on planning too far in advance you can spend more time on attacking the biggest productivity killer of knowledge workers – time eaten up with work sitting in queues, blocked, or waiting for approvals. Most experts put this at between 60% and 85% of the total lead time for any work item. This will be the subject of a future post.