A Bit More Background
To illustrate, let me tell a bit more about the circumstances of the project mentioned above.
This was to be a replacement system. All the existing functionality had to be preserved in the first release. There was to be innovation to enable easier extensibility, but this was mostly “under the covers”. (Later releases would add new functionality.)There were to be some changes to the user interface, but these were being developed by a completely separate team, using traditional techniques of mock-ups, focus groups etc. The development team was to implement this predetermined user interface with perhaps only minor adjustments.There were many non-negotiable and well documented business rules to be implemented. High product quality was essential.The client wanted to see reduced costs of maintenance and enhancement going forward.The client required a very firm estimate for this pre-specified functionality.
So this still left lots of room for agility. We would be prototyping iteratively all the time and we would have co-located subject matter experts to help us validate and refine important details. And we would be developing with small incremental sub-releases, with continuous integration – we would be applying all of the principles and techniques of Agile that would work within their project realities. And we would ignore those aspects of Agile that would lead to failure.