Making the Move: Our Transition from Scrum to Kanban
By now we’ve all felt the impacts of the worldwide COVID-19 pandemic on our work and home lives. Process facilitators and coaches churn out content every day on how to keep business moving forward using remote-friendly formats and online collaboration spaces.
The Digital team at New York Public Radio builds software for most departments in our business, including podcast creators, music, and news. We used the Scrum framework for product development for at least 5 years, but by summer 2020, our long-time Scrum approach to software development started coming under strain. We craved focused time to work, and spending almost a full day in total every two weeks to prepare, refine, and ingest a new sprint backlog became untenable.
After a thorough examination of the issues we were experiencing and working through numerous process optimizations, we transitioned to using the Kanban framework. Below I’ll get into some of our reasoning, some tips for process facilitators considering a similar change, and a few anecdotes about how it’s going for us here at NYPR.
Step-by-Step Reasoning for a Framework Change
As you may know, human brains typically struggle with change. This is why at the inception of a framework change idea, process owners and participants must fully understand the benefits and drawbacks of each framework in consideration.
Key questions we asked, as a starting reference:
- What problems are we experiencing?
This first step should be easy — find out from your team what isn’t working.
2. What are the root causes? Are the issues process-agnostic, or actually resulting from the process itself?
Dig deeper with your team and understand the root causes behind any issues they brought to your attention. Try “5 Whys” or another root cause analysis exercise to reach the true underlying problems.
When you understand them, you may find that it takes less effort to fix difficulties within your existing processes — through adjustment of your tactics, re-education of team members and rule-setting with stakeholders surrounding the team, or a novel approach to any necessary activities. Give these possibilities added consideration and make improvements to your existing frameworks where it makes sense.
If the problems truly do stem from the process itself, bring your takeaways into the next step…
3. Define what you are optimizing for.
Scrum and Kanban, as two examples, were created to facilitate workflows in different businesses, industries, and contexts. This means they (and all process frameworks) intrinsically create different benefits and drawbacks for teams using them.
Here’s a summary of our thinking:
Scrum allowed us to set short-term goals with a time-bound period to complete them and a built-in cadence for inspecting and adapting. But in this new working world full of uncertainty, Scrum cadences were too difficult to match to the availability of new information from the business and the daily changes in peoples’ working-from-home lives. It seemed like the timeboxes were too top-heavy, as we put in all the effort up front to create and agree upon sprint goals that were almost immediately the wrong choice due to new information or unforeseen circumstances. We wanted the ability to shift focus as more information became available and were ready to leave behind the practical and emotional effects of mid-sprint shifts in goals or the need to carry over work from one sprint to the next.
Kanban permits a leaner way of working by focusing on the efficiency and optimization of the workflow itself. It necessitates the efficient preparation and prioritization of the system’s inputs, and it suggests (though it doesn’t require) frequent digestion of how things went, and feedback-gathering from the outputs to inform future work brought into the system.
Since typical cadence meeting activities happen on an ad-hoc, as-needed basis in Kanban, team members must take responsibility for intentionally communicating about their work and staying focused. When we removed artificial timeboxes with Kanban, we also experienced an equalization of the prep work to ready inputs to our workflow.
A side note on tracking:
Changes like this tend to cause anomalies in metrics tracking, both in terms of the numbers on paper and the procedures you’ll undertake to capture them. Know that it may also take practice for people to develop a muscle memory for the interactions and activities a new framework involves. Expect that this may impact your predictability for a time, until things equalize.
We decided to track throughput in terms of a straight count of completed backlog items, noting the grand total and the items completed in specific areas, like design and product research. We also decided to pay attention to median and average Cycle Time.
4. Does your current working environment (both physical and cultural) support a new framework or way of working?
Think about “support” from every possible angle. At the risk of answering this question with more questions, I’d suggest that you start by asking yourself, your team, and your stakeholders:
- Are you receiving sufficient business and product development guidance to inform the work you take on?
- Are you able to limit Work In Progress?
- Do your engineering practices and standards enable quality code, and are they efficient enough to support flow?
- Do you have enabling software to keep everyone organized and track your progress?
- Does your physical office space accommodate pairing activities, support remote worker connectivity to meeting rooms, and otherwise have the space for team activities? If everyone works from home, do they have adequate internet connectivity and the digital tools to meet and collaborate when they need to?
- Do managers know what you’re trying to achieve, and do they have the tools to mentor their direct reports to be successful in this new modus operandi? Will managerial roles and responsibilities change?
- Does your culture support failing fast and learning from mistakes?
If you answered “No” to any of the above starter questions, make an action plan for any changes needed to make the answer affirmative.
5. Always remember, process is not a miracle cure.
A process, framework, or methodology sets basic ground rules and recommends good practices to ensure they’re reflected in actions. But choosing one framework over the other won’t miraculously cure what ails you.
In fact, a change in process may address some previous issues while causing or leading to others! Prepare for these new issues when you can. But when you can’t, be honest about them and collaborate with your team to tackle them together.
How It’s Going
We’ve been using Kanban since just before Thanksgiving 2020. Some takeaways so far:
Going Well!
We may have removed the cadence layer from our schedules, but estimation has still proven critical! We typically estimate the effort, risk, complexity involved using the Scrum concept of story points, because we’d used Fibonaci scale for sizing for so long that everyone had that “scale” as a ready reference for pointing. We do this at “the last responsible moment,” during a short daily refinement session, as a last step before including it in the To Do column of our board. We try to spend as little time as possible on this to minimize waste — and we refine in the mornings to leave as much of the day uninterrupted as possible.
We’re a relatively small team of software engineers, and the demands on engineers’ time and effort are always tight. When we first approach an upcoming high-priority project, we list out the general features and sit with a small group of engineers to arrive at a best-guess time estimate for each feature, in weeks.
Then project management uses the time estimates to map out a rough answer to the question, “How long will this take?” We label all of these timeline estimates as “SWAGs” and communicate that we fully expect Actuals to be different, but this exercise still gives us a rough idea of upcoming dependencies, work sequencing, duration, and anything we’ll need to communicate with our stakeholders. We visualize this info using Miro or Roadmunk.
Still Working On It…
We’ve learned that force ranking is harder than it looks!
For a small team, we have a vast purview across all our owned and operated brands, platforms, and infrastructures. There’s a lot of nuance and priorities change quickly. We’ve gotten better at having open conversations with Product Management and Engineering leadership to articulate the reasoning for our priorities and adjusting our short-term focus as needed.
We use a “To Do” (meaning “Ready for Dev”) column to indicate work that has been refined and understood, and we reprioritize the work in that section frequently to match our latest information.
If you’re working to become more Agile, you’ve heard the advice to break down silos within your team — but in a framework like Kanban, it’s a necessity. A beautifully-organized and prioritized “Ready for Dev” column isn’t helpful if the next available team member lacks the knowledge or exposure to a given application area. We have a healthy culture of pair programming and synchronous and asynchronous knowledge sharing between engineers, and also between functional areas, so engineers and product designers (as one example) approach work jointly. Even so, this is a habit we’re working to strengthen.
