Kanban has always been the “start with what you do now” method, and  no one gets a “new role, responsibilities, or job titles” at least not  initially. However, it is now clear that some roles are emerging in the  field with some implementations. So, it is valuable to report this,  while they remain suggestions, options, or ideas, rather than prescribed  roles for a Kanban implementation. This post follows my previous one  that Kanban doesn’t share Agile’s cross-functional team reorganization agenda,  and has always been a cross-team, cross-function solution for service  delivery workflows. What follows is in the context of a service delivery  workflow that spans functions or teams and is (most likely) orthogonal  to the organizational structure of the enterprise, business, or product  unit.

Flow Manager

When organizations make a transition from Maturity Level 1,  Team-focused, to Maturity Level 2, Customer-driven, we observe a shift  from managing tasks to managing customer-valued and customer-requested  deliverables. The focus switches to the flow of work rather than merely  completing small tasks. However, the distinguishing between upstream and  downstream Kanban and commitment points are still ambiguous. Hence the  role of the Flow Manager.

The Flow Manager is responsible for creating the consciousness that  the service team is delivering a service to identified customers. The  person playing this role facilitates the Workflow Kanban Meeting and  Flow Review, ensures that metrics are collected, and uses these metrics  to effectively run the Flow Review. The Flow Manager facilitates the  resolution of blockers, rework, and aging WIP–related issues that are  escalated from the service team. And, last but not least,  facilitates the understanding of customer requests.

A typical approach to implementing this role is to assign it to a  team member who has volunteered for it and has the appropriate knowledge  and skills to do the job.

At Maturity Level 3, Fit-for-Purpose, this role evolves into the  Service Delivery Manager and the Service Request Manager roles.

Service Delivery Manager

There is a precedent for renaming concepts in Kanban to give them  more customer focus. Inspired by the Improvement Kata in Toyota Kata, we  defined and named, the System Capability Review meeting in 2012. This  was later renamed to Service Delivery Review (SDR). The name change was  to give the meeting an outward focus on customer needs, rather than an  inward focus on process performance. By keeping the naming, the  language, and the values, externally focused, we ensure that the right  metrics are used to drive relevant, valuable improvements. An outward  focus is vital to ensure “fitness for purpose”.

A fit-for-purpose organization manages work effectively through the  entire value stream, both upstream and downstream. This naturally leads  to the emergence of two roles, Service Delivery Manager (SDM) and  Service Request Manager (SRM).

The Service Delivery Manager is primarily intended to be a role  played by an existing member of staff and not a new job title or  position. So, by creating Service Delivery Manager, we do weaken the  message that no one gets new responsibilities – actually, someone  does, that person takes on the SDM role.

Service Delivery Kanban with SDM role

The SDM role existed in 2007 in our first full-scale Kanban Method  implementation. It was usually played by a project manager from the PMO,  or the customer-facing, usually first, function manager or team lead,  in the workflow.

The person playing this role oversees the delivery of a  fit-for-purpose service, ensuring a smooth flow through  the kanban system and conducting appropriate actions to improve the  service.

The SDM manages the downstream flow of work, that is, the delivery of  selected items to customers carries responsibility for the Delivery  Planning Meeting and Service Delivery Review.

Within the scope of this role is to guide the identification,  analysis, and resolution of impediments in the workflow such as  blockers, rework, and aging work items and oversee dependency management  and assignable causes for delay in service deliveries that failed to  meet customer expectations or SLAs.

Service Request Manager

For some number of years, the question has existed, what do you do  with middle-men in the workflow? As a general rule, we wish to remove  non-value-adding middle-men positions from the workflow. However, we  also wish to avoid resistance to change. These are two core tenets of  Kanban coaching and general goals we might have for change management  when deploying Kanban in an organization. And the following guidance has  existed since 2009: we seek to elevate the role of the middle-man,  above the workflow, out of the value stream. The most common example of  this is shown in the diagram, “What do you do with the Product Owners?”

What do you do with the product owners?

he goal is to reposition the role of the product owner as a risk  manager and facilitator: someone who owns the policies for the system  which frame decisions together with facilitating the decision-making  mechanism. This role is of higher value, is transparent and open to  scrutiny, and relieves us of the risk of the “hero product owner” who  magically understands where the best business value is to be found. This  elevated risk management and policy-owning position improves corporate  governance, improves the consistency of process, and reduces personnel  risk associated with a single individual.

Nevertheless, an individual with a “hero product owner” self-image  will resist such a change. Kanban Coaching Professionals are trained to  manage this resistance as part of their training in the Kanban Coaching  Masterclass.

When the product owner is successfully repositioned above the  workflow as the owner of the policies for risk assessment, scheduling,  sequencing, and selection, they have successfully transitioned into the  Service Request Manager (SRM) role.

Again, we are weakening the “no one gets new responsibilities”  principle, but this transition is generally managed over a period of  time and isn’t necessarily thrust upon individuals at the start of  Kanban adoption.

Typical functions of the SRM include the following:

  • Develop an understanding of customers’ needs and expectations.
  • Oversee  the development of a consistent request elaboration process, agreed by  all stakeholders. Th is includes defining explicit policies for triage,  managing options upstream, qualitatively evaluating options, and  discarding upstream requests.
  • Facilitate the Service Request Review.
  • Facilitate, select, and order work items at the Replenishment Meeting.

At higher maturity levels, the SRM facilitates the upstream Risk  Review and participates in the Operations Review. The SRM ensures that  the decisions made align with the organization’s strategic objectives.  Therefore, a solid understanding of the business, as well  as well-developed communication and negotiation skills, are  essential. Similar to the SDM role, the SRM role could be implemented as  an individual or group responsibility, job title, or a position in the  organizational structure.

Implementing Roles

The roles described above are intended to be played by existing staff  who keep their existing job titles: they are roles not organizational  positions. However, we´ve learned that this doesn´t always work.  Instead, the means for implementing a role should be adjusted according  to organizational culture.

Kanban: Successful Evolutionary Change for Your Technology Business,  made no mention of roles. The assumption was that with Kanban  implementations, people keep the roles they already have and that  responsibilities are only slightly modified as a consequence of specific  practices.

However, what we now call low-maturity implementations persisted, and  it became evident that the pattern of low-maturity implementations  involved a failure to take responsibility— responsibility for flow and  for delivering on customer expectations. This led to a change of  guidance: if no one was responsible for these two crucial roles—Flow  Manager and Service Delivery Manager—it was necessary to assign them.  This led to another change in the guidance: we added all three  roles—Flow Manager, Service Request Manager, and Service Delivery  Manager—to the KMM in October 2019, prompting the 1.1 release of the  model.

It is important however to remember that there is a variety of ways the roles had been implemented.

  1. The group shares responsibility.
  1. An individual takes on additional responsibilities within the scope of their current job.
  1. An individual is formally given the Flow Manager or Service Delivery Manager job title.
  1. A new organizational structure is introduced, formally creating a new position and reporting structure.
Graphical user interface, text
Description automatically generated with medium confidence
Great! Next, complete checkout for full access to Kanban Maturity Model Blog.
Welcome back! You've successfully signed in.
You've successfully subscribed to Kanban Maturity Model Blog.
Success! Your account is fully activated, you now have access to all content.
Success! Your billing info has been updated.
Your billing was not updated.