Godzilla versus Mothra. Microsoft versus Apple. Pineapples versus pizza. There’s no shortage of great rivalries in the world. But for those of us concerned with optimizing workflows, few can match the ongoing debate between flow and iteration.
In Agile parlance this often comes down to a match up between Kanban, the embodiment of continuous flow, and Scrum, the champion of recurring iterations. While there’s also a mash-up of these two frameworks known as Scrumban, the tendency to force teams into a choice persists.
We’re told to pick a side, choose a winner, get on a team and stay there.
But as Agile expands its influence outside of software development, the relevance of this dichotomy is fading.
Groups like marketing don’t benefit from choosing sides in this debate. When we pigeonhole our practices and rigidly follow one framework, our effectiveness suffers. We might be comforted by the act of choosing, but picking team Kanban or team Scrum for life glosses over the nuances and complexities within our workflows.
Rather than choose once and for all, I propose a more adaptive approach. This alternative framework, known as Rimarketing, was developed as a result of years of work with thousands of marketers, and it bypasses the need to choose sides in the framework wars.
Why Agile Marketers Shouldn’t Choose Sides
It’s vital to remember that, whatever you think about the Scrum and Kanban frameworks, they weren’t built to manage marketing work (or finance, or human resources, or any knowledge work beyond software development).
Kanban, the older of the two, was developed by Taiichi Ohno at Toyota in the 1940s to streamline the production of cars. It’s heavily influenced by Lean principles of waste reduction, and focuses on using visual cues (kanban loosely translates to “signal card” in Japanese) to indicate when certain actions should occur.
While many of its core principles have been extrapolated to apply to non-manufacturing activities, there’s no getting around its origins.
Scrum, likewise, evolved to meet a very specific need in a very specific environment.
In the 1990s, as software development emerged as a new kind of knowledge work, older systems of project management proved ineffective in handling these new processes. Software updates took many quarters, sometimes several years, to complete, only to be released to an unenthusiastic (or downright disappointed) consumer. All of this despite months of information gathering and huge requirements documents.
Scrum’s short iterations, called sprints, were put forward as the antidote to this absurdly long and ineffective process. Rather than work for months to produce a huge chunk of work only to discover that it wasn’t what people wanted, developers would work for a couple of weeks on a small piece of valuable code and then show it to real users.
If they liked it, they’d keep working on it. If not, they’d throw it out and try something else.
For better or worse, neither origin story reflects the realities of modern marketing work.
Marketers have to balance ongoing, recurring activities (content creation, email distribution, social media communication, etc.) with major strategic efforts (product launches, events, press releases) and requests from others inside the organization for our expertise (sales enablement, PR, customer support, etc.).
We aren’t building a steady stream of similar vehicles, nor are we accumulating valuable features of a single piece of software.
In the past, applying Agile to marketing has been a bit like being asked to build a birdhouse with paper and staples. You might create something that looks sort of right, but it’s not going to do the job you were hoping it would.
Related Article: How to Build a Sustainable Agile Culture
Rimarketing: Getting to AND, not OR
Having seen this happen time and time again with marketing teams I’ve worked with, I developed a new Agile framework known as Rimarketing. You can read more about the origins of its name here, but the TL;DR version is that it’s intended to be the culmination of long years of study, experimentation and evolution.
Essentially, Rimarketing doesn’t force marketers to choose between flow (Kanban) and iteration (Scrum). It embraces our need to move between these modes periodically.
Because flow-based systems are historically easier to implement, Rimarketing suggests that teams begin there. Visualize your upcoming work in a queue (prioritized to-do list), use a kanban board to track what’s in progress and what’s stalled, and build in moments to inspect your process and adapt to what you’ve learned (also known as a retrospective meeting).
This state of flow will serve some marketing teams, particularly those for whom sprints are nothing more than arbitrarily imposed deadlines, for much of their time.
Others will find that from time to time they need to use iterations to provide intense focus on a small subset of their work for a period of time. When that happens they deliberately transition to a more Scrum-style way of working by planning sprints, holding reviews, etc.
Once their crucial project or effort is over, they can return to flow.
Related Article: How Flow Science Helped Us Align Marketing and Sales
Does Everybody Need to Iterate?
One question that comes up really quickly when people are introduced to this concept is whether every single person on an Agile marketing team needs to jump into the sprints at the same time.
In other words, can a subset of the team enter into a series of sprints while the rest remain in flow?
While this can sometimes work, it essentially splits the team into two parts, each working in different ways. Depending on what’s driving the move to iteration-mode, that might be OK. But if parts of the team are working differently on a regular basis, you might actually have two distinct teams that have been smushed into one.
So give it a try once or twice, but keep in mind that the ideal situation is for the entire Agile team to move in and out of flow together.
Don’t Get Trapped by Your Agile Framework
If you’re a marketer struggling to choose between Scrum and Kanban, maybe that choice isn’t one you need to make. Consider whether you might benefit from a more flexible framework, one designed to evolve with the kind of work you do, rather than force you to fit your work inside it.
If you’re curious about the framework, you can read more about it here.
Unfortunately I can’t help with that whole pineapple versus pizza thing.