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)
It’s strange how when a company grows, it suddenly fills up with people not really doing anything. So called management. I mean sure, they’re doing SOMETHING. But they’re not creating. They’re not producing.
No wait, that’s not right either. They’re producing stuff like policies. Processes. Rules. Sometimes they’re even yelling and pointing fingers. I’m one of them management types. That is, I try not to point fingers too much, but I’m quite keen on the rest of it. Well, I’m actually mostly a process guy. I happen to think they are quite useful. Rules on the other hand, that sounds a bit harsh, doesn’t it? And what does a policy really tell you, when you get down to it?
Our policy is to have policies
A policy is some kind of general principle that the employees and / or company commits to. “Never say no to a customer.” “You must change your password twice a month”. “In order to protect the environment, you are not allowed to print emails.” Stuff like that. If you are really lucky, you’re in a company where policies are defined as the stuff your boss rants about before they give you access to the alcohol at the Christmas party. He’ll say something like “From now on, everyone must work smarter!” and you will go “What does that even mean?”
To be fair, having sound policies like “Don’t share company secrets on Facebook” and “Don’t say bad things about our customers, at least not in public” is probably a good thing. But they seldom tell you exactly what to do in any given situation.
The beauty of the Process
A process is a documentation of the best known way to solve a given problem or situation. “Best known way” is the key part. That means every time the road changes, the old process no longer applies. The process must be changed with it. It also means that every time someone figures out a better way to do something, the process must reflect it. Implementing a process for the first time doesn’t necessarily mean you have to change much, or even anything at all. The process is there to document how something is done. And how it’s done right. How to update a server. How to service a car.
What’s the point of that, if you’re already doing it? Well, if you got more than one person performing any given action, it’s very likely that there are as many variations on execution as there are persons. A documented process improves the chance that more than one person is performing the action in an optimal fashion (according to the process).
Simply writing down the process the first time, will probably trigger someone going “Hey, that’s not how I’m doing it!” – and you’ll discover that four out of five guys where doing it wrong. If it’s a complicated task, the process will also help people so they don’t forget any vital part of it.
Last but not least, documenting a process is the first step towards improving it. Which is another subject, for another post (or series of posts). So I guess that’s a cue for me to stop writing, for now.