Emerging Roles in Kanban
Authors:
David Anderson, pioneer of the Kanban Method, co-author of the Kanban Maturity Model, CEO of Mauvius Group Inc.
Anna Radzikowska, Accredited Kanban Trainer and Coach
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 a Service Delivery Manager, we do weaken the message that no one gets new responsibilities – actually, someone does, and that person 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, 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 middlemen in the workflow? As a general rule, we wish to remove non-value-adding middlemen 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 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 processes, 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 upon all stakeholders. This 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 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 have been implemented.
- The group shares responsibility.
- An individual takes on additional responsibilities within the scope of their current job.
- An individual is formally given the Flow Manager or Service Delivery Manager job title.
- A new organizational structure is introduced, formally creating a new position and reporting structure.
Explore more about Kanban on Kanban+
Kanban+ is one source of truth when it comes to the Kanban Method. It is one platform that gathers all possible Kanban method materials, taught and used by Kanban University. Create your free account now and get access to a set of free content such as posters, infographics, book chapters, and more. Learn more about the Kanban Method today!
