Scaling Agile marketing is a topic that I expect to come up more and more as Agile gains currency with marketing groups. It’s certainly coming up frequently on The Marketing Agility Podcast so this post pulls together some of my thoughts on the topic. By way of introduction to the topic, here’s a brief quote from my book The Agile Marketer I point out that:
Agile methods scale about as well as any other method. The same scale issues that arise with Waterfall tend to come up with Agile. The single biggest one is communication: The more individuals involved in a project, the bigger the challenge it is to ensure good communication. Dunbar’s number applies here; it states that there is a limit to the number of people with whom one can maintain stable social relationships. This is, of course, an inherent barrier to scale, not unique to Agile.
There’s also a second issue to contend with, namely that Agile must be integrated with more traditional research, planning and strategy practices. In other words, scaling Agile isn’t isolated to the teams that are doing implementation. There must be a robust connection between those teams and leadership teams. This is hard and something that I discuss at length in my book but since it was published I’ve come across some frameworks that I think are very useful to consider as you grapple with scale.
I’ve embedded 3 fairly long videos in this post that get into the details of different frameworks that promote scalability. Though it will take some time, it’s worth watching these videos to really grasp some of the emergent patterns that you might be able to apply. At a very high-level I see a few of ideas that run across these frameworks:
- Adaptive Methods: These frameworks all highlight the importance of adapting your method in support of scale.
- Extending Transparency: A central idea to Agile and each of these frameworks proposes ways of extending transparency beyond the team’s backlog to the program and executive level.
- Self-Optimizing Pathways: Transparency sets the stage for better coordination but transparency alone is not enough. These frameworks all promote the development of communication pathways that leverage transparency but which limit the overhead associated with transparency.
Tailoring Agile to your team
A prerequisite for scaling Agile is that you can tailor your method to your team, project, and company culture. If you are not adapting your method you won’t be able to effectively scale. Of course, this is what the retrospective practice is all about. The retrospective is not isolated to the work you released in your most recent iteration, it’s also focused on evolving your Agile method (i.e. Scrum, Kanban, etc). Ultimately methods are just a collection of practices that are bundled together and the retrospective is about adjusting that bundle based on what’s working and what’s not.
I really like the Shuhari framework which breaks down to this:
- Shu = Follow the rules
- Ha = Adapt the rules
- Ri = Break the rules
The final stage essentially represents mastery—not in the sense that your process is perfect and stable but in the sense that you’re highly adept at continuous improvement. The following presentations touches on this framework in more detail.
Scaling Agile Framework (SAFe)
The following is a wonderful presentation by Henrik Kniberg and Lars Roost that focused on how they’ve scaled Agile at Lego in the context of product management. To be clear, SAFe has not come to the marketing world yet … and to be frank it’s just gaining traction in product management but it’s a glimpse into the future for marketers. As with Agile in general, marketers are taking a page from product management’s book and this will not be an exception.
You’ll see that this framework includes practices designed to scale Agile across a large team with the use of practice layers (e.g. Scrum of Scrums) and by leveraging transparency to keep leadership in alignment with implementation teams. Prepare to geek out on Agile:
Other relevant frameworks: Google’s OKR
The second video that I am sharing below comes from Google and is focused on their Objectives and Key Results (OKR) framework. This framework has come up in a few conversations recently as a mechanism for connecting leadership with Agile implementation teams The key take away from my perspective is that this framework feels a lot more like a marketing-friendly practice to achieve some of the same goals of the SAFe framework. Again, this is a fairly long and detailed presentation and it really gets into the guts of what you’d need to know to actually get started using OKRs.
Is the OKR framework consistent with Agile? It’s a fair question but going back to the Shuhari framework the question may just be a statement about what stage your team is at. The fact is that these frameworks may be early examples of an emerging dominant design. I’m personally inspired by SAFe and it’s provided depth to my perspective on my team’s Agile practice and I’m also looking forward to exploring OKR’s soon.
Finally, I’d like to share a video from Spotify on their Agile practice and how they’ve scaled it. I love the statement they make up front that Agile is more important than any method. This really speaks to the fact that methods must be evolved to support scale over time. If you really want to get into the guts of what Spotify is doing, check out this paper which was co-authored by Henrik and Anders Ivarsson.
Spotify Engineering Culture – part 1 from Spotify Training & Development on Vimeo.
Leave a Reply