A Story of a Software Project

Iteration 1: The team picks up the first stories, and makes good progress. The result is showcased to the customers. The mood is encouraging.
Iteration 2: The team churns a bit, trying to get the first stories closed and iron out some technology choices.
Iteration 3: Not enough stories are being closed. The team's velocity is lower than needed. The PM gets worried, and starts calling meetings and raising red flags. The PM declares that the team needs to catch up, and look for ways to increase velocity.
Iteration 4: The team makes good strides, and appears to be back on track. Nerves settle down a bit.
Iteration 5: The team's velocity is soaring. The PM says that given the current velocity, the team will meet its target date. The team starts taking care of technical debt.
Iteration 6: The business functionality is taking shape. The customers start to get a feel of how the system works. They start asking for modifications.
Iteration 7: The customers become more demanding. They notice some gaps between the functionality of the application, and what is needed to run the business. Defects start to creep in.
Iteration 8: The PM talks the business out of some of their demands, and the team devises workarounds for some outstanding issues.
Iteration 9: Faced with approaching deadlines, the PM asks developers to stay late and work over the weekends to finish the remaining tasks. The code quality suffers and technical debt increases.
Iteration 10: The team manages to finish all the remaining tasks. The application is put in production, with minor hiccups. Time to celebrate.


Does this sound familiar?
The team delivered on time. Is there a problem here?
The above pattern causes hardship for the team. The resulting code quality is rarely satisfactory. But we shouldn't be surprised or get overly worked out because of things that are really to be expected:
- Estimates are not always met, because they are estimates.
- The team takes more time in the first iterations because it's the first time this team tackles this problem.
- The customers don't like what they see the first time, because it's the first time they see it.
- The project is taking more time than expected because our expectations are just now being reality checked.
- The developers are being asked to work extra time because the team's management over-promised. However, the developers had no clue initially whether these promises can be met. Everything looked good on paper.

What's the way out of this?
This is not an easy problem. What makes it even more difficult is the fact that the team delivered after all, reducing the incentive for change. There are ways, however, to make things better:
- Educate all parties on all aspects of the project.
- Get the customers involved as early as possible.
- Manage all parties' expectations.
- Communicate regularly, and facilitate information sharing.
- Make it clear that the process of adaptation also includes dates and scope.
- Learn from the past. If you've seen this before, it's likely that you'll see it again unless you change your approach.