Do more with less: Scaling delivery management in large organizations | Francesca Salvati

My name is Francesca. I work at Just Eat Takeaway. I am the lead delivery manager. A delivery manager, to my European friends, is effectively a role that is a hybrid between a scrum master and a program manager. It was born in the UK public sector and then slowly extended into the various sectors, which is where I work. I currently lead a team of program and delivery managers in the CIO or GCP/Oway. We deal mostly with data, infrastructure, security, and TICKs. I lead a team of about 20 people that operate in a space that has about eight teams. It's important for what I'm going to say later. Regarding my background, I've had quite a mixed background. I started in product engineering, doing a little bit there. Then I moved forward to Scrum mastery, product management, and a little bit of food delivery. So, the first time I presented this talk was actually internally at Just Eat Takeaway. There was a little bit of a joke going on because the way the SOAP was presented was scaled agile. Actually, that's pretty funny, because this is not at all what this was about. Actually, this is the story of how I failed to implement scaled agile. So three years ago when I was a manager, I had a big dream. Obviously the area I was operating in had a lot of work streams and body streams. I thought it would be cool to implement something like flag levels or Nexus, and so on. However, I had a very big reality check when I tried to do that. We had a series of problems that were preventing me from achieving that. First and foremost, there were very few of us. As I said in the beginning, right now we have about 20 people in eight TICKs. If you think about the way agile roles typically work, you can imagine that's quite scattered and not quite the amount that you need to have. Secondly, at the time, we didn't have any program managers. Now we do, but that's still very few. So, we didn't have people who were able to manage big, complex workstreams, if that makes sense. We didn't have a lot of product presence either, so we were lacking in the vision side of things. We just had engineering teams trying to do their best, which is good but very hard for my yield. Also, we have varying levels of agile maturity across the board. That was because there were so few of us. The way it was working is that some teams had all the luck. Maybe they had the in-teams form master type figure that had implemented their upgrade work preferences with the teams. Then there were teams that were basically abandoned for themselves. This meant it was very difficult for them to actually achieve a level of agile maturity. It became very clear really quickly that what we needed was not quite scaled agile, but an infrastructure on which we could build scaled agile, but also other things. Effectively, we had to find an effective way to operate, given how few of us there were. What found together was actually a three-part solution. First and foremost, we have to identify what we call a minimum level of service coverage. Effectively, a bare minimum of delivery service that could be guaranteed to all confined teams to avoid that gap between the teams in terms of Agile hierarchy. Secondly, we had to find an easy and intuitive way to actually zoom in to problems that we could then solve in an efficient way. Then we also had to provide teams with tools that they could use to develop themselves without necessarily having a bottleneck of the delivery manager or the scrum master. So today, a little bit about the first topic, which is the Minimum Service Coverage. This is how I personally interpret the role of a delivery manager. It's these seven areas. I know it's a bit controversial. I know that it's up for debate depending on the company. This is pretty much the way we used to intend the role of the delivery manager at Just Eat Takeaway to be. First and foremost, we helped teams identify metrics that mattered to them. When I say metrics, at the beginning, I talked about how our teams had varied levels of agile maturity. What that meant is that some teams had an in-team scrum master type figure. Effectively, they had really great work practices. Everything was going fine. Some of the teams were getting absolutely nothing. When we came up with this system, what happened is that the teams receiving nothing were actually happy because they started receiving something. What that meant is that teams that were treated really, really well started getting annoyed because they started getting less from us, or so they perceived. So effectively, it's really important when implementing something like this to manage expectations and talk to the teams. As I said, it's always a two-way street, and we always coach people while being mindful of their needs or what they believe are their needs. To make an example, um, one problem that I had, one of many, when we started implementing this was that a stakeholder got really, really angry because they felt like the delivery manager had to run each retrospective in the team forever. Obviously, that is not something that was achievable given how we were operating. And so, I just asked why, what problem are you trying to solve with your retrospectives? Because retrospectives are a workshop, potentially one of the simplest workshops you could ever run. So, is there something else in there? Why do we need to have a professional facilitator all the time? What came out of it, after a little bit of digging, was that the team was really unhappy because they didn't know how to plan their work. I responded to it that maybe we should support you with organizing your planning better, to have a more long-term solution rather than the patch of the retrospective every two weeks. When we prioritize, we also try to take the team on board with us. Obviously, we don't always agree on what the biggest value item is, but it's important to communicate.