If Kanban is the adolescent member of the Agile work management family, Scrumban is the wee toddler.
Although the foundational work on the methodology was published in 2008 (Corey Ladas’ Scrumban: Essays on Kanban Systems for Lean Software Development), it hasn’t yet caught on in the software world. But don’t let this scare you away from giving Scrumban a try!
Because it’s still emerging, we have a chance to make our voices heard before its practices become as solidified (some might say fossilized) as those of Scrum.
While Ladas wrote the original book on Scrumban, a more helpful guide to its actual implementation was recently released in the form of Ajay Reddy’s The Scrumban [R]Evolution: Getting the Most Out of Agile, Scrum, and Lean Kanban (2016). This should be the foundational document for any marketing team looking to roll out this method; it’s far more practical than Ladas’ work, and includes case studies and examples. (Software case studies, yes; and we can learn from them.)
Although its name is obviously a combination of Scrum and Kanban, Scrumban isn’t just about mashing together a few pieces of each methodology and calling it something new.
Reddy defines it as:
applying kanban systems within a Scrum context, and layering the Kanban Method alongside Scrum as a vehicle for evolutionary change. Ultimately, it’s about aiding and amplifying the capabilities already inherent in Scrum, as well as providing new perspectives and capabilities.
Scrumban emerged to fill gaps in both the Scrum and Kanban methodologies, which seem obvious in retrospect. Scrum covers meetings and roles in detail, but it does little to provide guidance on how teams should go about completing the work they commit to in each Sprint. It focuses on managing the project and the team, but not tasks themselves.
Kanban concentrates on the completion of individual work items. It assumes that some form of project-management system is in place on a team, and promises only to improve existing systems, not to create them.
So, for thinkers like Ladas and Reddy, putting the two pieces together just made sense.
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.
Anthony Coppedge offered a great description:
So, to summarize: Scrumban leverages the ceremonies of Scrum and the flexibility of pull-based Kanban, allowing structure and organization to keep the framework in place and accountability and transparency high while also adapting to the realities of change during a Sprint for marketing.
Scrumban is the combination of Scrum (the ceremonies of Sprint Planning, Stand Ups, Retrospectives) and the pull technique of Kanban with WIP (work in progress) limits. Therefore it is actually driven by BOTH demand AND a pre-established schedule. Allow me to illustrate, below.
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
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.
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…
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 Ladas, 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
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.
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.
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.
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.
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.
Portions of this article originally appeared on MarketerGizmo.com