Sometimes you just have to . . .
If you were not moved by the case for Scrum then the next step, just as suggested by our wayward Scrum Master is kanban. If re-committing to Scrum is equivalent to putting the genie back in the bottle, then adopting kanban is the equivalent to throwing the bottle away. Kanban is a flow-based framework based that originated from concepts in lean manufacturing that have been tuned for software related projects. A team or organization using kanban pulls work from a workflow (across the board) at a pace equal to the work in process limits for each step in the process. Kanban requires team members to have the discipline to observe the policies set for the team such as only pulling new work when it can be started and swarming to bottlenecks when they are identified. Efficient and effective teams using kanban are very disciplined; whether this is because of the people or the framework is debatable.
Returning to our original context that spawned this theme, a team that historically was very successful using Scrum recently was assigned a new Scrum master. The Scrum Master and the teams have run into trouble. The Scrum Master has proposed abandoning Scrum because the “team” does not get Scrum and will understand kanban. Assuming the Scrum Master now has a clearer understanding of the role, there are four relevant indicators to examine if considering kanban for a troubled team.
- Dynamic Priority Changes. Some types of work are like a water fountain (longtime friend and agile practitioner, Paul Laberge taught me this metaphor nearly 17 years ago), new requirements are constantly bubbling up in an unplanned manner. Examples of water fountain scenarios that lead to dynamic priority changes include changes resulting from help desk calls or the identification of defects and maintenance in heavily used production systems. No one who wants to stay employed is going to suggest postponing fixing a priority one defect until the next sprint. Kanban is more effective for planning and controlling the flow of work in scenarios where work has to be based on the priority at the moment and where the key demonstrable attribute is responsiveness.
- Good at Decomposing Work But Poor at Estimating and Planning. Teams that deliver value in an Erratic flow even if they are able to break work into granular stories need a mechanism to visualize the flow of work. Kanban provides a structure for visualizing the flow of work and a set of policies to develop control over the flow (policies include pulling work rather than pushing work and work-in-process limits). Visualization is the first step for teams to identify and correct constraints and bottlenecks so that a constant flow is established which improves estimating and planning.
- Continuous Process Improvement. Kanban teams continually improve the flow of work through their process by identifying and removing bottlenecks and exploiting constraints. Visualization of work flowing through the process provides kanban teams with DATA to identify potential changes and then to evaluate whether changes are effective. One of the key components of the Kanban Method described by David L Anderson is the commitment to make process changes based on data when a constraint or bottleneck is discovered. Scrum teams are less able to visualize and measure the flow of work. Kanban teams that commit to the level of discipline needed to continuously improve will flourish.
- Technical Practices Solidly In Place. Excellence in technical practices increases the flow of work through a team’s process. Technical practices like code reviews, coding standards, continuous builds, automated testing, and test-driven development are only a few of the techniques highly proficient teams embrace. Each of these technical practices has built-in controls and cadences that improve a team’s level of discipline which makes adopting a continuous flow model like kanban practical and is perceived to make time-boxed methods like Scrum chafe (we will return to his perception when we tackle the case for scrumban).
Kanban helps a team focus on flow, however, kanban is not without policies and requires discipline and commitment from the team using kanban. In the case of the wayward Scrum Master and team, if we can’t put the genie back in the bottle and recommit to Scrum then perhaps it is time to throw the bottle away, but only if we can do what is needed to make kanban work. Luckily there might be a happy compromise that gets the best of both worlds. Next the case for scrumban.