Did you know that Kanban suggests specific roles within the method?
Let’s take a step back. When people understand their roles and accountabilities they can perform their work confidently. I would argue no one really accepts a job without knowing what the responsibilities are. Maybe you don’t know the specific name of the job position, but you know what needs to be done. In other cases, maybe the specific tasks are to be defined, but you know what are the responsibilities. And in some cases, the name is everything we need: we have an idea of what a Project Manager is. Or a Business Analyst.
Yet when adopting a new structure (a framework, a method), some companies resist the idea of new roles and accountabilities. They want different results with similar roles. Sometimes people forget that projects are a construct of waterfall approaches and to work on them you need someone whose accountability is to steer the project. They named that person a Project Manager. There was no such a role for a while in companies. You had General Managers. Line managers. Account managers. Project Management was a different approach on waterfall. It was a novelty once.
Well, Kanban is also a different approach, so it is no surprise you would need different roles as well. Kanban is rather forgiving, having a rule of start with what you do now. However, sooner rather than later teams find the need to adopt some prescribed roles. First, because you need people who really understand Kanban to help everybody else succeed when adopting the method. Just like a Project Manager knows a project needs a Communication Plan and a Risk Plan, for example, the people occupying the Kanban roles will understand and teach others to understand flow, the Kanban cadences, and everything else needed for the method mechanics.
Kanban Roles
The roles Kanban introduces are Service Delivery Manager and Service Request Manager. They are like the ying to each other’s yang:
Service Delivery Manager (SDM)
makes sure the work flows out of the system: removing impediments to delivery, facilitating the seven Kanban cadences. Basically, anything related to improving workflow efficiency, including paying attention to quality. Another accountability of the SDM is making sure teams are following Kanban policies and monitoring and managing risks.
Service Request Manager (SRM)
makes sure new work flows into the system, so that the system is never idle and that all work that enters the system is valuable and prioritized. That means understanding the product or service at hand and front-facing relationships with clients and other stakeholders. An SRM does not need to understand how work flows within and out of the system as this role is not directly involved in delivery.
How to adopt them
In theory, these roles can be accumulated with other roles already existing in the company. There is no law in Kanban saying you need to hire someone new or that these roles have to be dedicated. I would stress, though, these are key accountabilities and there is no excuse for missing on them, or else your Kanban system will suffer. That is to say, if you don’t have individuals accountable for SRM and SDM you will have to spread that accountability throughout the team, which can be cumbersome. Not only it is a lot of observational work, it means team members such as developers can focus less on their development work. Diluting focus does not rhyme with Kanban.
My personal stance is to suggest these roles to be adopted and having individuals who are dedicated, even if you do not hire new people. Have one SRM and one SDM. These folks have very specific perspectives (inside vs outside outlook), SDM needs to be knowledgeable in Kanban, and SRM needs to have business acumen and be proficient in prioritization and stakeholder management.
Now, can you be both roles at once? Can you occupy one of the roles while also being a developer on the team? Technically yes. Should you? I will leave that for you to experiment with and answer.
In Conclusion
Only now I will mention these roles are not mandatory. Yes, you can actually do Kanban without them. And maybe that is how you want to start: from the basics, no specific roles. Here’s 10 seconds of Kanban history: these roles were a natural evolution from early Kanban days. People implementing Kanban felt the need to have such accountabilities clear, especially in more complex product development. That said, it is possible that mature Kanban implementations will outgrow these roles or make them evolve in another direction. Mature. Not cop-out, ad-hoc interpretations of Kanban.
It is also possible that the people occupying these roles will eventually move somewhere up the chain of your production and delivery. Because as your Kanban matures, the need for clarity and organization move from your teams to your structures, from structures to strategies. But that is a whole new discussion. Stay tuned here on the Kanban category of the blog!
