"To be Agile" is not sufficient reason by itself to undertake the difficult work of an Agile transformation. It's crucial to know your why before you ask people to change their core ways of working.
There's a reason that we're often admonished to "start with the why." Articulating the key reason behind an action is the best way to both initiate and sustain that action.
The same is true for adopting Agile ways of working.
"To be Agile" is not a good reason by itself to fundamentally change the way you get work done. It's comparable to saying, "I want to be healthier so I can be healthier." Not only is it confusing, it won't help you stay motivated when you're deciding whether to order a burger or a salad.
A true Agile transformation is an end-to-end overhaul of your entire process. To make such a big change, especially if it involves adjusting team structure and/or the way you interact with stakeholders, you need to know what you want to get out of it.
Your Agile why matters not just for motivation but also for measuring, so take the time to identify and document it at the start of your transformation journey, then track your progress to clearly show how the effort of change is paying off.
Three common drivers toward Agile ways of working
If you know you need to change, but you aren't sure exactly what your why is, here are a few of the most common drivers for change. It's likely that your big why is a combination of something you see here, along with other factors.
1. Speed to market
Agile is often closely associated with speed, whether that's getting software features to users sooner or implementing a marketing campaign more often. Many of the more traditional marketing departments I work with, for instance, are still putting out only a few huge campaigns per year.
In a world where people expect real-time responses and up-to-the-second relevance, measuring your release cadence in quarters just doesn't cut it.
In these situations, sheer speed may be your primary driver for adopting Agile ways of working. But even if you're looking to move faster, make sure your why also includes a nod to the other key component of agility: delivering customer value.
No matter the framework you use, Agile exists to allow knowledge workers to provide value to their customers early and often. So even if more rapid releases are your primary goal, you can't lose sight of the value of the delivery piece.
Quickly putting out work that doesn't help anybody isn't going to do you any good. For marketers specifically, creating tons of collateral that's off-brand and missing tracking parameters is a terrible use of Agile.
Speed may be at the heart of your why, but don't sacrifice brand standards or measurement capabilities on the altar of rapid releases.
2. Effective collaboration and fewer handoffs
Many organizations, particularly the marketing function, realize that much of their process stagnation stems from inefficient collaboration.
Maybe people have to meet too often because their communication isn't effective. Maybe a lack of upfront scope alignment creates multiple rounds of revisions, or even a last-minute rejection of work that was considered done. Maybe silos have run amok and work has to pass through multiple teams of specialists, each of which may introduce its own flavor of delays and complications.
All of these scenarios are solved, or at the very least mitigated, by an effective Agile system. But they are significant, far-reaching issues that can't be solved by optimizing one team's process. That means if your why lies in these areas, you're looking at a big process change for multiple teams.
You'll need to get agreement both about your big why, likely with some small adjustments to make it highly relevant for each group. You'll also need alignment on what changes will be made first, their expected impact on the big why, and a clear strategy for measuring the success of your transformation efforts (more on that shortly).
3. Improved alignment around organizational goals
I was recently working with a group of marketing leaders who were creating their first ever departmental backlog. Each of them was throwing out priorities relevant to their own part of the marketing function, but they were struggling to agree on overarching priorities. I suggested that we use the larger goals of the organization as our North Star to make sure what we prioritized within marketing would be supporting the bigger picture, and they admitted that no such goals existed.
If that sounds familiar, an organization-wide shift to Agile may be just what you need. If, on the other hand, the organization's goals are clear, but functions like marketing struggle to show their impact on those goals, Agile is also the right antidote.
When alignment like this is your big why, it's important to lean into strong visualization with a digital tool. You'll need to ensure that you can directly tie the day-to-day work of various teams back to the goals of their department, which should in turn correlate to those of the organization as a whole.
It's practically impossible to achieve this without near universal adoption of a unified tracking tool. Once you have that, however, you can see at a glance what percentage of work ladders up to a particular goal, initiative, objectives and key results, etc. And, more importantly for leaders, you can identify how much work doesn't support any objectives.
That non-value-adding work should be eliminated, freeing up time and mental space for teams to tackle the important goal-supporting items.
Because it hinges on taking things off people's plates, this type of why can be great for getting buy-in across teams. Positioning it as a way to focus effort and decrease burnout makes this big why one of the easier to sell.
How your why impacts your transformation
As you zero in on the why behind your move to Agile, consider how it will impact your transformation plan. Different objectives lead to different forms of measurement, team structures and Agile frameworks (among other things).
What you track
Your why should have clear metrics attached to it that indicate whether your transformation is delivering the value you had hoped for.
For example, if you're looking to increase speed to market, establish a delivery baseline pre-Agile and track future releases against that. If your marketing campaigns aren't getting to customers faster after Agile is in place, you'll have a data-driven place to start figuring out what's not working.
When your why is more tied to collaboration, you might want to track how many rounds of review a creative effort goes through before and after Agile ways of working. You'd hope for less of those once Agile improves interteam cooperation.
You may have already noticed a pattern here. Regardless of what you're tracking to measure Agile's impact on your why, you'll need a baseline to start from. Take the time to assess your current state so you can accurately track the impact of your transformation on your why.
How you reteam
As part of an Agile transformation, we often need to reteam. Moving people into different team structures can be stressful and shouldn't be undertaken lightly.
Make sure everyone understands how you expect team structure to contribute to achieving your why. They're far more likely to embrace the change if they know it'll keep them out of review meetings, increase the impact of their work, or take useless busywork off their to-do list.
If you position reteaming as something that's happening just so we can "be more Agile," you're setting yourself up for resistance.
Your why also influences the way you put these new teams together. If collaboration and/or alignment is a big part of your why, working hard to create fully cross-functional teams will be crucial to achieving it. Speed to market, on the other hand, may not demand true cross-functionality if you can divide and conquer the work using your existing team structures.
Which frameworks you try
Only here at the end of this discussion am I bringing up specific practices of Agile, and that's quite deliberate. Leaders need to spend a lot of time grappling with the why and creating communications based on it before diving into the day to day doing of Agile.
But, once you're at this point, your why should still come into play. Teams looking for speed to market should consider carefully whether iterative timeboxes, a la Scrum, will help them deliver value faster. In many marketing teams I've coached, flow-based frameworks like Kanban are in fact more effective at increasing their output. Often a hybrid, like the Rimarketing framework I outline in my new book, is the right option.
Likewise, teams striving for better alignment to goals and better collaboration should consider what meetings, practices and roles are likely to help them deliver on their why.
This critical look at frameworks from the point of view of your ultimate objective for Agile will get you far better outcomes than just picking a framework off a Google search.
Managing change by starting with why
Agile is a team sport. Sell your Agile transformation up, down and sideways by focusing on what it gets for everyone involved. Position Agile as a solution to a specific problem, not a panacea for everything that's wrong with your processes. Socialize your results, comparing them against your baseline metrics, to show where the expected outputs are showing up and how you plan to get even better over time.
Above all, remember that "to be Agile" is not a good reason alone to start an Agile transformation.