Agile teams have always struggled with their intersections with their non-Agile counterparts.
In the early days of agility it was developers bumping up against, well, everybody else.
Now, as non-software developers are adopting Agile ways of working, there are more and more of these points of friction showing up.
Eventually we’ll arrive at the utopia known as business agility, when every function, team, and department uses Agile frameworks and practices, and everything is built on Agile principles and values.
Until then, it’s crucial for Agile teams, whether development, marketing, or others, to learn to effectively interact with those who are less advanced on their Agile journey.
If you’re facing challenges connecting with non-Agile teams, here are five tips and tricks to help you navigate those touchpoints until you make it to the business agility promised land.
For marketers adopting Agile ways of working, this one should be easy. Make it all about what’s in it for them, not what’s in it for you.
Often referred to via the acronym WIIFM (What In It For Me), this is a handy way to remind us to frame our asks or arguments in terms that are beneficial to the audience rather than ourselves.
When it comes to agility and our stakeholders, the difference is obvious. When it’s all about thenew agile team, it goes like this:
“We’re Agile now, and we demand that you come to all our daily standup. Also the only way we’ll do any work for you is if you make tickets on our board.”
When we’re using WIIFM, we phrase things differently:
“We know you’ve always been frustrated with how long it takes marketing to turn work around for you and your team. We’re trying something new so we can get you a faster turn around time. Would you be willing to help us by using this form we set up, and joining our standup meetings every Tuesday and Thursday at 9am?”
Notice that the WIIFM version doesn’t mention Agile at all.
Newly minted Agile teams often get excited about their shiny new framework and its corresponding lexicon, but for the uninitiated it sounds like a parade of buzzwords. Avoid a knee-jerk rejected by keeping the focus on the value Agile is brining, and don’t use the terms unless you really need to.
One of the best ways to get to a strong WIIFM position is to spend a little time assessing exactly what problems your stakeholders are facing in their interactions with you.
As part of our enterprise Agile transformations we often run a stakeholder assessment, which lets us get a first hand perspective on the pinpoints that people outside the Agile team(s) are experiencing.
For marketing teams going Agile, for instance, we ask how reliable they think marketing’s data is, how easy they find it to get updates on their projects without calling a meeting, and whether they believe marketing teams can make progress with interference from leadership.
An initial assessment gives us a baseline, and repeatedly administering the same assessment over time helps us see if Agile is providing value to those outside the marketing function.
As with all surveys, we often uncover unforeseen hurdles, which inform the way we communicate about the shift to Agile, bring stakeholders into the processes, and otherwise manage the change associated with the move to Agile.
Assessments also make sure our WIIFM messaging is on point; we don’t want to be promoting the positive impact Agile will have on a problem that isn’t really pressing for our stakeholders.
As your building your WIIFM statements and crafting the right way to bring stakeholders along for the ride, you’ll eventually get to a point where you need them to understand just enough about Agile ways of working to be useful, but not so much you overwhelm them.
Getting the tenor of their education right is key to alignment with non-Agile teams.
Don’t make them sit through an 18-hour Scrum Master course.
Don’t ask them to watch six hours of videos.
Give them a tailored educational experience that enables them to participate, and maybe even gets them excited about what Agile might mean for them.
Your focus here should be on how you’d like them to plug in to your process. If it’s a legal and compliance team you’re working with, your main interest is likely bringing them into the planning process and daily standup to avoid end of the line bottlenecks that delay the release of finished work.
In that case, help them understand only those Agile events, and their role in them.
They don’t need to understand retrospectives or backlog refinement, so don’t muddy the waters by trying to bring them up to speed on every aspect of your framework.
Our first three tips focused heavily on the stakeholders themselves. This one’s just for the teams.
Consider how you interact with your stakeholders today, as well as what those interactions would look like in your perfect world. I like using a diagram like this one:
Each piece of the pie can have a set of stakeholders with a say in different parts of the process. Sales might dictate a lot of what you do. Product development might influence when things happen based on when features are released. Legal and compliance might tell you how your campaigns and messaging should be structured.
Each of them gets a slice so we can consider them as discrete units.
Then, we add a dot for each individual person or interaction that takes place in that slice.
For example, if we usually present finished work to sales at the end of every 2-week sprint, sales gets a dot in the “every 2 weeks” slice within the “what” segment.
The closer a dot is to the center, the more often we interact with that group or person.
Start of by mapping the current state with one color of dot, then do another round of your ideal interaction cadence with a separate color.
Work with the team, their Agile coach, and the leaders within the stakeholder group to figure out how best to move from the current state to your ideal, always considering your WIIFM position, and what training might be needed to facilitate the journey.
As you work with more and more non-Agile groups, you’ll inevitably encounter moments of frustration.
No matter how masterfully you craft your interaction models, how perfect your training regimen is, or how empathetic your WIIFM statement is, their lack of agility will eventually slow you down.
While irksome, this is actually a good thing.
It means that you’re no longer the bottleneck in the delivery of value to the customer. It also means it’s time to expand the reach of Agile ways of working to other parts of the enterprise.
We can mitigate some of the friction and try to smooth out the handoff process, but ultimately we want each and every piece of our organization humming along at the maximum sustainable pace.
This means, eventually, you’ll need to be an advocate for making your non-Agile stakeholders into Agile stakeholders.
Be prepared to take what you’ve learned and help them apply it to their unique context. You’ll likely learn just as much watching them apply frameworks, practices, and values as they learn by evolving their own processes.
Do your best to interact with non-Agile teams now, but watch for the opening to make everyone’s lives better by helping them transition into the wonderful world of agility.