We implemented Kanban and continuous flow almost two years ago. Continuous Delivery was a big part of that transition and we made big strides in our CD process which allowed us to deploy multiple times per week for most of our products.
With the adoption of SAFe (Scaled Agile Framework) our teams were asked to move to a Scrumban process to improve alignment with other Scrum teams. Immediately, our number one concern was stopping our continuous flow process because it had been very effective in the past and we didn’t want to give it up. In this post we will review some findings from our transition.
Quick Overview
First off, let’s take a cursory look at the main tenants of Scrum and Kanban.
Scrum
- Small cross-functional teams (5 +/- 2 typically)
- Work is broken down into small, valuable, deliverable stories
- Upfront planning and team commits to work
- Defined cadence of delivery (iterations/sprints)
- Retrospectives and continuous improvement
Kanban
- Visualize the workflow
- Work is broken down into small, valuable, deliverable stories
- Pull-based workflow
- Continuous flow of value delivery as soon as its ready
- Limit work in progress (WIP)
- Measure, analyze and improve
There are several commonalities between Scrum and Kanban. Specifically breaking down the work, smaller teams and continuous improvement. The main differences can be categorized under planning and delivery. Let’s review these differences in the context of adopting Scrumban.
Planning
More ceremony
Scrum prescribes some ceremony around the development life cycle with sprint planning, daily standup and sprint review meetings. Kanban doesn’t formalize these but (at least for the last two) they are implied via the principles of Kanban. Over time we created a ceremony for Kanban where we met with the teams, management and executive management on different schedules to review progress, identify issues and define experiments to improve. This took us months to refine and perform consistently. Scrumban would help new teams formalize these processes much quicker and with more efficiency.
Iterations and planning
In preparing to move to Scrumban we were worried we would go back to the waterfall days of planning if we formalized it. In Kanban, the only planning we performed was to rank stories so the most desired (or ready) work was performed first. Looking back, we would occasionally have issues where we found unfulfilled dependencies at the last minute which would end up deferring work unnecessarily due to poor planning. Adding sprint planning to commit to work in the upcoming sprint and looking ahead a couple sprints to prioritize work is helping us avoid dependency issues and line up work appropriately.
Delivery
Still flowing
The other big concern we had in moving to Scrumban was around our continuous flow process. We have made many tools/process investments to ensure the teams can release value to the customer very quickly and have seen success from this process. We were afraid we would be required to only release at the end of the sprint. This was not a requirement however. The only requirement was we must demo the committed work at the end of each sprint. We are free to continue to release within the sprint whenever we wanted and keep our continuous flow process.
Release REadiness/Feature Flags
As discussed in my Are you Release Ready blog post, feature flags are one of the key technologies that support release readiness and allows us to deliver continuously. There are typically multiple developers working in the same code base for any given sprint. Feature flags allow us disable/hide functionality that isn’t ready while others release their changes.
The key point here is all the process/tooling we enacted for CD in Kanban is still valuable in Scrumban or Scrum for that matter.
Feedback
Do you agree? Do you have questions? Continue the conversation in the comments below, or on Twitter/Reddit.