Robert Frost’s famous poem “The Road Not Taken” is a brilliant cautionary tale about decision-making. The traveler must choose one of two paths that “diverged in a yellow wood,” looking down each as far as possible before finally choosing “the one less traveled by.” The speaker believes this choice makes a major difference in how his future unfolds, since it’s unlikely that he’ll ever have the opportunity to take the other route.
Marketers who hope to change their broken processes face a similar choice.
Agile marketing is inching toward the mainstream, enticing more and more teams to take their first tentative steps on this exciting path. And very early in their journey, marketers encounter a fork in the road. Will they take an iterative approach to agile, as embodied by the scrum methodology, or will they choose a flow-based approach, commonly known as kanban?
It’s not an inconsequential decision, but fortunately we have more data to act on than Frost’s uncertain narrator. Like the paths in the poem, both options are viable. There is no universal right choice when it comes to picking an agile approach. But making an ill-informed decision can still make all the difference, leading to frustration, lost opportunities and possibly even abandonment of agile marketing.
Let’s explore both of these common options, so you can pick the right path the first time and look back on the start of your agile journey with pride, not regret.
An Overview of the Scrum Path
Since the early days of the agile software movement, scrum has enjoyed a high degree of popularity. Recent surveys show that about 58 percent of agile software and IT teams use it, making it by far the most common agile approach.
The appeal is easy to understand. Scrum centers on short iterations, or sprints, during which an agile team commits to finishing a set amount of work from their backlog. Once they make that commitment, they’re supposed to be allowed to focus on those tasks to the exclusion of all other work.
During the sprint, the team meets every day in a 15-minute daily standup to talk about their progress and discuss removing any roadblocks in their way. By the time the sprint is over, the team should have something suitable for release to their audience or customers.
They demonstrate their completed work to others outside the group during a sprint review meeting and then get together as a team one final time during a retrospective meeting to talk about their process and how it might be improved. Then the process starts over with a new sprint.
Scrum methodology assumes a particular kind of team exists. The five to nine team members should be cross- functional, meaning most of them could pick up any task from the backlog and start working on it. The team should also be fairly autonomous and self-organizing.
To help ensure the scrum team is doing the right work during each sprint, a new role known as the product owner
is created. This person is the liaison between the team and the business, relaying priorities and strategies from above while protecting the team from unneeded distractions. A second role unique to scrum is the scrum master, who helps the team follow scrum’s recommendations and improve their process steadily over time.
As you can see, scrum is very prescriptive. For most teams, it represents a change to nearly everything about how they function. Sometimes that’s good, other times it’s not.
Scrum for Marketing
Teams who use scrum routinely report massive improvements in productivity and satisfaction, because they’re regularly finishing projects and getting them out the door instead of getting bogged down by interruptions. Marketing teams are particularly prone to emergency requests and unplanned work, so sprints can help us break out of that cycle.
However, the strict timeboxes can also create friction for marketers. We often have daily recurring tasks that aren’t necessarily part of a bigger plan but must nonetheless get done. Social media, for example, requires constant attention. How do we fit these things into a sprint?
Then there’s the problem of roles. Marketers are, for the most part, not building a product. This makes the product
owner role seem out of place. We can give it a different name—
marketing owner is what I typically suggest—but it can still be a bit out of sync with how marketers are accustomed to working.
The product owner usually acts as a buffer for the agile team, taking in requests, politely turning them down if they don’t align with the team’s goals, protecting the team from interruptions, and so on. But marketing leaders aren’t used to acting like this. They’re far more comfortable saying “yes” to everything and then figuring out how to get it all done. This role is usually the most difficult one for agile marketing teams to take on.
##tweet##
Who Should Use Scrum
If you take even a perfunctory glance at scrum, you can see that it won’t be right for each and every team or organization. But here’s who typically benefits from choosing this agile path:
Relatively small teams. Scrum works best on a smaller scale. If you have a team of five to nine people, or could create several teams of that size that are all cross-functional, then scrum could work well for you. Don’t, however, try using scrum within your existing silos. Having a content scrum team and a design scrum team and a social-media scrum team that all try to pass work back and forth will not get you the benefits you’re after and may even create more problems.
Cross-functional marketers. You’ll have the most success if you already have people who can do different kinds of work with confidence. Just as handoffs among different teams can create issues, the need to pass work through several different people on the team is likely to introduce stress into your sprints rather than increase productivity.
Teams who need protection. If your teams are constantly derailed by last-minute demands or other interruptions from outside of marketing, the protection of a sprint may help them. Being able to put a new request into the backlog for an upcoming iteration is a nice way of saying “no” while still providing good customer service to the person making the request. Of course, this does require a strong marketing owner who’s committed to being a buffer for the team.
Teams who can embrace change. Applying scrum isn’t an overnight project. It requires serious changes to how the team plans, how they interact with one another and how they think about their work. If your team is ready for something new, they may wholeheartedly embrace scrum. If they’re already overworked and overwhelmed, they may balk at such a big change.
Kanban: The Road Less Traveled
On the continuum of agile approaches, scrum and kanban are at opposite ends of the spectrum. Scrum is highly prescriptive, while kanban is supremely adaptive. Whereas scrum asks a team to follow its practices precisely, kanban is designed to be applied to your current way of working.
In other words, you don’t have to change anything about the way you do things now to adopt kanban. Sounds nice, right? The tradeoff is that kanban’s lack of structure requires agile marketing teams to do more critical thinking about their process (and its shortcomings). Here’s how it works.
First, sit down and sketch out your workflow, meaning what happens to a piece of work from the time it’s requested to the time you deliver it. This is honesty time. Your workflow should reflect what really happens, not the pretty imaginary picture of what you wish would happen. Then you turn that sketch into a real kanban board, which you’ve probably encountered thanks to the wild popularity of tools like Trello.
This board will be the lifeblood of your kanban team, so take a couple of hours to make sure it’s as accurate as possible.
Once you have a board, you need to fill it with work. Since kanban works within your current system, you can go ahead and put whatever you’re working on now in the appropriate column. So if you have a blog post planned but not started, it belongs in the defined column. A new email campaign that the team is actively creating would be in progress.
This is the simplest version of kanban, and just visualizing your work like this often reveals startling new information about where things are getting stuck and why that’s happening. But we can get even more benefit by adding in two more components of kanban: work item types and work in progress (WIP) limits.
Work item types are essentially categories of work. You can think of them like buckets that help you quickly sort projects and guide the team on how to handle things. Some common work item types are based on the level of urgency associated with a project, for instance:
- Expedite: An urgent request that requires immediate attention
- Fixed delivery date: Deadline-driven work, such as a webinar or in-person event that can’t be delayed
- Standard: Regular work that needs to get done but doesn’t have a specific due date
- Intangible: Nice-to-have work that will benefit the team or organization
After we know what kind of work we’re dealing with, we need to put some boundaries around how much work the team can handle. This is where WIP limits come in. WIP limits are applied to each column of the workflow, and they force the team to complete what they’re currently working on before they can start something new.
In this example, we have a WIP limit of five on our in progress column and it’s currently at that limit. That means we can’t start on a sixth project until we finish one and move it into the done column.
As you can see, all of these components can be applied to your existing workload without making any changes to how your team gets things done. Then, as you use kanban you can find opportunities for enhancement, unlocking a cycle of continuous improvement that delivers better results and more satisfied team members. Kanban teams manage this process through regular retrospective meetings, just like scrum teams do, and they also have daily standup meetings.
Who Should Use Kanban
Since it’s designed to improve your workflow rather than change it up front, kanban can work for just about any kind of team. Even teams of one can use its principles to improve their effectiveness.
But there are situations in marketing where kanban is particularly useful.
Teams outside the scrum size range. If your team is particularly small (four or fewer) or particularly large (10 or more), kanban is probably a better fit than scrum. You can certainly make scrum work at those sizes, but the adjustments needed might not be worth the time and effort.
Specialized teams. Scrum teams work best if they’re cross- functional, but kanban doesn’t have that requirement. If your team members have specialized skills, or if you rely on third parties (agencies, freelancers or other departments) to complete your work, scrum sprints may just stress you out. Kanban doesn’t stipulate cross-functionality, but it can reveal gaps in the team’s skills that you’d like to fill.
Teams inside a skeptical organization. Some organizations love agile, and they’re delighted when marketers want to give it a try. Others need proof before they commit, and for those situations kanban is a good option. Since it doesn’t require a lot of up-front change, kanban lets you get up and running quickly so you can deliver results and prove agile works without doing a big scrum launch.
Burned-out teams. It’s far less cumbersome to start using kanban than scrum, so if your team is in desperate need of process improvement but can’t bear the idea of making major changes, kanban is probably a better fit.
Choose Your Path Wisely
As you can imagine, this isn’t everything you need to know about either of these methodologies. Take these suggestions as a starting point, and try to look down each path as far as you can see. Keep reading, keep asking questions, and most importantly keep your team involved in the process.
It’s an exciting time to be a marketer. We’re forging new ground, and whether you choose kanban or scrum, you’re going to be exploring some new territory. Like Frost’s traveler, given “how way leads on to way,” we won’t be at this crossroads again. Choose wisely, and an amazing agile future awaits.
