Many times we focus on determining our agile approach upfront; should we follow Scrum or Kanban? Well, what happens when we want to change?
Our project started in a Scrum style. We had a Minimum Viable Product (MVP) to deliver, so the objective was to get as much done as possible within our delivery window. While we were able to successfully deliver the MVP (and some additional functionality), we noticed certain facets of our Scrum that we wanted to improve on.
Story Completion – week 1 of each sprint saw low story completion levels, and week 2 would realize significant story completion levels.
QA – due to most stories being completed during week 2 of the sprint, the QA team would receive high volumes of functionality to test at the end of the sprint. Since we were performing QA within the sprint, we were rolling over stories frequently.
Work in Progress (WiP) – swarming would occur at the end of each sprint, but prior to that point we would have a significant amount of our story commitment in progress.
The MVP delivery was also the demarcation of a change in approach on the project. During the MVP phase, we had the entire team (10 devs, 5 QA) focused on this work stream. With the MVP delivery complete, the team was reorganized into 3 separate workstreams, only 1 of which continued on this solution.
We took this opportunity to transition from Scrum to Kanban in order to see if we could improve in the areas mentioned above. Our workstream now has 4 devs and 2 QA and we’re utilizing a Kanban board in JIRA. We’ve migrated over open backlog items and have started with a very simple column structure: Pool Of Work (backlog), Selected for Development (minimum of 3 tickets, maximum of 7), In Progress (including QA, maximum of 7), and Done.
Since our transition, we’ve experienced some noticeable improvements including:
Story Completion – with limitations on WiP, the duration of ‘starting to done’ has decreased. This has organically encouraged the team to swarm on tickets sooner, and through completion.
QA – we are no longer delivering massive amounts of stories to QA at a given time. Instead we are delivering functionality in smaller increments, allowing QA to test individual items sooner and give more timely feedback.
WiP – limiting WiP is allowing the development team to alter focus. The team is now focusing
on the Kanban mantra of “Stop Starting, Start Finishing”.
Team Morale – before transitioning to Kanban, we asked the team to weigh in on changing our approach. The team was in favor of the change and has enjoyed using Kanban for our current phase of work. Additionally, we’ve become more efficient in our delivery, reduced our ticket cycle time, and improved quality.
In addition to development goals, our client wants to roll out individual business units to the new solution. Shifting to Kanban has allowed the team to look at development at a feature level in order to complete functionality, one business unit at a time. It has also allowed our client to change priorities more frequently.
Kanban and Scrum are both great approaches to organizing development. When determining which approach is best for you, be sure to evaluate each use case individually to choose which might be best for you.
-Drew Moyer
Delivery Lead
