When I first joined the Cyber Security and Innovation team, it was a very busy time, with a rapidly expanding team and remit. The team is split across London and Leeds, and between us all covers a wide range of projects. One of the challenges was getting to grips with the sum total of everyone’s work and understanding how much resource was needed for each project.
The Digital and Technology Strategy team offered to help our team try out the 'agile' style of working, using regular stand-ups, sprints and retrospectives to continually review and manage our work. I was up for trying something new, but pretty sceptical about whether it could work for our team – it seemed like it would be a new admin burden and wouldn’t fit a team based across 2 sites with a lot of reactive work to deal with. So although I was willing to try it, from the outset I was pretty sure that a regimented project management style with daily meetings and strict prioritisation just wouldn’t work for a policy team.
That was 7 months ago now and I have 100% changed my opinion – and I’ve never been happier to have been wrong. I had kind of missed the point in my understanding of the agile methodology before we tried it. I now see that it’s not about sticking to a strict recipe of daily meetings and weekly retrospectives, but rather it’s about a flexible model of work management centered around visibility and constant review.
The bit that I hadn’t grasped was that it can be adapted to suit the team using it and still be agile and a really effective tool. Over the course of a few months, we made some changes:
- given that we are split across London and Leeds, a daily meeting wasn’t really practical, so instead we have 2 a week. So that we can all see each other, we do this as a video conference. So it’s not standing up, and it’s not daily, but we each take turns to talk briefly about our key priorities that day/week, and we all share potential blockers to delivery, and try and help each other with those
- we don’t have a physical project board but instead use Trello to log our work. Each project/piece of work gets it own slot on Trello, and we’ve agreed the bare minimum format for information that each Trello card so that it's really clear what each piece of work entails
- our sprints are a month long instead of 1 to 2 weeks, because it suits the pace of our work better
- each month, we ‘budget’ a certain amount of time for the reactive work, and in the retrospectives at the end of each sprint we’re able to see if any projects weren’t completed because we didn’t budget enough time for the reactive work
- in the planning session each month, we prioritise all the work that must be completed that month, and then assign work to everyone. When we’re doing this we take into account all sorts of factors: priority concerns of our senior leaders, how many times we’ve de-prioritised something already, individual interests of team members, development needs – the list goes on. It means that the prioritisation and allocation process is completely transparent and everyone gets to be a part of influencing what work makes the cut for that particular sprint
This might all sound very simple and intuitive, but it was quite a transformation for us. The moment I realised that it had really transformed the way we work was the last day of our January sprint – I had run out of things to do! In 5 years in the Civil Service I don’t think I had ever come to the end of my to-do list, but with a to-do list that is constructed to be a month long, and with a heavy focus on keeping it all achievable, the agile methodology makes it possible.
If other policy teams are thinking of trying agile but not sure it would suit, I would definitely recommend it, and I would recommend tinkering with the exact format to fit your team and your team’s work.