How to choose the right agile marketing framework
Before you decide on a Kanban or Scrum agile approach, it helps to consider your company culture, team size and the type of team you lead.
I often get asked which framework is better for agile marketing — Scrum or Kanban? The truth of the matter is every company and every team is a unique organism with differing needs and there’s no one-size-fits-all approach.
Having coached a lot of teams over the years in marketing, software and everything in between, there are a lot of things you can think about to help you select the right framework to best meet your needs.
A lot of marketers have started agile marketing with no framework at all. While that may work in a really small, lean organization that is well-aligned to the agile marketing principles and values already, most marketers are transitioning from a traditional culture, and therefore benefit from a proven way of implementing agile marketing.
The origin of Kanban and Scrum frameworks
Before you can select a framework, it helps to really understand each of them in-depth and I encourage you to learn more, but here’s a high-level overview:
Kanban originated in manufacturing and was popularized by Toyota as a pull system for optimizing workflow and efficiency. Today it’s widely used on agile teams. Kanban has no specific roles and the belief is that you start with where you are today, empowering people at all levels to be leaders in pursuing evolutionary change. The team looks at its workflow and everyone is empowered to streamline the process to maximize efficiency.
Scrum was created from the software development community a few decades ago, but today is widely used in many corporate departments as well as in schools, home, house flipping, wedding planning and more. Scrum includes three roles: A Scrum Master, Product Owner and Development Team. It is a continuous cycle of timeboxed events meant to ensure collaboration and transparency. The team works in sprints, which can be anywhere from one to four weeks in length, with the goal of having potentially shippable or ‘done’ work at the end.
Now that you have a bit of context, here are some things to consider when choosing the best framework for your team.
Company size and culture
In general, large companies coming from a traditional culture often prefer Scrum because it’s closer to how they’re already accustomed to working. If your company is used to a lot of formality and process, moving to Kanban will feel like you’re being thrown into the middle of the ocean without a safety net.
I was recently training a healthcare company on agile marketing and after in-depth learning of both frameworks they unanimously agreed that Scrum fit their culture better. Kanban was way too unstructured compared to how they’re currently working.
On the flip side, startups or marketing agencies are usually smaller in size and often are naturally more ‘agile’ to begin with. This opposing culture may find Scrum to be too structured and rigid for their loose way of working and are better suited for Kanban.
These, of course, are generalities. I’ve seen teams within large companies thrive using Kanban and I’ve seen small companies take on a very lightweight approach to Scrum.
But if you’re looking for a starting point, Scrum may be better suited for a larger, more traditional organization and Kanban for a smaller, leaner one.
If you tell me you have three people on your team, Scrum is not for you. A small team doesn’t need it’s own Scrum Master and Product Owner, so if you have just a few people, stick to Kanban.
The recommended Scrum team is a two-pizza team. Any more, it’s too big. Smaller than that and you just have a team. A good size is five-to-seven members plus a Scrum Master and Product Owner.
Kanban doesn’t give specific recommendations on team size. I’ve found it works great for one person running a solo business up to a team size of approximately ten people.
Ability to plan
If your work changes every few days or few hours, Scrum will be difficult to implement because of its sprint time boxes. Kanban works great for teams that get a lot of requests frequently that can’t be planned. I’ve seen Kanban effectively implemented for social media teams who deliver multiple times a day, or teams that run online promotions that need to change with a lot of regularity.
Scrum is great if you can plan 80 percent or more of your work and stick to that plan for at least a week, possibly two. If a typical campaign takes you weeks or months to deliver right now, Scrum may be your best bet. However, you can still deliver work anytime in Scrum, not just at the end of a sprint.
Type of team
There are two main types of teams I see in agile marketing — support teams and cross-functional teams.
Support teams are groups of people in the same discipline who support several areas within the organization or with external clients. Content marketers are often a support team for the rest of the marketing department. These types of teams work better using Kanban because the requests come in quickly and work typically happens in the order it’s requested.
Cross-functional teams are ideal for Scrum because they can deliver a campaign from end-to-end. A cross-functional marketing team may have on it a strategist, content marketer, graphic designer, web developer, editor, SEO specialist and anyone else needed to deliver directly to the client without having to go to another team.
Scrum was really built upon the idea of the cross-functional team and the end-to-end delivery of work, although that can happen as well with a Kanban team.
Experiment and learn
Agile marketing is all about experimentation and learning and the best teams I’ve seen are the ones where leaders allow each team in the organization to choose a framework that best resonates with them, try it for a while and modify if needed.
A lot of agile marketing teams end up using a hybrid approach to these two frameworks commonly called Scrumban.
The goal of a framework isn’t to perfect a process, but rather to have a proven, known way of being an agile marketing organization.
Opinions expressed in this article are those of the guest author and not necessarily MarTech. Staff authors are listed here.