What alternatives can I find to Kanban for enterprise applications

Question

We are currently using Kanban to manage customizations and extensions within our application.

Our application is an enterprise application which is highly configurable, however, configure the tool right is quite complicate. The development of our tool have been taken place during several years (about 15), and the code is quite complex. Furthermore, the requirements and specifications from the customers are highly volatiles. They often change substantially before the end of the project. Therefore, we need a flexible (agile) process to adequate these changes into the project.

Our current Kanban board counts with the following status/columns: * Specifying * Specify-Approving * Rejected * Ready for dev/conf * on progress (dev/conf) * Testing * UAT * Done.

In my perspective, our current problem with our implementation of Kanban is that we are not including essential information which should be required stage after stage before being moved from one to other column. E.g Software Specification, Acceptance Criteria, Testing Plan, Release Notes... I see that including these items might increase the complexity of the Kanban process, and this makes me question if Kanban is the right solution that we need.

On the other hand, I feel that our Kanban implementation is not giving use the flexibility that we want. The requirements often change before completion of the project.

• Is kanban the right solution for project similar to ours?
• How can I modify our Kanban process to be more efficient?
• What alternatives are for Kanban for this kind of projects?

Answer 1

Kanban absolutely sounds like the right solution for you. I'm just not sure what you describe that you are doing is Kanban in the common definition.

Having a task board, with work phases does not make it Kanban. One thing I hear you saying is that requirements can change from when you start to when you finish. This is telling me that your cycle time, from start to finish is long. This usually means your "Stories" are too large. This often means your stories are not well defined and decomposed.

If you are working a software project, then a single "story" should generally not have a cycle time of more than a week. If you move beyond a week, then you're probably dealing with a lot of complexity and the chances of not getting it all done right and on time greatly increase.

The "Story" is pretty critical. I would recommend Jeff Pattons User Story Mapping book as a key resource. You need to get your user stories down to small, valuable pieces of work product.

This is a fairly high level answer as I'm making several assumptions about what is going on based on your description. Find a way to reduce your cycle time and I think you'll see everything else improve. Best way to reduce cycle time is the break up your stories into smaller chunks.