You must have heard the archetypical story of a failing/failed project:
- A team of inexperienced programmers work 24x7
- Bugs are fixed only to introduce new bugs
- Customer is screaming that he could not even do the basic stuff (Saving/Querying) etc.
- Programmers used to having the spec handed down struggle to improvise
- No automated unit tests aggravate the situation
- Architecture document that looked nice on paper was not followed in practice
- Third party components used become bottlenecks not having been tested for fitness in the first place
- Milestone after milestone missed
- The team is not able to come up with a delivery date as nobody agrees as to the quantum of work actually needs to be done
- No technical leadership / or a Cowboy Coder that can take on the technical issues
Now, If you were to be brought in as #10 what would be your first steps?
Update: First of all: Thanks to you all for chipping in. Well... I'm being brought in as #10. I was the original Architect anchoring the solution when we made the proposal to the client. Then, unfortunately, I couldn't take on the delivery responsibilities as I was assigned somewhere else. :)
Let's say it's a webification of an existing desktop application. I'm now being brought in as #10. Running away, sadly, is not an option. I'm sure this can still be reversed by following agile best practices and just wanted to tap the community for ideas.
The larger question perhaps is this: If the development team does not have specs but only the (baselined) code for a running application, the original solution called for looking at the code and extracting business rules on the fly. Now, the inexperienced programmers are reluctant to look at VB 6.0 code and want documents! So how do you fight this if you were to instate Agile processes?