How we transformed our Scrum with Kanban (part 1)

The six Kanban principles

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

Visualising the workflow

I will talk about how we adopted each of these principles and the work we did in future posts. For now, I’ll focus on the first ‘defining and 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.

  • 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, this is 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. 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.
  • 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.

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Agile Alex

Agile Alex

10 Followers

Hello! I’m Alex, a product manager based in the UK. This is my blog about product and agile.