The Delivery Manager Role — It’s Totally a Thing
I’ve talked with a lot of different scrum masters and agile teams over the years. And all agile transformations are messy, it seems. But there’s one place where all the dysfunction tends to collect and concentrate. Middle management! There’s articles about “what do all the managers do”, for example, that give a lot of reasons why manager’s roles need to be radically changed or even not needed in an agile environment. But clearly, that can’t be true.
I think it’s time we admitted that there is a role that we’ve been terrible about defining and staffing properly in the industry. The space is called Delivery Management. And for all my PMI friends, yes, you can probably call this an Agile Project Manager or Agile Program Manager as long as you mean the same thing as I describe below (but I don’t have to like it). There’s an important reason I don’t like those Project Management sounding titles though, because what we’re talking about here is an agile-specific concept that needs to closely complement our evolving standard about longstanding autonomous teams. And traditional project management isn’t usually in line with that, in my experience.
So, to better describe what I mean by the Delivery Manager role, let me first level set with you what I think about teams and teams of teams. There are clearly on-team roles, for those that adhere to one of the various agile software development processes or frameworks. And I think this applies whether you’re Scrum or Kanban or LeSS or Nexus or most anything that doesn’t get specific with new roles like SAFe does. On team are all of the skills necessary to own the whole development and delivery of the product. The autonomous team, as I like to define it, has all of the skills and roles it needs and is empowered to design, architect, develop, deliver, deploy, own and support the entire solution. I realize there are many barriers at some organizations to achieve all of those functions on-team, but this is what I would label as the ideal team. On that ideal team are also the Scrum Master (if you’re in fact Scrum, otherwise I hope you call it something else like Agile Lead), as well as the Product Owner. You may even have some shared roles if you don’t need all of a Solution Architect, UX Designer or UX Researcher, for example. And if there are multiple teams working on the same product, I’ll assume you’ve figured out how to share a common backlog, possibly (but hopefully not) share the Scrum Master and Product Owner and use some scaling techniques so that the teams can cohesively work together on the solution as a larger collective team. I also used the word longstanding because I assume you understand the value of a team gelling over time and are no longer tearing down teams and reforming them as your organization changes its mind about which products are being actively developed.
Now, this is where it gets interesting. Unless you work at a startup and I just described your entire development organization, all of the on-team roles above are inward facing and working exclusively on one product and solving day-to-day challenges with the Scrum Master and Product Owner to make your customers delighted every sprint. But in a larger organization, there are many other possible stakeholders. And the larger your organization is, the more complicated it gets. We’re talking about Marketing release schedules, Sales training, Customer Support, Data Center change management, Finance and budgeting topics, HR and staffing challenges, greater Product Management organizational expectation management, Portfolio Management, Executives and PMOs and Core Teams and Architectural committees and the list goes on. Who keeps everyone and all of the stakeholders connected and well-informed? Who handles the questions and challenges posed by any of those groups so that the team can stay focused? Who does the Scrum Master and Product Owner turn to when they need help? Who makes sure the team has everything they need to stay happy, safe and productive? This is exactly what I mean by the role of Delivery Manager. They are the glue that keeps the team or team of teams healthy, connected and plugged-in to the rest of the organization as far as the product and solution are concerned.
The Delivery Manager is a coach, a communicator, an expectation manager, a facilitator and a diplomat. They can step in and run a retrospective or play Scrum Master while he or she is on vacation for a week. They can help uplift the Product Owner’s skills. They can even serve as mentor and coach for individuals. But here is where a Delivery Manager needs to be sensitive and coordinate closely with the direct HR managers of the individuals on the team. The direct HR managers should be responsible for the career of the individuals on the team, but they are not always capable of also being agile coaches. When they are, it’s fantastic and you simply need to make sure you’re on the same page. But in some cases, you may want and need to offer coaching to the managers as well. And if you plan to coach individuals, make sure you are well connected and discuss with the HR manager in advance out of respect.
One note on Agile Coaches, because I realize I didn’t mention that role in any of the discussion above. In my experience, there are rarely enough Agile Coaches to assign one to every team. The Scrum Master is the on-team process advocate which serves the function of Agile Coach as needed. The Delivery Manager can fill in any gaps of agile knowledge to help the team in their journey of Continuous Improvement. And as an organization, there should be a process, perhaps through an Agile Center of Excellence, where a team can request the assistance of an Agile Coach to achieve some new skill or capability or solve a challenge the team is struggling with consistently.
In the diagram below, I try to represent some of what I’m suggesting about the ideal agile team in this post. On team resources are in the rectangle and make up the Product Delivery Team. Your team should include whatever skills and roles you need to be successful (don’t read too much into how many circles of which colors I have). And if you’re really awesome, many of your team members can wear multiple hats (Development and QA skills, for example, are best when an Engineer can represent both roles interchangeably and any two Engineers on a team can pair to accomplish any technical card in the sprint backlog, fully developed and tested).
In my opinion, the role of the team member’s HR manager should evolve into more of a Servant Leader. They are often responsible for the longterm well-being of the products and solutions their people have built, even though they may not be involved in the day-to-day management of the delivery. For this reason, they should be kept up to date with all changes, needs and challenges that arise on the team. Because, ultimately the person in the role of Delivery Manager as well as the individuals on the entire team may come and go over time. Perhaps there’s an even better name for this type of Servant Leader: the People and Solution owner. Doesn’t quite roll off the tongue. Either way, I think we need new names and better clarity about these roles. Perhaps the best we can do is “Delivery Manager” and just “Manager”?
I’m curious to know if anyone else agrees with me. It seems crystal clear to me as I’ve been able to operate in similar ways at multiple companies. But if you have opposing points of view or comments about the role of Delivery Manager, I’d like to hear them!
If you enjoyed this, please clap and share. It means a lot to know my work on this blog is read and used by agilists out there in the world.
Hi, I’m Brian Link, an Enterprise Agile Coach who loves his job helping people. I call myself and my company the “Practical Agilist” because I pride myself on helping others distill down the practices and frameworks of the agile universe into easy to understand and simple common sense.
I’m writing a book and will release the first of three sections soon! It’s called MakeTeamsAwesome.com. Sign up there to be notified when it’s released.
If you’re working on a hard problem and need some help or have questions about how an Enterprise Agile Coach could help you, your teams, and your company, let me know. I’d love to hear from you, email me anytime.
Follow me here on Medium, subscribe, or find me on LinkedIn, or Twitter.
