When we talk about agile methodologies, we can’t forget about Kanban. Learn all about this methodology and the challenges you will need to overcome if you decide to implement it.

Kanban is a simple visual planning system that allows teams to manage work as it moves through a process. It was developed for Toyota by the industrial engineer, Taiichi Ohno, with the goal of increasing efficiency and reducing waste. While it originated in the manufacturing industry, it is now quite common in the software development industry. It may help your team achieve higher levels of productivity, but it will also present some challenges that you will need to overcome with the aim of making the most out of this methodology. Let’s take a look at some of these challenges.

1. When will we be done?

At a glance, Kanban is not much more than cards on a board with Work-in-Progress (WIP) limitations and some explicit process policies. Its guidelines do not state anything about the complexity of the cards you put on the board, the amount of work they represent, or how to properly assess how much time it should take the team to move any given card from Point A to Point B.

In contexts where every piece of work is similar or the tasks are very repetitive, such as a factory production line, metrics like Cycle time or Lead time can help you predict completion times, but this is not usually the case for Agile software development teams.

Take a look at this: Scrum vs Kanban: which one is right for you?

In this scenario, one option you have is to try to split the work into fairly equal chunks which you can then estimate using the aforementioned metrics. Another option is to introduce a little overhead and run an estimation process that is independent of the Kanban board. Finally, good results can be achieved using Story Points and Team Velocity or Plain Time duration estimates that you can assign to each task.

2. What is causing delays?

Another common issue that might appear with Kanban is that it makes it difficult to quickly identify cards that have been sitting in a lane for longer than expected. This is partly because this methodology does not say anything about how much time things should take (as I stated above). It also lacks the prescriptive nature of other frameworks like Scrum which forces you to keep an eye on the approaching deadline. As a result, using Kanban heavily relies on teams and team members being mature enough to proactively identify tasks that are impeding progress.  They also need to be proficient in risk management in order to avoid major deviations from the set goals.

While this may not be an issue for teams that do not have hard deadlines, and they focus solely on completing work (like some support teams), Kanban can be a concern for engineering teams that work within the scope of a project that was approved by management with a given budget and a timeframe in mind.

If you decide to go ahead and estimate the effort for the cards, one simple approach to mitigate this risk would be to leverage the tool you may be using to color code the cards depending on the amount of time they spent on their current lane compared to their estimated duration.

3. What will we release?

Software development teams tend to work on several pieces of functionality at a time, which can be logically grouped according to different criteria such as a feature, requirement, or project.

On top of that, instead of releasing items one by one, it is common to try to package those newly developed features in releases in an effort to organize how we deliver value to end-users. However, Kanban, being, in essence, a tool for increasing productivity, does not provide any guidelines about how to group the cards together or when to release to production, which leaves all that management work for the team to decide.

In practice, this means that if you have a task board, then you will also probably want to use another board (or split the one you are currently using) to keep track of projects, releases, or whatever unit of work you use to group backlog items. This will allow you to understand the current status at a glance.

Do not miss this: Agile is OK… So now what? 6 ways to improve your software projects

To Sum Up

Kanban is an Agile methodology that is not necessarily iterative, so, unlike processes like Scrum, it does not rely on having Sprints, which are small-scale versions of a project lifecycle to organize work.

It is because of this noniterative nature that Kanban projects have no defined start or end points for individual work items; each can start and end independently from one another, and work items have no predetermined duration. However, while not iterative, its limited throughput make it an incremental process. By controlling the number of items that are in progress at any given time, the teams can still approach the overall project incrementally, which allows for Agile practices to be put in place.

It is up to the team to decide which methodology better fits their needs. However, when choosing Kanban for project-based work, it is important to take into consideration the three items described to better manage expectations from both the team and business stakeholders.

Content related: Lean software development: accomplish more by doing less

Comments?  Contact us for more information. We’ll quickly get back to you with the information you need.