Would love to hear stories.
I have similar experience to Shikarishambu. We started with the principles of XP and adopted Scrum because that's what our clients were using. We've been doing Kanban about 4 years now. The main motivation for the switch is that scrum didn't help us see how features were moving through the various roles on our team: namely design and development. Also, the ceremony around scrum wasn't helping us much any more.
- Accurately model how we get work done. What does it take to go from idea all the way to production?
- Daily standup is driven by the kanban board. Instead of everyone just saying what they're doing, we focus on the status of all the cards on the board. That lets our client know the exact state of what's being done
- No need to formally estimate stories; just focus on the flow
- Much less formality and ceremony. Kanban is very fluid.
- Like shikarishambu said, Kanban doesn't give you any long range vision. It's extremely tactical. How is the project tracking against it's strategic goals? You need something else to help with that. We use a User Story Map (a la Jeff Patton's wonderful book)
- Also like shikarishambu said, you need to track the story/feature all the way to production. That means your board needs to include your deployment process. If it's CI/CD, great. If it's not, make sure the board is setup to show where features are in the pipeline to production. For a while we had a column for "Acceptance" (or QA) that fed into "Ready for Production". This signified we had work we thought was done but was being batched up waiting for a production push. Our "Done" column means in production available to our customers. Now that the team and client is more comfortable with our process we're pushing directly to production.
- There's a temptation to model how you want the work to be done rather than how it's actually being done. The strength of Kanban is clarity. Don't kid yourself about the state of the system
- It's also really, really hard to enforce WIP limits. We pretty much don't even set WIP limits. The team just has to stay on top of WIP by gut feel.
We switched from Scrum to Kanban when we found that business couldn't keep to the agreed priorities for even a sprint and it was getting close to the release date. The pros: ability to reprioritize as we go Cons: No visibility into what is coming in <x period of time>. I think Kanban without ability to continuous deployment/development puts the team at a disadvantage. We lost the ability to advise the stakeholders on what is coming in the next deployment (we continued to do deployments like we were doing in Scrum).
A really great tool that, if used alongside other methodologies/tools (eg MoSCoW) can bring structure to product development. Key advantage is that it is a highly visual and interactive tool for management the product feature evolution. Key disadvantage is that it is difficult to introduce a timeline 'axis'.
Kanban can be great if it suits your needs.
There is a squad at my org that responds to RFPs for branded content campaigns and executes the campaigns that sell through. It is impossible for them to know what will come through the door several weeks from now but they do have a tight understanding of what they're currently working on as well as the next piece of work that is on deck.
Teams with a full backlog can also benefit from Kanban. If the team breaks down their tasks into similar sized units, the team will know how many same-sized-tasks they can finish in a week (or whatever time-box you want to measure). Over time, this metric becomes reliable and you can use it to forecast how long it will take to complete the portions of your backlog.
Unplanned work will emerge and take priority over planned work. You can track which tasks were unplanned vs planned to have a better understanding of how long it will take to complete the planned work in your backlog given an average amount of expected unplanned work.
I would advise to not overlook WIP limits as it is a fundamental component of Kanban. Without WIP limits, tasks could end up rotting on the board in lengthy columns forever. Measuring how many tasks get done in a time-box will lose its effectiveness.
- Less overhead than scrum
- Flexible with priorities and scope
- Provides a clear status of the current work in progress
- Colocation plays a big role in success (the board is most effective when it is constantly visible by all members of the team)
- Breaking down tickets into similar sized tasks can be difficult for some teams
This is a such a great kanban discussion — thanks to Jenny for starting this! 🙌
Since there are many Aha! users on the forum, I wanted to mention some new functionality we launched earlier this week. It might give you some more insights to consider as you decide if kanban is the right approach for your team.
Aha! gives you a kanban experience with our workflow board. Many product teams reference the workflow board continuously, to track features through the development cycle. Marketing teams also find this view helpful for coordinating the day-to-day flow of their activities. Our latest update gives you even more ways to use the workflow board.
You can now use the workflow board to visualize the status of your initiatives and requirements.