I'm Steve Bruce, one of the Delivery Managers in the DWP Transformation Hub in Leeds. I joined DWP in September last year as a delivery manager and, with my background in managing a digital portfolio, I soon found myself being given responsibility for managing the delivery of the Personal Independence Payment (PIP) digital service.
As I’d previously been a project manager overseeing a suite of digital projects, I was excited by having the chance to make a real difference with the PIP service and a little hesitant about getting my hands dirty in a new way of working. One of the Delivery Manager's roles is to keep the team agile. I thought I’d be fine with that. I’d done the training, got my qualification as scrum master. I was even fortunate enough to be part of DWP's Digital Academy which gives its graduates a thorough grounding in various aspects of agile digital delivery.
What I soon learnt was that being a Delivery Manager didn’t just mean turning up and facilitating a bunch of ceremonies and monitoring velocity, it is also about good team dynamics and a commitment to learning and improving.
My role as Delivery Manager
As Delivery Manager it’s my job to set the pace and keep it going. I am the interface with the business and act as something of a buffer - keeping the demands of the department off the shoulders of the team, so they can continue to work unhindered. I provide transparency to senior managers and a lengthy list of stakeholders, keeping them abreast of the latest progress in terms of the critical path, the finance picture, management of risks and issues, and escalating blockers where necessary. Our show and tells are used to demonstrate how our designs have been led by user research and iterated accordingly.
Discovery: we secured the right skills and direction
The PIP digital service was just about to enter discovery so as well as making sure we were making all the necessary research and really understanding user needs, I had to look ahead, commission the team that would get us successfully through alpha and ideally into beta. Although I was familiar with a devops arrangement, I was a bit of a newbie when it came to figuring out what skills and expertise I’d need. Java devs? Sure. WebOps? Yep. Need ‘em. Business analysts and researchers? Certainly. But when it came to technical architects, quality assurers, content designers and front end designers and developers, I needed some help.
Thankfully some of the people from the Government Digital Service (GDS) had my back. Some sound advice and a certain degree of pragmatism saw me working with our HR department to bring in the right level of expertise at the right time, and we were right back on track.
I worked with our business analysts and researchers to get under the skin of why the user would need such a digital service - one of the key outputs of discovery - and worked to challenge the current offline process. Taking a two-step offline model and looking to develop a seamless, intuitive online service from the start throws up opportunities to remove duplication in process steps which would annoy and frustrate our users.
Alpha: we proved that the concept would work
With the right level of support we moved into our alpha phase - which probably turned out to be the trickiest period of all. As Delivery Manager, I planned and facilitated a two-week inception. What’s inception? Well it’s no good if your partners, senior managers and stakeholders each have a different perception of what you’re trying to do and why. What’s the scope of the service? What’s the Minimum Viable Product? What is most important? Quality? Budget? Security? What are the legitimate policy constraints? Do we really need to meet those security standards? Inception brings all the right people into the room and gives you the opportunity to gain a common understanding and answer all those questions once and for all.
User research and testing assumptions
The key of course is regular user research and testing what we built with users. Within a couple of sprints of the alpha we had a prototype which we had put in front of users. And insight is dynamite. We were able to find out if users understood what we looking for with the level of questions. Did they understand what would be asked of them to complete the user journey? Could the users tell their story to us? Could they complete an end to end journey? Meeting with your users regularly is key, as our user researcher Simon Hurst’s blog illustrates.
Our first sprints
The first few sprints were a learning experience. How would we know how much work the team could handle? How much effort would it take to get the technical environments set up and working? How would I get the sprint rhythm right given we needed to act upon the user insight and iterate the prototype and get it back out in front of users as quickly as possible?
The answer of course is that you learn through doing. The first few sprints needed patience and a steady nerve to discard what wasn’t working and try new things. This includes how we work together and, as we got to know each other, our planning sessions have become more valuable, we get better results and we are able to get through them quicker.
Agile ceremonies brought the team together
The agile ceremonies were soon bedding in, but more importantly everyone knew why we were doing them. The morning stand ups have become crucial. Even with a large team they rarely go over 15 minutes and now each team member can see how they’re contributing towards our sprint goals. Our business analyst, developer and quality assurer get together regularly throughout a sprint as a “3 Amigos” session to flesh out the next set of user stories, so our backlog is sufficiently refined to take into sprint planning for it to run like clockwork.
The retrospectives aren’t seen as a chore, but rather an opportunity to speak out in a safe environment and discuss with the team what’s working well, what isn’t and what we should do more of, or stop entirely. It’s my job to not only facilitate these ceremonies, but to make sure that they continue to add value for the team.
From alpha to beta
The PIP digital service recently passed the GDS alpha service assessment. Moving into beta brought a greater sense of urgency and desire to develop a digital service that puts the user at its heart. After all we’re in full production mode now. The gloves are off. The user is waiting and expecting.
There’s a growing community of Delivery Managers in DWP, and we meet weekly to share good practice and help each other out - whether it’s sharing resources or overcoming shared obstacles. We’re all in it together. Some may have more experience than others. But everyone’s view is respected and valued.
I may know the priorities for the following day, but I can guarantee that a new challenge will rise to test me. And that’s why I love being a Delivery Manager in DWP.