Select Page

Barry Ashford

Scrum Master

How to be a superhero service manager – what I learnt from Government Digital Service training

When I first heard about the Delivery Manager Training run by Government Digital Service (GDS) and its aims and objectives being to provide a deeper understanding of the role of a Delivery Manager and explore some of the techniques and methods that are commonly used on digital teams, I couldn’t type the message to my manager any quicker to ask if I could attend this course as I want to continually develop my knowledge and skills to become an awesome delivery manger.

So what did I learn? – The first thing to say is “a lot”, all jokes aside I could write all day long about the numerous things I learned but as my manager set a max word limit of 600 (those that know me will understand why), I can only really talk about the things that really stuck in my mind. The training helped to expel some myths around my beliefs and understanding of agile, it led me to realise that the agile way of project management is forever evolving and the benefits of honesty and reflection.

‘Agile is faster’ – agile is not faster (in regard to the actual work completed) but rather smarter in the way it helps identify the best development path to get to a viable product far sooner. Using research from the discovery phase to identify the features / tasks that are more valuable to the business / customer, the whole project is broken down into sizeable chunks that can be implemented. These build on features of the whole project and in many cases the customer realises that they don’t need everything that was originally planned which brings the finish timeline forward.

The power of reflection and open honesty – no one can hide in an agile project or more appropriately, no one should want or feel the need to hide in a project being delivered in an agile way (no covering your own back here). In particular, the most popular agile framework in use today is the SCRUM framework and this is underpinned by 5 values:







Keep what works and drop what doesn’t.

Reflection and learning in retrospectives and being open and honest within your team are fundamental to building trust and respect which in turn are vital in a high performing, high functioning team.

Keep what works and drop what doesn’t!

The final thing I wanted to write about was what one of the training facilitators referred to as an ‘Agile Toolbox’ in which you keep a collection of ‘tools’ that you use when needed. This can be anything from physical things like post it notes, packs of planning poker cards, a stopwatch or even pens to intangible things like different retrospective techniques, ways to handle blockers (Bash-Board) or even an acronym to help you break down an epic user story (INVEST or SPIDER). The one resounding statement he made, which surprised me, but makes perfect sense was that you should keep anything and everything that works and drop anything that doesn’t, regardless of whether it fits with waterfall techniques or agile or anything else. He mentioned that he keeps a Gantt chart for himself (not for sharing) that helps him keep track of his own tasks and plan his own time (obviously this chart is subject to change though).

I have mentioned a few things here that just skim the very surface, of the things I learnt throughout the 3 day course at GDS and pale in comparison to the other aspects of agile project delivery and the benefits of developing software and applications in this way. I have to thank the other DM’s attending the course and their willingness to share experiences and expertise but I must give credit and thanks to GDS, as their purpose for their new academy is to upskill civil servants in Digital and Agile ways of working to help facilitate government transformation, which I think we all need to do a little more of, as for me? My learning continues…