I would like to see anyone, prophet, king or God, convince a thousand cats to do the same thing at the same time. ― Neil Gaiman.
Have you ever thought about the Just-in-Time (JIT) concept? It is the concept that stems from the industrial philosophy that reversed the “old method” of producing finished products for the warehouse (waiting to be sold), to introduce the new paradigm of production only of what has been sold or expected to sell in the short term.
In this article we will analyze one of the techniques based on this philosophy, the Kanban technique applied in the software development field – but we can apply it in many other fields as we have to remember that it stems from the industrial field – where this philosophy has been introduced for some time with excellent results.
What’s the Kanban technique?
Kanban, from the Japanese “Kan” (“Visual”) and “Ban” (“Board” or “Card”), is a technique useful for managing a software development process in a highly efficient way.
It enables us to visualize our workflow, limit our work in progress, and optimize our “cycle time”.
Now I guess your next question; limit? Why have I to limit, as a Project Manager, the workflow? Shouldn’t we try to produce as quickly as possible?
The answer isn’t so simple; there exists many bottlenecks that we should remove in order to have a fluent river on its bed.
This technique helps us find bottlenecks and improve quality.
We have to consider the software development process as a stream with requests (our “desiderata”) gushing from the source (the owner of the process, who can give us what we usually call User Requirements) and the improved software flowing into the sea.
During the flowing, there will be some kind of process and this process we have to detail in order to get a success.
The Bottleneck’s effect
Let’s consider a really simple software development lifecycle, with main stages such as Analysis, Design, Development, Test, and Release.
What would happen if our developers realized too many features and the testers weren’t so rapid to check them? We could think the same if the bottleneck was between the analysis and the designer stage.
A bottleneck in a stream is something like a restriction in the bed of the river; have you ever seen one? It restricts flow so that the flowing turns out to be limited to the obstacle imposed by the bottleneck.
Returning to our stages in the software development example, if the analysts and developers aren’t aware that the testers are the bottleneck, then a warehouse of work will begin to store in front of the testers; it’s not what prescribes the just-in-time philosophy, we don’t want to waste our time and money to invest in a warehouse to stock the late tasks, don’t we? As, inevitably, quality would suffer.
In the real world, and this is my personal experience, the testers start avoiding some tests, the more simple at beginning (but don’t think that the hardest tests will always be taken out).
Of course, as the Murphy’s Law teach us, we will be burdened with bugs derived from those not-taken tests; and what next? Our programmers will be burdened with fixing the bugs and our development capacity will be reduced till frustration.
If, on the other hand, we knew where the bottleneck was, we could redeploy resources to help relieve it. For example, the analysts could help with testing and the developers could work on test automation.
Kanban will show us the bottlenecks
Kanban is simple, but incredibly powerful. There are many kinds of Kanban systems, but we can start with a Kanban system that consists of a big board on the wall (if you’re not be able to use the wall, you could use a computer software that simulates the board) with cards or sticky notes placed in columns (that represent your stages, for example) with numbers at the top.
The cards represent work items as they flow through the development process represented by the columns. The numbers at the top of each column are limits imposed on the number of cards allowed in each column; there’s not a rule to choose the limits, we can decide them depending on the number of tasks that our team is able to take home without creating bottlenecks.
The limits are the critical difference between a Kanban board and any other visual storyboard. Limiting the amount of work-in-progress (WIP), at each step in the process, prevents overproduction and reveals bottlenecks dynamically, so that you can address them before they get out of hand.
How it works
Let’s identify the main stages in our process.
We mentioned, as an example, Analysis, Design, Development, Test, and Release.
The work items can be, for example, something that we could demo to users, such as the features of our product/service.
Let’s name them, write them down on stickies, and place them on our Kanban board.
Now if we are going to use a Kanban board for a newly started project, all features must be placed on the Analysis swim lane, but if we are going to use the board for an on-going project, we’ll have probably a situation like the one in the next figure.
An advice; while introducing the Kanban board in our projects, don’t change our team’s process.
It’s important, because only doing this we’ll be able to find the actual bottlenecks and we’ll have a concrete chance to remove them.
Now we have to set out limits.
Let’s start with the development stage; we have to set a limit for how many items should be actively in development at any given time. I know, this is a hard choice, because we are probably used to having a lot of work in flight and we are probably experimenting a lot of switching among tasks, rather than concentrating on finishing them.
But, let’s think that every finished feature is value added to your project, something that you could probably show to your users in your next progress review meeting for example; isn’t it better than simply saying that you’re at X% of your path?
If we’re in trouble to choose our development limit, let’s make it simple and choose a value just reading our actual board; for example let’s choose a value of 3 and experiment the consistency of this limit.
Is it right for our team? Is it underestimated? We’ll discover it, just looking at how many people become idle at any time during our process.
When we are ready, let’s choose the other limits and remove the bottlenecks that will unveil dynamically.
In the above figure, for example, we are seeing that the developers are becoming our bottleneck; they have to do 5 tasks and they are only able to develop 3 at the same time.
How could we remove this bottleneck? This is the question that we have to pose ourselves and depending on the skills that we have in our team, we have to find a solution before going on.
Let’s improve quality now; let’s ask ourselves a few questions.
What kind of problems did we find during the last taken “Test” stage? Let’s list them and ask ourselves: What could we check for before entering the “Test” stage for every feature? Let’s list all the checks.
Let’s repeat these questions for all other stages; what could we check for before entering the “Design” or the “Development” stage?
Does it sound simple? It is simple, but at the same time really important, because if we enter a stage without having satisfied every gate on the relating list, we’ll probably find a trouble in the last stage; for example, if we had a not sufficiently clear and testable feature, we’ll probably develop something wrong or not as our user expected it was (because the analysis stage wasn’t completed really well) and the “Test” stage will probably reveal too many bugs or the “Release” stage will probably reveal that the user isn’t satisfied by the feature.
Some useful tools
I’d like to leave you some tools I found really useful for starting this adventure using the Kanban technique.
I’m personally using Kanbanize, a free online Kanban board –http://www.Kanbanize.com/
Another useful online tool is KanbanFlow – https://Kanbanflow.com/
Lately I started using Trello – https://trello.com/; it’s a really nice tool with, as the others, the possibility to have an app on your smartphone or tablet to synchronize your projects and take them always with you.
Who is Saverio Losito?
He is an enthusiastic and highly motivated PMP and Prince2 (Foundation) Senior Program Manager with 16+ years experience in the Healthcare industry. He often work in highly pressurized and challenging environments, managing a large-scale software development program up to an order value of €6M. He is passionate about process improvement, technology innovation, knowledge sharing techniques and how businesses can capitalize on social media integration.