Delivery Management in an Agile World

This week, I’ve been working with a growing technology company in how it should should scale its capability to deliver product into the market. As part of this, they are working through implementing a new Delivery Management capability. But doing so has raised a few challenges.

The first is in defining what Delivery Management is. Once an organisation reaches a certain complexity, they tend to have Scrum Masters, Project Managers and Delivery Managers. If the growth has been organic, the scope of these roles are often blurred, combined or overlapping. Even though these roles don’t cut code, lack of clarity still leads to slower team velocity and higher cost of quality.

The definition of roles is an application of Conway’s Law, in that how the company has decided to organise itself is a constraint upon the software that is created. This company has decided to define Product Owners as responsible for soliciting and shaping the demand for their product. Their responsibility ends at the refinement and prioritisation of the User Stories. The Delivery Manager is then defined to match the Product Owner and be responsible for ensuring the software development tasks are completed to the expectations set by the prioritisation. They turn software development by a team responsible for a specific tech stack into a delivery capability.

To do this successfully, the Delivery Manager needs to have a deep understanding of the technology stack to be able to assess delivery risks and mitigations, have good commercial acumen to negotiate re-sequencing of product priorities in order to match demand to capacity, have real-life Agile experience to be able to coach the team to be effective, and great communication skills to foster a common understanding with all stakeholders. It’s a skilled role that needs a seasoned practitioner to do it properly.

The best delivery is a single continuous pipeline that maps the value stream from demand to delivery and back to demand. However it’s very difficult to justify the cost to duplicate a delivery capability if multiple products use the same technology stack. So this company, like many others, has decided to pool its development resources. One delivery capability fulfils multiple products, demand is aggregated, and a better utilisation achieved - at least in theory.

This is the second challenge of Delivery Management: how exactly to collaborate with multiple Product Owners. On the face of it, their role is to aggregate and prioritise the already prioritised product backlogs into the development team. But it’s a poor outcome is if they turn into de facto Product Managers, needing to be convinced that one product’s User Story is more important than another’s. It’s a poor outcome if they are a filter that impedes the transparency within teams. This many-to-many relationship between products and capabilities is fraught.

The final challenge comes in the overlap with Project Managers. Simply put, there shouldn’t be any. But there often is because Delivery Managers are often ex Project Managers. Whereas a Delivery Manager focuses on the value delivered by their delivery capability, a Project Manager will ensure that all of the other things needed to get the product to its customers get done. This is a broad and important remit. They might administer internal compliance processes, ensure that finance and accounting systems make necessary changes, coordinate with external suppliers or collate status information - the list goes on.

How each company addresses the three challenges of defining the role of Delivery Management, developing a coherent way of aggregating product demand, and ensuring that they complement Project Management, will depend on their unique context. However one thing is needed by all companies: to be successful collaboration is critical. The right way of working will emerge if we value individuals and interactions over processes and tools.