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 reogranization 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 which spans functions or teams and is (most likely) orthogonal to the organizational structure of the enterprise, business or product unit.
Service Delivery Manager
From the early days of Kanban, we talked about the need for a manager to take on responsibility for flow of work. Perhaps, echoing the concept of scrummaster, in some implementations the role of person responsible for flow has been nicknamed flow manager or sometimes “flowmaster”. It’s a sticky, if arcane and tribal, title. For our official literature, I wanted something more corporate friendly, and something that is more outwardly facing. “Flow manager” is inwardly facing and focused on process problems. I prefer names that are outwardly focused and address customer needs. This is in line with the Kanban value of “Customer Focus.”
There is 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 insure that the right metrics are used to drive relevant, valuable improvements. An outward focus is vital to insure “fitness for purpose” and to deliver on the Kanban agenda of survivability.
So, the “flow manager” concept is called the Service Delivery Manager. It 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, the someone who takes on the 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. The SDM carried responsibility for the Replenishment Meeting, the Delivery Planning Meeting, escalating blocker tickets, and what we would now call Risk Review. Replenishment, Delivery Planning and Risk Review are 3 of the Kanban Cadences.
In more recent implementations the SDM also facilitates the daily Kanban Meeting. In 2007, this role was taken by one of the function managers in the workflow. The SDM role was usually played by someone from the PMO.
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?”
The goal is to reposition the role of 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 understand where the best business value is to be found. This elevated risk management and policy owning position improves corporate governance, improves 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.
When the SRM role exists, the SRM usually takes responsibility for the Replenishment Meeting and will play a role in the Strategy Review and Risk Review.
