Business Agility Vs. Agile Software Development

Once upon a time there was an Agile marketing team that tried to say no to a last-minute request from sales. An event was coming up, and the salesperson wanted a piece of custom printed collateral and a corresponding landing page.

The marketers were in the middle of a sprint. The sales request was urgent, but not really important.

The Agile marketing team had been taught that they shouldn’t accept work into the middle of their sprint without a strong business case, so they promised to document the ask as a card in their backlog and consider it for their next sprint.

Appalled, the salesperson went ahead and threw together their own one-pager and started a free trial of a landing page tool so they could drive traffic from the event to it.

They never told marketing about any of that.

Meanwhile, another salesperson received a new feature request from a prospect and asked the Agile development team to build it. Like the marketers, the developers were mid-sprint and declined to start work on the feature right away.

The salesperson was disappointed, but had no choice but to accept the decision and wait for the feature to get prioritized for attention.

Why do these stories look so different? Both teams are Agile, both should be empowered to control their work streams. Yet one’s refusal is met with a secret workaround, while the other is, however begrudgingly, accepted.

This story illustrates a key issue for Agile ways of working as they move outside of software, one that all proponents of business agility need to consider carefully.

Respect, Mystique and Agility

These two stories play out so differently for a few reasons. The first is rooted in the internal perception of a particular function. Software development is, by and large, a mysterious process for those of us not able to do it.

Letters and symbols get combined into code, somehow that’s compiled (whatever that means), and eventually it shows up as new things that people can do with a piece of software or an app. (My husband graduated with a computer science degree, and would no doubt cringe at this crude description of the development process, but I only know this much from hearing him talk about his job for years.)

Fortunately for Agile software teams everywhere, this mystique often translates to a respect for development. We don’t fully understand it, and we certainly couldn’t replicate it, so when a dev team tells us how long something will take, we’re inclined to believe them. We might negotiate scope or delivery date, but in the end we’re going to take what we get.

What’s more, software products are sufficiently complex to have a robust governance structure that prevents unauthorized people from messing around in them. If a dev team turns down my feature request, I can’t just log into the production server and add it myself.

Taken together, these two things have enabled frameworks like Scrum to be effective in software development in ways that are often not replicable in other functions.

Marketing Is Just Liquor and Guessing

Marketing is an excellent example of this nuance. Several Agile marketing teams have told me that they can’t turn away work requests, even if they’re already overloaded, because if they don’t do it someone else will.

As in the story that opened this article, the requestor will find a workaround to get their task done. Oftentimes the outcome is work that's not aligned to brand standards, not effectively tracked, utterly ineffective, or all of the above.

We all consume marketing materials, whether that’s an email, an ad, or a website, and we therefore assume we’re qualified marketers.

A Dilbert cartoon in which a software developer is considering moving to marketing closes with Dilbert telling him he shouldn’t do it because marketing is “just liquor and guessing.” With this perception, it’s no wonder people have no problem going behind an Agile marketing team’s back when they have the audacity to say no to a request.

Without the ability to push back on incoming requests, no Agile team can thrive.

Fostering Respect for All Agile Teams

It’s not super practical for us to create the equivalent of a production server for marketing and every other function that wants to be Agile. The goal isn’t to lock down the means of doing work.

What we can do is build a culture of mutual respect between functional areas.

An Agile marketing team who says their workload can’t accommodate a last-minute request should be listened to just like an Agile development team. What’s more, there should be acknowledgement that marketing is a complex profession. There are specialties and nuances that make it highly difficult — not everyone is qualified to be a marketer.

As agility makes its way across the organization, more and more Agile teams will form. Each and every one of them has the right to own their work.

If my Agile marketing team wants to make a new hire and we make a request for help from an Agile HR team, they can tell us “not right now” if they don’t have capacity. That doesn’t mean we should post an unapproved job description on Indeed tomorrow because we don’t want to wait on them.

Without making a deliberate effort to understand the intricacies of our colleagues’ work, we put an entire Agile transformation at risk.

It may seem like the height of waste to explore what an entirely separate department does, but these points of connection and empathy are crucial to make business agility work. It’s a shift from relying on the mystique of software development to protect teams, but it’s vital to long-term Agile success in any organization.