People often ask me: "is an agile approach relevant for non-digital or non-technology projects?" I always answer: "agile is for everyone."
Anyone can approach a project with the Agile Manifesto and its 12 principles in mind. The agile movement comes from software development, so don’t be surprised when you encounter terms like ‘working software’. Just scrub it out in your mind and replace it with ‘delivering my project’.
Delivering your project with agility is especially relevant and helpful when you meet the following challenges and needs:
1. Uncertain Conditions
When you need to find a solution and it’s not clear how you can solve the problem up front. An agile approach encourages you to pick the simplest part of your goal to deliver quickly, so you can learn from the results, iterate, or fail quickly and cheaply.
2. Structuring change and iteration
When your understanding of scope is a moving target, agile techniques can help you to add enough structure, control and routine to flex, test and iterate on your solution to find the desired result.
3. Uniting and empowering the team
We have a saying - “the team is the unit of delivery”. Providing an environment where team members can collaborate with stakeholders and self-organise from clear priorities, results in a two-way design process. The entire team is empowered to find ways to simplify, enhance the project vision and deliver early and often.
Constrained by expensive materials
Before you say, “I’m quite certain of my project’s scope, so there’s no need to change or iterate”, pause a second.
If your project involves digging a super sewer under London, building a new high speed railway or constructing a skyscraper, you will most certainly need a distinct design-up-front stage. This is usually because the expense of the materials and a 500+ labour force means the cost of a test, change or a mistake can blow the budget and call a halt to the entire project.
Constrained by safety
If you’re shooting a rocket carrying an astronaut to the moon, safety is a priority. But let’s not forget there were 17 missions (or iterations!) in the Apollo Programme. The first unmanned Apollo 1 mission caught fire at launch. Apollo 13 aborted their mission on the third lunar attempt and the crew returned to Earth in a space life raft. It seems that no matter how certain you are of your project goal, there are so many things we can test and learn from in previous iterations.
Arguably, projects constrained by expensive materials and human safety can still be inspired by agile. Zoom out slightly and we can see these projects are still learning from testing and failure, but with much longer iteration cycles.
Constrained by failure
If you’re not constrained by expensive materials and human safety, perhaps it’s time to challenge your approach. Things can always go wrong, no matter what approach you take. If it’s cheap to fail, why not try it out? We often find projects inspired by agile release early, improve over time, avoid waste and save money.
If your project or programme involves transformational and organisational change, or a repeatable process, you have an excellent opportunity to approach your project using agile techniques. Design-up-front traditional project management processes were created to combat constraints that simply don’t exist for these projects.
Agile organisational change
One example of a non-digital Agile project at MOJ, is the Shared Estates Cluster. This project is designed to build and merge the Estates team across a cluster of government departments. MOJ Digital is currently providing agile coaching to help the project team in their initial Discovery phase and looking to identify the small piece of the project to test for the Alpha phase. The project team understands there are so many possibilities for how this new Estates team could be structured, so they are testing a small piece of the puzzle first.
You can read more about the Discovery, Alpha, Beta and Live phases in GOV.UK’s service manual.
Within MOJ Digital, our recruitment team is working hard to catch up with the demand for our services by finding more MOJ Digital team members. With the use of a Trello board for task management and some Kanban reporting techniques, we are starting to understand which roles are taking the longest to fill, identify bottlenecks and track average cycle times. Perhaps slightly controversially, we are also starting to understand which MOJ Digital characters are taking the longest to provide feedback on CVs.
There are so many useful concepts in the world to get inspired by, and if I can inspire to read more about agile and iterate on your processes, that’s my job done.
Image courtesy of NASA on The Commons.
Comment by Dan Brown posted on
This is a great post. I spent some time yesterday talking with Arie van Bennekum - one of the authors of the agile manifesto - on this very topic, and he told me that with hindsight he believes that they should have used the word 'systems' instead of software in the manifesto, I prefer 'services' as that implies not just the system, but a way of using that system effectively.
The agile or no agile decision is really all about understanding the complexity of what you're doing. Complexity leads to emergence, and this is where agile excels. Where there is little complexity, agile is too heavy, but all knowledge work is complex, so agile should help us wherever knowledge work is being done.
Comment by Amy Wagner posted on
Hi Dan, thanks for the comment!
Interesting comment from Arie van Bennekum! Did you catch Jeff Sutherland's (co-creator of Scrum, co-author of the Agile Manifesto) talk at GDS yesterday? During the talk, he flashed up the Agile Manifesto and replaced the word 'software' with 'product'. I like your 'services' idea though, it feels slightly more inclusive somehow. Jeff also mentioned there are plenty of safety software / aero-engineering projects using an agile approach too. I'd be VERY interested in understanding more about how they manage their safety constraints.
Comment by Hugh Knowles posted on
Are you aware of anywhere that offers training for the agile approach for non-software projects?
Comment by Amy Wagner posted on
Hi there Hugh.
I can't recommend any specific non-software courses I'm afraid, but I firmly believe that formal training only makes up part of the agile development picture. Anyone can get started today! There's some great info on GOV.UK about agile training: https://www.gov.uk/service-manual/agile/training-and-learning.html
The Scrum Alliance believes you can apply Scrum to to non-software projects (https://www.scrumalliance.org/home/non-software-professionals) but you would need to be careful to select a Scrum trainer / course that focuses more broadly than software.
I hope that helps 🙂
Comment by Hugh Knowles posted on
Thanks Amy. Much appreciated. We are looking to apply the approach as increasingly our projects involve uncertain outcomes and multiple parties. Will take a look.