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!
Let’s say you witness a boy fall off his bike. What do you see? What do you do? If you help the kid back up on his bike, most would argue that you’ve solved the issue at hand. But isn’t it likely that the boy will soon fall off again? And if that is the case, did you really solve the problem?
If we scratch the surface, there’s a whole range of other problems hidden behind the most obvious one. Why did the child fall off the bike? He probably needs more training in order to reliably control a bicycle. He certainly lacks basic risk management skills. Do we have an equipment problem? Perhaps the bike is of the wrong type or size for the child?
Riding a bike is basically a process. I don’t know about you, but when the rider of the bike ends up face down in a ditch more often that not, I see room for improvement.
Let’s leave the kid and his bike for now. Say a customer reports a bug in your software. What do you do? Fix the bug, of course! Problem solved, right? Wrong. Why wasn’t the bug discovered before the software was released to the customer? Your test team (if you even have one) should have prevented that from happening. So improving your test and QA process will do the trick, surely? The QA manager raises his hand: Wait a minute, isn’t the developer supposed to test his work before releasing it to us? A lazy developer must be the real problem here!
At this point you’re probably on to me. “I see what you did there,” you say with satisfaction in your voice. These are all reactive solutions to the real problem. The real question. Why did the bug occur in the first place? Lazy or incompetent developers? Maybe. Someone has created a piece of software that doesn’t work as intended. You may guess my next question: WHY?
When I find myself in a similar situation, I often find that the developer wasn’t given enough information to make the right choices during development. Let’s all say it together: Shit in, shit out. If I had a better developer, he may have recognized the turd when I shit in his hand, but I can hardly argue the origin of the turd itself.
So we have established that I’m full of shit, but how did we do that? We did a (somewhat informal) root cause analysis. As a fan of Lean and the heritage from the Toyota Production System, I like the 5 Why’s. – It’s a process where you basically keep asking why until you arrive at the real source of whatever problem you need to resolve.
The kid fell off his bike – Why?
He doesn’t really know how to ride a bike all that well – Why?
His dad doesn’t have time to teach him – Why?
He works all the time – Why?
He thinks making money for his family is more important than being there for his kid.
So there you go. Not only did you learn how to solve problems (instead of just removing symptoms), you also got a life lesson. No worries, you can thank me later. Now put down your laptop and go be with your family. And never solve another problem without asking WHY at least five times!
My first post will be about a recent discovery, personal kanban. I’ve been managing software development based on KANBAN the past few years, but it never occurred to me that I could use the same concept for personal task management.
Personal kanban is basically about two things: Visualize your workflow, and limit work in progress.
Visualize your workflow
In a process based on KANBAN, you usually throw a board up on the nearest wall, draw a flow and put the tasks into the workflow using sticky notes. Personally I prefer a digital board, and I’m using Agilezen for this purpose (for our team we use greenhopper).
I’ve got several columns on my board, but just start with “Todo”, “In Progress” and “Done” and work your way from there. You should also have some kind of backlog (possibly outside of the board) so you don’t end up with too much in your Todo column at any one time. For some good principles for managing future tasks and todo, check out Getting Things Done by David Allen (more about that in another post).
Limit work in progress
When you’ve set up a board and figured out what columns to put on it, you need to set a limit for how many items you will allow in the “In progress” column. All work you’ve started but not finished, occupies a part of your brain. When your brain has to focus on several tasks at once, the quality of your work decreases. I know you think you are an expert multitasker, but you’re not.
These days, most people multitask like squirrels on speed. You start one task, *pling* an incoming instant message distracts you, and when you’re done chatting you start something else. Before you know it, you’ve got two half finished emails, you’ve written four lines on a document because you need feedback from your boss (and he’s out of town on business), and forgot what you were supposed to be doing in the first place. Limit your “In progress” to three, and you’ll be amazed at how quickly it fills up.
When you learn to limit your work in progress, you’ll find that you’ll get more done. Instead of doing ten tasks at once, you will be doing one task at a time. Not only will you become more productive, increased focus will also increase the quality of your work. You’ll also have a great system to keep track of all the stuff you need to get done.
This was just a brief introduction to the concept, for more information I encourage you to google “personal kanban”, follow #pkflow on Twitter or buy the book. If you have any time / task management tips of your own, feel free to share them below!