Share:

My affinity for Scrum began in 2007, and my experiences with 352 have only made me love it more. The beauty of Scrum is that it can be applied to all sorts of tasks – our founder built an entire management philosophy around it, and I’ve used it on non-tech projects like remodeling houses and growing my own footwear company.

That versatility makes agile methodologies ideal for digital product development; we can get to market quickly, test functionality and prioritize new features to enhance the product. At certain times in a product lifecycle, however, your team will need more flexibility than Scrum typically allows.

Some teams might be tempted to slip back into waterfall when Scrum feels too cumbersome, but since our team still occasionally has Waterfall nightmares, we’ve chosen to alternate between Scrum and another agile methodology: Kanban.

While Scrum allows for clear expectations and feature delivery, Kanban puts less emphasis on large sprint goals and robust feature delivery by enabling team members to pull down single, sometimes unrelated, tasks without the pressure of the burndown chart. While most 352 teams utilize Scrum, we like to employ our culture of testing and iteration to our internal workflows, as well as our products.

To choose between Scrum, Kanban or a hybrid approach to any given sprint (aptly named “Scrumban,” for maximum strangeness), you’ll need to truly understand your product roadmap and balance project needs with the strengths of each methodology to make a decision. Let’s get started.

What’s a Kanban?

Compared to Scrum, most teams will find Kanban incredibly lightweight. Kanban calls for implementation of four key practices to be successful:

Visualize the Workflow – Create a board (called a Kanban board) where everyone can see the work to be done and its status. Seeing work at a high-level like this provides perspective and enhances team decision making. Limit Work-in-Progress (WIP) – Studies have shown a performance penalty when working on two tasks simultaneously. Limiting your work in progress really means you should focus on one thing at a time. Limits will force you to stop taking in new work when problems arise and fix any bottlenecks down the line. Manage Flow – The end goal should be a smooth transition from work being added to your backlog to being completed. You’ll want to watch metrics like how long something sits in the queue before it gets started, how long it takes to go from Started to Complete and how many items get finished in a day. Continuously Improve – Watch your metrics and perform experiments. Start with a small tweak. If it helps, keep doing it. If it hinders, stop doing it. Don’t be afraid to try something crazy for a week; don’t throw out an idea because you think it won’t work.



That’s it. As you can see, Kanban provides some guidance but is very loosely defined. It doesn’t tell you how to improve your metrics or which process is optimal. Compare the four practices above to Scrum’s 16-page guide, and you’ll see what I mean by “loose.”

So when does it make sense to abandon the familiar safety of Scrum and try Kanban?

When We Choose Kanban

In agile, Kanban is the de facto choice for maintenance-type projects where Scrum might be too rigid.

For example, if you’re running a network-ops organization and a network switch dies on a Thursday, you can’t say, “We’re already working on a sprint, so we will take a look at it next week – you’ll have your fix in 3 weeks.” In these situations, Scrum creates more stress and headaches while Kanban’s flexibility allows you to pull down prioritized tasks immediately and work on urgent matters.

My software development team recently took over a project that was plagued with bugs. We started with our tried-and-true Scrum process but immediately ran into issues because we couldn’t go more than a day without getting urgent requests from customer service regarding customer transactions.

You can’t tell a customer, “Please wait for 2 weeks and then we’ll have a developer research your issue.” So we switched to Kanban temporarily to get through the weeds. We squashed bugs like bosses and helped get the customer service issues under control. Our priorities could change at a moment’s notice and we were making a huge difference. And it felt great.

Another Kanban-to-the-rescue moment occurred when working with our friends at YouCaring.com. The project was going well, so we added three new people to the dev team. In the second week of that first sprint, we realized we had a big problem. The only way to complete the sprint was to have the original team work heads-down, but the new team members needed training. Should the developers help bring the new guys up to speed, or actually finish everything committed to in the sprint?

Deciding that we valued our onboarding process and didn’t want to cut any corners in training, we made a temporary switch to Kanban. This gave us the freedom to train when needed so we didn’t inadvertently rush things to meet a self-imposed deadline or out of fear of neglecting the sprint goal.

When We Return to Scrum

Kanban let us tackle customer service issues the moment they arrived without grief and helped us grow our team without putting project goals at risk. It helped us achieve success when priorities could change at a moment’s notice.

Which is the crux of the problem. Scrum has helped us deliver incredible client results precisely because priorities can’t change from day to day. When it’s time to buckle down and move a product toward launch, Scrum outshines Kanban.

You see, if new things constantly jump to the front of the line, you will inadvertently de-prioritize the big, difficult, but – ultimately – most important goals. You’ll spend your time putting out small fires and lose sight of the full landscape. It’s why many people don’t use their gym memberships; fitness is important, but so are the 100 little distractions that pop up each day.

Taking the Long View

To be successful, every digital product needs a roadmap. From feature prioritization and user onboarding to iteration and monetization, you need a plan to see the path ahead. Like any road trip, there will be stops, detours and chaos on the route – but if you’re skilled, you can plan ahead to tackle these issues.

Scrum provides the framework to be strategic. It gives you the rules to say “no” to the little fires; they can wait. Scrum helps us keep the destination in mind. If we want to avoid a heart attack in 30 years, our trip to the gym trumps all the important little things.

Scrum Makes Structure

Even though we know we’re always moving toward an ultimate goal, Kanban makes it more difficult to build a theme or goal for a particular sprint. The stories are in priority order and often feel random, whereas Scrum allows you to choose stories around a central theme. More importantly, we found that Kanban often left us with half-finished tasks at the end of an iteration.

Scrum provides a reasonable expectation of what we will finish from day 1 of an iteration. This knowledge equips us to choose an optimal order for every sprint task. For example, we choose to work on the big things first and save small stories for the end. This lets us prioritize heavyweight items for QA and bug fixes, and the team approaches the end of an iteration with complete tasks ready to launch.

So, Which is Best?

Ultimately, we’ve had successful sprints with each methodology, and I’d never try to pick a winner in this fight. Different approaches will work well at different times during a product lifecycle, and your team needs to choose which works for the needs of a current sprint. Being agile is all about experimenting, learning and iterating accordingly. The end goal is to have an efficient, effective and self-organized team. So enjoy the process, and happy hunting.

Image Source: Bruce Turner

Share: