May 7, 2018
Rolling out Scrumban with Andrea Fryrear
This year, our special guest star on all things Agile marketing, Andrea Fryrear, will be providing Agile marketing newbies with a monthly step-by-step guide to their first year as an Agile marketer. This post is the sixth in the series. Enjoy!
Chicken and waffles.
Chocolate and peanut butter.
Sea salt and caramel.
The world is full of combinations that complement one another, each part enhancing the other to create a partnership that’s somehow greater than the sum of its parts.
See "The Best (and Worst) of Times: Why Digital Marketing Needs Agility ASAP" to learn about the benefits of Agile marketing.
If you read those articles and thought to yourself, “They both sound so useful, I wish I didn’t have to choose between these two great options!” you’re in luck.
Because today I want to introduce you to Scrumban, a hybrid methodology that brings together some of the strongest components of both Scrum and Kanban to form a powerful hybrid methodology.
Put simply, Scrumban involves applying Kanban systems within a Scrum content.
When that simple phrase gets applied to reality, however, it becomes much more difficult to describe the results succinctly, because each and every rollout of Scrumban is unique.
The goal of Scrumban is to allow an Agile team to make pragmatic choices about how they get things done based on their particular situation.
The systems in which teams find themselves dictate many of their choices, and Scrumban offers the flexibility to create a methodology that fits within those systems (and makes them better).
When using Scrumban to manage an Agile marketing team, your objective is to meet the needs of the team and the organization, not to optimize for a particular practice.
Scrumban is also built to expand as the Agile marketing team grows in maturity. For example, it can easily embrace lessons from systems theory and the theory of constraints.
What Scrumban Takes from Scrum
Scrum was designed as a more efficient, more effective means of managing the work done by teams, and Scrumban hangs onto this team-centric approach.
The team remains in charge of planning its work and deciding how to execute it. It’s also the primary mechanism for process improvement, engaging in regular retrospective meetings.
Those retrospectives could happen at the end of a Sprint, just like they do on a Scrum team. But they might not. Some Scrumban teams maintain the Sprint Timebox, using it to govern the cadence of their planning, delivery, and retrospectives.
Others find that other components of the system can replace Timeboxing, and they move to a continuous delivery model more akin to the pull-based Kanban methodology.
What Scrumban Takes from Kanban
One of the most common complaints about Scrum is that it exposes problems without providing solutions.
There may be issues within the team, or issues in the interaction between the team and the organization at large. In fact, some organizations come to blame Scrum for causing the problems, when in fact all it did was bring them to the surface.
Scrumban maintains this ability to showcase shortcomings, but by adding Kanban to the mix it introduces possible solutions to the problems it exposes.
Kanban focuses heavily on visualizing marketing work via a Kanban board, which looks something like this before any work gets added:
After the team starts tracking its work on the board, it becomes clear very quickly where bottlenecks are forming. As the team gets more experienced setting its WIP limits (more on these shortly), these constraining points will become even more obvious.
Now the team can clearly identify the point in their process where the process is breaking down (in this case, editing) and address the problem, rather than simply lament their poor velocity every couple of weeks during the Sprint retrospective meeting.
The 4-Part Scrumban Kickstart Event
The first step to using this adaptive approach is to run a Kickstart Event, a meeting in which the team will nail down the foundational elements of Scrumban so they can start using it to manage their work.
Like Kanban, Scrumban is designed to fit within your current work management approach, which means you don’t have to change anything about how you work before you implement it.
An Agile coach can guide you through an intensive Kickstart that includes exercises and detailed walkthroughs of all the intricacies of Scrumban, but if you want to handle it on your own you can boil it down to just four steps:
- Visualize the Workflow
- Identify Work Types & Build the Backlog
- Set Preliminary WIP Limits
- Schedule Major Cadences
Visualizing the Scrumban Workflow
Many Agile teams use a Kanban board like the one above to map what’s up next, what they’re working on now, and what they’ve completed, but during a Scrumban Kickoff we want to get more specific.
We want the whole team to discuss how work happens, including:
- Where does it come from?
- Who makes and receives the requests?
- What kind of approvals need to happen?
- Where does work go when the team is done?
- Does work need to be revisited in the future?
All of this information then needs to be reflected on the board. If you’re doing a Scrumban rollout for a large team that handles several different kinds of work, then you may want to create two or three distinct workflow visualizations.
Your content marketers, for example, may handle work much differently than the events team.
So if you try to create a board that will accommodate both of them, it’s likely to either be so generic that it gives you no insight into bottlenecks, or so complex that you can’t see what’s going on with a particular project.
The goal of visualizing the workflow is to create the simplest version of the board that will still accurately reflect the work being done. Seven columns, 10 if you’re handling very complex projects, should be all that you need.
A casual passerby should be able to glance at the board and get a sense for how things are going.
Identifying Work Types and Building a Backlog
Work types are like buckets into which you can put all the work your team has to do. As with all things Scrumban, you’ll need to base your work item types on the unique situation you’re working in, but consider these initial work types:
- Work that has the most value for customers or partners.
- Work that is demanded the most and the least.
- Work that is usually more urgent than other types.
- Work that is most and least aligned with the team’s ultimate purpose.
As you choose your work type buckets, use them to categorize the team’s current workload too. This categorized list can then be turned into your first backlog, a prioritized to-do list from which the team pulls its next round of work:
You may find that in order to project completion dates your team needs to estimate the size of work in addition to categorizing it, particularly in the early days of a Scrumban rollout.
But as time goes on it’s likely that you’ll begin to understand that Work Type 1 tends to take six days to finish, while Work Type 2 can get done in just two or three days.
This general sizing often eliminates the need for task estimation, a Scrum practice that troubles many Agile teams. Combining work types with WIP limits makes delivery dates even more precise, and estimation even less necessary.
Preliminary WIP Limits
Work in Progress (WIP) limits govern how much work a Scrumban team can have in any given state at once:
If you have a WIP limit of five on your In Progress column and there are already five things being worked on, no one on the team can begin new work until something moves out of that column and into the Done column.
WIP limits are enormously powerful, but one of their most important tasks is to show where bottlenecks happen. If the board above was for a five-person team, and the In Progress column was always at its WIP limit even though two team members were idle, a problem would be very clear.
Either the two idle team members need to jump in and collaborate on the In Progress tasks so they can be marked as done, or other team members need to limit their personal work in progress more closely so the team’s flow can proceed.
It can be tempting to set WIP limits of one or two on every column, but when choosing your first WIP limits start a little higher than you think you should and work your way down.
This will allow enough work to enter the system to reveal bottlenecks in the workflow; very low WIP limits not only slow down the flow of work, they create multiple idle team members.
Scheduling Major Cadences
As the final step in your Scrumban Kickstart, you need to settle on some initial Cadences to govern your team’s process.
You can discuss releases and delivery of completed marketing campaigns, planning, backlog refinement, and other typical ceremonies, but at the very least you need to tackle three core cadences:
- Sprint length
Scrumban Standup Meetings
The Cadence of the Standup is pretty much already decided for you: nearly all Agile teams will get the most out of this meeting if they have it every day.
However, Scrumban teams typically benefit from using the Kanban style of Standup. This format foregoes individual updates on what team members did yesterday, what they plan to do today, and any blocks impeding their progress.
Instead, a facilitator walks the team through the Kanban board in reverse order, from Done to the Backlog, discussing notable work items.
This type of Standup should still take only 15 minutes, but not every team member has to speak.
How Often to Have Retrospectives
A new Scrumban team will benefit from regular Retrospective Meetings, so I’d strongly suggest holding them at least every two weeks.
(If you’re not familiar, during a Retrospective Meeting an Agile team discusses their process, including what went well, what went poorly, and what concrete steps they can take to make the next iteration better.)
Scrumban teams aren’t beholden to Sprints, however, so you can also hold impromptu Retrospectives if there are moments of learning that you want to apply in advance of your next scheduled meeting.
Finally, the team should determine if they want to start out by using Sprints. If so, they should end their Kickstart meeting by deciding how long those Sprints will be.
For Scrumban teams engaged in continuously delivering marketing work, such as social media or blogging, Sprints may not be necessary. Those that feel more comfortable with Timeboxes and deadlines can start with the traditional two-week Sprint and adjust its length as they see fit.
A Powerful Combination
Will this potent combo be the magic bullet for your Agile marketing team? It boasts many of the strengths and few of the weaknesses that plague its predecessors, Scrum and Kanban.
But its flexibility can be intimidating for teams new to Agile and lacking an internal coach or advocate. If structure and certainty will help you get started, Scrumban’s adaptability might be a detriment.
In the end, it’s up to each Agile marketing department to take a long, hard look at all the available methodologies and decide which seems likely to meet their needs. The good news is, even if your first choice doesn’t work out, you can always pivot to another.
Agility is a constant work in progress, and your team’s methodology should be too.
Our post "Finding Your Hybrid Project Management Sweet Spot" can help you determine which hybrid methodology is right for your team.