Working Planet is an Agile shop. This doesn’t mean we’re sprightly and nimble, although we generally are those things too. It means we adhere to strict Agile methodologies in how we prioritize and execute our work. We are very routinely told by clients who have worked with multiple agencies that we’re the best they have ever worked with, and we credit Agile with helping us to be the secret weapon our clients want in a digital media buying partner.
So I am often astounded when I hear marketers say Agile doesn’t work.
“Oh we tried that Agile thing” some say. “We gave it a shot, it didn’t really work for us” say others. “I think it’s a fad” you can hear whispered on social media, if whispering on social media were a thing, which it isn’t.
Agile is so critical to our work, I thought I would take a moment to try to dissect why it works so well for us and hypothesize why it might not for others.
1. Agile doesn’t work without clear goals
We optimize digital campaigns for financial results. The financial KPIs are unambiguous goals for us to pursue. As a measure of business success, profit is unequaled and unarguable, which makes it an excellent KPI. Agile, whether you are in the Scrum or Kanban camps (we’re proud Scrumban fence-sitters) works for three different reasons, one of which is the continual prioritization of what you are working on in the moment. This implies you have something meaningful to prioritize against. Our financial lens and using profit as a KPI gives us clarity for prioritization in a way other agencies might lack.
2. Agile works best when marketing is a team sport
Many agencies are set up as specialists working independently on work for the same client. It is not at all unusual for agencies to have a unique expert for Facebook, Twitter, or data analytics. Or they might have all work for one account done by a single person. Accomplishing any one thing when it can only be done by one person can absolutely benefit from Agile (one of my favorite books on this is Jim Benson’s Personal Kanban) but Agile really kicks into high gear for effectiveness when you have a cross-functional team. Team-based Agile Marketing is better for two reasons. The first is that teams lend strength and flexibility to client work, making deadlines attainable and vacations possible even if they happen to coincide. The second is that a team of smart people who all have intimate knowledge of the workings of the client’s campaign and finances are unmatched in effective prioritization.
The second and third reasons Agile works are through visualization of the work and the limiting of context shifting. The multiples of effectiveness in these gains at the team level cannot be overstated.
3. Agile rituals can’t be done ritualistically
Agile, and particularly Scrum, is full of rituals. The fact that they are commonly called “rituals” instead of, say, “building blocks” or “improvement checkpoints” makes them too easily bucketed into the “I have to do this because it is in my calendar” zone of things we hate but are forced to do at work. This is a shame, as Agile rituals exist for a purpose. At Working Planet we don’t stand for our daily standups (gasp) and they are more often held at the end of the day than the start (more gasp), but we do make sure the daily meeting involves a hard look at current priorities and whether reality has shifted since those priorities were made. Our Retrospectives are always held, and are always about how we continually improve as an organization. If a Retrospective is just a recap of what you did or a social chat, it doesn’t move you forward towards your goals.
Often when I read about Agile experimentation it feels like the Agile rituals are done ritualistically, by which I mean without purpose. I am guessing this might not doom an Agile migration to failure, but it won’t help anything improve quickly, or rapidly show the power of Agile processes.
4. Agile isn’t something you “try”.
As Yoda famously exhorted, “No! Try not! Do or do not. There is no try”. I know of no better place to apply this Jedi maxim than with Agile. When we first started Agile seven years ago, it was hard. It was different, it felt weird. It wasn’t always easy to voice to a team how you as an individual prioritize tasks. We wanted to just get on with the work. It feels easier to just go do something than talk about it. Like most firms starting Agile, we started with Scrum and all those meetings! It was only with time that we realized how much control it gave us. How the frequent fires became a lot less frequent. How it was easier to know what to do when everyone agreed on why to do it in the first place.
You have to see it through for a longer period of time than you might think before it becomes habit, and you will likely need everyone to do it all at once. If everyone is not doing it, it will be very hard to protect the Sprint or Kanban or process of those who are doing it. It also has to be viewed as permanent or no one will commit to it, because they know they don’t need to. Lastly, Agile also needs a champion, and (at least in the beginning) that person needs to have the power of Yoda to repeatedly hammer home that there is only “Do”, and the seniority to apply the Do Hammer to everyone.
Several years ago we switched from Scrum to Scrumban, although we call it Kanban internally to highlight the differences from our old practices. Our learning curve was much easier and within a few weeks our teams were hitting a new stride. We found it worked well, and I believe Scrumban might be the superior flavor of Agile for those delivering ongoing services vs. creating a product. With its focus on finishing over starting and softly enforced collaboration, it is a good fit for us. Our teams credit it for their being able to easily achieve some seemingly hard goals with more ease than was expected. We’re an even better agency for migrating to Scrumban. Once again, we can’t understand not doing it when the benefits of doing it are so clear.
When you have something that works, it is hard to let it go. And I think that might also be the power of Agile as a methodology of continuous improvement. Before we moved to Agile we had embedded best practices that worked for us as all agencies have practices that work for them. But Agile was better. And then the Scrumban version of Agile was better than that. Now we are testing layering on personal backlogs, incorporating DevOps concepts, and other experiments. With Agile we test new things all the time. And maybe this is the most powerful reason I wouldn’t let Agile go. Agile won’t let you be complacent. If you embrace the purpose of Agile, embrace continuous improvement, don’t fall into ruts, and prioritize towards goals that are lofty and measurable then you simply cannot be complacent. And maybe that is Agile’s hidden strength.