How we transformed our Scrum with Kanban (part 1)

When I look back at my agile journey, two facts were true on the first day I became a product owner (PO), which are still true now.

First, Scrum has a clear guide with key concepts which make it effective. If you ignore those concepts, you will lose out on some of the benefits. Second, even when done well, Scrum still doesn’t explicitly address or help with all the challenges a team will face.

Some practices have become folklore. By that, I mean they are established as the way of doing Scrum. A third truth I have to keep reminding myself is there is no such thing as ‘best practice’. There are good things you can do in your particular situation. Charting a course will require an empirical approach — relying on the information you have now and the sum of your experience.

Burndown charts, velocity, story points. All Scrum folklore. It’s how we do Scrum, right?

Wrong according to the Scrum Guide and even worse, bad practice, says Daniel Vacanti. A video I saw some years ago from a 2015 Lean Kanban Central Europe talk started me down a new path. ‘Story points are the greatest fraud ever perpetrated on the agile community’ claimed Vacanti. There is a better way.

The team I was a PO for was working fine, delivering good increments and a valuable product for our customers. We used velocity and burndown charts. I didn’t pay much attention. There was an attraction to Kanban ways of working, though we didn’t need them.

A few years later, I joined a new team in a very different context. Simply put, our Scrum didn’t work. We were ignoring many of the concepts in that first truth. We were doing Scrum, though it was mechanical, soulless, zombie even — to take a phrase from our Dutch Liberator friends.

The other big issue was the nature of the team. Our work came from internal stakeholders on a demand basis. As an operational team, our work was often unpredictable and changeable. We would start a sprint and then over time start to unpick the sprint backlog as new, more urgent items came in. One time, within two hours of starting a sprint, I had to bring in two new urgent items. Knocked off course almost immediately, it hindered us from achieving what we had set out to do. As a PO, I was spending my time shuffling tickets in and out of the sprint.

We also had good ambitions as a team to achieve better outcomes for our customers. Working with other Scrum teams, in a complex environment, we knew increments could be valuable. As individuals, every member was brilliant. All were dedicated and specialists at what they did. All kept a focus on the customer.

We fixed the problems where we could and started following the Scrum Guide. Things still weren’t working. We were slow to respond, suffering from the same issues still. Our Scrum was holding us back. That talk by Vacanti I had heard those years ago suddenly came back into my mind.

After reading and looking into Lean principles and specifically Kanban, I realised I had bought into another lie. It’s Scrum or Kanban like they were incompatible with each other. My great ‘ah-ha’ moment then came: they complement each other: peanut butter and jam, fish and chips, Scrum and Kanban.

Start with what you’re doing now?

One thing you often hear is that you start with what you’re doing now and incrementally improve. The Japanese word kaizen is used in this context — it means change for the better as a gradual process. The idea is that you take what you do now and evolve, step by step.

That may work in some contexts, I didn’t in mine. I wanted to build a workflow quickly, which would focus the team to deliver customer value at pace. If I had started with where we were, that would have been wasteful as we would have needed to change things again soon after. Instead, we reimagined our processes and system together as a team. The end result was quite different than what we had before.

And Kanban in the context of Scrum is defined in the Kanban Guide for Scrum Teams as ‘a strategy for optimising the flow of stakeholder value through a process that uses a visual, work-in-progress limited pull system.’ Visual I understood — we had a Scrum board, which we updated each day. But ‘work in progress’ and a ‘pull system’? We continued that learning journey together.

The three Kanban practices

To ‘do’ Kanban, you have to follow three practices. All of them are compatible with Scrum and will even enhance it. These core practices, in one form or another, are generally recognised as a minimum requirement.

1. Defining and visualising the workflow
2. Actively managing work in progress
3. Inspecting and adapting (improving) your workflow

Visualising the workflow

The first thing to say is that a board is only part of a Kanban system. Just having a Kanban board in itself is not enough. It is a good starting point on your journey, though, as it gives the team something tangible to focus on.

Defining your workflow is the first part. Here are the steps we took, which you can follow:

• Working with the whole team, designing the board meant they were bought in from the start. The team felt like they understood and owned the journey. There’s nothing worse than change being forced on you or feeling like management is cooking up something in a closed room
• Then define your columns around the state each item is when it lands in that column. The most straightforward boards go with a planned/ready/doing/done or similar column definition.
• Build a queue for unrefined items. If you’re a PO (and using Scrum), this could your product backlog.
• When something is refined and want to bring it into your sprint or workflow, your ‘Ready’ column is the commitment point. I’ll talk about metrics in a future post, though this is when the clock starts ticking for cycle time.
• We used a buffer column after something had been worked on, which wasn’t then ready to go live. We called this ‘Team review’ as it was a chance for the team to come back together to inspect and adapt the item if needed.
• It’s important to remember that Kanban is a pull system. Tickets only go one way, according to your exit policies. In your daily scrum, read the board from right to left. As a PO, I care about driving the maximum value. I can only test if value is delivered when the card is done and we ship something. As a scrum master, if cards are going backwards secretly on the board, you lose visibility and can’t track what is going on.
• The best daily scrums were those focused on items that were aging. We used an aging chart as the focus.
• Working this way helps you to understand what is going on. If tickets are going backwards because of defects, you have a quality issue somewhere in the system. If you’re missing features, that’s a refinement issue somewhere upstream.
• We tracked cycle time as a key metric. Cycle time in our context was a time stamp in days of when something exited our system (done) minus when something entered our system, plus 1 day.

Defining and visualising your workflow gives the whole team visibility on what is going on. Where there is an issue, we have more transparency on how to fix it.

The STATIK method

A powerful tool you can use is the Systems Thinking Approach To Introducing Kanban (STATIK) method. This method comes out of the systems design thinking and helps frame what you’re trying to achieve and why. It gives you a series of questions to start with a new team. It helps to visualise what is true and not and to get going quickly.

Specifically, it will help you to:

1. Understand what’s not working now
2. Analyse the sources and nature of demand
3. Analyse your current delivery capability
4. Model the service delivery workflow
5. Identify and define classes of service
6. Then design your new system.

Working together as a team, answered these questions and found solutions for our context. After several iterations (and many more since), we came up with a basic proof of concept. Here’s a screenshot of our Mural board from that early session.

Our journey was just starting. We tried our new ways of working for six weeks, over three sprints. Early on, the results were astonishing. The team communicated more, the quality of work went up and we fixed problems quickly, as they were emerging. Our cycle time went down by 25%. Our internal stakeholders were happier, as were the teams. We were delivering better outcomes for our customers. Adopting Scrum with Kanban transformed our team.