Many companies tries to be Agile, but how they do it can be very different. It can be very tempting to use KanBan when you start working with Agile since it is easy to integrate into the existing processes. Just add a KanBan board and let the team pull the stories. You can easily let the whole company use KanBan and define a workflow to have bug reports pass though support and directly into the developer teams and the product owner can put stories on the teams backlog.
But is it Agile?
No, not in itself. You can add KanBan as a tool in almost any situation, regardless of if you are working with waterfall or in an agile environment. KanBan can help you optimise your work flow by exposing the bottlenecks but it doesn’t mean you are Agile.
Let’s assume you are working with a software product that has a main branch where the new features are implemented and a couple of maintenance branches that must be maintained. There are usually some kind of SLA specifying that bugs found by a customers needs to be solved within a specified timeframe. Other customers are expecting new features at specific dates.The company then creates a release plan with features and bugs to be delivered at certain dates.This is not a very unusual situation.
Can KanBan work in this situation?
Of course it can! KanBan doesn’t care about this. All processes that existed before KanBan was introduced still applies so if this worked before, it works now. So the interesting question would be how to work in an Agile way with KanBan in this situation.
Now, this is a bit trickier… Starting with SCRUM, you have a product owner adding stories to the backlog. The team picks stories during sprint planning and delivers most or all of them when the sprint is done. After a few iterations the team will have an idea of their velocity and can start estimating how much they will be able to complete in the next sprint. This will help the product owner to plan the upcoming releases.
But with KanBan we don’t have sprints. When the product owner adds stories to the backlog, the team just starts working on them. So how can you plan for the upcoming releases? The product owner continuously makes sure the highest priority story is at the top of the backlog to make sure the most important stories can be delivered. When it’s time for a release, he makes sure the release story is at the top. It is easy to fall into the trap that the team should keep track of the release dates and notify the product owner if they will be delayed. This is where it gets hard. It is very far from Agile to set the time and scope for the team. In this situation the product owner should either bring in the team to do the release planning or he should trust the team to do the best they can and handle the release followup himself.
Don’t make the team accountable for a time and scope they have not been part of defining.