Category Archives: Kanban
The main point of the Kanban board in knowledge work, is to visualise “invisible” work. What exactly is invisible work, you may ask. In knowledge work, the answer is simple: Almost all of it. While work is in progress, it only exists as ideas in our heads or, at best, as lines of code in a computer somewhere. The Kanban board helps us visualise what we are doing, and how far along we’ve come.
That’s only sort of the topic for this post, though. More specifically, it’s about how we can use the board to discuss problems based on where they surface. All processes consist of what we call a “workflow”. A set of steps or stages required to complete the process. Each phase is named based on what we are doing or attempting to find out in that stage of the process. In a software development process, it could look something like this:
- Todo (work ready to be started)
- Analyzing (trying to figure what to solve and how)
- Developing (creating a solution)
- Reviewing (verifying that the solution is free of technical bugs or weak architecture)
- Acceptance testing (verifying that our solution fulfills the need of the customer)
- Production (work completed)
Say we have some piece of work, perhaps a new feature to develop. If a problem should occur with this feature, it is interesting to know how far along we got in the above flow when the problem was identified. It’s probably quite obvious that the more stages we’ve been through, the more work has been done. So the more stages we’ve been through before we identify that something is wrong with the result, the more work has been wasted, and the more serious we should be about figuring out why it happened. With me so far?
Using the above process as an example, finding a problem in the final stage is the least desirable. When the software has been deployed to production we’ve been through a lot of work, and it has also been made available to the customer. So any problem that is present has been exposed to the public. Depending on the nature of the problem, finding it this late in the process may also limit our ability to figure out what happened. If the problem is a technical bug, it’s easy to blame the closest stage related to technical stuff. In this case it’s stage 4, called “Reviewing” above. That stage was responsible for figuring out that the solution was technically sound. Let’s go yell at the guy who did the reviewing. Problem solved! Maybe.
Let’s say that we did find the problem in stage 4, so the reviewing actually worked as intended. The reviewer successfully identified a technical issue. Now what? Obviously someone in the “Developing” stage were sleeping on the job, right? Well, it could also be that the problem is related to insufficient analysis. The development done to implement the new feature may have been fine, but due to limited investigation of the rest of the system, a problem occurred elsewhere in the system. Software development is complicated stuff.
But what if the problem we found in production wasn’t technical in nature? What if the feature we released worked as designed, but it didn’t really solve the customer need? Then what? Obviously someone did a poor job during acceptance testing, but why was it wrong in the first place? The developer could have misunderstood the customer, thus solving the wrong thing. The reason could even be outside the entire process. The description of what to solve could have been wrong or incomplete all the way back in stage 1, when it was delivered to the development team. Note that even though the cause isn’t found within our immediate responsibility, we should actively assist those who can do anything about it.
Another interesting thing that may surface during such an analysis, is that the visualisation of the workflow is inaccurate. Suddenly you find that the problem happened in a stage somewhere in the middle, a stage that isn’t even on the board.
So what’s the point of all this? A useful map for a blame game? As you may have guessed, it’s not an exact science. It is however an interesting way to discuss what went wrong and why. And no, the point isn’t to find someone to blame, but to figure out how to get better. Any individual working in a process like the one above is likely to have good intentions. If something goes wrong while they’re “responsible” for a piece of work, the causes are usually a combination of many different things. A common misunderstanding when looking for root causes, is to be looking for the root cause. Look for as many causes (plural) as you can, and collaborate as a team to figure out what can be solved and improved both in the short and long run.
(also published at www.revio.no)
“In Scrum we <insert Scrum practice here>, would we still do that if we switched to Kanban?”
Occasionally I’m approached by people curious about Kanban, and more often than not they are already familiar with Scrum. They may have read some brief blog posts about Kanban, but are left wondering what it’s really about. What are the rules? What do we have to change? Can we still do Scrum? Help! So I decided to write a blog post looking into some of the stuff you would usually be doing in a Scrum team. Would you still be doing it if you were doing Kanban, or would there be an alternative approach to achieving the same goal?
“In Scrum we divide our project into sprints. I’ve heard that you don’t do that in Kanban?”
The answer to this is, it depends. Many teams find it useful to establish a regular delivery cadence to either test or production, while others deliver when it makes sense to do so. The general rule is, the more often you deliver value to the customer, the better. The biggest difference is that with Scrum, all the practices (planning, retrospectives, releases) are tightly coupled to the sprint. With Kanban it is 100% decoupled, and everything is optional.
“I heard that with Kanban, you don’t do estimates. How does that work?”
There are no rules in Kanban explicitly saying that you can’t do estimates. In many situations it will make sense to do some form of estimating up front, or during a project. If feasible in your setting, we would however prefer to focus on what is important, and the assumed cost of delay . What would it cost us either in direct cost or lost revenue to NOT do this task now? In 3 weeks? In 3 months?
“I attended a conference once, and some weirdo on stage claimed we shouldn’t prioritize items in our backlog?”
In a large project you may well have tens, or even hundreds of individual items in your backlog. For the sake of argument, let’s say you have 50 items. To follow Scrum, you need to order all 50 items according to priority. This is typically done several times during the project, maybe as often as once per sprint. Let’s say that you on average deliver 5 items per sprint. So in reality, for any given sprint it adds little (no) value to order anything below the top 5 items in the backlog. In Kanban we prefer to ask our product owner “What is the most important task(s) for you right now?”. Answering that question is usually easier (and faster) than ordering 50 items.
“In Scrum we have a Scrum Master. Is there such a thing as a Kanban Master?”
In Kanban we recognize the fact that change is hard. People naturally resist anything that threatens their identity. Asking people to change their professional roles would do just that. When implementing Kanban, everyone involved keeps their current roles and titles. There are no formal roles. A basic principle is “Start with what you do now”.
“In Kanban you apparently have a board to visualize tasks, like we usually have in scrum?”
Yes, but with one crucial difference. Scrum has a lot more formal “rules” than Kanban, but they’re missing one – and it’s an important one. Limit Work In Progress. In Kanban we define a workflow, and we limit the work allowed in each state. As a result, we implement a pull process. Whenever there is room for more work in a board column, more work can be pulled from an upstream state (typically to the left on the board). Limiting WIP and pulling work prevents overburdening, reduces multitasking, decreases lead time (the time it takeS from we start something until it is finished) and increases flow through the system. It will also quickly uncover flow problems. If an item is impedimented for some reason, it will quickly stop or limit the flow of the entire system.
(illustration below stolen from Henrik Knibergs excellent post One day In Kanban land)
“That answered some of my questions, but I’m still a bit confused. What are the RULES of Kanban?”
I’m not sure there is an answer to that. Kanban is a management and change management technique that require some time to fully understand. There are few explicit rules as to exactly what to do, but Kanban will help you figure out what works for you. There’s no one right way, the context of your situation is always unique. Does it make sense to always have sprints with a committed list of deliverables? Probably not. Does it make sense to have stand up meetings? Probably, but maybe not every day in any context. Does it make sense to have a retrospective after each delivery? Who knows what’s right for you? Only you.
“So are there any rules at all?”
We have what we call principles:
- Start with what you do now (No set rules or processes. Start from where you are, and improve from there)
- Agree to pursue incremental, evolutionary change (Make a small change, see if it is an improvement, then try another)
- Respect the current process, roles, responsibilities and titles (Don’t manage by fear and force, build trust and understanding. Respect persons and identities)
- Leadership at all levels (Delegate, build trust, encourage acts of leadership at all levels of your organization)
And six core practices:
- Vizualise the workflow (Without understanding what happens, it is hard to implement change)
- Limit work in progress (Implement a pull system, typically a kanban system)
- Manage flow (monitor and measure how work flows through the system, in order to detect problems and opportunities for improvement)
- Make policies explicit (Document how the system works, thereby creating a common basis for understanding and improvement)
- Implement feedback loops (Regular collaboration and review at both team and company level is important to facilitate continous improvement)
- Improve collaboratively, evolve experimentally (Involve and inspire everyone to suggest improvements, and experiment to validate theories)
If you are ready to dig deeper into how Kanban may help you and your organization, I suggest you start by reading: “Kanban” by David J. Anderson
Now you may proceed with your day, I wouldn’t want you to miss your daily Scrum!