Government has been using Agile methods for digital projects for a few years now. This is part two of a very short series on learning about project delivery methodologies. Part 1 was a general overview of how to develop expertise in project delivery, there’s a third part on PRINCE2 and if people ask more questions then I’ll write more parts.
I’ve worked on a variety of different kinds of projects since the mid-1990s. Some of them have had features that we now recognise as Agile. In government we’ve been consciously applying a range of agile methods since about 2012. It’s probably worth mentioning that there isn’t a single agile method, or a correct way of doing agile (although there are wrong ways).
Shouldn’t we all be Agile?
Agile is a really interesting concept, one I’ve applied to about half a dozen projects. It’s a really nice approach if you are doing something that it suits. I think it gives you more control as a senior manager and it also gets you away from the rigidity of plans and explaining why you are off-track. That said, it doesn’t mean an end to planning. In fact it’s the opposite, there’s more planning, but it comes at the right point. The backlog is re-prioritised frequently by the product owner, and the team plans the top priorities for each sprint, so there is little room for you to go far off track.
However Agile isn’t the answer to everything. It was made for software development where you gain lots by frequently iterating your design and showing it to real users. It works less well for things that are hard to iterate, like building moves. It also doesn’t work terribly well for outsourced activities (unless you were bringing them back in-house).
What is Agile?
As mentioned above, agile isn’t a method, it’s a way of thinking about delivery. If you find yourself about to work on a project that is using agile ways of working then you absolutely must read the Agile Manifesto. It’s very short, it all fits on a half a powerpoint slide in about 18 point. There are four points, and they are about emphasis when you need to compromise, rather than absolutes to obey. But don’t take my word for it, read the original, and take it to heart.
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
You can replace a working solution for working software, it still applies just as well in other contexts.
Agile as Used in Government
The best starting point for this is the Government Service Design Manual, which is produced by GDS and available online. It’s useful for non-technology enabled services as well. It sets out how we should go about designing and building new services, with an expectation that they will have a strong digital element.
Most digital projects use some form of scrum, these follow a general pattern of working out user needs, prioritising those and then completing chunks of works in sprints. At the beginning of each sprint a planning session re-prioritises and allocates work within the team, and then daily stand-ups check progress, ensuring problems are highlighted as soon as they become visible.
Sprint lengths vary, but most teams go for one or two weeks. Some run longer. They key to this method is that there are tangible results at the end of every sprint. This helps engagement, of both the team and key stakeholders, through frequent successes. There’s also an opportunity to revisit things in response to changes in the environment. If you need to re-plan, or plans are negated by events mid-sprint more than once, then the chances are that your sprint is too long. The converse is also true, sprints that are too short lead to slightly more time spent planning than doing. The focus is to get most of your effort on doing relevant things. Most teams I’ve worked with have settled on two weeks as an acceptable compromise.
One of the key features of agile, as I’ve experienced it, is that the planning and delivery is more inclusive. The whole team sits in on the planning session and everyone estimates how long they think things will take. Those actually allocated the task get the highest weight when taking size/time into account. This leads to better engagement in the team because everyone gets a say in how they will do the work, and people understand the complexities of what is involved.
Like all the other methods this is easiest to learn when you are on a project using the method. Agile isn’t itself a single coherent method, but a group term. So you need to know what the general flavour is on the project that you are working with. Unlike many of the other project methods I’ve worked with I’ve found that agile is more heavily tailored and often a specific team will have blended more than one method to suit their way of working. Your experience on an agile team will count a lot towards understanding the philosophy and methods. So only book yourself onto a training course once you have a place on an agile project and know that you will get experience of using it.
You could do worse than to start your learning journey on Civil Service Learning https://civilservicelearning.civilservice.gov.uk/learning-opportunities/working-agile