The three rules (in my head)
Kanban used for software development has in my mind been built on the three rules below.
- Visualize the workflow
- Limit Work In Progress (WIP)
- Measure the lead time
And depending on the situation the team exists in, the rules can be narrowed down even more. Like, if the predictability isn't a big concern, the rule about measuring lead time can be left out.
And also, if team members are conscientious enough about not starting too much new work before finishing already initiated work, the WIP limits don't seem to add much.
In that case, the only thing needed is to visualize your workflow. But if you don't do that either, then I find it hard to get anything out of Kanban.
So, that's the reason that one day when it became obvious that the tasks on my team's Kanban board was out of sync with reality, I told the developers:
- "If we don't keep the Kanban board in sync with reality, we follow none of the three rules only of Kanban!"
One of them responded teasingly:
- "Well, what do you expect from a bunch of we'll-do-as-we-pleases?"
(The word used was "rättshaverister", but I can't translate that into a word that describes what I think the person meant).
There was no further discussion and the board was adjusted after a while. But having referred to rules brought up from my memory, I also remembered that when reading about them a few years ago I hadn't got a good grip on where they come from, what their original source is. So, before banging them in anyone's head again, it was time for a bit of research :)
The closest source: Kanban and Scrum, making the most of both
So I began with trying to find more info there. There they were, with a short explanation for each rule. But I lost the word "rules", because the only thing the book says about them is "Kanban in a nutshell" and then lists the three points. Not a word about "rule".
Next up: Crisp's homepage
Both Henrik Kniberg and Mattias Skarin works at Crisp, so I took a look at Crisp's homepage. And yes, the same points are mentioned there, with just a touch of more context:
"There are many flavors, but the core of Kanban means:"
Ok, so there are different flavors?! Like "Standards are good, everyone should have their own."?
At Toyota, Kanban is the term used for the visual & physical signaling system that ties together the whole Lean Production system. Most agile methods such as Scrum and XP are already well aligned with lean principles. In 2004, however, David Anderson pioneered a more direct implementation of Lean Thinking and Theory of Constraints to software development. Under the guidance of experts such as Don Reinertsen, this evolved into what David called a ”Kanban system for software development”, and which most people now simply refer to as ”Kanban”.Wow, a pioneer, David Anderson seemed as a promising track to research further!
David Anderson, a pioneer
Crisp's homepage linked to the book Kanban: Successful Evolutionary Change for Your Technology Business by David Anderson.
"If there is any book that will bring clarity to this, it will be this one!", I thought.
What I found was:
Kanban uses five core properties to create an emergent set of Lean behaviors in organizations. These properties have been present in every succesful implementation, including the one at Microsoft described in chapter 4.The five properties are:
- Visualize Workflow
- Limit Work-in-Progress
- Measure and Manage Flow
- Make Process Policies Explicit
- Use Models to Recognize Improvement Opportunities
Ok... so "Properties", not "Rules".
But five instead of three? The first three properties maps well to the ones mentioned before, but what do the two extra mean and why did Henrik and Mattias drop them?
What the two "new" Kanban properties means
Make process policies explicit
This can be done by agreeing on and writing down the "Defintion of Done" policies you use between the different stages in your process. and perhaps putting them up on your board for good visibility.
Use models to recognize improvement opportunities
Your process can probably be improved by reducing "waste" or finding and act on bottlenecks. There are models for doing that, as David says:
Common models in use with Kanban includes the Theory of Constraints, Systems Thinking, an understanding of variability through the teachings of W. Edwards Deming, and the concept of muda (waste) from the Toyota Production System. The models used with Kanban are continually evolving, and ideas from other fields, such as sociology, psychology, and risk management are appearing in some implementations.
Why were they dropped?
David's book predates Henrik's, why has the number of properties gone from five to three? I asked that question on Crisp's Facebook page. None of the original authors answered me, but another author did, he pointed me to the next book, Kanban in action.
Others have been pondering this too in Kanban in Action
messier! But also revealed interesting info.
There is a section titled
Three principles? I thought it was five properties. Or was it six practices?
which indicates that others have had a hard time finding their way to getting clarity about this. That section contains the text below.
The three basic principles we describe in this section make up the foundation that kanban is based on. Recently, David J. Anderson and others have extended the three basic principles to five properties and later six practices; these are now referred to as the core practices.
Anyway, this info and Google led me to David Anderson's latest defintion, called Principles and General Practices of Kanban.
A blog post about Principles and General Practices of Kanban
In March 18, 2020, David Anderson added a post on his blog, from where I've copied the text below. In his post he also examines each point a bit deeper.
Since the book was published, we’ve expanded this list and they are now known as the Principles and General Practices of Kanban.
Principles of the Kanban Method …
- Start with what you do now
- Agree to pursue incremental, evolutionary change
- Respect the current process, roles, responsibilities & titles
- Encourage acts of leadership at all levels in your organization
- Visualize (the work, workflow and business risks)
- Limit WIP
- Manage Flow
- Make Process Explicit
- Implement Feedback Loops
- Improve Collaboratively, Evolve Experimentally (using models & the scientific method)
But Three, where did Three come from?
Well, I can't tell for sure. I've already put too much research effort into this and I think I can live without knowing that, although it doesn't feel like full closure... :) Anyway, now I know more about the history of Kanban used in software development, which I hadn't if I hadn't tried finding the root of the Three Kanban rules in my mind.
Please, do leave a comment if you have interesting info regarding this! :)
In the book "Kanban in action" the authors states that the last three of David Anderson's Kanban practices can be "baked into" the first three.
SvaraRaderaThe following text is how they motivate that:
As you probably have noticed already, we take a practical and pragmatic approach, and for us the last three practices fit nicely within the basic principles:
■ Make process policies explicit
Making policies explicit is what much of the visualization of work is about. As often as not, the important step might not be to write it on the board (although that’s important too), but rather to hold discussions that allow you to form consensus about the policy you intend to put
in place. Although it’s great to make this … umm … explicit, we feel that it’s part of the principle of visualization.
■ Implement feedback loops
This is part of the “manage flow” step for us. In order to help the work to flow, feedback loops are essential and should be sought and implemented where needed.
■ Improve collaboratively, evolve experimentally (using models and the scientific method)
We wholeheartedly agree on the importance of this. But this mindset is so deeply rooted in the Lean principles that underlie kanban that we don’t think it’s a principle of kanban per se, but rather the environment and
ecosystem that kanban springs from.
The teammate that told me "Well, what do you expect... " also told me he has started to write his own Agile Manifesto. It's supposed to grow to ten points, here's the first two:
SvaraRadera1. If a Product Backlog Item doesn't have any Acceptance Criteria, read it's Title or it's Description.
2. If your process includes Code Reviews, then assign the task to you when doing the review, so your name is visible on it. The more tasks your name can be seen on, the better you are.
:)