The Scrum is for Projects, Kanban is for Maintenance Myth
Don’t be fooled by this bullsh*t mantra.
I wanna talk about something that’s been bugging me for awhile. At my current spot, I’ve been called the “Kanban guy” more than once. Whether that’s a good, or bad thing is yet to be determined. When prospective candidates interview for a position with us, and they list the method as one of their skills, you know damn well I’m gonna bring it up; especially when folks insist that if a team’s core function is support, or maintenance, they shouldn’t roll with Scrum, but Kanban. I hear this from newbs to veterans alike, and it makes me cringe every time.
Every. Single. Time.
Yeah, I get it. This is Serious Scrum, and I’ma talk about Kanban. It’s not that I prefer it over Scrum, but like anything, it’s incredibly important to know your sh*t. So, when I hear that misguided mantra, I call bullsh*t. Scrum is meant to be “…a framework for developing, delivering, and sustaining complex products.” Oh, wait. There’s that word: sustaining. You know, maintenance. I guess it was part of the dance all along.
Unfortunately, the idiom “Scrum vs. Kanban” is proliferated throughout the Agile community. Though seemingly innocuous, this idea is a harmful misnomer. In my experience, people tend to see Kanban as Scrum without Sprints. Yikes! Another glaring indicator of misunderstanding is when the team treats their “To-Do” column like a backlog (an artifact unique to Scrum). Work items up stack like a never-ending tower. The justification for switching to Kanban can come in the form of statements like:
- “New, unforeseen work comes in all the time.”
- “Our priorities change too often to operate in Sprints.”
- “I can’t show a burn-down to management if it looks jacked up.”
The rationale is that support, or maintenance teams can’t work effectively when constrained to an iteration. And therein lies the issue. Applying a constraint is purposeful, and intentional. It’s a fundamental element in understanding predictability, and what the team is capable of producing in a sustainable manner.
Kanban stresses the importance of not taking on more than you’re realistically capable of handling at any given time. Fundamentally, this is expressed with work-in-progress (WIP) limits, a constraint. Scrum employs something similar. Whether your iterations are one month, or less, the Sprint is a constraint too. If your team rolls in two-week Sprints, Scrum suggests that the team doesn’t take on more than they’re realistically capable of handling within that iteration.
As an added bonus, Sprints are also learning mechanisms. Support, and maintenance teams rolling with Scrum can use them to learn how many items they can reasonably handle per iteration. If they typically resolve ten defects each Sprint, maybe don’t drop any more in the Sprint Backlog during Sprint Planning. If a high priority item comes in mid-sprint, place it into the Sprint Backlog, and negotiate with the Product Owner on what can be pulled. Adjust accordingly, re-prioritize, and remove anything that borks the ten-item-per-Sprint constraint. Let’s be clear. Nothing dictates that you can’t remove items from a live sprint, nor add for that matter. Check the Scrum Guide if you don’t believe me. Taking it back to the Manifesto, we’re s’pose to welcome change, remember? Even late in development.
I’ma stop for a second, because I know what’s coming. Inevitably, folks will bring up the dreaded Sprint commitments argument. More times than not, this comes up when teams aren’t using Sprint Goals. If they are, the goals are written in a work-centric manner. We’re s’pose to be about committing to the Sprint Goal, not the work. If the goal is to “Support, and upgrades on the ordering widget for Super Fancy Product X,” when a new, high-priority item comes in, and is placed into the Sprint Backlog, lower priority ones can be removed. Lo, and behold. The team is still 100% committed to the Sprint Goal. You’ve already established that the team can only realistically handle ten defects per sprint, remember? What good will come from additional ones in the live Sprint?
Some folks will argue that the practice of constantly adding, and removing work items will make their burn down chart look terrible. “And what about our velocity?” they contend. Well, the point was never to maintain a perfect-looking chart, or some vague, magical number, but to measure progress toward a goal, and spot historical trends. Obsessing over velocity won’t help matters. This is where you need to be especially cognizant of falling into the vanity metrics trap.
“When a measure becomes a target, it ceases to be a good measure.” — Goodhart’s law
Simply put, a burn down is merely one visualization. Another way we visualize is by using what some folks insist on calling “Scrum boards.” However, the entire concept of creating visual representations of work comes from Kanban. Hell, the first thing it asks you to do is to visualize your freakin’ workflow. I’m paraphrasing, but you get it. This is accomplished with a visual board. The why behind visualization is to help you understand the system that you’ve created (processes, steps to completion, people, etc…). With the system visualized, you have the ability to quickly identify bottlenecks (where things slow down), and where to focus improvements. Too many items stacked up in the “Testing,” or “QA” column? You’re overloading that part of your system with too much work.
Maintenance, or support teams who’ve ditched Scrum over to Kanban run into trouble when their board becomes a dumping ground. They typically don’t employ WIP limits, and each column is overloaded. By ignoring the constraint (the Sprint in Scrum’s context), and obscuring the bottleneck the team will have no idea how much they’re capable of realistically handling. Without that knowledge, improving workflow becomes increasingly difficult. But hey, at least you don’t have to worry about a burn-down in Jira that looks like a city skyline any longer.
Sure, Kanban is all about the flow, but if you don’t fundamentally understand the sustainable rate of flow that teams can handle, predictability goes out the window, and forecasting becomes a herculean task.
“If we’re using technology X poorly and are frustrated, then moving to Y won’t help. We won’t experience frustration for a while, but only because we are distracted. All the same dysfunctions will reappear. Instead, start working better and then re-evaluate the technology.” — Kent Beck
So how do you decide? In terms of project work, or maintenance, both can be simple, complex, or both. One way is to instead consider the nature of the work itself. Would it make sense to press pause at regular intervals, take time to plan things out, and collaborate on a solution because the work is complex? That’s in Scrum’s wheelhouse. Is the entire system self-contained (next to no dependencies), known, optimized, and the work is rather straight-forward? Kanban could work for that.
In the end, if it’s a better fit for your team’s context, roll with Kanban. But learn it. Understand the why, and how to leverage it to your team’s advantage. It’ll make you a better Scrum Master. Hell, teams don’t even have to choose one over the other. Why not use both? There’s a slew of articles out there on how to use Scrum, and Kanban. Even Scrum.org, and the Kanban community have come together to express the benefits of working together.
If you still believe that Scrum is for projects, and Kanban is for maintenance, have a conversation with Toyota. Known for developing the Toyota Production System (TPS) — called Lean Manufacturing in the west — they’ve used Kanban practices to build new cars since the end of World War II. Maybe they can convince you otherwise?
</rant>
