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.
10 comments
Comment by Adam Maddison posted on
Hi Suzanne,
Thanks for commenting. We're working on a few things to help explain why we do believe working in this way can help organisations be more dynamic.
There will soon be a cross-government blog devoted to the topic of improving delivery of projects and programmes of work. And the cross-government delivery community will be working with a number of departments and agencies, and the existing PPM profession, to see how we can best help and support each other. We are planning a small conference (organised on the same principles as UKGovcamp and UKHealthcamp) at the end of next month to kick start that.
So please do keep in touch, and keep an eye out for the new blog.
Comment by Suzanne posted on
Great! Sounds really useful, and I'll absolutely keep an eye out for more. Thanks again.
Comment by Suzanne posted on
I would really like to find out more on this - and what resources are available to help achieve a more agile approach and share lessons identified? Sounds sooo familiar though; the issue of working as part of a small team, trying to implement change and dynamic approaches, within existing larger legacy systems and ways of working. If nothing else, it's nice to know there are others out there facing the same thing!
Comment by Michael posted on
What I really like about this article is the positivity around the benefits of working in an agile way and the really simple suggestions that can help you start to use agile in a non-agile environment.
Agile is a very different way of working from many of the traditional and bureaucratic ways that many organisations work. But, that doesn’t mean that it can’t be used.
Working within a large non-agile public sector organisation, I have been using the agile methodology/approach with my team for over a year now. And that meant following the guidance and points suggested in the article.
My small team were not used to working in an agile way, but through letting the actions do the talking, we now use the approach for our work – but then present much of our work within the expected ways that the organisational is set up to manage. We now use the language within the team – now that the other team members are not put off by the terms such as sprints, etc. – which many felt just added another layer of jargon.
We have started dripping the language in to conversations with other teams and services – where we believe that it won’t ‘turn them off’.
But the key point was, as I highlighted below, we let our actions do the talking – even with the wider team around us. We can now deliver more, faster, based on user experience and user needs. And since the end of last year, we have realigned our resources slightly within the wider team as my team didn’t need as much.
Here’s to agile as a way forward within the public sector.
Comment by Ben posted on
Agile works great - when it is allowed to by the organisation and implemented by competent professionals.
Sounds like Mr KoolAid had a poor experience in this sense...
Comment by Thomas Brown posted on
Two very passionate advocates of their styles, here, I think; Digital KoolAid and our author, Adam. Good luck to both of you! And for the record, until Paragraph 5 of your response, Digital KoolAid, you were winning, then it all went a bit pear-shaped.
I think that the crucial point is this one. Its OK to work Agile, agile, or indeed non-Agile. But the problem with HMG and many public commerce situations is that although the many sub-systems can be built in an agile way, there are usually old-school contracts or over-arching waterfall projects on which the sub-systems depend. And even today (literally today) projects are stumbling and losing immediate impact because of those difficult to manage big dependencies.
Comment by Digital KoolAid posted on
Left a comment, but it has not appeared. Is there a policy concerning those who do not agree without question, or who actually know what they are writing about? Much of what the author has written is completely untrue or fabricated, or both: sadly.
Comment by Carrie Barclay posted on
Hi Digital KoolAid
Thanks for your message. I'm sorry you felt your previous comment wasn't dealt with quickly enough. Although we do aim to moderate comments within 24-hours, this relates to the working week. As you submitted your comment at 7.38pm on Friday evening, it was not moderated until this morning. Your comment is now live.
Comment by Digital KoolAid posted on
You simply cannot say silly things such as “agile is a thing you are, not a thing you do” and expect to get away with it. This has become quite absurd, when you tear the meaning from established terms and replace it with your own convenience. Agile is a project approach, perhaps a methodology and certainly not a quality of the human being. If, as you say, the language of agile is words like "sprint" and "standup" and "iteration", these have nothing to do with the verb to be. They are not part of we humans.
There are a great many people in the world who would not agree that “Revolution is disruptive, which is a good thing”. It may be that a large majority opposes your statement, I have no figures, but many people profess conservative views and attitudes. They feel that revolution is not a good thing.
It is equally inaccurate to claim that Agile reduces risk. You have no basis for that claim, and it is quite untrue. Agile creates a number of risks that do not exist elsewhere, and has an historically poor track record in risk management (as it displays a preference for unstructured over strict method). It is quite untrue to declare boldly that “the greatest asset of being agile: it lets you see value delivered sooner”. Such value is not measureable. IT departments have struggled, and generally failed, to define “value” for 30 years. A leaderless group on a sprint is less likely than most to get to grips with the definition.
You must please attempt to grasp the important difference between doing “something” and actual delivery. Agile does not, as you claim, “greatly reduce the risk of not delivering anything at all”. Delivery of completed systems into service, “Go-Live” if you prefer, is the right thing, the thing that meets user needs. Your focus is not on outcomes over deliverables, Adam. Your correct focus is on deliverables, testing, function, reliability, quality, maintainability, all the old-fashioned hard work of IT systems. Other people will use the systems you deliver to create outcomes. You don’t know their business and don’t work there. Really, you don’t. You create IT “stuff”.
Agile is suitable for teams that hate the hard work of design. It can apply when there is a violent distaste for fore-thought and documentation. It thrives where there are is no mandated approval process. It works for teams that can’t hold their focus for very long. And when all the early, easy bits are “done” the originators can “roll-off and hand-over” to a team of poor blighters who have to fix the mess of anticipations, expectations and undocumented code created by the Wizards of Agile.
Yes, “Agile sounds more risky” and it is. It's doesn’t reduce risk and get more control. That’s a lovely ambition but quite untrue. The “real change starts happening” when we stop replacing the meaning of name Agile with the word agile. An unstructured method in the hands of innocents creates a chaos that can rarely be reversed. Use it with great care.
Comment by Adam Maddison posted on
Hi Digital KoolAid,
Thanks for your response. We focus on the principles of agile software development, rather than any specific development methodology. So, for us, being agile is about focussing on user needs, using iterative and incremental development to deliver measurable value sooner, and empowering our teams to do just that.
So yes, we do focus on achieving outcomes, rather than just delivering things we hope or assume others will find valuable.
There is plenty of evidence to show that working in this way does mean projects are less likely to fail, and are more likely to deliver what users actually need. But I absolutely agree with you - we need to be organised and disciplined, to be accountable and to hold ourselves to account.
The most successful digital companies - companies such as Google and Amazon, Facebook and Spotify - all work in an agile way. We should aspire to be like them. Although focussing on delivering the most value to citizens, rather than delivering the most value to shareholders. A purpose which motivates us all.