HOW WE SWITCHed FROM WATERFALL, TO SCRUM, TO KAN-BAN.
Challenge
While still on our on-premise product (you can read here about the transition to the cloud), we realized that we were lacking transparency and planning capabilities around development.
Solution
This challenge combined with the desire to standardize our practices with the rest of the tech community led us to research Agile/Scrum processes. We knew that adding this framework will not solve all our problems, but will give us the tools see issues faster, as well as the capability to address them in a constructive way.
High Level Approach
We came up with a roll-out plan that included: training, backlog org and grooming, identifying the different roles and corresponding teams, setting up the various meetings and agreeing on some preliminary measurements of success.
Execution and Evaluation
We’ve decided on Scrum at first; two-weeks sprints, with planning, standup, review and retrospective meetings. Product Owners, Scrum Masters and teams were identified. I started as a Product Owner on one of the teams and later switched to the engineering side as a Scrum Master.
Things were a bit rocky at first - we couldn’t settle on what composition each of the team will be - at first we tried a cross-domain model in which we had developers with different expertise in each team, but that didn’t work since the product backlog was organized according to function/domain. We changed the model to be one scrum team per domain and that worked better.
Scrum worked relatively well, especially with the retrospectives as milestones for minor improvements. Main challenges were:
Balancing bugs and stories was not easy; high priority bugs were always addressed, but medium and low priority bugs were always pushed down in the backlog.
The product team was sometime adding stories out of the sprint scope, which caused confusion for the team and some context switching.
We needed more manual QA than the average software company, so it felt like every sprint is a mini-waterfall iteration, in which the QA team had to play catch up with the Development team.
Releases were monthly, so every second sprint there was a substantial period of time in which only release hardening activities were happening.
At this stage we’ve started discussing a switch to continuous releases; this was part of transitioning to the cloud and we were automating a lot of the regression tests already. We’ve decided to go full Kanban, and hence improving our process from different aspects:
WIP limits helped the team focus on what’s important at a specific time, without worrying about the priorities shuffling too often.
Dev handed off the cases to QA and then those cases were immediately released; the collaboration around that process shortened the feedback loop.
The process today is Kanban, but retrospectives are always an important tool to evaluate - are we still doing the right thing? Using the Inspect and Adapt approach has always kept us conscious about the fact that processes that worked yesterday will not necessarily be the best for us tomorrow.