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? :)

9 comments:

Roberto Fasciolo said...

My response to Jani posted in facebook:

with kanban there's not really the need of someone who will say no, it's the board itself that will say that :)
As you know, every slot in a kanban board can have only a limited number of items in it, also the "not started" or "ready to start" one. Therefore, if that slot is empty no more things can be added there (unless of course something is removed from it before, thing that require a bit of coordination between the POs feeding their items to the board, and this might be tricky). Many teams use 7 as limit for the "not started" slot, as 7 is the max amount of item that normally a person can hold in his/her mind.

Mayur said...

I see couple of problems in this approach. The shared meeting is held before the sprint planning meeting to come up with the tasks for the shared resource. I wonder how feasible is to create tasks for the shared resource (database developer) in this meeting. As the team collectively decides what are the tasks needed to complete a user story. It might be possible that they might or might not involve database work. So I wonder how the POs & the resource in isolation can come up with the tasks. The way I have seen it work is that the shared resource attends both team's planning meeting & from there takes it on his kanban board. The other way it could work is having a meeting with the PO after the planning meeting to his what work is there for the shared resource. But I could see some problems with this also.

Marko Taipale said...

@Mayur For this case (db developer) it has been very clear if the new story involves database.

Basically db guy has compared the existing schema and asked questions from the PO to figure out if the old schema is capable of persisting the information that the PO wants to have. On many occasions db is not involved at all (there is no data to be persisted at all, nor to be read at all).

It is true that teams "collectively" decides what are the tasks, but in this occasion there is no other team member who could tell if the database needs to be changed or not due lack of expertise.

Of course there are confusions and sometimes some work is missed in the meeting. In such case the PO of the team goes to db guy and puts his item (found in his sprint planning) to the top of the not started column (and removes the lowest item if WIP is exceeded).

Marko Taipale said...

@Mayur Yet one more thing: If in doubt, the PO will ask DB guy to add "support" task on his kanban for the team. That means that the db guy goes to the team on that date when he "pulls" the item to "In Progress" and then they check the story/ies again as the PO has build more knowledge.

Mayur said...

"... but in this occasion there is no other team member who could tell if the database needs to be changed or not due lack of expertise."

What I am suggesting here is whether the story would involve database work or not depends upon how the team sees they would implement it. And it is up to the database developer to figure out what needs to change, if any. The other important question which arises is of team meeting their commitment. Do you estimate tasks of the shared resource, since in Kanban style of working you generally don't? If not, then how do you balance out db work & rest of work so that work can be completed in one sprint. If yes, I feel it could very wrong. For example, for a functionality team can decide to do most of the work in the code or they can decide to do in database. So the effort could vary a lot. How do you handle such situations?

Marko Taipale said...

@Mayur Just got interesting: you have any reference for people applying kanban and not estimating?

In this case the kanban items are estimated by using t-shirt sizing and then tracking the cycle time (for instance S = 3 days, M = 9 days, L = 21 days - adjust empirically). By doing this the DB guy commits to the cycle time ("Based on my previous track record this will get delivered to you in X days").

Now if the team has come up a plan that invalidates the db task ("we will keep this data in the session, it won't be in database"), then the task is just removed from the db guys kanban and he continues doing the "next" item. Of course it is suboptimal, as is the whole idea of having "shared resource". Sometimes the db task is very vague (support team X) just due to this issue.

Anyway, according to my experience it is not common that some data that has any signifigance to the PO/business is not stored so this would be kind of exceptional.

We were thinking of using the same "shared resource" kanban also for the user interface guys. In that case I would also see that it is pretty clear if the new story has any impact on any "view".

Just a side note: I am not suggesting that the shared resource could not be part of the sprint plannings of each teams that he will get involved. The point of doing the pre-sprint-planning meeting is to avoid "team X being blocked due waiting the db guy".

Some of the teams actually do task breakdowns / preliminary design for upcoming stories way before sprint planning (during current sprint).

DB work is usually just part of the story (as you pointed out) and therefore there is a risk that the story won't get done within the sprint. That's true, but I do not see how that would differ if the "shared" resource would be FULLY part of the team, even with the estimates :o).

Ari Tanninen said...

Having intimate knowledge of the organization Marko's blog refers to, perhaps I can chime in.

Mayur: "So I wonder how the POs & the resource in isolation can come up with the tasks."

Easy. The organization is mostly a healthy one where POs happily co-operate with their teams and shared resources. People are invited on meetings on-demand, and there is no reason to have strict rules for sinister PO-only meetings where tasks are assigned to shared resources who are micro-managed to death.

Also figuring out whether database changes are needed is usually quite simple. "So you have this data here, do you still need it after an hour?"

Shared resources are troublesome in any case, and its good to have a working solution ableit not a perfect one.

Anonymous said...

To get pissed = to get drunk
To get pissed off = To get greatly annoyed

Mike Strong said...

Do you still have the imagess for your post? The embedded images are apparently not accessible anymore. So, we can't see your original illustrations.

Thanks.

MJS