Skip to content

Ode to Kanban

Defining and measuring business outcomes is one of the most important challenges we need to tackle in order to sustainably generate value. Kanban holds a lot for agile software development and is worth having a look at.

Published by Juliane M. on / Product

Once upon a time...

... when I did my Product Owner certification around 10 years ago, I was immediately intrigued by the Scrum framework. This workshop was my ticket to start my career within the software industry and become, in addition to my Product Manager role, a (Scrum) Product Owner. So before I start advocating for Kanban, I would like to point out that Scrum is still a big driver behind agile transformation and it provides a number of valuable roles, methods and rituals to introduce agility to engineering teams. And of course there might be other cool agile frameworks out there, unfortunately, I have not been able to try them out yet.

The system should serve the people!

After my first 'crush' on Scrum and after becoming a real Product Owner, I found myself struggling with Scrum in different teams and topics. It works pretty well when you have 'dev-only' teams with a small share of unplanned work. But looking towards DevOps and serverless transformations, many teams need and want to include operations work in their day to day work.

After spending many hours within retros, I've found that operations work is particularly hard to mix with Scrum. Operations means that you need to react when incidents occur and you cannot wait for two weeks. Operations also doesn't care if you have a buffer or bucket for operations work or if a buffer has already been filled during the sprint. After trying very hard to make processes and tasks fitting to Scrum, I experienced Scrum as being very limited with regards to unavoidable, unplanned work. Thus I started looking for a system which matches the real-life requirements better and ended up with Kanban.

At LeanIX, the teams are able to decide on their working mode and of course there are many opinions on this. As I'm a big fan and always ready to advertise Kanban, I decided to write down my experiences for anyone who might be interested inside or outside of the company. (Disclaimer, I can only refer to software development specific Kanban and not to the original one). For those who are not familiar yet with the mechanics of Kanban, I collected some resources at the end of the article.

8 reasons why Kanban can stay

When you are switching from Scrum to Kanban, some people regard this as a downgrade or as a starting point which inevitably leads back to Scrum at some point. I agree that Kanban is a leaner way to start than Scrum with its roles and rituals, but I found a few reasons why I liked to stick with it:

Less (waste regarding unrealistic) plans

Did you ever struggle as a team to create a meaningful sprint including a valuable scope package on the one hand, and the right amount of work for different skills and roles in the team on the other hand? Are you wondering about big variations of the story point count between the sprints, leaving you with no guide to plan a reasonable amount of work? Are you frustrated because plans and goals become obsolete after day one, because more important work popped suddenly up? With Kanban, you just don't plan that much (detailed) ahead. You have your list of topics and prioritise those from the most to the least important. Who ever runs out of work, can pick the next one to work on.

Limit the 'Work in Progress' (WIP)

One central piece of Kanban is to visualize the progress of the software development process. But Kanban is much more than a board with columns, colourful sticky notes and playful tags. The key insight for me was: working on too many different things at the same time slows us down.

Kanban forces us to focus on what's currently in progress and to evaluate how the amount of items, which are in progress, impact our flow and speed. The so called Work In Progress (WIP) limit is the tool we use to limit the ongoing work per person or per team. The principle of limiting WIP does not only help within software development, but it can also be used in other situations and every day life where work starts to pile up. Once you start defining WIP limits, it is very hard to stop!

Focus on closing work

In Scrum we often have to balance the constraints of:

  • gathering an amount of work whilst not over or under committing the team
  • collecting a reasonable share of topics covering the teams stack
  • maximising the product value and customer success of course

Weighting these aspects can become a really difficult task while striving to create a sprint which supports the flow of the team. In Kanban, we focus instead on the cycle time (time from starting to closing a story) and try to finish work as fast as possible. We are aiming to improve our processes and the amount of work at a time to accelerate. As only items which are actually delivered create value to the customer, I like to focus on closing out and even release finished items.

More flexibility for the team (and the Product Owner)

As a Product Owner, my goal is to prioritise based on the importance of outcomes for the customer. But as explained above, this is not the only metric to count within a team. Sometimes, it is not possible to do certain stories simply ordered by priority, e.g., because they imply functional interdependencies or they belong to specific technology stacks or parts of a system, which are only owned by specific team members. Especially, if you have unavoidable interdependent tasks, it is very hard to forecast how those will end up in a sprint. So sometimes you end up either with missing stories in the sprint or you are stuck with a lot of blocked stories in the sprint. Of course, ideally all user stories would be fully independent, but reality often is different. In Kanban, you simply have a list, which can be clearly prioritised by the Product Owner. The engineers, who are running out of work, can pull in the next suitable task for them. This is a very important implementation of the pull principle as well.

Room for unplanned (and unplannable) work

In Kanban, we finish a task before we start the next one. If urgent incidents pop up, we can just put them to the top of list of the open to-dos. There's no sprint to break and we do not need to sort tickets back and forth. Ideally, nobody should be disrupted when completing their outstanding tasks. For tasks which require immediate attention, we have the expedite lane. If we put an item there, every team member who can contribute will help in finishing it. After the incident is solved, the team can continue with the other work.

Nevertheless, Kanban should not be used to accept unnecessary and reoccurring incidents. We of course need to analyse and mitigate the root causes of those incidents and aim overall to build a resilient system. Continuous improvement is actually a very important aspect of lean working.

Simplified collaboration with other departments and customer feedback

If you are working with different teams or departments following Scrum, the whole company is constrained by the rhythm of the sprint schedule. Sometimes it is really hard to hit a certain date for refinements or plannings, in order to prioritise cross-cutting tickets on time. (Yes, ideally we should not have cross-cutting concerns, but in reality it is often different).

As everyone is equally busy to close and plan the sprints around the same time, it is even more difficult to align with other parties. So either a ticket needs to wait for a couple of weeks or unrefined work will be pushed to the sprint when deadlines are pressing. Same goes for customers interactions. Real customer feedback on the sprint work is the most precious thing to chase after. If you have a lot of different customers, it is very hard to get a valid, aggregated feedback between closing and starting a new sprint. So that necessarily means, it can only affect the sprint after the current one, if you don't want to break the current one.

With Kanban you can have shorter feedback cycles. If your priorities change or you get important feedback, you can simply reorder the to-do list.

You don't need to give up roles and rituals

I was always wondering about the emphasis of the Scrum Product Owner. The actual Product Owner work is the same for Kanban. You listen to the customer, gather and analyse requirements. You reflect with your team, aim to build your product as valuable as possible and to learn with each iteration. Neither the product nor the customers are directly affected, if you change the collaboration mode for the team. You can even have a 'Kanban Master' or another agile coach who supports improving on WIP limits, cycle times and framework independent parts of agile software development. You can still do refinements, reviews (e.g. smaller ones on a weekly basis) and bi-weekly retros. There's no strict process which forbids this and you are much more flexible in scheduling these rituals and meetings.

Optimize the flow along the Value Stream!

With the evolution of Value Stream Management, understanding, modelling and measuring the flow of work within and above teams becomes even more important. We are striving to improve the flow for individuals and teams along the value stream and reduce friction, bottlenecks and waste on the way as much as possible. I see a strong emphasis on metrics like throughput or cycle time, which come out of the box with Kanban, as well as the visualisation of value maps.

But, how do we find closure with Kanban?

The main objection I hear regarding Kanban is, that it lacks providing the same closure as sprints in Scrum do - with a specific start, end and (hopefully) meaningful sprint goal. Still, if you are working happily with Scrum, you usually are able to fulfil your sprint goals and you don't have big overlaps between the sprints, I won't try to convince you to use Kanban! But if the potential lack of closure is the last and only objection keeping your from trying out Kanban, let me try to mitigate this concern.

The queue of tickets, stories or topics waiting for engineering teams will stay the same whether you pick Scrum or Kanban. Same goes for goals like 'Deliver feature X for beta testing', 'Create a prototype of Y' or 'Go live of Z'. With sprints in Scrum we draw artificial borders of one to four weeks and try to forecast what we need to do in order to achieve a specific goal. We assume that an assembly of stories will lead to the fulfilment of a specific business goal. It can happen in the middle of the sprint, that we find out that the planned stories are not sufficient to fulfil a certain outcome. If we are working with Scrum, it gets uncomfortable now. We might need to remove tickets from the current sprint, pull in new ones, re-estimate existing ones and there go all of our Scrum metrics.

As much as I try to embrace how contemporary software products support us planning and tracing our agile work, I wonder if it trains us to overrate tickets as such. I observed myself getting really obsessed with the sorting of tickets in the backlog and I will certainly express a certain joy whenever I keep the board tidy and close tickets (with my favourite resolution “won't do”). Sometimes I need to remind myself that those tickets only represent what is inside our technical or organisational system. So finishing tickets at first measures the output of the teams work, but it does not necessarily or directly lead to outcomes, the impact we want to achieve outside our system. And even-though it can be really difficult, I find it much more important and sustainable to get the closure from the impact, rather than by technically closing stories or sprints.

Kanban of course should not relieve us from defining business outcomes and purpose, but it allows us to be really flexible on the way there. We can delay the decision about the stories to be prioritised as much as possible and we still can find closure in achieving and measuring business outcomes.

So in a nutshell, defining and measuring (and of course celebrating achieving) business outcomes resulting from the engineering teams work is one of the most important challenges we need to tackle in order to sustainably generate value for our customers. We can map those outcomes either with a Scrum or Kanban organisation. Picking one of the two systems allows a us to find out how we can achieve those goals most efficiently, but it should not alter the goals themselves: Scrum is aiming for focus and predictability and Kanban is striving for speed and flow.

Get started with Kanban

So in case you are not happy with Scrum at the moment, I think Kanban holds a lot for agile software development and is worth having a look at. In case you would like to try it out, I have gathered some recommendations for introducing Kanban in your team:

  • Practice by playing: There are different (board) games, that help to feel the mechanics of Kanban. I strongly recommend using those to learn and feel first-hand about flow, bottlenecks and throughputs.

  • Start small: Depending on the agile maturity of the team and its common sense regarding Kanban, you might not need the full Kanban Ramp-Up. You could beginn with just removing the aspects of Scrum you don't need (e.g. the velocity). Either way, continuously improving the working mode and fit it to the teams needs is a crucial part of the process.

  • Introduce weekly goals: They don't carry the same expectations as the sprint goals, but they may help to see the bigger picture in a bunch of stories and give additional focus to the team.

  • Simplify estimations: In order to make use of the flexibility of Kanban and be able to reprioritise things, it is helpful to cut the stories really small. I found it handy to have them in a size, that they can be done within a week or less (and then you can the even ditch the Story Points or Person Days).

Resource...

... and how they're related to the article:

Image of the author

Published by Juliane M.

Visit author page