Many people, too many people, have compared Scrum to Kanban. Too many people still think they have to choose. I’m not going to go into that now. It’s like arguing against a flat-earther. I’ll just say, Scrum and Kanban are not mutually-exclusive options. They are two very different tools.
Let me just begin by making it clear that that Kanban is a tool for balancing demand and capacity (that means not promising more than you can do or taking on less than you’re capable of) and for incrementally improving the flow of value through a system (getting better at doing the right stuff). Scrum is a set of tools that play well together for getting things done in collaboration with other people. It’s about agreeing on who does what and when.
That said, Kanban teams can learn a lot from Scrum. Why?
The two combined are powerful, but if you’re adopting Kanban, and you aren’t using Scrum, then what do you do? Kanban tells you to “start with what you do now” and so adopting Scrum AND Kanban at the same time only makes sense if 1) you’re just getting started on a brand-new project with a brand-new team that’s never worked together before or 2) the present situation is so abysmal that it will self-destruct at any moment leading to the permanent dismantling of the team or company (this is rarely true; try not to fall for any “burning-bridge”-style change consultant bluster). Because Kanban assumes that no matter how messy it looks or how many people are giving you grief, if you’ve got a system that is somehow paying people’s salaries then something must be working. Why not figure out what it is and build on that? It’s safer and more likely to succeed than throwing the baby out with the bathwater.
But, if you’re adopting Kanban, and you’ve got a process that isn’t Scrum but isn’t hopeless, either, there’s still a lot to be learned from Scrum. Like so many other product development methods, Scrum is a set of rules and procedures that is optimized for someone else’s situation, but that can be tweaked to shoehorn it into a surprisingly wide variety of places. Why? Because it includes, in one handy little package, the four components of a working software development system. You might find that those particular tools are not optimal for you, but I’m going to argue that all four components are essential and that you probably have them all even if you don’t realize it now.
Those four things are roles, rules, rituals, and reports. I call them the four R’s. In some organizations, usually the more dysfunctional ones, there’s a fifth R — repercussions. I say dysfunctional not because there should never be repercussions, but because an effective learning organization learns and adapts from unexpected setbacks, and repercussions imply formally or informally understood personal penalties for mistakes independent of a learning phase. But let’s focus on the primary four Rs which any process needs to succeed.
I became aware of the four Rs when I implemented my first Kanban process wrong. I was always a by the book kind of guy. I was a vocal member of the Scrum-but crowd who was quick to blame poor implementations of Scrum for its failures rather than Scrum itself. My Kanban journey is also my journey from Theory X to Theory Y management. Because of Kanban, I came to see that the system is at the core of most organizational successes and failures, not the people in it. So being a by-the-book kind of guy, I didn’t want to drag any Scrum baggage into my first Kanban experience, and so I chucked it all. We created a board based on how we thought we did things and scheduled a daily standup meeting to review the board. But we removed roles, sprint reviews, the three questions we used in the standup meetings, sprint retrospectives, and Sprint planning. Needless to say, we missed most of those things very quickly. I should have known better. In my defense, this was almost a decade ago, and there weren’t any models to follow. David Anderson hadn’t even written his Kanban book yet.
The Four R’s
There are certain things that any process needs to work, and they are role, rules, rituals and reports. If you’re applying Kanban to a process that is not Scrum, and something’s going very wrong, you might check to see if you have these four things in place.
Roles, whether explicit or implicit, make it clear who does what. If you’ve got people blaming each other for mistakes, or stepping on each other’s toes, perhaps you need to experiment with making roles a bit more explicit. Or, if the opposite is true and no one is taking responsibility for something, then the scope of the roles is perhaps not clear enough. I like how Scrum gets rid of functional roles but makes it clear that the responsibility for achieving Sprint goals and ensuring quality levels lie with The Team. Are you on The Team? Then quality is your responsibility.
Rules address the edge cases that don’t come up regularly. They help to manage complexity and provide constraints for problem-solving based on experience. “We never release to the testing environment until all automated tests pass” or “Nothing goes to production without the Product Owner’s approval” are the kind of rules that can save a team a lot of grief. I’m not saying they are good rules in all situations (in Kanbanery we don’t have either of those rules, for example). If you see common problems with easy solutions, perhaps the answer is a clear rule.
Rituals serve two important purposes for people. They mark periods of change, helping people to understand that some things are going to be different from now on (like the ritual of marriage or a retirement party). In a software team, they do something else that is also extremely important. They make those really important, but not urgent things like learning and experimenting into habits. When things are going badly, who would call for a retrospective if it weren’t already on the schedule? And why would it be on the schedule if it wasn’t something we always do at the end of a Sprint? If there’s something important that you never have time for, consider incorporating it as a ritual with a name, a purpose, an agenda, and a trigger. A trigger can be time (every two weeks, every Friday) or some event (after every release, or every time there are less than two cards in the ready column).
Reports provide essential feedback loops that support continuous learning. In Scrum, they are the burndown chart, the Sprint board, the daily standup, and the backlog. Each is a report that provides clear and essential data to team members and project stakeholders. If your team is fielding questions from higher up, from users, or internally, consider whether a simple verbal, email, or wall-mounted report would address those questions so the team can focus on delivering value.
And one to avoid
Beware of the fifth R, repercussions, which commonly appears to make it easy to lay blame at the feet of people. When you do that, you take your eye off the system which is the best place to effect a lasting solution.
I hope that way of thinking about the various components of a process is helpful in identifying what’s working, what’s not, and where you might have some holes in your system. Remember when you make changes to treat them as experiments, or you might end up making things worse or adding complexity that doesn’t add value.