I’ve been a senior project manager at PDS for 18 months now, working on complex digital projects with a wide range of people across Parliament.
One of my priorities is finding a style or method of working that suits each project, its team members, and its users. You’ll hear a whole host of buzzwords thrown around when talking about project management methodologies. Each of them have their merits and challenges.
Over the past six months our team adopted agile to successfully help structure and improve our approach on our latest project and I thought I’d share some thoughts on using agile as a way of working.
Applying agile to a project
In January 2019, I started working on the House of Commons hardware refresh project. One of the aims is to replace old hardware with new hardware in MPs’ offices across Westminster and in their constituency offices.
I was keen to see whether agile delivery principles could be applied to a project where what’s being delivered is more or less the same every time. Agile has always been my preferred delivery method in previous project work but it’s more traditionally used in software development where a product or service is incrementally delivered and iterated sprint by sprint. A hardware refresh project is a different ball game. A laptop is a laptop is a laptop (except when it’s not).
Agile can help to refine a process as well as a product
Just because agile was born out of software development doesn’t mean it has to be exclusively reserved for those types of projects. If the project you’re working on stays relatively static but you want to improve efficiency then the process can become your focus of improvement and iteration.
This was our approach with this project. We wanted to improve the rate we could approve hardware orders for MPs’ offices while still capturing all the data we needed. We decided to hold retrospectives at the end of each week's sprint to agree what to change/stop/start. By reserving time for analysis and reflection into the project, we managed to improve the productivity of our approval process by 300% in six weeks and shortening the time it takes to get new hardware.
Agile values are great for building teams
Forming a new project team can be challenging as it’s bringing together colleagues from a range of disciplines, grades, and project experience. Many of the agile mechanisms like standups, sprint planning sessions, and retrospectives are perfect for establishing a sense of togetherness on a project.
Everyone in our team was encouraged to give their views in meetings and given enough freedom to find the areas they naturally feel best placed to help with. Investing in “individuals and interactions over processes and tools” is the single most important agile principle in my opinion. Allowing your team to self-organise is crucial to build trust and unlock everyone’s potential. And remember, without your project team, you have nobody steering the ship!
Agile gives you freedom to fail
The step by step nature of agile means you can take a few risks when trying something new. The worst case scenario is that it doesn’t work and after trying it out for a sprint you go back to the drawing board.
In the hardware project we introduced new process changes on a weekly basis, some of which we scrapped after a week and some that stuck for the duration of the project. This freedom to fail is hugely important in empowering teams and giving them the confidence that it’s okay not to get something perfect first time. That confidence in turn breeds creativity and ultimately leads to a better end product.
You don’t have to call it agile
Last but definitely not least, if the people you’re working with don’t like the term ‘agile’ then don’t use it. Agile can sometimes have negative connotations and some people don’t like the ritualistic nature of ‘standups’ and ‘ceremony days'. The main thing is to know your audience and stick with the principles.
Agile is about taking simple concepts and common sense approaches, and creating a common language around that. The principles are the same whether you call something a review session instead of a retrospective, or a timebox instead of a sprint. As with everything, it’s about what works for you, your team, and your users.
Read other posts about cultural values in PDS.