Kanban is a widely popular way of organize a software development process. It became popular because it is intuitive and matches the most simple software development flow, the Waterfall model.

Developers pick a task from the "TODO" column and move it into "Doing", "WIP" or "In Progress" one, however is called. Once the task is over, it is moved into "Done". That's it, deadly simple.

In real life there could be many more columns. Just to name a few of the ones I saw the most:

• Pending Clarification: when the task cannot be started due to lack of information.

• Ready for QA: when the development is over and some QA testing is required.

• Testing: when QA testing has started.

• Blocked: when the development cannot continue as it is blocked by some other task. Once this dependency is resolved, the task can be completed.

Those are the most common task states, I found them quite regularly in every Kanban team.

That's all fine, yes, but...

...while everything seems so simple and straightforward, software development is not. I think this model is far too simple to match its complexity. Let me explain what I consider being the weaknesses of Kanban.

It implements a Waterfall model

While Kanban allows tasks to be moved back and forth between columns, its nature is far from being iterative and all tasks requirements have to be fully clarified beforehand. That is why oftentimes a column like "Pending Clarification" is added.

Software development is iterative by nature. Just think about how many techniques were created that require some kind of loop back. TDD and Scrum are surely the most famous, but also refactoring hides this structure within. A refactoring can be undertaken, for example, because the requirements are changed or the overall architecture has evolved, thus some code needs adjustment.

Even without TDD (shame!), the every day development itself is iterative. We firstly draft the code, then adjust it until it reaches its final form. We iterate over it again and again to refine it.

Also, requirements may not be crystal clear at the very beginning, but we may need many iterations to discover what is actually required. This is true despite the amount of time we allocate for an in depth initial analysis. Requirements change and evolve over time, so the code have to adapt and we cannot shot a picture of what we think we need at a point in time and pretend to be valid as-is in the future.

Kanban is an implementation of the Waterfall model, that's what I think is one of its weaknesses. Waterfall has been long contrasted ever since, because it clashes with iterative nature of software development.

Lack of collaboration

An often unseen drawback, is that Kanban allows parallelization quite easily. While it seems a good point, it is not. At least, not entirely, not in every situation.

When there are no emergencies and everything is going smoothly, the team could allow techniques like pair programming and code reviews. This is more than just fine, is the right way to bring actual value to our software! But that's not true for every team. If the team has not a collaborative culture, is easy for developers to be left alone with their tasks.

And as soon as emergencies arise, it's easy to foresee how the picture blurs. To maximize the throughput, as many tasks as possible are put in progress, leveraging parallelization. Developers are busy on their own tasks, no way to allocate time for pair programming or code reviews, leaving every developer with the whole responsibility of a single task. That is, if a task is not done properly for whatever reason, or blocks other activities, the stress upon the shoulder of its owner increases.

Overall, the software quality is decreased and when something goes wrong people may start to blame each other.

So what?

The Waterfall problem can be solved by segregating Kanban in a well defined period of time, e.g. two weeks. First, an analysis is started that produces tasks to be put in "TODO". Such tasks are measurable and the team agrees they can complete them within the two weeks. Then the Kanban flow starts and completes, the tasks are handed over to the next steps, e.g. UXT, QA or something else, and the process repeats.

This simple solution also enforces team members to collaborate, because they now have to agree on what tasks to work on the next two weeks and help each other to reach the common goal of the two weeks deadline.

Does it ring a bell? Yes, this is a first step toward Scrum.

Conclusions

I have seen Kanban used in many teams and for some of those it was working great. The problem is the software development culture of the people involved, from developers to product/project managers and other stakeholders. As soon as it lacks and what's valued the most is the deliverable, regardless its quality, it can become frustrating.

As usual, software is created by humans and their relationships, thus their culture is reflected in the process management and eventually in the code quality.

To the next bite!