This is a recap of my presentation at Content Marketing World 2017. If you’re interested in bringing a similar talk to your group or organization, give me a shout.
It’s no secret that Scrum has a great public relations firm, but in the world of Agile marketing it's anything but a magic bullet. Instead, its counterpart known as Kanban may be the best hope for Agile marketing teams to get the results they're.
Since the earliest days of the Agile software movement Scrum has been the de facto methodology for that industry, and recent results from VersionOne’s annual State of Agile survey prove its continuing dominance:
The title of this post not withstanding, I actually don’t have a problem with Scrum. Years ago it swooped in and saved my sanity when I was the lone content creator on a marketing team.
My problem comes when marketing teams start defaulting to Scrum for no better reason than it has the best brand awareness.
My problem is that we’ve started treating Scrum the same way Gus from My Big Fat Greek Wedding treats Windex. Gus believes that any physical ailment, from psoriasis to poison ivy, can be cured by applying Windex.
And marketers are starting to do the same with Scrum.
We assume it will magically save our broken process, when in fact it comes with its own set of issues.
From day one Scrum was created to work in particular contexts, namely on fairly small teams with highly cross functional team members. Scrum teams work best with 5-9 team members, and sprints run smoothest when each person on the team could pick up any task and competently work on it.
Software teams have struggled with these criteria for years, and marketing teams are no different.
We’re in a particularly tough spot when it comes to cross functionality since silos and specialists are the norm in nearly every marketing department out there.
Additionally, Scrum isn’t designed to be terribly flexible.
Regardless of what’s going on with your team, you get sprints, a Scrum master, a backlog, and all the other trappings of Scrum, and you’re expected to use them in very specific ways. It doesn’t take a team’s unique context into account.
As a result, some team members’ problems simply won’t be solved with Scrum.
They’ll have to go through the painful rollout process, change up the way they manage their work, and start being evaluated as a team rather than as an individual, all without seeing much improvement in their day-to-day struggles.
You can imagine how that kind of situation impacts people’s commitment.
Given all of these issues, it’s no surprise that marketers report very different methodology preferences than their counterparts in the software world:
Given all of this, you can see why I pose the question about Scrum’s departure. In many cases, marketers need to show Scrum the door, because it’s going to cause more problems than it solves.
In its place, I propose that we look to the more adaptive methodology known as Kanban.
One of the primary hurdles to Kanban adoption is a lack of familiarity, so I want to offer an overview of six main Kanban components. My hope is that this will provide you with enough background to get started, and also that this kind of methodology empowers you to learn and adapt over time.
Before we dive into each of these components in turn, it’s important to remember that Kanban is designed to work on top of your existing process. It will reveal issues and bottlenecks so you can make them better, but it assumes you have some sort of work management going on right now.
Before we make the well-known kanban board, we have to figure out how work really gets done on the team. In most cases, that means we need a simple sketch like this:
We’re looking at where work comes from, including stakeholders, executives, the team itself, what happens to it while it’s in the team’s hands, and then where it goes once it leaves the team.
There are two important considerations here:
Once your process is out in the open, you get to turn it into a kanban board:
Your workflow sketch should guide you toward what columns reflect your team’s process, but if you’re struggling think of gates, gatekeepers, or handoffs and use those states as your column labels.
Keep this board simple -- no more than ten columns at most.
If you find you need more than ten columns, you might actually need more than one board because the team deals with a wide variety of work.
The second, and in my opinion most awesome, part of Kanban are known as Work in Progress (WIP) limits. They put strict limitations on how many items the team can have in each column of their kanban board.
That might not sound very exciting, but WIP limits do amazing things simply by forcing us to finish a project before we can start on another. (You can read more about their powers in this article.)
When we jump around from project to project we introduce a HUGE amount of waste into our days. As this very depressing chart illustrates, working on just five things at once leaves us a meager 5% of our time for each project.
The rest of our time, 75% of it to be exact, is wasted as we spend time and brainpower switching from one thing to the other.
The next question, of course, is what should your WIP limits be?
That varies from team to team, but we’re looking for a number that delivers:
Downtime for team members, known as slack in a Kanban system, may sound like a bad thing. But in reality it’s a source of innovation and productivity.
Slack lets us tackle professional development, consider process improvement, and enjoy creativity. Without it, we work nonstop and eventually burn out.
Before we start filling our shiny new kanban board with stuff, we need to consider the rules and policies that will govern our team and its work.
Many of us have implicit policies. We follow our own procedures to get our little slice of a project done, and we give little thought to how it impacts others. But by making policies explicit, they become available for optimization.
The first, and possibly most crucial, policy for any Agile marketing team is the definition of done.
What has to happen before a piece of work is actually finished?
How many rounds of review should it go through?
Is it done when it’s published, or when we’ve promoted it on social media?
Should we include imagery, or will that be handled by a different team?
Do we need to measure success before a project is done?
As you can imagine, you may have multiple definitions of done that apply to different kinds of work, and that’s completely fine. You may also want to create policies around:
As you may have noticed during our discussion of the definition of done, marketing teams are often responsible for vastly different kinds of work, each of which needs to be dealt with according to its own rules.
To help us manage that complexity, we use Kanban work item types.
The easiest way to think of these is as buckets:
As work comes in, we want to be able to put it quickly into the right bucket so we know precisely how to prioritize and work on it.
BONUS: Work item types allow Kanban teams to bypass the practice of estimation because size becomes a much less important factor in how they handle work. Instead, they use their buckets to pull the right work from the backlog.
Here are some potential labels for work items types on a marketing team:
If I’m choosing my next project and there’s a Standard item and an Expedite item at the top of the backlog, it’s pretty obvious that I should pull the Expedite item first.
You can then create explicit policies for each of these buckets. For example, maybe an Expedite item must be pulled as soon as it enters the backlog, and Standard items need to be completed within six days of entering the workflow.
It’ll be up to the team (and possibly their Agile coach) to figure out what work item types and policies work best for them, but don’t let the number get out of hand.
Try to keep your work items under six, and the number of policies that govern each of them below six as well. This guideline will allow the team to retain the whole system in their memories without needing to consult documentation, which will in turn streamline their efforts to finish work.
The fifth piece of an effective Kanban implementation is to decide on your cadences. In a timeboxed system like Scrum, everything is based off the Sprint.
At the start of the Sprint we do planning, in the middle we do daily standups, at the end we do review and retrospective.
In a flow-based system like Kanban, each meeting and event can run on its own schedule.
So maybe we need to refill the backlog once a week, but there’s no need for structured planning that often. We can have retros every weeks, but only do reviews after a major campaign release.
Each cycle can be based on the team’s needs rather than tied to a Sprint.
The exception to this rule is the daily standup meeting, which should still happen each and every day no matter what type of Agile marketing team you’re on. This meeting keeps communication and collaboration flowing through the team. Don’t skip it.
Finally, no matter what initial configuration you land on for your Kanban marketing team, don’t let it become stagnant.
Commit to continuously and deliberately improving the system over time.
This might include specific process changes like adjusting how your kanban board is laid out, or more team-centered adjustments like cross-training. Whatever it is, just make sure you keep pushing yourself to get a little better.
That’s the power of Kanban -- it doesn’t demand a lot of up front change, but it will deliver dramatic improvements over time.
If you’re finding yourself uncomfortable with how loose the guidelines for Kanban, you can combine its adaptive nature with the structure of Scrum in the hybrid known as Scrumban.
The full slide deck below finishes with a 4-step process for rolling out this approach on your team, so check it out and see if its boundaries feel right for you and your team.
Whatever you decide, just don’t revert to Gus’s Windex approach. Pick the right tool for the right project and you’ll get the Agile marketing results you’re after much faster.
Is It Time for Scrum to Scram? Alternative Agile Marketing Methodologies from Andrea Fryrear