A day in the life of a delivery manager

Tina smiling at the camera, wearing glasses and a headset

Tina is an agile delivery manager, working with a multidisciplinary team on the Restart project. She’s based in our Leeds hub.

Hybrid working

Hybrid working is the perfect work life balance for me, and we spend 40 per cent of our time in the office. It’s important for us that we’re together as a team for our sprint changeover days. So I usually cycle to the train station, jump on a train, then have a short walk to the office.

Once I get to the office, I’ll pick up a coffee and check my emails. Then I’ll set the room up for our sprint changeover.

The sprint review

We go straight into our sprint review session at 9:30am, which replaces the usual daily scrum on sprint changeover day. I facilitate our sprint review sessions, which I really enjoy. They’re completely open, and anyone can join to see what we’ve been working on over the two-week sprint but will usually include the scrum team and key stakeholders.

This is how a sprint review usually works:

  • Revisit the sprint goal. 
  • Go through our completed work, discussing how they went and any blockers we encountered and any resulting changes to the backlog. 
  • Close the sprint and create a new one in Jira, ready for sprint planning.

Sprint planning

The scrum team reconvene for sprint planning at 11:10am. I facilitate this too, but it’s led by the product manager.  

Sprint planning works like this: 

  1. Determine team availability over the next two weeks. 
  1. Project manager shares the sprint goals and outlines the value the sprint will bring. 
  1. The team have an open discussion about the goals. This gets us all on the same page. 
  1. The delivery manager (in this case, me) goes through the product backlog, and we agree as a team what needs to move from the prioritised backlog into the current sprint to meet the sprint goal and deliver value. 

Two men and a woman looking at a whiteboard covered in neatly organised post-it notesThe product backlog 

The product backlog is a list of work that has been previously estimated by the scrum team and prioritised by a product manager with inputs from a tech lead, and a senior business analyst. This process helps us get organised, and it also allows for potential curve balls.   

Once everybody is happy with the sprint plan and the purpose and value, we work on a name for the sprint. We don’t like giving them boring numbers, so we’re currently going through our favourite animals, with the current sprint named ‘Antz’.

Top-down view of notebooks, pencils, a calendar and a coffee cup on a desk

After lunch, I’ll get ready to facilitate the retrospective, or ‘retro’. The retro is one of the most important parts of our two-week sprint. It brings us together as a team to talk about what the team have achieved, who helped us, and anything that could have been done better.  

Creating a safe space to solve problems together 

As a delivery manager, I want to help and support the team in any way that I can. Sometimes during a two-week sprint everybody is very busy and may not share their thoughts openly. The retro is a safe space for that: an allotted time to share our thoughts in an honest and open way. 

I also encourage the team to think how we could improve the inefficiencies we’ve identified or solve problems better together. Any improvements we try might not go right the first time, but that’s ok, and we keep trying until we get it right. 

A team of men and women standing and smiling as they look down at laptop screens

If there are big problems that we can’t solve as a team, I’ll take them to our community of practice. We have a ‘retro of retros’ every month where we can all share issues with the community and resolve them together. 

We’re a big organisation and, while our challenges are sometimes huge, we’re lucky to have supportive communities around us to support. I haven’t always felt part of a community in other organisations, and I really value this aspect. 

Our teams also include user researchers, interaction designers and content designers. This diversity of skills helps keep us focused on user needs, and make sure we’re delivering value for our users.

Sharing the outcomes

In the afternoon I’ll share the outcome of the retro on a wiki, including any actions that we may have agreed as a team to take forward. We’re always focused on the impact our projects can have. The work we do can impact millions of people, so being clear on the outcome of a sprint is essential. 

We approach retro outcomes with an ‘inspect and adapt’ process, with the team looking at how things have gone in the sprint, and making changes to improve things they’ve identified. If I have any actions, I’ll start thinking about how I will resolve them.  

Before I leave, I’ll check that my team have no blockers, before packing up my kit and heading for my train. 

To get more articles like this delivered to your inbox, subscribe to our newsletter.