I hate the term "shared resources", but sometimes my customers tend to have them and they are wondering how that fits into agile. Mumbling about cross-functionality and "whole team" just usually irritates them; they want to get their stuff done, even it is suboptimal.
I demonstrate what we did in one of my customers about year ago to solve this issue before they got cross-functional.
Two scrum teams, one shared resource (Database developer).
In the beginning they had one database developer for a department having multiple scrum teams. It was really common that since the database developer commited to Team 1 sprint, he could not serve the others (he was PART of the team 1). Product Owners (PO) got pissed off about not getting their stuff done and always waiting for the "shared resource" to be assigned to help their team.
We figured that we need get the database developer to help the team 2 in middle of the sprint in case the team 1 database related stories would take a day or two to complete. So we moved the guy in between.
Of course we had to ask ourselves how would he know which team to help at any given time, how to prioritize, how to get visibility what he is up to and so on. It was obvious that the "shared resource" would need some kind of "to do" list. I had previously seen kanban used to manage work done in technical operations, so I thought maybe we could use kanban here aswell.
Product owners would still have their backlogs so it would be natural for them to feed the kanban with those.
How to get that done in synchronized manner with everything else? We decided to setup a shared resources meeting before the sprint planning meeting so that the PO1 and PO2 could take the shared resource into consideration while sorting out their individual backlogs. The meeting takes place between POs and the shared resource(s). In following picture the meeting is visualized by dashed circle.
So how does the kanban look alike? Here is a simple example kanban for database developer:
The red counters are Work-In-Process limits. As there was one database developer, we decided to have limit of one item for the "In Progress" column. As you see, each item on the kanban board describes also which team is involved. As this PHYSICAL board is placed on the corridor of the development department, anybody can tell where the database developer is working (he sits together with the team that is visible in "In Progress" column.
It turned out that the solution really worked. POs were really happy to have visibility to their shared resources and they also were amazed how big of a constraint (being visual now) it was for their organization. Another improvement was the increased motivation for the "shared resource" - he got visibility for his future assingments by having them on the kanban board and also he ws in control of his tasks as they were not "hidden" as part of something else.
I would not recommend to have shared resources even with help of what is presented here. Cross-functional teams are more optimal, but if you are on your way to get there, maybe you found this useful.
Please do not hesitate to give me feedback by commenting or sending me an email to marko dot taipale (at) huitale dot com. I am also interested to hear if yu have found some other ways to manage your shared resources :o)
UPDATE - some comments
I got some feedback from various people so here are their comments:
Hmm.. Shouldn't this be a topic in Scan-Agile - the power of coaching?