Monday, August 31, 2009

Managing "shared resources" in Agile way

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.

Conclusion

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:

Jonas Lindström
problem comes when not all sees the benefit and it isnt followed up upon, for it to have any value at all we need to be able to trust the kanban at all time... but that's a completely different issue :)

My response to Jonas
Yeah, if the kanban is not up to date then it is basically lying -> no information maybe better than misinformation

Jani Vesterinen
This is quite good note, not that I've seen this kind of problem.. ;)

One important thing, which in my mind is forgotten nowadays easily with all these different work practices and tools, is people coaching. E.g. with shared resource, you should use most of the time for coaching and teaching the people in organization what does it mean if there ... Read moreare shared resources AND that screwing around has to end AND this is the way we try to solve it - Using Kanban board.

p.s. I would even recommend that these shared resources would need dedicated person (Scrum Master or just some bad ass mfucker) who says no if needed as long as everyone understands and is used to work with this kind of concept.

Jonas Lindström (response to Jani)
well, if the work is pulled from a prioritized task list and the only way you get work done is if its on the list you shouldn't have to use a 'no' person... and if you see that you often have too much work that cannot wait a day or 2 for it to be prioritized you might have other issues you should be looking at :)

btw, what is there really to teach and coach here, seems pretty straight forward?

Jani Vesterinen
Hmm.. Shouldn't this be a topic in Scan-Agile - the power of coaching?

Ari Tanninen
Liked the blog! Good basic stuff, a great example and clearly put. :)

Ari Tanninen (response to Jani and Jonas)
Are you guys talking about coaching or tools or processes or what? A Kanban board is just a tool, and no tool will serve is used wrongly. Nor will it compensate bad management nor coaching. Duh? :)