Kanban, the alternative path to agility
How to help your teams become service-delivery-oriented
“Kanban is not the solution to all problems if the organisation is not open to change. Without openness, no framework or method will help you reach business agility.”
As an Agilist, people often approach me for advice about Kanban. They want to know how “to enter Kanban mode”. However, there is no Kanban “mode”, but rather a “Kanban method”. Kanban is a very useful agile concept that can help teams become more service-delivery-oriented. But sometimes, those who want to start using Kanban just want to stop doing sprints. They think that Kanban is simply “removing” the Scrum ties and working ad hoc.
However, when a team removes those rituals without knowing the Kanban method, the service or product they’re developing tends to lose quality. In turn, this will probably delay the deliveries due to the lack of predictability. In the future, they will say something like “Kanban does not work for us” or the most common one: “Kanban is only good for maintenance, not for new products”.
In this article, I’ll explain the Kanban method and share how we’re using it at tb.lx to lead our teams towards the famous Business Agility.
First, let’s look at the word “kanban”.
I bet many of us have used the term “kanban board” before, right? With this, we mean the visualisation tool to provide transparency on what’s going on. However, one of the older uses of the word “kanban” dates back to the Japanese manufacturing system used at Toyota: “Just in time” (JIT). This is an example of a kanban system that controls its deliverables by only pulling more work when there is capacity.
And what about the Kanban method? What is it?
With a capitalised K, Kanban is a working method that helps us improve our processes and our business by using an evolutionary change approach. As explained above, the word kanban (not capitalised) has been used by Toyota since the 60’s. David Anderson introduced the Kanban method about his work at Microsoft, and then documented in his book `Kanban: Successful Evolutionary Change for Your Technology Business` also known as `The Kanban blue book` — more info at https://kanbanbooks.com/.
The Kanban method provides us with best practices and principles to help us reach the so dreamed agility. One important thing to point is that, as a method, Kanban is not prescriptive. That means that we are not forced to use the entire set of tools; we must understand our context and apply what better fits our situation.
What are the principles of Kanban?
First, we have the ones that help us with Organisational Change:
- Start with what you do now: respect the current process and roles. This means no revolutions! No big changes! We will not arrive Monday morning and tell everyone they have to do several plannings and that we changed their roles to fit a new framework. We need to analyse and map our situation to decide the best approach. People tend to resist change if it is too drastic or if it is not properly explained. Therefore, people should understand and engage with the transition to evolve.
PRO-TIP: When I started at tb.lx, I took a couple of weeks to watch the environment, understand the challenges and how people were working. Then I began to propose smooth changes that would help us work with the best practices Kanban. Things like defining Work in Process limit or starting to look at metrics.- Agree to have an evolutionary approach: as said earlier, no big revolutions! An evolutionary approach will help us have a smoother transition and let us know which changes led to improvements and which ones didn’t. Moreover, we can use the learnings to propose new ideas.
PRO-TIP: A good example from tb.lx is that while some teams started using Kanban right away, others preferred to do the famous ScrumBan approach as documented by Corey Ladas, which refers to a smooth transition from Scrum to Kanban.- Encourage leadership acts at all levels: People should feel empowered to propose changes and lead the improvements, like removing ineffective meetings, for instance.
PRO-TIP: At tb.lx, we take this very seriously and encourage people always to challenge the decisions they don’t believe in. For example, we have teams that decided to change the retrospective cadence, having it every three weeks instead of the traditional every two weeks. We have teams that decided to stop making story points (a metric used in agile project management and development to estimate the difficulty of implementing a given user story), while others prefer to keep them.The Kanban Method tackles the complexity of modern workplaces by looking at organizations as a set of interdependent services, managed and organized in a service-oriented approach.
Essentially, Kanban aims to improve service delivery by following these principles:
- Understand and focus on customer needs and expectations: we are not simply writing code; we are building a solution that real people will use to solve real problems. So, we need to understand our customers’ and users’ concerns to provide the best solutions. How else could we know if we’re developing the best customer experience?
PRO-TIP: At tb.lx, we are doing that by visiting the truck production lines to understand the assembling, visiting logistics deposits with chargers for their fleets, or inviting our customers and fleet managers to explain their pain points to us.- Manage the work, not the people: Don’t micromanage; don’t control how people organize their time and daily activities. Manage the flow and the work, understand what needs to be done, and focus on that. You must believe that everyone is doing their best to build great products and services.
PRO-TIP: At tb.lx, we have teams that slice their work in small pieces to visualize it better, and yet we (the PO’s and I) aren’t concerned about that. We always look at the work item level (tasks or user stories, on Jira, for example). If someone needs to create a sub-task, we trust that this is how they manage their work.- Review policies to improve deliveries: Kanban is a service delivery approach, so all decisions must lead us to delivery. As Klaus Leopold says in his book `Rethinking Agile: why agile teams have nothing to do with Business Agility`: “Working costs money, delivering makes money”. If our approach is not leading us to improve our customer experience or delivery, we must review it.
What are Kanban’s Best Practices?
Keeping the principles in mind, we can start looking at the practices that will lead us to improvements:
- Visualize the workflow: the workflow should reflect every step needed to deliver something. It helps us understand our pace and look for bottlenecks that may affect our delivery. It also can be used to avoid overworking people. Below you can see an example of the downstream (development phase) from one of our teams:
- Limit the work in progress (or process): all kinds of systems that get overloaded tend to get stuck. Take a look at a road: if you’re using 100% of its capacity, you’ll have a traffic jam. If you use 100% of your computer memory or CPU, it will freeze. This applies to people too: If we work too much for an extended period, we’ll probably burn out. By limiting the work in process, we create a smoother flow that will help us keep delivering value consistently at a healthy pace. For example, we can use Little’s Law applied to software: When we look at the formula, we see that Lead Time and WIP (Work in Progress) are proportional. This means that if we increase the amount of work on our flow, the lead time will increase, meaning that we’ll take longer to deliver something. And since they’re inversely proportional to throughput (the number of work items we’re delivering by cadence — per week, for example), as a consequence, we’ll deliver fewer items.
- Manage and measure the flow: this is one of the key ways to succeed in any Kanban adoption. We need to collect information from the flow to understand how a team is working and how we can improve it. Below is an example from one of our teams: We started to watch our weekly throughput, i.e, the number of items we’re delivering each week, to check how predictable we are. We keep in mind that we shouldn’t be afraid of spikes; the only problem is not knowing how to explain those outliers — for example, a delivery rate higher or smaller than the usual. Fluctuations are common when someone is on vacation, when there is a public holiday, or when someone new enters the team, since we have to onboard the person, do pair programming to show the architecture, and help the ramp-up.
By analysing the example above, we can check the team’s predictability, despite the fluctuations on the sample (some weeks only one item was delivered and others nine). We can assume that the team has a healthy flow. Why? Let’s look at some statistics:
The median of the delivery was 4.5, and the average was 4.04. Both the percentile 85% and 75% are 5 (85% or 75% of the sample are below that value). Too many numbers, right? Well, these numbers tell us the team is consistently delivering around 4 to 5 items per week, helping us understand if we’re predictable on our delivery rate. This makes it easier to align expectations with our customers and also to manage dependencies with other teams.
- Make process policies explicit: You are familiar with the definition of Ready and the definition of Done, right? Those are explicit policies, as they represent our way of working. Everyone on the team must understand what “Done” means, for example.
- Improve collaboratively and evolve experimentally: as explained before, we empower people and ask them to collaborate and improve the company at all levels. As humans, we are curious, and we like to try new things or check if some technology will help us. So, experimenting with new ways of doing things is in our veins.
- Implement feedback loops: we should always analyse the way we work and search for improvements. Retrospectives and Delivery Reviews are good examples of moments to ask for feedback. They help us evaluate our way of working (process) and what we deliver (product) to improve.
Cadences and team events in Kanban
- Delivery Planning: a common misunderstanding is that “Kanban has no plannings”. This is not true. The main difference between Kanban and Scrum, for instance, is that while in Scrum we usually plan a two-week sprint by work items (user stories), in Kanban we plan the Service Delivery: what we will deliver to the customer in a business perspective, and then all the work that we’ll do to reach that business goal. Planning in Kanban is per delivery cadence, such as a release, for instance.
- Replenishment: this is the moment when we feed the flow. It usually isn’t scheduled and happens when we see that the system has more capacity to pull work — remember the Japanese pull system mentioned above? During the replenishment, the teams commit to new deliverables. If we want to draw a parallel, it could roughly relate to the sprint planning.
- Kanban Meeting (or daily meeting): this is how we align daily and check updates of what’s going on. The main difference here is that instead of asking what people did or will do, we focus on the work — remember: manage the work, let people be self-organised.
PRO-TIP: What we do at tb.lx is open our boards and go through the cards asking “What need to be done for this item to be delivered?”. By doing that, people will not feel forced just to report “I’m working”.- Service delivery review: it’s how we review what was delivered and check the metrics to see how predictable we are.
PRO-TIP: At tb.lx, we usually do an internal one to check how things are going and evaluate the business. When we have something with a “Wow!” factor for our customers, we schedule a service demo to show them the cool stuff we built.Last but not least, classes of service and prioritisation
Classes of service are an excellent way to help us prioritise our work. This approach allows us to think in terms of Cost of Delay, i.e what is the opportunity cost that we’re losing by not having this use case in production? At tb.lx, we use the approach presented by Don Reinertsen in his book `Principles of Product Development Flow`, with the following classes of service:
- Expedite: the biggest priority! Everything that may block our work or will affect our customers in the near future. These issues should be solved ASAP and appear at the top of our workflow to quickly visualize and solve them. On Jira, we set priorities as Blockers and create swim lanes based on queries to slice our work by classes of service.
- Fixed Date: some deliverables are firmly attached to dates. For instance, when launching a new electric truck, we have to provide a set of services that will help the driver have more knowledge of the vehicle. The trucks have well-defined delivery dates, so the related services must also follow those dates. We like to visualize it on the board, so the entire team will understand the urgency level of what we’re building and organize accordingly. On the example below, we can see that we have two more Fixed Dates of delivery besides the Expedite.
- Standard: this is the daily work, or even the work items on the backlog that are also important but don’t have a hard deadline or block others. We can treat those items with the FIFO (First In First Out) approach, delivering them in the same order as they arrived in the backlog.
- Intangible: here, we’ll find all the issues that seemed to be a great idea but were never prioritised and thus live on the bottom of the backlog. Intangible items usually don’t have a clear value defined and probably will never be done.
Lessons learned
From my experience working with Kanban and my work at tb.lx, I have some valuable learnings to share:
· Don’t force it — Some teams prefer to work with Kanban, others with Scrum. Some people like to use story points, and others don’t;
· Respect each team’s timing. It’s not a race: at this moment, we have several teams using Kanban, others ScrumBan, and others Scrum. And that is ok. All teams will eventually adopt the improvements when needed;
· Don’t do things just because they’re trending;
· Avoid the “task delivery” mindset and focus on the “service delivery” behaviour. We’re not building “Jira cards”; we’re creating high-quality services that will make our customers’ lives better and transportation more sustainable.
Final notes
Kanban is a method that will help us improve the way we work if we want to! It’s not an exclusive approach that will leave Scrum or Waterfall to the side. All the good practices presented can — and should — be used in any method or framework you may be using.
And nowadays, the big trend seems to be “scaling” agile. So, how can Kanban help that? Simple: The way to scale Kanban is by doing more Kanban, using the practices presented here, and some help from the literature.
If you’re curious, I highly recommend you look at Klaus Leopold’s work `Rethinking Agile: why agile teams have nothing to do with Business Agility and take a look at the Flight Levels architecture, which we will cover in a future article.
Do reach out if you have any reading recommendations, comments, or questions!
_______________
Sources:
David Anderson, Kanban: Successful Evolutionary Change for Your Technology Business
Don Reinertsen, Principles of Product Development Flow
Klaus Leopold, Rethinking Agile: why agile teams have nothing to do with Business Agility
Corey Ladas, Scrumban: Essays on Kanban Systems for Lean Software Development
