Specialized resources can't be outsiders...

Disclaimer: To protect the innocent, I'm quoting people from a forum conversation, but I'm not going to mention where or who. If you don't agree with this approach, feel free to drop me a line and complain. It just wouldn't be fair for me to put their names in the limelight without explicit permission.

Problem:

In our company some resources like DB developers (and architects) are shared. This makes sense as one team seldomly utilizes one DB developer 100% through the whole sprint. I know we have to use specializing generalists, but you inevitably end up depending on specialists outside of your team and there is nothing I can do to change that. I have problem with planning their demand and availability in v1 [our project management tool].

I need some way to predict when a task will be started in the sprint, so I can notify my shared resources in advance and make sure they are able to focus on that task.

My proposal:

This is difficult and is one of the anti-patterns in agile. Dependencies (especially on resources) are a major problem and require lots of management. You should read Mike C's recent post on this.

One of the changes of going agile is creating a dedicated team where people swarm as needed on the right things. Unfortunately, as you already know, not every skill area can be dedicated in larger organizations. I used to be a usability guy, and my first experiences with agile were excruciating because I couldn't keep up. Things happened when I wasn't allocated and I was always playing catch-up. Also, the team was always upset I wasn't there when they needed me (which meant they started to ignore my role).

Eventually we moved towards "simulated" dedicated resources. I would be "dedicated" to the team every morning every day. In the afternoon's, I would "consult" to other teams and float. This meant I had one main priority project and the others were in maintenance or ramp down. This allocation was tweaked every sprint (most project sprints were aligned). We did the same thing with our QA folks. They had to sit in the team room for at least 3 hours every morning. The whole team was present in the same room for a window of time each morning. This helped a lot. As a specialized resource, I had to prioritize my backlog across projects and work accordingly (and let people know what I couldn't do).

This created a balance. The team might have a dependency on a missing resource for a few hours, but they always knew the resource would be back tomorrow and they would work around that dependency until then.

If you can't dedicate your resources, then you need to lighten the spread of things they work on. Another good post by Tim Ottinger on that topic.

None of this is a tool issue. By going agile, you could trick yourself and plan it out in MS Project or MS Excel, but the reality is that it wouldn't play out as you planned. Instead, you are dealing with a process and culture issue. You have to get your team together and talk through it. See what they can negotiate would work for them. The shared resource is going to have a different set of needs than the scrum team since they are a member of multiple groups. It's a great retrospective topic and it will take time to work out. I'm guessing you won't end up with the textbook agile solution, but part of being agile is adapting.

Response summarized:

I really am not in control of this problem and can't change it. Thus, I need a way for the tool to help me trigger notification that a specialized resource is needed at a point in the middle of the sprint.

Last words back:

Having super-specialized resources like that will make it very difficult. To manage, schedule, and predict dependencies to that level of detail lends itself more to GANTT charts than backlogs. There's little flow or adaptation when you have to manage to these details and therefore this will be a hindrance to maturing agile and letting your team become self-empowered and self-managed.

I'm not being a purist and saying it's not possible, just that it is a difficulty to be overcome within agile. At a prior company, we overcame the architect role by allowing the team to build whatever they wanted and handling the standardization and schema naming convention issues as a refactor by the end of the sprint. Unfortunately this led to a different set of problems.

Good luck.

A 3rd person weighing in:

... In reading your post, I'm not sure what your role is in relation to the team and scrum master, but it appears that you may be trying to manage resources, instead of shifting the responsibility of self-organization to an empowered team.