For the last seven years, I’ve devoted my professional life to helping my fellow marketers enjoy all the benefits of real agility: Clear priorities. Limited work in progress. Focused effort that delivers rapid results. The list goes on and on.
Much of my work, and the work done by my amazing team has focused on taking what’s worked in Agile software development and translating it to apply in the world of marketing.
Meanwhile, my esteemed colleagues from the world of Agile software development, the OG agilists if you will, have often insisted that this kind of translation isn’t necessary. If Agile principles and values are universal, they ask, why does marketing need its own flavor? Why should HR be Agile any differently than the rest of us? Do we need to launch, document and shepherd an Agile revolution inside each and every function to achieve lasting agility across the enterprise?
Historically my answer has been, “Probably.”
I’ve seen the difference in how marketing teams respond to trainings tailored to their context compared to workshops grounded in software development ideas. The more applicable the training, the more likely they are to actually implement the concepts they learn.
So what does this mean for business agility … or enterprise agility … or organizational agility — whatever we decide to call it? I don’t claim to have all the answers, but I’d like to put forward some options for how we classify and approach transformation within and across our functions.
Option 1: Ad Hoc Functional Agility
Let’s think of this as the “choose your own adventure” version of Agile. Each function gets to visit the Agile buffet, look at all the options, and decide how best to do Agile in their particular context.
Software development got to the buffet first. They chose a lot of Scrum options, to the point that over 90% of Agile software development teams are now using Scrum.
Marketers are visiting now, and their choices look different. Often being very service-oriented and obligated to respond to market changes in real time, they gravitate toward hybrid models that incorporate more flow-based Kanban practices.
As others visit the buffet, they’ll bring back different Agile plates.
Agile finance, Agile human resources, legal agility — each of them will create a version that’s reflective of their own ways of working.
This approach can be highly impactful for organizations that operate with a high degree of independence between functions, or one with large swings in readiness for adopting Agile. But when there’s a need to coordinate and collaborate to deliver value (a situation that’s more the norm), having multiple different Agile flavors may not combine to deliver a pleasing mouthful.
Related Article: Variety Is the Spice of Agility
Option 2: Transformation Across all Teams
Beyond ad hoc functional agility we have something broader and more holistic, sometimes referred to as organizational or enterprise agility. For the purposes of our comparison here, let’s think of it as functional agility mandated from on high, rather than adopted organically within each part of the business.
In ad hoc functional agility, each part of the organization operates on their own timeline. Whenever they’re ready, they undertake a finite Agile transformation that’s isolated in their function.
But in organizational agility transformations, the CEO (or similar) tells everyone that Agile is now the modus operandi, and each senior leadership team is required to figure it out. There will be some agreed-on points of commonality between the functional areas, but no coordinated cross-department transformation plan.
In this instance the organization will likely choose a core operating framework — Lean, Kanban, SAFe, etc. — and any buffet visits will be limited to choices that align with that framework.
The tradeoff here is you get more consistency in ways of working, but fewer options for customization from one function to the next. Functions also retain ultimate responsibility for making Agile work in their corner of the world. They get it right or they don’t according to their own capabilities.
It can be nice to give each area of the business ownership and autonomy, but chances are you’ll see uneven adoption and a transformation that drags out for several years.
Related Article: The 3 Fundamental Pillars of Organizational Agility
Option 3: Business Agility as the New Operating Model
The third option is the hardest, but delivers the most revolutionary results. I’m calling it business agility here, though I’m not sure that name is sufficiently distinguished from enterprise or organizational agility.
In my mind the distinction is that business agility encompasses literally every part of a business, from its purpose to its team structure to its hiring processes and beyond. It’s independent from how particular functions would, could, or are using Agile practices on a day-to-day basis.
Business agility is more holistic, integrated and universal, which means getting there is a more difficult journey that requires more deliberate, sustained effort.
To achieve universal adoption of Agile ways of working and thinking, everyone transforms together (though that’s not the same as transforming simultaneously) under the eye of a BATO, Business Agility Transformation Office.
The BATO is a cross-functional team of senior leaders whose full-time job is rolling out Agile across the organization. This includes designing training programs, retaining coaches and consultants, working with senior leaders on department structures and team composition, engaging in change management, and so on.
One of the biggest differences between undertaking a business agility transformation and an enterprise agility transformation is that enterprise agility remains the responsibility of existing functions within the enterprise. Business agility, on the other hand, is tackled cross-functionally, with all functions joining forces to collaboratively transform the business end to end.
Some organizations might start with ad hoc functional agility, move to enterprise agility, and finally undertake a business agility transformation. In my mind those three could be different phases of maturity, or stages on the journey.
What do you think? Are these the right categories for making Agile work across an entire organization? Is it even helpful to draw these kinds of distinctions?
Learn how you can join our contributor community.