"Using the right tool, not the tool that worked before"Why changing from Scrum to Kanban? Link to heading
I have to say that Scrum is a good agile project management method and the engineering teams can benefit a lot from it. That’s why it has grown very fast and being adopted widely.
However, in a startup environment (especially early-stage startups) where time-to-market is one of the most important factors, Scrum might not be a good fit. I used to try applying Scrum in an early-stage startup and figure out some of its limitations:
- Everything is limited to “a sprint": it can be good or bad but the main downside of it is that the output of the sprint might not be a completed feature. One of the reason for it comes from the lack of engineering resources to finish everything in one single sprint. From the engineering perspective, that’s fine. However, from the non-tech stakeholders (e.g. business team), it looks confusing. Quesions like “What is the point of managing by sprints if it does not produce a working feature?" or “when can the user use the feature?" will come. It leads to the next limitation below.
- Everyone must be educated about Scrum: its’s more like a diffuculty than a limitation. Believe me, if you are not building the company from scratch, educating everyone about Scrum is not easy, especially with non-tech members, and “stupid” questions keep coming. In fact, those questions are not “stupid” from their view point.
- Scrum is a well-defined method and you have to adhere to it: during my past careers, I heard more than one time things like “it’s not Scrum” or “we have to do it like this” when someone would like to do something different. Don’t waste your time debating about those kinds of things.
- Scrum is not designed to deal with a high frequency of requirement changes: “not well-defined requirements”, “I want to change A to B”, “I want this new feature next week” … Those things could easilly break your Sprint and unluckily, those things are common in startups. Scrum is designed to move steadily, not to move fast. I think this is the most critical reason for changing to Kanban.
Ok, it’s time for some changes. What are they? Link to heading
You should have a sense about Kanban. Check this out
Basically, the changes are:
- No more Sprint. We will focus on releasing the completed feature (or MVP, or anything that a user could use).
- No more board for each sprint, there will be just one Kanban board (or multiple, based on your team structure) staying there forever.
- The feature is released right after it is completed instead of waiting till the end of the sprint.
- A new constraints is coming and it’s very important: WIP Limit. Basically, it’s the maximum number of items in a Kanban column and it shouldn’t be exceeded. It helps keeping the team focusing on finishing pending items to be able to drag more items into a column. It’s also a way to foresee bottle-necks and be aware of the team resources (e.g. the WIP Limit of the “Ready for test” column reflect the number of QAs in the team).
- New metrics to pay attention: “Time in status”, “Throughput”, “Cycle time” …
- And more … Just deep dive to it to figure out.
Unchanged things Link to heading
Backlog grooming, daily standup, feature demo, retrospective … Just keep it if you want. The only change is that you don’t really need to do it at the fixed schedule. Feel free to adjust the timezone if you want to. If something is going well, don’t change it.
Be careful Link to heading
- Keep your Kanban boards clean and well-organized. One of the common issues is that when there are many features to do at the same time (and your team is big), you will end up with a big board & dozen of tickets and you can lose your control. At that time, you can consider splitting your team by feature and making use of several Kanban boards instead of just one.
- Remember that you should focus on completing things, not doing multiple things at the same time.
- Keep an eye on how long a story stays in a column (status) and keep your WIP limit at a good-enough number.
- And even more … No pain no gain!
Conclusion Link to heading
Everything comes with a pros and cons. You should monitoring the process and improve it to match with your team. There is no way to immediately do things right at the beginning.
Keep calm and good things will come!
Subscribe to our newsletter • About the author