It is probably safe to say that Kanban and Scrum are the two most common agile approaches that teams and organizations decide on. In the minds of most people, these are sort of competing options and you are supposed to choose one of them.
In reality, however, nothing could be further from the truth. Scrum teams can benefit greatly from certain concepts and ideas from the world of Kanban and vice versa.
Many teams and organizations already combine these two and Scrum.org has done great work on helping Scrum Teams add certain Kanban ideas to their process. We even interviewed Mr West from Scrum.org on exactly this some time ago.
But, why exactly should you provide Kanban training for your Scrum Team?
The Flow of Empiricism
The key element of Kanban is the flow or the concept of flow as such. The flow in Kanban is basically the movement of value that is present in the entire lifecycle of product development. Kanban, therefore, focuses on optimizing this flow by improving both efficiency and effectiveness of a process, thus ultimately making it more predictable.
When placed in the context of Scrum, optimizing the flow would require defining what the flow is, in the first place. The Scrum framework is based on empiricism, which defines the frequency of transparency, adaptation and inspection cycle.
Simply put, you can describe it as a cycle time during the feedback loop. So, when practices native to Kanban are implemented in the Scrum framework, they can grant a certain focus on improving the flow during the feedback loop, thus optimizing the frequency for transparency, adaptation and inspection of both the product being developed and the development process.
Defining the Workflow
The main advantage Kanban practices can provide to the Scrum teams is the ability to define the workflow. Kanban introduces four practices that help optimize the flow, which are:
- Workflow visualization.
- (WIP) Work In Progress limitation.
- Active management of the work items in progress.
- Inspection and adaption of the team's definition of the workflow.
That said, it's up to the Scrum team to define the "workflow", which can mean their unequivocal understanding of policies they use to follow the Kanban practices.
Furthermore, the scope of the definition can encompass more activities beyond the sprint itself or the Sprint Backlog. In essence, no one other than the Scrum Team should instruct them on how to define the workflow or how to define the aspects of it.
Visualizing the Workflow
Adding visualization to the workflow allows the Scrum Team to improve the overall transparency. This is where the Kanban board comes into play.
The role of the board is to encourage conversations and collaboration on various ways the workflow can be improved. With that in mind, the board's configuration should look something like this.
- Specific points which the Scrum team considers where the work began and where it ends.
- Defined work items, i.e., product backlog items alongside units of value, such as stakeholder value, process improvement value etc.
- Defined workflow states, such as moving from (left) to-do, to the (right) completed or done.
- Policies for items that move through the states of workflow, such as the definition of "done".
- Policies of WIP limitation.
Kanban practices encourage the teams to limit the work items that are in "work in progress" state as much as possible. WIP items are work that the team has started working on but haven't finished yet.
How many items should be in the WIP state at any given time is up to the Scrum team to decide. The teams decide on the limit based on their capacity. However, once the criterion is established, the teams should strictly stick to it.
But why though? Simply put, limiting WIP creates a so-called pull system. What that means is that there's always a limit to WIP items on the board and once the work items fall beneath the limit, it's a signal to pull more work that needs to be done. This helps the Scrum team improve their collaboration, communication, efficiency and self-organization.
Actively Managing the WIP items
Limiting the WIP items is good on its own but it's oftentimes not enough to optimize the workflow efficiently. Henceforth, the active management of WIP items is also necessary. That way, the teams can establish a flow management for WIP items. During the sprint, the development team can decide how to manage the WIP items. Here are a few examples.
- Pulling work items at the same rate they leave the workflow.
- Making sure that work items aren't left unattended for too long.
- Quickly responding to any blocked or queued work, in order to match the team's expected cycle time.
When talking about the expected cycle time for the Scrum team, it refers to the velocity metric. However, when Kanban and Scrum are combined, it refers to the SLE (Service Level Expectation). The Scrum team estimates how long will it take for work items to move from start to finish within their workflow. They then use this forecast to identify issues and improve in case they're falling behind their estimations.
Inspection and Adaptation of the Workflow Definition
With the help from Kanban practices, the Scrum team uses their existing Scrum practices to define the meaning of workflow. This enhances the empiricism and helps the Scrum team maximize the value they deliver. The Scrum team can, therefore, adopt the definition of workflow based on the following aspects:
- Policies for visualization - Workflow states can either change the actual workflow or address the transparency in specific areas the team wants to inspect and adapt.
- Policies for work - These policies can drastically impact the impediments. As an example, limiting WIP items or adjusting the SLEs can greatly influence the workflow.
Providing Kanban training for your Scrum team can do amazing things for the way it works. It might take some time to figure out what works for you, but that is the whole point of Scrum, Kanban and agile in general, right?