Agile question

Question

We have to let go 3 of our software test contractors due to budget constraints, in the middle of a project that had adopted agile development practices. The management attitude is to throw equal number of full time bodies to compensate for this. Does agile development allow for this disruption? I would like to know if any one has been in a similar situation, and how was it handled?

Answer 1

What type of agile do you do?

If we speak in general I would say that they are not any problem. You just need to change your team task to continue to do testing. Do not stop testing! You simply need to take time on testing that would have been initially planned to develop.

Answer 2

Well, any methodology has to allow for the disruption of team loss or its simply unrealistic. Whether they are laid off, resign or simply die, people will leave. New people will have no track record and this will effect your team's velocity, at least in the beginning. Analyse your project -- keep doing what has proven itself successful in the past. Assume (this is what I've done) they will be 1/2 productive for the first month and slide them up according to the complexity of the project they are working on.

Answer 3

We use Scrum Methodology, and this certainly does allow for this. Infact, it is built around exactly this kind of situation. Because the business decides which parts of the backlog you want are to work on, depending on the amount of resources you have available for that sprint, you can change the available resources on a sprint by sprint basis and this is still viable, although maybe not advised

Answer 4

I was on a project that was going pretty well with 9 developers. For various reasons we had to take 5 people off and add 3 new people in the span of two months. We were following most XP practices (can't say we were 100% XP, but we were close). Our velocity dropped for a time but did not go to zero.

• The lack of code ownership meant the people leaving had no special knowledge that wasn't relatively well shared.
• Unit tests did a good job of documenting the code in an executable way so that the new people could see what was going on and make changes in a safer manner.
• Pair programming helped us get people up to speed quickly.
• Short iterations allowed us to show that while velocity dipped it did start climbing back up quickly and gave business users confidence that we were still producing value.
• Iteration planning meetings helped the new people understand the requirements and stay focused on the iteration goals instead of just running all over the code base.

It wasn't an ideal situation. Agile helped make it better, but it still hurt. It still took a great deal of effort by all involved. If they hadn't all been really good developers and team players it wouldn't have worked. I can only speculate, but the team was good enough that we probably would have pulled it off even without Agile, but I think it went smoother because of Agile. Nothing would have worked if it had been a bunch of chumps.