Government Digital Service (GDS) Blogs
Printable version

How to be agile in a non-agile environment

Blog posted by: , 9 October 2015 — GDS team

Image of a sign in the countryside that reads "dogs welcome; cats use side entrance"


Licence: Creative Commons Attribution Giles T

At GDS, we think working in an agile way is a good thing. You’ve probably gathered that by now.

Over the years, we’ve not missed an opportunity to talk about why we think it should be happen more often across government.

The reality for many of our colleagues is that being agile is easier said than done. One thing they often say to me, or to my colleagues, is something along the lines of:

I want to work in an agile way, my team wants to work in an agile way, but we're just a small part of a much larger organisation that doesn't work that way at all. What can we do?

A fair point and a good question. I have a few suggestions.

The first thing you need is top cover. Find the most senior person you can find who will back your efforts to be agile, and get them to publicly declare their support.

Remember that agile is a thing you are, not a thing you do. Revolution is disruptive, which is a good thing - but people don't always like disruption. Understand that what you're doing, and particularly how you’re doing it, might disrupt the work of other people and other teams. Try to see things from their perspective. See if you can help them.

Respect existing roles and processes. This follows on from the point above. Just because you're agile, it doesn't mean that you can expect the rest of the organisation to bend around you. That will never happen. So make a point of learning how they do things already, and how they've done things for the last 10 years. It's fine to ask "Why is it done that way?" but don't say "That's a daft way of doing it, you should do it like this instead."

Use language your non-agile colleagues will understand. It's fine to use the language of agile (words like "sprint" and "standup" and "iteration") within your team, but when talking to colleagues in the wider organisation, make a point of using the language they normally use.

Until they come to you, take things to them. Make that extra effort to ask for time from busy people, and go to them with a demo. Over time, and as your team's work shows its value, perhaps those people will start coming to you.

Be agile with a small "a". Show you can be trusted to get work done. Do small, frequent changes and show how they're making a difference.

Grow organically. Grow with the thing you're making. Scale the team carefully, and only bring in new people when you need their skills and experience.

Show the thing. Invite people to show-and-tells, do demos at every opportunity, give presentations, print out screenshots and put them on the walls. By showing the thing, you let it speak for itself. That alone can get you plenty more support.

But I still need help ...

Even if you follow every one of those tips, it might still not be enough. I get that. I’ve seen it happen before. Transformation is as much about changing processes and culture as it is about digital services, and processes and culture are much more deeply ingrained. Changing stuff like that is hard.

So let’s work together on it. Join our cross-government agile community, and let’s get everyone to share their knowledge and experience. Make things open, it makes them better. Something that worked for one team could work for another.

If you’ve tried all the tips above - or as many of them as you feel comfortable trying - and you’re still struggling, perhaps joining that community of like-minded people will help. If you’re interested, contact me directly:adam.maddison@digital.cabinet-office.gov.uk.

Agile is less risky

Sometimes, large organisations are so large that even good change can get overlooked and misunderstood.

Even then, don't give up. Remember the greatest asset of being agile: it lets you see value delivered sooner. It greatly reduces the risk of not delivering anything at all. It means you deliver the right thing, the thing that meets user needs. Your focus is on outcomes over deliverables.

Often, you'll get there faster too - not always, but often. It's true that an agile work might take just as long as non-agile work, or it might even last longer. But when you're agile, you get to test your assumptions much earlier. You get to spot the false ones sooner.

Agile sounds more risky, but actually it's all about reducing risk and getting more control.

Once your colleagues and management working in the wider organisation start to see that happening, and see the results that working agile brings, they'll start to see things from a different perspective.

That's when the real change starts happening.

Follow Adam on Twitter, and don't forget to sign up for email alerts.

 

Channel website: https://gds.blog.gov.uk/

Share this article

Latest News from
Government Digital Service (GDS) Blogs