Imagine you’re in search of an amazing treasure. For the sake of argument, we’ll call it agility. This treasure is not only beautiful, it’s useful too. (Plus, your boss says it’s mandatory for you to find it and start using it ASAP.) Here’s the problem: the treasure lies at the peak of a treacherous mountain. To seize it you’ll have to navigate some serious challenges; if you mess too many of them up, you’ll never make it to your agile treasure.
In this situation, would you rather have a guide that’s climbed this exact mountain before, or one who’s gone in search of a similar treasure and climbed other mountains sort of like yours? The answer is obvious: we all want the most experienced possible guide when venturing into the unknown.
This, in a nutshell, is why an internal Agile Center of Excellence (CoE) isn’t the best guide for Agile marketers. Sure, many of their members are experienced mountaineers. They can tell you what it’s like to climb a mountain, but they probably can’t tell you what it’s like to climb your mountain.
Many marketing teams we’ve coached tried to work with these internal groups, only to leave frustrated and confused. To be blunt, coaches and trainers with the same subject matter expertise as the teams they’re working with are the best guides for non-IT groups.
Let’s look at three of the top reasons why.
If all you have is a hammer, everything looks like a nail. If the only framework you know is Scrum, you’ll try to use it to solve every process problem you encounter. I have absolutely nothing against Scrum as a framework. It’s useful and powerful and proven to work in many, many contexts.
But Agile isn’t just Scrum. There are dozens of other pieces of the puzzle that need to come into play for agility to thrive, but coaches who’ve spent much of their careers in software and IT are likely to have experienced mostly Scrum implementations. VersionOne’s annual State of Agile Report regularly puts Scrum at the top of the list of frameworks employed by its software and IT respondents. Marketing teams, on the other hand, prefer hybrid methodologies. Not only do we prefer them, these kinds of approaches deliver better results:
Speed, responsiveness, and quality are all more likely to be reported from hybrid Agile marketing teams than from other kinds. So we need coaches and trainers who can get us to these kinds of systems. Most folks in a CoE are too Scrum-focused to make it happen.
Beyond the need to get a wider array of framework options, CoE members are rarely (if ever) marketers themselves. This makes it difficult for marketing teams to connect with them in order to access their help. At an Agile event not too long ago, I was chatting with a senior coach leading an Agile center of excellence in a large financial organization.
He needed a coach to help guide new Agile development teams responsible for moving to Amazon Web Services (AWS), and was bemoaning the difficulty of finding the right person. “I’ve got to find someone who knows AWS,” he told me. “If the coach doesn’t understand the work, how can the team respect them?” Shortly after I asked if he thought he could coach a marketing team going Agile. Without missing a beat he said he was sure he could...despite having no professional marketing experience.
It’s an unhelpful stereotype to assume that all engineers or developers believe, as Dilbert does in the cartoon above, that marketing work is inferior to what they do. The punchline is funny (and back in the Mad Men days might have been eerily accurate), but there are certainly coaches who have empathy and respect for those outside their own sphere of experience. However, as my coaching colleague intuited in our conversation, it’s tough for teams to respect a coach who doesn’t understand their work.
Imagine a team has just launched a new ABM initiative, and their existing Agile system has been thrown completely out of whack by this new kind of work. They call in help, but end up spending tons of time trying to explain the initiative (and probably what ABM even is) just so their CoE contact can understand why it’s caused a problem.
By the time they’ve helped the coach understand what’s going on, their energy for addressing the problem is sapped. Faced with this result often enough, marketers often end up circling the wagons and stop reaching out to an existing CoE. It’s easier to just muddle through problems themselves than to spend hours explaining their work to a non-marketer.
Unfortunately, they then miss out on opportunities to iterate and/or avoid common mistakes, which means their Agile system never works as hard as it could. It’s a sad -- but avoidable -- end result of assuming that all work is the same.
Lastly, coaches who started out as software developers probably haven’t experienced one of the most dangerous impediments to agility outside of IT: the project. Many marketing organizations are overrun with meetings and context switching because of their focus on projects, yet a CoE almost never considers it as the root cause of Agile marketing failure because it’s rarely a problem in software.
Software developers work on one thing: their piece of software. Sure they have different areas of expertise and focus within that type of work, but they’re contributing to the creation, expansion, and/or improvement of this one, big thing.
Marketers, on the other hand, flit about from project to project like hummingbirds on speed. If I’m a copywriter, for instance, I might be asked to write copy in support of our annual customer event (one project), create sales enablement materials for a new ABM effort (another project), and work with internal subject matter experts to create thought leadership content (a third project). Oh, and all three of these projects have different owners with different priorities and they definitely never talk to each other.
I’m also responsible for contributing regular customer-facing content for a blog, writing press releases whenever they’re needed, and otherwise “wordsmithing” anything that anyone puts in my inbox. My functional boss oversees this work, with little to no visibility or influence into my project work. Again, this boss doesn’t ever talk to the project leads I work with. (Recreate this fractured focus over an entire department, and you can see why marketing processes are often such a disaster.)
At some point, hearing tales of inefficiency and delay, someone from the CoE comes along and delivers a 3-4 hour workshop on Agile. The marketing teams and leaders hear this, and instantly apply it to the project perspective that runs their professional lives. “This sounds like a good idea,” they think to themselves. “Let’s run the new ABM effort with Agile!”
The CoE representative helps them build a backlog of the ABM work, they prioritize it, plan their first sprint, and off they go! Yay agility! The problem is the new Agile ABM “team” isn’t really a team at all. They have 37 other projects they’re working on; they can’t commit fully to their shiny new sprint. So the sprint fails, and they try to plan to work on fewer stories for the next one. But the 37 other projects keep getting in the way, and they can’t ever deliver on their sprint commitments.
They conclude the experiment is a failure. Agile doesn’t work for marketing. Too bad so sad. This, of course, is the absolute worst way to pilot Agile (more on the right way here). But because the CoE person hasn’t ever been in this kind of department, they don’t even know that the experiment they thought they were setting up had failed before it started.
To be clear, my point in making this argument isn’t to disparage my fellow Agile coaches. They work hard and run head first into challenges most others would avoid at all costs. They certainly do their best to make Agile work wherever they can.
But assuming that one type of Agile expertise translates to all Agile ways of working does everyone a disservice. What’s worse, it jeopardizes our chances at achieving business agility at scale.
So unless you’ve stocked it with a wide variety of subject matter experts who’ve worked in marketing, finance, and HR, don’t rely on your internal Agile Centre of Excellence to train and coach non-software teams. Everyone will be better off.