Scrum to Kanban – 10 Lessons learnt from migrating

The initial phase of the responsive redesign of metro.co.uk was a project that spanned 14 two weeks sprints. At the end of the sprint cycles we released a minimum viable product which we had to rapidly iterate to fill in some gaps that didn’t quite make the last mad dash. During this process we migrated from Scrum to Kanban as the pressure to get things fixed was as constant as the changing priority of requirements. Having been through this process I am not sure that I could go back to Sprints for the business as usual part of a project. However we have learnt a lot over the last few months and I thought I would share my lessons learnt in case you are also interested in making this transition.

Scrum to Kanban

1. In order to release as often as possible, focus on smoke tests and automation of deployments between environments. Usually this requires a pretty complex setup that will take some time to find the optimal process.
2. Use feature branches to allow small changes to be encapsulated and tested on each environment. This can take some getting used to but the pay off is well worth it.
3. Don’t under estimate the power of a Dev Ops culture even if you don’t have a specific person for this role empowering both developers and testers to have the time to set everything up correctly will save you time and errors in the future.
4. Break things down to the smallest possible developments based on the feedback that they can provide to avoid blockages. This doesn’t mean large projects can’t be done but should be packaged in multiple small releases.
5. Limit work in progress (WIP) as well as items on the backlog. A large backlog is usually the most inefficient part of this process. No longer can it be the dumping ground for ground for random ideas. If it isn’t done within three months I auto delete and see what people complain about.
6. Hold product performance meetings rather than sprint planning. Bring feedback and measurements and invite both business and development resources and let the data win the arguments. Setting the measurements up takes a while but they payoff of everyone looking at the right metrics is worth it. You will also need a solid goal to be aiming at.
7. Much more conversation needed on a regular basis, we now hold product owner stand ups twice a week as talking every other week isn’t enough when you are moving that fast.
8. Talk about problems define small solutions to provide learning then iterate.
9. Whiteboards are your best friend. All of the walls in our new office are whiteboards and it really helps quick brainstorms. Also allows you to leave complex problems in visible place to revisit over time until solutions become clear.
10. Don’t forget retrospectives.

Conclusion

Now that we have been running with Kanban for over three months it is amazing how much faster the team has become. Breaking things down into small pieces is probably the biggest skill that is needed to keep the process efficient. Also ensuring that the business are engaged throughout the process has taken some time but the benefit is huge. Agility has also increased as now when we find an issue or discover a new key piece of information you are able to act on it straight away rather than waiting until the next planning meeting. If you are interested in reading in more detail about Scrum vs Kanban then I highly recommend reading Scrum vs Kanban by Henrik Kniberg.

Music to Read this Post to

Silicone Soul always bringing the heat and their Darkroom Dubs compilations are a great example of that.