How we transformed our Scrum with Kanban (part 3)

In the last two blog posts, I described how we transformed our Scrum with Kanban — adding in these new ways of working made our team better. We improved customer outcomes and saw lead time improvements of close to 30%. In this final part, I talk about the feedback loops and policies we put in place.

As a reminder, you can build a Kanban system around six general principles. All of them are compatible with Scrum and will even enhance it.

1. Defining and visualising the workflow
2. Limiting work-in-progress (WIP)
3. Actively managing the items in progress
4. Inspecting and adapting your workflow.
5. Having feedback loops
6. Make policies explicit.

The Kanban Guide for Scrum Teams from Scrum.org only goes as far as number four on the list above. Feedback loops are already built into the Scrum framework, so redundant as an additional core practice. Explicit policies are an extra practice we found helpful in defining our workflow and actively managing your work-in-progress.

Feedback loops

If you want to be a Scrum team that uses Kanban principles, all the Scrum events still stand, including the sprint itself. Each Scrum event is designed for a specific purpose. They give the team the chance to inspect and adapt each of the Scrum artefacts. Inspection and adaption drive greater transparency.

If you read any other books on Kanban, you’ll quickly see the feedback loops used in purely Lean systems have some similarities, depending on the event. However, in general, Scrum’s feedback loops are different to Kanban’s. If you follow the guide from Scrum.org, you won’t need to worry about this too much. We looked at some of the Kanban events to see if we wanted to move away from Scrum towards Lean ways. Working through all of this, our team decided to follow the Scrum Guide instead of adopting pure Kanban.

One interesting Kanban event is a weekly replenishment meeting. In this session, you replenish your ‘ready’ column, often with your stakeholders. Scrum doesn’t have a direct equivalent, though product backlog refinement (not itself a Scrum event) and sprint planning (an essential Scrum event) have some similarities. As a product owner (PO), I have regular refinement meetings, and these replenish our ‘ready’ column. There’s no real difference here, except for the fact I don’t have a set time each week for this work. For me, as a PO, this is ongoing work with the team and our stakeholders.

You may also read about the Kanban workflow meeting. This session involves all teams in delivering the service. The idea of a Scrum of Scrums might be the most similar, though it is used for scaling agile. There aren’t any directly matching events, as the daily Scrum is a timeboxed event for the developers in a team only.

The daily Kanban is the closest event to one from the Scrum guide. In Scrum, the idea is the developers self-manage and decide the best use of the timeboxed 15 minutes. In Kanban, the idea is that you start from the right side of the board. The final ‘done’ column is where the value is delivered. Where necessary, you pull items across the board. Finally, you look at ageing PBIs. We have adopted many of these principles from the daily Kanban into our daily Scrum. The art of self-managing ensures the team owns the time and uses it in a way that best works for them. It’s up to the team to decide if they want to use their 15 minutes to review the board, talk about impediments or use the time in another way.

The delivery planning meeting is sometimes used in Kanban, once a week, usually in place of the daily Kanban. Its purpose is to look ahead and see what needs to be delivered when. The delivery planning meeting is a bit like sprint planning, and like in Scrum, Kanban teams will use metrics to make forecasts.

Finally, the flow review is a bit like a sprint retrospective. Kanban teams will run this either once or twice a month to look at how healthy the system is. They will also review how effectively work is currently delivered and what changes are needed to improve the overall performance.

The reason for briefly outlining the Scrum and Kanban events is to show that while they are different, there are many similarities. If you choose to adopt Scrum with Kanban and follow the guide, you can evolve your Scrum events accordingly. Kanban has a way of doing things, as does Scrum. Some of these are complementary, and others aren’t. In Scrum, there are no best practices; there is only the Scrum guide. Follow the guide as it says and work out what is best for you in your particular situation.

Policies

Having clear policies helps the team when they come to define and visualise the workflow. The policies will always be unique to the team and their context. When we came to design our board, these are the policies we used:

1. Product backlog item (PBIs) types: Kanban sometimes call these ‘classes of service’. Our team has four different PBIs: fixed date item, non-fixed date item, accelerators and expedite. Accelerators are usually linked to a significant business objective or KPI and are still either fixed or non-fixed date. We use that label as the work will show up as a different colour on the board, and we’ll use the daily Scrum to call those items out specifically. Expedite items have a particular swim lane on our board, and the team will usually drop whatever they’re doing to work on that. Our current average lead time for expedite PBIs is one day. Expedites are for emergencies only, and we have a policy on what when we can use them. The team were rightly worried that any stakeholder might come along and insist their PBI should be prioritised as an expedite.
2. Workflow: these cover each of our disciplines within our development team. They focus on what a PBI is and the refinement process before it is accepted, along with a clear definition of done. For example, our UX policies include clear requirements about user goals, data we should be considering, related design principles and more. Another example around a definition of done for our developers is ensuring certain test conditions and the relevant sign-offs before going into production.
3. Visualisation policies: are linked to both points above. These are simple standards we have put in place to ensure everyone understands how our PBIs work and the relevant policies at each stage of our board. For example, each class of service is marked by a different colour. We have clear pull policies on how PBIs should move through a system and what needs to be in place before a team member pulls an item across the board. Having these policies means the right conversations happen, with a good amount of knowledge transfer.
4. WIP limits: are essential to Kanban. I spent some time in a previous blog post explaining them. Our WIP limits are displayed on our board at the top of each column. We try always try to keep our WIP limits at capacity as that encourages a healthy flow. The number turns red if the WIP limit is breached, usually serving as a talking point at the daily Scrum.

Having these policies might sound like a burden, and we had to work hard to ensure we didn’t have too many. The essential part of the process was working together as a team to define and shape them together. They have since become part of how we work together. Having them has meant better and more frequent conversations, more review points and most importantly, better outcomes for our customers. We have a more valuable product through these better ways of working.

A final note on tools

You may have noticed I haven’t talked about the tools we use to build our Kanban system. That’s deliberate.

From my experience, teams often start with the tools they have and build their systems around what is then possible. We didn’t want to do that; instead, we designed the Kanban system we needed to serve our product development. We ended up using Azure DevOps as we found it to be the most powerful tool available to us at that time. We work in a large enterprise company, and often the tools available are dictated to you by IT or another corporate function. It’s then inevitable you will need to make trade-offs based on the limitations of that particular system. By designing your system first, you will hopefully be in a position where those trade-offs are kept to a minimum. Ask yourself the following question: what is best for our product development and our team. Start there and work together to build the solution.