As I write this we are at the halfway point of our current agile marketing sprint.
We are also in the midst of a total reboot of our priorities for the next seven days because we suddenly need to support a rapid implementation of new server locations overseas for our sister application SurveyGizmo.
This situation, among other things, has gotten me thinking about agile methodologies and marketing and wondering if there isn’t a better fit than the Scrum-ish techniques our team is currently using.
It turns out the answer may lie in a powerful hybrid of Scrum, Kanban, and lean strategies known as Scrumban.
So let’s take a look at Scrumban in general, and how its core principles can be adapted to meet the unique demands of an agile marketing team.
The Basics of Scrumban (Scrum + Kanban)
Scrumban was designed for more mature agile teams, those working in an unpredictable environment where plans and requirements constantly shift, and/or teams who are supporting existing products rather than creating new ones.
At its core, Scrumban pulls together some of the structural components of Scrum along with the intensely pull-based nature of Kanban.
(If you’re new to agile methodologies, you might want to check out our Guide to Scrum and Guide to Kanban for an overview before going ahead.)
Here’s an illustration of a Scrumban board and process flow:
Keep in mind that because it’s a hybrid approach, each team tends to implement Scrumban a little differently. That alone makes it a great option for most agile marketing teams, because we are already customizing any agile methodology that we choose so it will work within our industry rather than in software development.
In a nutshell, Scrumban is driven by events and demand rather than a pre-established schedule. It focuses on minimal planning, providing just enough of a backlog to give the team enough important work to do next.
Scrumban also ignores the focus on egalitarian, cross-functional teams that Scrum emphasizes. Instead, it embraces specialized roles within the team (a more realistic way to handle marketing skill sets).
Like Kanban, an agile marketing team using Scrumban will rely on WIP (Work in Progress) limits to ensure that they are not overcommitting themselves, and that they are focusing on delivering completed projects of a consistently high quality rather than dividing their attention among too many disparate tasks.
Individual WIP limits govern the workload for each team member as well as for the team as a whole. This is vitally important, because it protects your team’s sanity as well as the quality of its work:
If too many issues are in progress, the team is at risk of not finishing anything to high-quality standards. Instead, there should be a maximum number of tickets allowed per column. If the number of tickets in that column ever exceeds the maximum, the entire team should swarm onto that column and help move tickets on.1
Core Scrumban Components Agile Marketing Teams Need
While there are certainly diverse ways of “doing” Scrumban, there are a few key components that agile marketing teams probably need to keep in place. We should make sure to identify the circumstances that trigger particular events or actions, create and adhere to strict WIP limits, and use the power of the Kaizen to keep ourselves on track.
What “Context-Driven” Means for Marketing
Essentially, when your process is based on Scrumban you only do things (meetings, planning, adding items to the backlog) when the context warrants them.
So you don’t spend hours planning or estimating task size every other week just because it’s time to do that. Instead you only plan projects when your team reaches the pre-determined minimum threshold of new projects on their list.
Put simply, demand goes before supply.
For marketing, this can work extremely well, because your social media team’s workflow can be triggered by a particular event, such as the completion of a new article or ebook. They can then begin promoting it, and the content team would need to respect that team’s WIP limits with their release timing.
And speaking of respecting WIP limits…
The Necessity of WIP Limits
In Scrumban you don’t have timeboxed iterations as you do with Scrum, so you need strict limits on how much work can be in each category (planning/doing/testing/promoting/etc.) to keep your teams from becoming overworked or scattered.
Corey Lapas, author of Scrumban: Essays on Kanban Systems for Lean Software Development, gives this suggestion in a blog post on LeanSoftwareEngineering.com:
You might have a simple principle like prefer completing work to starting new work, or you might express that as a rule that says: try to work on only one item at a time, but if you are blocked then you can work on a second item, but no more. In our example, that rule gives us an effective WIP limit of 6 [two works in progress for each of the three team members].
WIP limits should apply even to your backlog, which should provide your team with the best thing to work on next, and nothing much beyond that. Backlogs can become more like dumping grounds for ideas, requiring time-consuming culling periodically.
In fact, “Scrum-style timeboxed planning usually provides a much bigger backlog than what is strictly necessary to pick the next work item, and as such it is unnecessary inventory and therefore unnecessary waste.”2
Calling a Kaizen
Arguably one of the best things about both Kanban and Scrumban is the elimination of huge sprint kickoff meetings, retrospectives, and other meetings that can eat into productivity and begin to feel maddeningly repetitive.
Unfortunately, the lack of regular review is also a potential pitfall of Scrumban; this is where the practice of Kaizen comes in.
Kaizen basically means continuous improvement or change for the better, and on agile teams, it should be a major focus. This is what scrum retrospectives are supposed to achieve, and teams that don’t use them need an alternative means of self-examination.
Team members should be able to “call a Kaizen” anytime they feel that the process is breaking down, and you can also schedule them to occur when particular conditions are met.
Maybe after you release 10 pieces of content your content team has a Kaizen to review their process, quality, and teamwork for areas of possible improvement. Or maybe your team meets to review email performance after every ten thousand sends.
Whatever conditions make sense for you are fine, just make sure you don’t end up running on autopilot and overlooking potential problems.
Scrumban and Agile Marketing: An Unstoppable Team?
In truth, most marketing teams are already working “on demand.” Scrumban may just be a systematized way to handle how our professional lives already work.
Our team currently uses a hacked version of Scrum for most projects, along with a Kanban board for content marketing, so we’ve tried some of the more common implementations.
The flexible yet structured nature of Scrumban appears to be as close to a magic bullet as agile marketers are likely to get, but I’ll report back on its real-world application and see if it holds up to use by our team.
Can Scrumban Save a Struggling Scrum Team?
For the past six months, our marketing team has been implementing and wrestling with Scrum. Things are getting increasingly problematic, so I’m hoping to convince everyone to give Scrumban a try.
In case other agile marketing teams are experiencing similar growing pains, here’s how Scrum is beginning to break down for our marketing team.
- Some iterations go smoothly, but we’ve had to create a special card that we’ve labeled “By the Way (BTW)” to mark new tasks or requests that crop up mid-sprint and need to be addressed.
- Our board is becoming a sort of Scrum Frankenstein’s monster. To try and manage asks and expectations and prioritization, we’ve created a column for stories for this week’s sprint, one for the following week, and a giant backlog of “wish list” items submitted by various members of our marketing team as well as other employees and stakeholders.
- A big team, active executives, rapidly changing market conditions, and more mean that oftentimes team members are working on as many as 8 separate cards in a given sprint. Multitasking (the bad kind) is running rampant.
- We’ve added three new team members with development experience who are helping implement marketing projects on our various web properties. They tend to work on different projects than the rest of the team.
- We are also meeting jointly with another team who handles high level sales. Their work and ours often intersect, but actual joint projects are rare. Nevertheless, we all need to stay up to date on each other’s work.
- All this growth, while awesome, has ballooned our team to over a dozen members. Meeting length and frequency are consequently becoming an issue.
The ever growing complexity of our team and its objectives feels like it’s just overflowing the boundaries of Scrum, and is simply too cumbersome for Kanban alone.
My hope is that Scrumban will give us the structure we need to manage a large team with a huge variety of projects while offering the flexibility to break free of the forced sprint cadence.
Knowing When It’s Time to Manage Your Methodology
Corey Ladas puts it very eloquently:
Scrum can be a useful scaffold to hold a team together while you erect a more optimized solution…At some point you can slough off the cocoon and allow the pull system to spread its wings and take flight.
We’re getting ready to take our inaugural flight soon. We’ll let you know if we soar or sink.