Can Agile Development offset the loss of three testers in the middle of a project?
We have to let go of our 3 software testing contractors due to budget constraints, in the middle of a project that has adopted agile development methods. Management's attitude is to send an equal number of full-fledged bodies to compensate for this. Does rapid development contribute to this destruction? I would like to know if anyone was in a similar situation and how was it handled?
I was on a project that matched well with 9 developers. For various reasons, we had to shoot 5 people and add three new people within two months. We followed most of the XP practices (we can't say we were 100% XP, but we were close). Our speed decreased for a while, but did not go to zero.
- The lack of ownership of the code meant that the people leaving did not have specialized knowledge that was not relatively well spread.
- Unit tests have done a good job of documenting the code in an executable way so that new people can see what's going on and make changes in a safer way.
- Pair programming helped us get people to work quickly.
- Brief iterations allowed us to show that while speed was approaching, it quickly started to climb rapidly and gave business users confidence that we were still generating value.
- The iteration planning meetings helped new people understand the requirements and focus on the goals of the iteration instead of just working across the entire codebase.
This was not an ideal situation. Agile helped make it better, but it still hurts. All this took a lot of effort. If they weren't really good developers and team players, it wouldn't have worked. I can only guess, but the team was good enough that we could have pulled it out even without Agile, but I think it got smoother due to Agile. Nothing would have worked if it were a bunch of chunks.
source to share
Well, any methodology should be able to frustrate the loss of a team or its just unrealistic. Whether they get fired, resign, or just die, people will leave. New people will not have a track record and this will affect the speed of your team, at least in the beginning. Analyze your project - keep doing what has been successful in the past. Suppose (this is what I did) they will be produced within the first month and will promote them according to the complexity of the project they are working on.
source to share
We use Scrum Methodology and it certainly allows it. Infact, it is built in just such a situation. Since the business decides which parts of the backlog you want to work on based on the amount of resources available for that sprint, you can change the available resources on a sprint-based sprint and this is still viable, although perhaps recommended
source to share