Charlotte Fouque
The problem
The Scrum and Kanban frameworks are tools for development teams, and as with any job, it’s crucial to pick the right tool for the situation at hand. Caktus teams have been using Scrum for over two years, but one of my teams started to bring up in retrospectives that sprint deadlines felt arbitrary and were irrelevant to anyone outside the team. They also had to do some mental gymnastics to plan sprints that were so brittle they were likely to fall apart due to restricted monthly project budgets. As a result, I started to ask myself some difficult questions.
Why didn’t the team understand that sprint deadlines were there for a good reason? Sprints are essential when work has to be done iteratively, and a shippable product increment must be demonstrated to stakeholders at regular intervals. But this team was working on maintenance projects. They were not developing large, new features, but rather they were fulfilling small client requests or fixing an odd bug here and there. So, couldn’t maintenance work be done iteratively too? Well sure, but did it have to be done in sprints? The team kept bringing up sprints as a problem, so we needed to address it. I thought, what if the team could continue to work iteratively, deliver value often, AND get rid of sprints?
Kanban seemed like the out-of-the-box answer to the team’s problem. We could continue to be Agile by delivering value and gathering feedback iteratively, and we could also get around our restrictions with limited monthly hours and seemingly arbitrary deadlines that were creating friction.
The solution, maybe?
After reading about Kanban and what it would take to transition from Scrum successfully (check out Kanban and Scrum — Making the Most of Both by Kniberg and Skarin), I did what any Scrum Master would do — I brought it to the team. I called a team huddle and introduced the idea of making a Big Change to our process, in light of the issues we had been facing.
The idea was received positively as something we should explore, but it wasn’t yet clear to everyone how this new system might work in practice. I could see that not everyone was as excited about the idea as I was, so I made sure to emphasize that the decision was up to the team as a whole and that we wouldn’t make the change unless we all agreed.
We planned to discuss it in depth during our next sprint retrospective with the goal of outlining a potential transition plan, which we would then follow with a vote on whether we should proceed.
Planning
The team talked at length about how Kanban works and how it could help us, and we listed some decisions that we would need to make before the transition:
- Design our Kanban board: the first “Rule of Kanban” is to visualize the workflow, using columns and cards on a board. We had already been using a digital sprint board with columns representing workflow states, but realized that we would want to take this opportunity to update it.
- Assign limits for each column: the second “Rule of Kanban” is to limit work in progress by restricting the number of items allowed in each column, in order to encourage finishing tasks before starting new ones.
- Evaluate our regularly-scheduled Scrum events: Kanban does not prescribe any specific events or meetings, but the general advice for a successful transition was to “start with what you have” so we wanted to feel free to make some changes but stay close to what we already had in place until we could get a feel for the new process.
- Evaluate our Scrum roles: Unlike Scrum, Kanban does not prescribe any specific roles, and although Product Owner and Developer roles could easily keep their functions on the team, the fate of the Scrum Master was less clear. Had I talked my way out of this team inadvertently? I openly gave them the freedom to vote me off the team if they thought my role was not needed anymore, hoping they would choose to keep me so I could continue coaching them through this change.
There were also many outstanding questions that we needed to answer together, such as:
- How would we plan ahead for using but not exceeding monthly project hours?
- How would we ensure that tickets didn’t stagnate without the time pressure of a two-week sprint?
- How would we measure velocity without sprints so we could let clients know when we expected work to be complete?
- Did tickets all need to be the same size? And if that was the case, would the time investment in ticket management be worth it?
- Did we need some formal training in Kanban, or would we be able to rely on what we had learned on our own?
- How would we handle a new greenfield project without the structure of sprints?
Making the switch
After much discussion, the whole team decided that we should make the change. Although some members of the team were still hesitant (including the Product Owner), the conclusion was that we would try Kanban for a month and evaluate how it was going during our retrospectives, and go back to Scrum if it wasn’t working.
Ultimately, a bigger and better ticket board was designed collaboratively, with initial work in progress limits per column. The team kept all their Scrum meetings except for backlog grooming, and repurposed the planning meeting to include grooming of upcoming work. I was relieved that the decision to keep daily standups and regular reviews/retrospectives was unilateral, as these are important in any Agile context.
Perhaps the most challenging hurdle to clear before we felt ready to leave Scrum behind was cleaning up old work in progress. There were many forgotten tickets that had been left unfinished, languishing in the backlog, usually started during a sprint and never prioritized for the next one (another point to Kanban’s high visibility into all work in progress). The Product Owner worked with the team to clean up the entire backlog, across multiple clients and projects, so that we could start fresh.
The team also decided to keep me on, changing the name of my role to Kanban Koach. Grateful for the chance to continue working with them, I reciprocated by setting up a Lego training simulation (modifying Lego4Scrum to suit my needs) so we could get a feel for how this new system would work in practice (pictured below). This activity was a fun way to help everyone acclimate to the change in an informal context.
After our final sprint retrospective, we felt confident that we were ready to venture into this brave new world of Kanban. During our scheduled planning meeting the next morning, we just … didn’t plan a sprint. We retired our sprint board, reviewed the highest priority tickets that the Product Owner had pulled into the Ready for Development column of our new Kanban board, and then the team got to work.
It was contagious
Thanks to the continued team retrospectives, we were able to make tweaks to keep improving our process as we adjusted to working without sprints. The team liked that they had total visibility into what everyone was working on rather than only on sprint tasks. They liked leaving behind the artificial pressure of sprint deadlines while still pushing themselves to deliver value regularly to their stakeholders. They also liked having the ability to be completely responsive to new requests: clients didn’t need to wait until the next sprint to have their priorities addressed, instead we were able to get started on new work as soon as we finished what was currently in progress.
The team liked Kanban so much that word spread to the other development teams. We were asked to do a lunch talk for the rest of Caktus so everyone could hear about our experience. Some of us were later invited to sit down with other teams to answer specific questions on how to go about making the transition. One team went ahead and made the switch a couple months after the first team. Another team has changed their process to a hybrid method, incorporating aspects of Kanban on top of sprints.
Some advice
If you and your team are considering switching from Scrum to Kanban, perhaps the best advice I could give you is to start by examining the reason(s) why you are considering the change. It’s easy to fall into the trap of believing that changing methodology will be a silver bullet and solve all your problems. However, if your reasoning comes back to the Agile values and putting people over processes and tools — you should go for it! Scrum and Kanban are both wonderfully effective tools in the right context, and experimenting with changes to your process can be both fun and edifying.
If you have made this switch or are thinking about it, we’d love to hear from you in the comments below!
