A common smell that is often detected in teams trying to become more agile is more and more stories/backlog items incomplete at the end of the iteration. There are a couple of different reasons this might happen, but the one I'm interested in today can be detected by the claim "I finished my tasks". The clear implication is that "I got my stuff done, but someone else didn't".

A little additional research usually shows that people are waiting for people with some kind of specialization such as database, QA, UI, or any other skill that isn't widely distributed among the team. As an agile team this is where specialization gets in the way. In a more traditional project the measure of delivery is the task, however, in agile projects the measure of delivery of working features. Specialist typically don't deliver working features, thus the problem.

Note I am not saying that specializations aren't needed, but they do need to be balanced with other needs that help deliver features. Agile teams tend towards people who are "generalizing specialists" rather than generalists or specialists. Scott Ambler has a good discussion in this article as does Mishkin.

So the question becomes "what to do about it?" Well, it depends (said the consultant...).

Are your specialists on your team or part of someone else's?

Are they part of a separate group dedicated to their specialty (functional grouping)? Typical examples of this are dedicated DBAs and separate QA organizations. In general agile teams want to have all the skills necessary to be successful as full time team members. Of course this is not always possible due to organizational constraints or because the specialist is from an outside organization (contractor). Scott Ambler recommends explicitly scheduling tasks that involve external groups. I think this great advise and can clearly assist in overall project transparency. You are making your project plans publicly visible aren't you?

Are the specialists available to your team?

If the specialists are not on your team are they available when you need them? Or is it more like Baskins-Robins where you take a number and they will get to you when they are done with everyone else. Or have the other projects in your organization slipped their dates and now overlapping with yours so that the specialists are double or triple booked?

The first thing to do is to try and get your organization to work with you, rather than against you. How you do this is dependent on your organization and may take longer than your project can stand. However, in the long term this is the best solution.

Assuming the organization can't or won't work with you there are a few options. You can go outside your organization to contractors, consultants, etc. This may carry some political risk with it so you'll have to balance the politics with the ability to get things done.

If you don't have funds to go outside your organization think about training the team so they are more independent from the specialists. This may not be as quick a fix as you need, but it can get you there sooner than you might otherwise. Plus it has the benefit of removing you dependence on the specialists (as well as giving your team new skills).

A more radical idea is to look for ways to eliminate the need for the specialized knowledge altogether. This won't work in all cases, but a little creativity could buy you a little time and possibly a lot. Think about things like database needs. What if you designed you system such that it didn't need a database, or at least was independent of the database. Then you could make use of the DBA when they were available, but it wouldn't impact the progress otherwise on your project.

Is your team pairing with the specialists?

When the specialists are working on your project is someone from your team pairing (or at least working with) that specialist? Or is the specialist isolated from your team (even if just in a separate cube)? Your team needs to start absorbing this specialization as well as decreasing the feedback loop on what the specialist is working on. For example if your performance testing group just takes documents as input and sends back performance data after a week without any intervening interaction you've lost valuable time if there was an early problem that you could have corrected the first day.

Agile principles at work

So which agile principles are at work in correcting this smell?

• Generalizing specialists
• Whole team commitment to completing features
• Do the simplest thing
• Work together
• Reduce feedback loops