Webinar Recording: Becoming Agile
April 2022
How to talk about agile to non-digital decision makers
Many digital teams have adopted agile working. But it can be difficult to convince the rest of the organisation who may have little experience with it. And this is especially true of decision-makers who may, for any number of reasons, be mistrustful of agile working.
That mistrust is something I’ve experienced first-hand. And I know from conversations with people in public digital that I’m far from alone. So when it came to pitching a session to this year’s GovCamp, I wanted it to be about this. We called it “How to talk about agile to non-digital audiences”. The working title was “How to talk about agile to people that don’t get it” but we thought it was a bit too on the nose.
This post isn’t an account of what happened. It’s about what I think having done that session and letting some time pass. There were a lot of great insights shared on the day, and they’ve helped shape this post – so thanks to everyone that came and contributed.
Here’s the outcome: a few things to consider when talking about agile to non-digital teams. But first, a short recap on agile itself, in case that helps.
If you’re not familiar with agile, you can think of it as a way of working to guide the delivery of a project. But more than that, it’s a mindset. It encourages communication, collaboration and rapid iteration over documentation and big, long-term plans that are hard to change.
It encourages identifying a core problem and building the simplest thing you can to fix it, rather than designing a solution to every conceivable need in advance. It significantly boosts the chances of project success, so the goal should always be to help non-digital teams understand the benefits of an agile approach – and to get involved.
If you’ve ever worked in a performing agile team, it’s hard to think of working in any other way. We all know it works. And we want everyone to get it – and share in those benefits. But if there’s one way I’d suggest talking about agile to people who aren’t used to agile working it’s: carefully. Because sometimes the reasons they’re mistrustful of agile is because they have cause to be, because of the way they’ve heard agile talked about.
We should describe agile concepts in terms people are familiar with. We should say it’s about small incremental delivery allowing for great collaboration – and their service staff being listened to. It’s about making sure that the thing we’re building is going to work for the users we’re building it for.
When teams adopt agile, the terminology (and, let’s be honest, jargon) can be bewildering. This can create a perception of ‘us’ and ‘them’ in digital teams. This barrier is unlikely to help motivate them to take part.
Most people are more ready for change than we give them credit for. We just need to explain the information in a way people can understand. If your executive leadership team don’t know about agile they’re also likely to not care.
We explain it to try and show how they might need to work and get results in a different way – incrementally. And that we’ll continue to work with them after the first thing has been built. Often, IT projects have a strict deadline and then you’re left with whatever is built – but they just wonder why we’re telling them about our favourite project methodology when they need savings delivered.
If you’ve spent time in public sector digital, you’re probably familiar with the idea of communicating as clearly as possible. Especially when talking to a broader audience. So let’s not make an exception for agile.
It may seem obvious, but for organisations to adopt agile more widely, they need to understand why it’s important. You might think it makes sense to explain the fundamental benefits. To explain how agile strengthens work and provides better services, and helps you to continually learn and improve. But the reality is that you often don’t get the time and space to do this.
The best thing you can do is show the benefits of agile by building something useful, fast. But if you don’t have that opportunity, point to examples of where this has been done elsewhere – and crucially, to examples in the organisation where non-agile methods haven’t worked. They probably won’t care that agile might have worked better, but when you can point to past failed attempts, you have a better chance in getting permission to work in a different way.
But if your team is already interested, you can try to sell agile on a human level. Explain that it gives people control over their work, provides opportunities for challenge and mastery, and aligns their work with a higher purpose.
We know, as good agile practitioners, it can be fun to discuss the relative merits of our preferred methodologies. In a way, this is an extension of my first point: these conversations are impenetrable to people who aren’t familiar with them.
But perhaps the bigger issue is that they can create the impression that agile working is incredibly fragile, and prone to failure if you accidentally glance at a kanban board instead of a burndown chart.
But as good agile practitioners we also know that no one methodology is perfect in all circumstances. We know that methodologies can be adapted and blended. We know it’s about the mindset more than the method.
It’s not that these discussions shouldn’t take place – it’s just that they must not drown out the big-picture narrative of the massive benefits agile brings. Yes, acknowledge challenges and shortcomings, but be sure to put them in their proper context.
Some organisations have implemented agile in a siloed and limited way and not communicated their process with other, essential teams that support project delivery. Though it might be too big of an ask to expect everyone to adopt agile right away, working in a silo can create challenges.
Rather than waiting for other teams to come to you, it’s best to proactively engage with them. Invite them to show-and-tells. Invite stakeholders to relevant meetings. Explain the work done and the successes (and, yes, the challenges) in words everyone can understand.
Use your show-and-tells to bring teams together and build trust by sharing successes and looking for opportunities to collaborate. But be strategic, and spend time on building the narrative from agile working to project successes. Bit by bit, you can build a shared understanding of what agile means and why it’s important. You can also run shorter lunch-and-learn sessions if you find these get more engagement – or that different people come along.
And don’t forget to blog if you can. Writing things down in the open is a great way to get engagement, show your work and build trust in a way that’s quick and easy for people to engage with and share. But also share it on the organisation’s intranet. There can be cultural misunderstandings about what working in the open really means – sharing internally builds trust that getting engagement from the team and organisation is at least as important as sharing in public.
This was a quick look at how to talk agile, but if you’re keen to put agile working into practice, take a look at our book Building High Performance Agile Teams. You can download an e-book today.
originally posted here
