🙋♂️ Who's responsible for delivery here?
Why is this question relevant, anyway?
Because if we want better, fitter organizations, we need to shift emphasis away from managing teams to managing services with customer focus. And in that transition, a well known barrier is the absence of a person (or group of people) taking full responsibility to deliver services to customers.
By "responsibility" here we mean it in the Christopher Avery's "Responsibility Process" sense: "taking ownership" (owning your actions as well as their ramifications) and "being at choice" (responsibility is something you "choose", not something "assigned to you").
In Kanban we recognize these (and other) traits in the Service Delivery Manager (SDM) role. So asking "who's responsible for delivery here" translates to "who's your SDM here".
💡 Here's the thing: in many organizations, SDMs are already in place, but many don't see themselves as such, resulting in a dysfunctional, maturity limiting situation.
🙋♂️ What does a Service Deliver Manager (SDM) do?
In short, an SDM takes responsibility to manage a service to deliver on Customer's needs. There's a lot to unpack here.
By "service" we mean a group of people that need to collaborate to do work that satisfies someone's needs. We call that "someone" the "customer". This group is organized in various social structures, with "teams" being the most common. Although a single team can some times be a service, more often than not services require the orchestration of work across multiple teams.
Work in a service moves along a "workflow". As it moves, it crosses two important moments: "I promise" (where a commitment is made to the customer) and "here it is" (where the result of work is made available to the customer). By "taking responsibility", we mean that an SDM accepts full ownership between those two points.
This responsibility includes ownership of two areas of focus: delivery of the outcomes and results that will satisfy the customer's needs, but also working on the process, to improve it over time so it is (and stays) fit for purpose.
By "managing" we really mean "autonomy to set policy" within the service. In essence, autonomy to decide how work is done and how the service will run. This autonomy is not unbounded, though: it will fall within organizational constraints. It can also be exercised in a range of delegation styles (anywhere from an autocratic "I make all the decisions and tell everyone what to do" style, to a collaborative, servant leadership style).
Imagine a few neighbouring kingdoms surrounding a lake. They all fish in the lake to feed their populations. Eventually, their kings and queens recognize that if they all send their fishing fleets to indiscriminate capture fish, they risk entering into an escalating competition leading potentially to conflict and overfishing. A "tragedy of the commons" of sorts.
These enlightened rulers then decide to sign a treaty, by which they all agree to hire the services of a "fleet commander", who will be a "trusted partner" for all of them and take command of the combined fishing fleet, managing it to exploit the resources of the lake in a way that is fair for everyone and sustainable over time.
Essentially, what we have here is a group of stakeholders that realize that they all share a limited resource, and that uncoordinated access to it will eventually lead to overburdening and a poor experience for all of them, so they choose to collaborate instead of compete. They all agree to recognize the authority of the "fleet commander" and expect fair treatment in return.
A service usually serves multiple customers, with conflicting agendas and political clout. These can easily lead to service overburdening and unreliability (usually by high WIP, abuse of expedites and forced fixed date requests). This can be solved by having a clearly defined (and responsible) SDM who is recognized by all customers as the "trusted partner" that will balance their needs and the delivery capability of the service.
In practical terms, an important part of the SDM role is about setting policy.
Some of those polices control how work crosses the "I promise" line, which configures the "service interface". This includes defining what kind of work will be accepted in (Work Item Types), how it will be treated and prioritized (Classes of Service), in what proportion respect to other types (Capacity Allocation), how it will be selected and how frequently (Replenishment policies), what guarantees will be made (SLAs and SLEs), etc.
Once the work is accepted for delivery, policies are needed to mange how it moves through the workflow: what stages it needs to go through (Workflow States), how it will move between stages (Transition policies, including Definitions of Ready and Done), and how flow will be managed (WIP limits, blocker & dependency management, metrics tracking, etc.)
Eventually, work will have to cross the "here it is line". Policies will be needed to determine things like how often deliveries are made (Delivery Frequency), how many items will be bundled together (Batch Size), and possibly many others.
How is the Service Delivery Manager (SDM) different from the Service Request Manager (SRM)?
They manage different kinds of risks: the SDM makes sure the service delivers on its commitments, whereas the SRM makes sure that appropriate options are available at the time of making those commitments.
It's important to notice that SRMs are not "proxy customers". SDMs make promises (commitments) to real Customers, not their "representatives".
For simple services, the SRM role may even not be needed. The SRM role emerges when the upstream flow (the activities that precede the Commitment Point) is complicated enough to need someone dedicated to manage it, and additional sophistication is needed. In those cases, the SRM function is to help Customers refine their requests (or needs, or ideas), narrow down options, and marshal them towards the commitment point, where they can eventually be selected during Replenishment. This involves, of course, much more than managing a backlog and writing stories 😉
🙋♂️ How do I find the SDM? (or that it's absent)
Once you've identified the service, realize that there's probably someone playing the SDM role already (albeit not in complete form). Follow these steps to find the SDM:
Ask: what comes out, that is customer recognizable? You're looking for a deliverable (Work Item) that some customer would recognize as something they requested and that it satisfies some specific need.
Look upstream, and ask: who said "I need it"? You're looking for the Customer for that Work Item.
Ask: When was a promise to deliver that item was extended to the client? You're looking for the moment when the item crossed the Commitment Point.
Ask: Who said "I promised?"
Ask: Is this person taking ownership and actively managing all the way until delivery? You've found your SDM
Notice that the answer to #4 is usually clear, and very often surprising (not the person you would have initially thought it was.) Also, very often you will find that the person revealed by #4 doesn't pass the test of #5 (i.e. this person is saying "I promise" but then not taking responsibility for delivery); this often is the signal of a dysfunctional service, and a limitation to maturity growth.
Also notice that we're not looking for titles, or explicit roles, but for behaviours.
🙋♂️ What does the SDM role look like "in the wild"?
Once you start looking for it, using the "algorithm" described above, I've observed the SDM role to take various (recurring) forms, some of them yielding good results while others are dysfunctional. The picture below shows several of those "patterns", which will be described in future articles in this series. The ones in red are dysfunctional and, when present, represent a significant barrier to increasing the service's maturity level.
SDM by Committee
SDM by Functional Authority
Too Many SDMs in the Kitchen