How to be agile when most people have special jobs?

Question

Hi,

our team worked with SCRUM since a bunch of month (nearly 2 years). When in the first time it was a miracle how good it works, we now run against walls with this strategy.

Our problem is, that we have now (from a team of 10-12 people) a lot of special jobs, e.g. release manager, QA, architect, SQL specialist.

More and more we define tasks which can only be used by those special people and not by the team. E.g.: Deploy Version 1.8 -> Only release manager is allowed to do that.

The problem now is that 50% are overloaded and 50% have nothing to do, because we only plan 70% of our working hours as effective and the mandatory tasks are more and more for the special people.

How to deal with that?

I have a few ideas, but I'm not sure which are the most agile.

1. Get a buffer for mandatory tasks (20% of team time) and plan the rest for the whole team.
2. Get special people out of the SCRUM planning and only plan for the rest of the development team

Answer 1

The most obvious solution to your problem would be to try to make the team more cross-functional. Why is this not an option? If more than one person can perform a task, you would decrease these problems.

Answer 2

The two obvious solutions are:

• Cross train your existing staff such that they can at the very least cope if the specialist is overloaded
• Lay off those that are redundant, and employ those with the skills that you have a shortage of.

Answer 3

Why don't you use Pair-Programming to achive knowledge transfer inside the team. I used to do this for quiet a while and it helped us a lot. We try to have regular pair rotations (At least 2 times a day) to get the knowlegde to as many people as possible. It takes a while to achive that but it helped us. A cruicial part in doing this is, that all people are some kind of egoless. That means that they are willing to share all relevant information and that they are not scared to loose their jobs when someone else can do what they always used to do.

Answer 4

Looks like your team didn't really assimilate the "core" of the agile values. Specialization is a good thing and everyone in a team will inevitably end up being a "specialist" in something, but this doesn't mean that he will be the only one able to execute a task. The core of Scrum is about the self-organization and the Team commitment, which are fundamental to keep it up running and healthy.

The team in your situation - beside being considerably big - it is not maximizing the value of being a team vs. a group of people. Teams should learn to face every challenge as a whole, and not as individuals, and use the brains, experience and point of view of every member to come to solution faster. In this scenario every team member constantly shares and learns with others, maximizing the value of what she can do and making it an asset for the team.

Your team looks pretty much locked in, there is no polyvalence anymore, people are locked on tasks based on their "role" and "skills", which doesn't make it an Agile Team anymore. Bear in mind that no metter what process you use: XP, Scrum, Kanban, if you don't get the value right, it won't last more than the moment needed to make it "business as usual" and people will fall back to individuals working in the same room :-(

So I strongly suggest you to focus again on the intimate values of agile, and try with the Team to reestablish a clear identity, eventually split the 12 people into 2 teams. If the specialist will not have enough to do... well they won't have anyway, it is not because of Scrum. So they can still feel a part of the team and contribute with what they can to the Team success. Organize "brown bag session" and encourage the knowledge transfer, hold the whole team responsible, and let them make decisions, do not force or push anything :-)

Good luck with your agile revolution ;-)