13 Benefits of Kanban for Software Development

What is Kanban?

Imagine a Toyota center. You liked that Toyota Camry and paid a deposit. There was no car in a color you wanted and therefore your order went to a Toyota factory in Houston. You were notified when your car would be delivered, and the car is being produced for you starting from this moment. So they work according to the “sell first then produce” rule, in other words it’s the “Just In Time” rule. First you come up with the time and goal, then a work plan for achieving the goal. 

There is almost no stock in Toyota warehouses and there’s no need to store pre-made spare parts. Why? Because everything that is being produced now is already a part of a pre-sold car. One of the key elements in the JIT system is Kanban. KAN means visual and BAN means cards so that means visual cards. These cards are the traffic lights for the JIT system.

Let’s say you are installing a transmission for a Toyota Camry on an assembly line. There are 8 transmissions near your stations. You’re installing one transmission, then another one, then the third one. When you have only 4 of them left you take a Kanban card and write down an order for 8 new gearboxes and give it to the manufacturer since you know that your colleague will assemble and deliver those 8 gearboxes by the time you will be putting the last transmission in a car. Then everything repeats itself and you order new transmissions only when you need to. Do you recall the Toyota center? Where they order a car from the factory only after you have paid for it.

In fact, Kanban software development gives businesses an opportunity to be reactive towards customers’ demands instead of trying to predict the needs.

My example was from a production viewpoint, now let’s see how it works with software development. As auto parts we take tasks for development or bugs. A tester takes some tasks from a developer for testing (similarly to the assembly line when a master took transmissions for installing them in cars). When a QA is out of tasks for testing he/she needs to notify it to developers so they could hurry up and give them new tasks. If developers can’t finish new tasks then a tester is left without any work and stays idle. There’s also an opposite situation when a tester is overwhelmed by the workload and he/she can’t test everything in time. In this case a product’s date of manufacture (of a car) is delayed as a tester isn’t able to test every task properly.

It’s more difficult to balance Kanban in software development than in production due to work specifics. Machines as a rule make details of the same type whereas developers code with their own heads which has approximately 100.000.000.000 neurons and one big but notorious human factor.

What is the impact of Kanban on software development?

I tried Kanban in 2008 and have been using it since then both for my private life and for software development. There was also a time when we used Kanban software development boards for the ceramic studio of my beloved wife.

But most of my experience I’ve gained from different IT projects for website, mobile and web applications development. And now I want to share this experience with you.

In the following list I will mention the advantages of Kanban implementation in IT companies which develop software.

1. Detection of weak spots

After switching from a usual list of tasks to Kanban boards we found out our weak spots straight away. In the Testing column there was a big queue of tasks as our tester wasn’t able to cope with them. He started working on them with a long delay. As a result, when a tester was returning a task for further improvements a developer had forgotten it already. Meaning that he had to look at a code and remember what it was about, and this takes a lot of time. So we came up with the idea of taking a second tester. Bingo! Kanban board allows you to see those spots in your process where there’s a tendency for tasks to queue up. WIP limits let you find such weak spots on Kanban board.

2. Precise order of features release  

As a rule features release order plays a big role in software development. It’s pretty difficult to manage the order precisely in lists based on priorities (like major, minor, critical, etc.).  Let’s take a developer which has 5 tasks with major priority, which of these 5 tasks does he need to start working on?

When the order matters then Kanban offers an elegant visual solution in a form of vertical columns with tasks. The higher a task in those columns the more important it is. By the way, within Kanban framework defining the priorities in working process is one of the main task of a manager. Requirements as well as our reality change constantly. Some tasks after being in a queue for a while lose their significance and go down. They go down to that place where no one could ever see them. Some of the tasks do the opposite and they go up. In order for developers to work on the things that matter the most a manager has to always  keep track of the tasks’ order.

3. All attention goes to the most important things 

After switching to Kanban software development we started to do only the things that added value to the product. We managed to keep tonnes of useless bugs and modifications out of sight from our developers. Anyway where do these useless bugs come from? Obviously there are testers who are doing a good job and find them. But to define a bug from a bug is a task for a person who can reflect the needs of both users and business. Usually this person is a product manager.

To separate the wheat from the chaff we are using Swimlanes in other words horizontal columns on Kanban Board. As a rule developers usually have the following Swimlanes as:

• Blockers – it’s for tasks and bugs which need to be fixed in real time. I.e. a broken registration form.
• Tasks and Bugs – common tasks and bugs
• Someday – tasks that became irrelevant or have never been relevant.

Our system somehow reminds the Eisenhower matrix. Urgent and important tasks are the Blockers. Urgent and less important ones are Tasks and Bugs. Less important + urgent and less important + less urgent that’s all Someday.

Swimlanes are horizontal columns on Kanban board

 4. Focus on work

A developer sees his queue and doesn’t think what to do next as a manager has decided it for him.  There’s no need to spend time for choosing the next task. No more questions like “Should I fix this bug or work on that task first?” But there are different types of Kanban. You may decide for developers what they do and assign tasks to people beforehand. Or you may give people the opportunity to take any tasks from the top. But in this case your people should have quite similar skill level, otherwise, a junior may take a difficult task which he won’t manage to handle and that will only undermine his/her confidence.

My Tasks filter helps to focus only on those tasks that are assigned to you:

5. Panoramic view

You can have a whole picture of your project lying open before you. You can go to a board and quickly get answers to the important questions:

• Who is busy now?
• What are they going to do next?
• What tasks were reopened due to bugs?
• Who is left without work?
• Where is a big queue of tasks?
• Which tasks have any changes during the last day?
• When the task X will be finished?
• How soon an employee will run out of tasks? (how soon you need to assign him/her new tasks?)
• Which tasks have already taken more time than it was planned for?

6. More flexibility

We became more flexible in software development. We started changing requirements on the fly without any resistance from our developers. This attitude is pretty important especially when the product is released and you receive a lot of useful feedback. Such things as behavioral analytics, requests to support center, A/B test results, reviews and etc. Therefore as soon as we implement a new feature for production we start to change it according to the feedback. Earlier the developers didn’t want to do extra tasks, out of the fear of not coping with sprint deadline. With Kanban a developer works like a processor with clock signals. One clock signal equals to one task. The more frequent clock signals the more flexible the development team is. 8-12 hours is the perfect clock signal for our team. That’s when we always decompose big tasks. 

7. There’s no need to assess features

When using Scrum a lot of time went to features assessment before sprint’s start. Now there’s no need in the assessment, we just do a feature asap.

8. More work less talk

In scrum a lot of time goes to communication. Before sprint starts there’s its planning such as tasks analysis, tasks assessment. During a sprint there’re daily standups. And retrospective occurs after a sprint ends. As a result all costs on communication takes about 30% of time which a team could have invested on development.

9. Team cohesion

Testers started working on features almost immediately after they have been finished by developers. Before QA tested a feature not when it was completed but long time after that. A developer could hardly remember that feature by that time and was spending a lot of time trying to catch up with a task. Now in Kanban a QA tests a feature almost after it was finished. The same works in other segments like with designers, editors and salesmen. Teams start working more consistently like a metronome that produces regular beats: one-two-three, one-two-three.

10. More frequent mistakes

When we work with Scrum we launch a feature only at the end of a sprint, like once in 3 weeks. With Kanban we’re launching them almost after a testing period is finished, that’s like once in a few days. In that way we’ll find out more quickly whether the users like the feature or not. If they don’t – that means we’ve made a mistake somewhere. And we want to be the first ones who are mistaken. That doesn’t mean that we like to make mistakes but if we are the first who make them means that we will also be the first ones who get the experience and will know in which direction to go.

11. More flows

There’s no need to keep nagging developers with a question “what are you working on now?”. Just open a Kanban board, take a look at what people are doing and continue working on your own managerial tasks, let a developer stay undisturbed and enjoy the working process.

12. I want to know everything

Developers had no idea what their colleagues were busy with. Now a developer just like a manager can open a Kanban board and to see what their co-workers are working on. As a rule they need to know it for a better coordination of joint efforts on a project.

13. Focus on one task

Earlier a developer could work on a few tasks at the same time. Either  he chose tasks depending on his mood or on Mondays he just forgot which task he was working on last Friday. What I want to say is that a developer switched from one task to another one and spent huge amount of time switching. Why huge? Can you imagine what developers should bear in their head for coding? Name of variables and data structures, API calls and algorithms and much more detail. And each time you need to go into a task: to review terms of reference and a prototype, to read a current code and build its inside representation, so later on you could operate with it in your head. Now thanks to WIP limits and a panoramic view a developer can’t work on more than one task at a time.

Resume

You might think that Kanban is cooler than Scrum but it’s not like that. Let the cobbler stick to his last.: Scrum fits well at the start of a product development and Kanban when the product has been already released.

Kanban software isn’t a panacea and a silver-bullet. If you lean a ladder against a wrong wall no matter how hard you climbing it up you won’t end up where you want to be. Therefore Kanban is an essential but is an insufficient condition for the success of your project.

Kanban is that thing which helps your IT team to work coherently and maximum effectively.