Me: I’ve fallen in love with Kanban again.
My friend: Um, yeah… Who is Kanban, again?
From David Anderson, the founder of the Kanban movement: “with Kanban we’re using visualization, a working progress limit (WIP), and a quantitative measurement to stimulate Kaizen (Japanese for “improvements.”)
Me: In Kanban, we show all of the work in the system on one board, control how much we work on at any one time, and use data to improve the flow of the work through the system.
My friend: And they pay you to do this?
Me:
When I was first introduced to Kanban in 2009, it was this funny sounding thing, (which I didn’t really know how to pronounce) and while I understood the whole “controlling WIP” concept, I have to admit, I felt like it was just lazy Scrum. But, as I get to know Kanban more, I’m realizing all I didn’t know.
IT’S NOT LAZY SCRUM
Kanban is not an agile development framework, even though we often see it compared to Scrum. Particularly in the technology arena, there is the pervasive aura of high performing, cross-functional teams solving complex problems. We release small features, we rinse and repeat. Scrum, extreme programming (XP) and a variety of other development practices have taken hold where quality, rapid iteration, and collaboration are the organizational focus. However, Kanban’s principles are based in Lean thinking which is much broader than the typical agile frameworks. And Kanban works in any domain, not just software development.
Kanban is not a Project Management method. On the other end of the delivery food chain, there is a bunch of energy and goodwill and agile intent in the PMO world, embracing small iterations while focusing on economic returns, risk management and governance. Lean concepts, including Kanban, care about all those elements. However, Kanban doesn’t require start dates and end dates. In fact, it might shine best in a non-project world, where the focus is to deliver the item with the highest value as soon as it can be completed.
Kanban is not Lazy Scrum. It’s not Covert Scrum. It’s not Scrum-But. It doesn’t get rid of planning, or commitment, or feedback loops. It has all of those ingredients, but delivered through an explicit set of policies that are unique for each team. These policies are guardrails, not rules or gates, that provide boundaries to help each team deliver what they are working on while managing shifting priorities.
KANBAN AS A CHANGE MANAGEMENT TOOL
If it’s not a development framework, and it’s not a PM Method… How to describe it? How to teach it? How to coach it? To answer my curiosity, I dove into the background, reading books and listening to interviews with David Anderson, the founder of the Kanban model. In an interview with InfoQ, I heard him describe Kanban as a “change management tool.”
Julia Wester, at everydayKanban highlights that the first three principles of Kanban were chosen specifically by Anderson to avoid emotional resistance to change. (Read Wester’s article for a solid Kanban 101.) 1. Start with what you do now. 2. Agree to pursue incremental, evolutionary change. 3. Respect the current process, roles, responsibilities and titles. The fourth principle is worth noting here too: 4. Encourage acts of leadership at all levels.
This caused me to pause. I have some experience and training with change management, so I had to stop and evaluate this statement. Sometimes really smart people, smarter than I am, apply a description or a purpose to their framework or ideal that I can’t really support because it just doesn’t work as designed in practice. But, after I thought this one out, I believe it describes what I have experienced by implementing Kanban.
There is lower resistance from teams because it’s simple to start and it gives them autonomy to keep doing what is working while they make their own evolutionary improvements.
There is lower resistance from managers because it doesn’t change anyone’s roles. It doesn’t require new head count. There’s no fear. In fact, many of them tell me that practicing Kanban makes them better managers because they can make better decisions.
There’s lower resistance from business partners because it allows for very fluid prioritization of emerging needs – even if it’s daily. The visualization of all the work on the Kanban board makes the impact of expedited items and any re-prioritization transparent to everyone.
There’s lower resistance from leadership because it helps deliver valuable stuff, fast, to demanding customers.
KANBAN’S KEY DIFFERENTIATOR – SAYING “NOT YET”
The principles practiced in Kanban require a combination of it’s values as well as a high level of discipline. The most well-known principle may be the visualization of the work, the Kanban board, that is also used in Scrum. However, the key differentiator, in my opinion, is the principle of controlling the work in progress (commonly called WIP limits.)
From David Anderson to us: “you are not allowed to start other things if you’ve already filled up the system to the limit that’s been agreed.”
This single practice, in my experience, can take several weeks, or longer, to establish. Being diligent about finishing the work in progress before new work is started requires the Kanban values to be integrated into the team’s culture. The principle of controlling WIP is founded in the Kanban values of balance, flow, collaboration, and transparency. It requires leaders to reflect through their language and behavior that they support their teams who understand the goal of customer focus to such an extent they are willing to say ‘not yet.’ This is respect in action; to come to an agreement as individuals and as an organization; to move forward toward common goals.
Any culture shift – changing how a team or an organization fundamentally works – takes time, encouragement, and reinforcement. Be patient and celebrate any small win along the journey.
THE MVP OF KANBAN – 3 IMPORTANT EVENTS
Anderson describes seven different opportunities to build in feedback in a typical organization. He describes a monthly operations review, for example, and the Kanban meeting as another. (You can read more about the review opportunities in his books and other material, which I highly recommend.) There are three baseline meetings that I believe are the MVP (most valuable parts) of Kanban. In practice, perhaps because of my agile experience, I compare these to Scrum events, with some differences.
The daily Kanban. Just like a Daily Scrum, this serves to plan the day. Instead of the team answering the three questions encouraged for a Daily Scrum, the team should use this time to share the information that is important to them to solve the problems they are facing that day. In practice, these generally focus on bottlenecks and dependencies. And, similar to the Daily Scrum, there are a lot of problem solving conversations that happen directly after. A Kanban team is often larger than a Scrum team, but I still limit it to 15 minutes, (a best practice borrowed from Scrum) and I encourage standing up (a practice borrowed from XP.)
The replenishment meeting starts very similar to Sprint Planning. We talk about the work coming up and we break it up into manageable chunks so it will flow through the system. It’s just good planning. First, every team craves knowing the big picture. In addition, we get the best buy-in when the people who do the work, plan the work. But instead of planning all the work that can be completed within a strict time table, the team focuses just on the work that is coming up next. They may break a large item down, but they don’t task out work to a detailed granularity because they don’t need to. Rather than committing to a timeframe, the team commits to always completing the most valuable thing before they take on new work.
Kanban works well with teams with short planning horizons and shifting priorities. There is no need to wait until the next sprint, as in Scrum, to add something to a Kanban team’s backlog – they can re-prioritize any unstarted work as much as they need to.
Then there is that other funny Japanese word associated with Kanban, that means improvement: Kaizen. If the team is not taking the time with a Kaizen event to create experiments and use them to improve their process, they are not doing Kanban. Does this description seem similar to the retrospective in Scrum? (I think so.) It’s a simple formula to scale: The more dependencies, the more collaboration is required. Therefore, the more opportunities for reviews, feedback and improvements.
KANBAN IS ALL ABOUT BALANCE IN A MODERN AGILE WORLD
In my coaching network, we are expanding our agile mindset into the myriad of domains that are using Modern Agile principles: make people awesome; make safety a pre-requisite; deliver value continuously; and experiment and learn rapidly. Modern Agile doesn’t prescribe to any framework, but Kanban is a great aid to implement the principles of Modern Agile. I’ve been introducing the combination of these two concepts to Executive leadership, PMOs, Marketing and Sales, DevOps, and Business Intelligence teams – and it’s working.
Kanban provides a balance for non-software teams and organizations who are embracing Modern Agile principles, but feel that following a proven model for delivery can help provide safety – and still stimulate change and deliver awesomeness.
STOP STARTING, START FINISHING
I hope you will consider Kanban, for the right reasons, as the valuable tool that it is to manage change and deliver value. What do you think? I’d love to get your thoughts on Anderson’s question: “Could Kanban help make a difference to the performance of the business you are in?”
~Julee Everett
Hone your craft; speak your truth; show your thanks
