Letting the Teams Decide: From Scrum to Kanban
By: Louise Story
Tags: Engineering, Kanban, Product Management, Agile, Scrum

By Mike Finkel and Louise Story

WSJ’s web team decided to switch from Scrum to Kanban

A lot of things have changed since we all started working from home, but one thing we have worked hard to preserve is our culture of empowering engineering teams to be leaders in decision-making.

One recent decision by WSJ’s web team reflects our collaborative approach to decision-making and has turned out to help us a lot in the new world of ‘Work From Home’.

It was the middle of the summer when we started a dialogue around the way our web product development team works. Like some of our other teams, the web team had followed the Scrum framework for Agile development for several years. We liked many things about Scrum — it is collaborative, transparent, and it lets us stay nimble and closely tied to our business goals.

But as the team grew in both size and scope of responsibility, planning meetings were becoming unwieldy and tough to organize.

By July, engineers on the team were starting to question their practices. Why, they wondered, wait until the end of the standard two-week sprint to figure out the next thing to do? While we can come together by virtual hangout for daily standups and the other ceremonies prescribed by Scrum, synchronous meetings are not as easy as they used to be. We’ve been responsive to the realities of the pandemic — children at home, other family members with needs, logistics of daily life — and we’ve allowed alternative work schedules. Scrum planning sessions weren’t exactly designed for this.

So, the team started looking at Kanban — — a different approach to Agile.

Agile engineering — a philosophy published in the Agile Manifesto by a group of influential software engineers from across the industry 20 years ago — has led to many different approaches in the world of product development. Scrum was one of the first formalized approaches in Agile, and it focused on creating short planning cycles with regular team check-ins and retrospectives to revisit the process and continuously improve as a team. Kanban, in contrast, aims for a continuous flow where a team can constantly adjust priorities and take on new work as soon as they ship something. For the web team, the Kanban board, where the list of work and tasks is openly shared, and this process overall, are better suited for the quick-turnaround requests we often get inside of a news organization. It also happens to serve us better in this new world where our teams are highly distributed.

The Kanban board is, for some, better suited for the world of asynchronous communication.

Because we have empowered teams to define their own ways of working, this wasn’t a shift that came from the top. Instead, Vasudha Maganti, the manager on the team, researched Kanban, spoke to other managers who recently made the shift, and suggested the idea to her team through several 1:1 meetings. They all agreed that this shift would address their concerns, so they talked it over with their product and program partners.

“We wanted a simpler process that can increase our efficiency while also being flexible to changing priorities,” Ms. Maganti said. “We were doing two-week sprints previously, and we felt the existing process was too rigid. We would spend too long in planning meetings and sizing stories, and give inaccurate estimates at times, and still come out with unknowns on tasks.”

The pandemic accentuated the need for change, said Marta Jakubanis, the director of product for our web platform.

“We all wanted to cut down the noise and focus on delivering the next thing, one day at a time, rather than trying to forecast priorities for and output of our engineering team beyond a one-week horizon,” Ms. Jakubanis said.