For much of Agile’s short history, Scrum has been the star of the show.
Development teams in various industries applied the framework and sang its praises far and wide. Personally, all the developers I know tell me “Scrum is King.”
However, when it came time to choose which framework I would use with our B2B marketing team I eventually chose Kanban, Scrum’s prodigal younger brother.
Given Scrum’s star status, the obvious question is “Why?”
There are a number of factors that influenced this choice. I also believe, many of them are common to other marketing teams out there.
I’m going to tell you why we made the choice to go with Kanban, but that doesn’t mean it’s the perfect framework for everyone.
If you’re leading a marketing team and still deciding between applying Scrum, Kanban, or something in between, keep in mind that it’s not about what is generally better, but what is right for your team.
Fifty four percent of respondents in this year’s annual State of Agile Marketing Report say they’re using a hybrid approach to applying Agile within their teams.
In other words, they’ve come to the conclusion that, “there is no one right way to do Agile”.
To my team, Kanban proved to be a great starting point to creating a flexible and customized process that fit our needs.
Here are some of the things we considered when making our choice.
The Pain of the Failed Sprint
In the marketing team I led between 2014 and 2017, we once tried structuring our work in two week sprints.
Our developers were working with a one month release schedule, but we knew our time boxes could be shorter due to the size of our tasks.
Even with the smaller task size, sprints seemed like they would be a moot point.
We knew we would rarely keep our commitments because of our external dependencies.
After two or three “failed” sprints, in which the output did not match the expectations we had set during our planning meeting, the team morale started to suffer.
Naturally, there are ways to bring team morale back up.
But, in our situation, moving to a flow-based method like Kanban helped us stay real when it came to our constantly changing priorities.
At the same time, it helped us avoid the negativity around the failed sprints and helped us focus on moving tasks continuously over the finish line.
Roles are for the Theater, not Kanban Marketing
We also tried giving members on our team traditional Scrum roles.
We had a Scrum Master, who was responsible for leading improvements in process, as well as a Product Owner, who translated and prioritized customer requirements into work items on our visual task board.
In our version of Scrum, once a sprint was underway the self-elected Scrum Master and Product Owner would become part of the executing Scrum team.
For us, the differentiation between master and owner and the general team created some friction.
This was especially true because the “master” and “owner” functions were coming back to the delivery team as members during the sprint. We couldn’t do without them.
When we learned that in the Kanban framework roles were optional and there was still room for continuous improvement on several levels we were thrilled.
Image from CA Technologies
In reality, the Kanban mindset allowed us to move away from figuring out how to take on official roles and encouraged the entire team to feel accountable for improving process, task prioritization, and execution at all stages of the work process.
We Didn’t Want to Make Meetings Mandatory
Depending on the discipline of the team, setting up mandatory Scrum rituals such as the planning meeting, review, and retrospective may prove necessary to the team’s success.
These obligatory events work well when:
- You need to carve out time for the team to suggest process improvements because they don’t feel encouraged to do so on an ad hoc basis.
- The team isn’t co-located, making it difficult to regularly share finished work and provide feedback face to face.
- The team is able to plan further ahead about initiatives that don’t rely on factors outside their control.
- There is someone to lead these meetings in a constructive and timely way.
For us, hosting these types of meetings when needed (as opposed to on the schedule demanded by the Sprint cycle) proved much more aligned with our team’s existing dynamic.
In fact, we started including elements of the review and retrospective as part of our brief daily standup meetings, a ritual we kept (and loved).
Although, some may claim it is not best practice to combine these, it helped us allot time to discuss all objectives -- both process and product -- without forcing our standups to drag on.
For example, team members would spontaneously suggest a process change and take ownership of its application during standups.
The completion of initiatives was also shared during standups triumphantly.
Planning for the day, for smaller work items, or week, for larger work items, also found its place in the format of the daily standup.
It’s no wonder both Kanban marketing and Scrum marketing support daily standups. From our team’s perspective, these meetings helped us steer incrementally towards our goals.
Ultimately, standups became a crucial touchpoint that we all relied on and allowed us to jettison most of the other formal Scrum meetings.
Timelines of our External Content Efforts
One of the main types of work our B2B marketing team would undertake was the creation and publication of guest blog posts in external media.
In B2B, education and thought leadership are crucial. Reaching decision-makers on their own turf even more so.
That’s why we focused on offering free, original guest blog posts to media outlets that already had a captive audience of the decision-makers we desperately wanted to reach.
The problem with external guest posts is the unpredictability of their publication schedule. We never knew when a piece would go out.
Our dependence on the external media outlets and the editors on the other side made it impossible to fulfil the sprint commitments that included guest posts.
Instead, we decided to find a way to measure how long each media outlet delayed the publication of our posts versus how long it actually took us to write them.
This data point led to a focus on measuring the lead time and cycle time of our tasks, two Lean metrics that the Kanban method supports.
Reliance on our Marketing Agency
For a time, our team collaborated with an external marketing agency. Their team handled some of the promotion of our content and supported our link-building efforts.
They were based in the United States and we were in Europe, so communication was tough. In an ideal world, we would be collaborating with them on one Kanban marketing board.
In reality, we had little-to-no predictability about their delivery times or where our priorities were in their queue.
This lack of visibility pushed us towards the adoption of Kanban. Being more flexible would allow us to quickly shift gears and capitalize on some of the agency’s ad hoc output in a timely way.
Education about Kanban vs. Scrum
The struggle is real. Overcoming misconceptions about Kanban marketing can be tough.
When you’re collaborating in a team with many members, chances are they will all have a preference about how and when they do things.
Getting aligned about which methodology to choose can be a really daunting task, especially if there are members of the team who have experienced one or more of the options and are able to influence the decision in a given direction.
Among the various teams within the company, we had members who had experienced the disadvantages of Scrum at their previous positions. They were also very vocal about it.
While this made our decision to go for Kanban marketing easier, it also helped us become more informed about the pros and cons of Agile’s main headliner - Scrum.
Team Over Best Practices
My team and I were among the 9% of marketing teams that chose Kanban as a basis for our workflow. As we became more confident in our Agile mindset, we evolved our process collaboratively, incrementally making it support the production of our best work.
Best practices are great, but no two teams are exactly the same.
There is no guarantee that what works for someone else will for you as well.
Different factors, such as your dependencies, org structure, or types of work items, will influence which best practices apply in your context.
When making a decision about which Agile process framework to use, consider how you already work and which practices will help your team succeed.
