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, I mean in the most generic meaning possible. It could be your product metrics, your engineering DevOps metrics, - or your flow metrics, pre-metrics, - whatever there is to measure that matters to the team. We wouldn't mandate what types of metrics the team needed, - but we would help them find their own. We would also run programs because, again, it's a hybrid role. Effectively, our role was to accompany the teams through delivery of outcomes. And that also meant managing big work streams. Health checks, also really important. I personally believe that a healthy team is also a more productive team - that can do great things. Ways of working. Same as with metrics, - we would help the teams find what worked for them. Agile practices doesn't need any introduction. We would help teams achieve the type of agility that works for them. We would also help teams plan their work. I say continuous planning, because it's the type of planning I prefer. I don't really believe in big block quarterly planning. I know that's the reality in some cases. I just don't prefer it, to be honest. Then, background management support. We would help teams visualize - their work with whatever tools are in use at that time. We use Jira and Confluence. I'm aware that elsewhere - other teams may use something different. Given how few of us there were, you can easily imagine that this is a lot. It could easily lead to burnout, but also, it could lead to inefficiency. What we had to do at that point was select - among this big remit that I described, - some areas that we would guarantee to everyone at all times. So this is it. This was the result of the selection. We decided to maintain the current remit, - the attention to metrics, health checks, planning - and backlog management support. Now, this ruffled a lot of feathers, especially among the stakeholders, - but also the individual engineering teams. If you think about it, the selection that I've just highlighted - feels a little bit cold, with the exception of health checks. It's very facts and data. In reality, though... This was never meant to be all that a delivery manager would do. It would be just a baseline level of service. The areas we selected were selected because they would - give us enough information to be able to then make important decisions. The way this works and the way we transition - from a minimum level of service coverage into a deep dive and problem solving - is that the delivery manager just looks at their data sets. Obviously, among the data sets, I also include relationships with the team. Obviously, we don't just talk data and numbers, there needs to be - an underlying level of relationship with the team to be maintained. It doesn't mean attending all the stand-ups and so on, - but there needs to be a human connection that would allow us to communicate. Other areas that a delivery manager would look at - would be wellbeing metrics and health checks. We would try and see what's going on with the teams from a human perspective. Activity and communication metrics. Does the team communicate well? Do they do pair programming? Do they work together? Do they review each other's work? Do they team up and mentor each other? Are they efficient? Are they productive? Is their code secure? Also, are they visualizing their work in some way? I prefer Jira, but again, it doesn't necessarily have to be that. Is the work visible? Are the teams aware of the work - that's going on from a holistic perspective? So, the delivery manager would look at the datasets, and then - would spot problems or opportunities. The way this would work is that when a problem arises, - it doesn't get taken as absolute truth. The delivery manager would compare the findings in data with other data. If the problem is confirmed, they would initiate a conversation with the team - to see if the problem is recognized by the team, first of all, - and then if the team accepts to be pulled. This is really, really important. We never coach teams without their consent. We need to try and find solutions together and act as a well-gelled group. At that point, the delivery manager would coach the team - through resolution of their issues and end this type of engagement - and go look for a different problem. In this way, the delivery manager would be able to operate in a large area, - potentially, let's say, seven, eight, nine teams in an effective way. The manager wouldn't burn out and wouldn't necessarily have to be - in all the stand-ups, print planning, retrospectives, and so on. I'm going to make an example to explain a little bit what that means. This is a real life example that has actually happened. A delivery manager runs a cycle of health checks in a group of teams. So for context, a takeaway, our health checks are - revolving around scoring six main areas. We don't use the Spotify health check model. We use a model that is inspired by the Google five characteristics - of high-performing team, if anyone is familiar with it. It's inspired by it, it's not exactly that. The six areas that get looked at are psychological safety, - which, I think, doesn't need any introduction. Dependability explains whether or not - team members can rely on each other to deliver good quality work. Structure and clarity. It revolves around the idea - that the team has the appropriate tool or information - that they need to do their job. Meaning of work is an area that focuses on - whether or not the engineering teams feel like - they're delivering good and meaningful work. Impact of work is more outward facing. Effectively, it's whether or not stakeholders feel like - the work that the team delivers is important. And then speed, which is whether or not the engineers - feel like they are proceeding at a pace that is satisfactory. In this example, the delivery manager spotted - that the scoring for speed kept going down. Obviously, it's a health check, so it has a lot to do with perception. This is even more of a reason why we shouldn't just stop at the first metric. Then, the data from the health check was compared to other data sets - that were available, such as the cycle time, the rate of work in progress, - whether or not there were blockers, and so on. The delivery manager, together with the team, - acknowledged that there was indeed a problem going on in the team, - that the team was going slower than they liked. So at that point, the deep dive started, and the delivery manager - started observing the team a little bit more closely, - started acting a little bit like an in-team scrum master. The delivery manager attended all of their events, - looked at what the team was doing, et cetera. The analysis returned some results. What emerged was that the team had a series of blockers - that were always occurring with the same teams. The team was always blocked by the same external teams. At that point, the team started, with the help of the delivery manager, - mapping their dependencies a little bit better. They also found out that the reason why they were going slower. They were getting stuck on other teams, they were dragging more work in - and therefore creating bottlenecks for themselves. The way it went, and of course I'm oversimplifying, - was because this was a process that went on for quite a long time. Effectively, the team was coached in principles such as Little's Law, - but also started planning their dependencies with a little notice. They initiated the conversation around organizational design as well. Because if you're always blocked on the same teams, - there's something fundamentally wrong with how things are being structured. So, at that point, the delivery manager - supported the team through the resolution, - and then restarted the cycle somewhere else. Self-service tools also need a mention because it's true that there was - and there is still very few of us in the organization. Also, and this makes me a little bit unpopular among my peers, - I don't think that there's a need to have a scrum master - in each and every team necessarily. At the end of the day, when you think about how scrum started, - it was engineers self-organizing. We should promote that type of behaviour. We should provide engineering teams with the tools that they need - to find the right pace for themselves. We also started working a little bit on our self-service tools, - that would be anything that would help engineers achieve that. I'm going to show a non-conclusive list here. It really depends on the realities of the companies that you operate in. Effectively, these tools include metrics dashboards. My team at Just Eat Takeaway has created some wonderful eazyBI dashboards - where we could see all the metrics that mattered everywhere. Obviously, this is not micromanagement. We would just offer these to the teams. Actually, it was engineering teams that asked us to provide that. Now we're using an external tool for that, - but eazyBI or anything internal that you may have does the job just fine. How-to documentation. Don't underestimate the power of a Confluence page. It seems like a really simple thing to do, but if you create pages around - what's Little's Law, what cycle time, et cetera, - people will read it and they will self-serve. Team assessments, I don't actually have that. I keep putting this on my slide at conferences - because I'm always hoping that someone gives me a solution. My dream is to actually find a nice automated way for a team - to do self-assessment on their agile practices and find what works for them. So, dear AI friends, if you have any ideas, here's a business idea for you. If you achieve that, let me know, because I'm interested. Project management handbooks. My team here, Phoebe, who is here, has provided a lot of documentation - around how to run a program if you're not actually a program manager, - so that engineers can just run their projects and achieve results without us. Then training. It's really important to train engineering leaders into agility - and into program management, so that they can either self-serve - or understand the purpose of these practices. We run a cohort, a three-day training course internally at Just Eat Takeaway - that trains engineering managers to be their own delivery managers. Now, this is my favourite section, because - when I explain it on stage, it sounds really smooth and easy, - but this was actually a really bumpy road. There were a lot of learnings. First of all, when you try to scale yourself, - the first temptation is not to scale yourself and burn out. What I've observed in myself and other delivery managers - was that we were trying to do it all. So instead of selecting and prioritizing, - we were trying to be a scrum master in seven, eight, nine teams. If you think about your standard, let's say scrum events, - not everyone does scrum, but you can imagine, - it's impossible to actually do that. It leads to burnout and lack of wellbeing. We need to practice what we preach. We need to learn how to prioritize the biggest value items. This is the recipe of success. In the context of that, - dream big and think in ecosystems. When you're prioritizing, my recommendation, - even though it's not always that way, - is to focus on problems that impact the largest amount of teams. You probably have met in your career a Scrum team or a Kanban team - that has implemented their work practices just fine, - and yet still failed to deliver their outcomes. The reason why that was is that despite that team was - working really well, the ecosystem they were in - was not quite working right, and so they were not delivering. So, if you need to select problems to solve, - try and think about large scale first. This is somewhat similar to the Flight Levels theory, - if you're familiar with it. Now, also the system was created in a moment of crisis. I came up with it because I was desperate, - I was trying to make things work. But it's not a system that is necessarily just applicable - for teams that are understaffed, effectively. It works just fine, even if you have more people available - and actually works even better. So the difference is here. Let's imagine we have six teams, - and we need a delivery person. We have just one. The delivery manager proceeds the way I described, - conducts their analysis, does that deep dive, then repeats. Let's say, if you had two delivery managers, even cooler, - because effectively they can conduct their analysis together. They can look at data together. They can conduct multiple deep dives simultaneously. They can be connected. They don't have to be connected. Then, look at their achievements together and then repeat. This is actually quite a good way to go on about this - because it also helps training more junior team members. So, looking at data, looking at metrics together, - it's a bit like pair programming for engineers, really. There's a lot of learning to be had. Another thing I've encountered in my career in general, - not just for this system, is that teams sometimes - don't know what they need from their scrum masters or delivery managers. They come up with requests that are rather bizarre, - such as, can you run all of our standups as a host? Or can you schedule all of our meetings? Can you write our user stories, or can you tidy up our backlog? Now, none of those things are actually in the remit of a delivery manager. We know that reality is complex, and I myself have organized a meeting before for a team. The way I see it is that these things are a bit like making tea for your team. It makes sense sometimes for you to do it, - but that shouldn't become your entire job. In that case there's something going on in the team, - and it needs to be addressed. We need to make sure that as professionals, - we communicate where we can add value - and where we can prioritize our needs better. Another problem that we had was that it was really hard to manage expectations. 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