How to manage agile development when the team is not stable? [closed]

Question

I have been using agile approaches (XP and Scrum) for my projects for several years with great results. But in all cases, all members of the dev team were committed 100% to the project.

Now I am faced with doing this when the team is not stable. For instance, one iteration there may be four people working, the next maybe only two or three.

I realize this makes it hard (or impossible) to estimate using the normal velocity approach since it will fluctuate to much and not be stable. What follows is that one cannot really expect to be able to release at the end of each iteration.

Maybe another approach is needed here. Just grab stuff from the backlog and just muddle through and release whenever it is possible. I really don't like that though...

Any thoughts?

Answer 1

From the question I assume you have some developers (probably, 2) 100% commited to the project and some (another 2-3) only participate at a times.

One thing you can do is set different process for core developers who are 100% commited and everyone else. Use you normal agile process for core people and release their work at normal iteration cycle. For non-core people, do little planning and assume their (and your) estimates would be way of at a times. Ideally their changes should be isolated and merged into stable branch of code by core members, but not every project's architecture and team roles allow this.

The point is to separate and isolate source of chaos and leave the heart of a project and team unaffected.

Answer 2

Maybe instead of agile approaches, you can slow things down with other iterative and incremental approaches. Instead of having iterations measured in weeks, having longer iterations (perhaps measured in months) would be better if you keep adding and dropping people from the team.

This doesn't mean that you still can't use some Agile techniques. I would still maintain your Backlogs and burn down charts, with the realization that instead of having a release every 2 weeks, you'll release every 6 weeks (~2 months). If you have new developers joining more experienced developers, use pair programming, assign the new developers to bug fixes, or assign the new developers to maintaining unit tests to help them learn the code base.

Answer 3

Velocity is only an estimation.

Naively, if you have a given velocity v with a team of 4 developers, then schedule your iteration with a velocity of (v/4)*number_of_developers

You can fudge this value if the members you are losing are particularly stronger or weaker than the average.

This is basically what PivotalTracker does with its team strength metric.