The Agile vs. Waterfall debate is often framed as an argument of extremes. People experienced in a variety of development methodologies understand that a tuned process is more nuanced than the this vs. that blog entries described.
The characteristics of a good development process include:
- value based delivery prioritizing based on what is most valuable to the business
- iterative cycles where a small chunk of development goes all the way through to the testing and acceptance stages and learnings are fed into the backlog
- not spending time developing around generalizations and what-if scenarios that distracts from valued deliverables
- experienced people who all have a stake in the outcome
Upfront planning is essential but the trick is to know what needs to be determined, how much detail needs to be known, and making sure that the plans evolve in response to experience gained from successive iterations. Mistakes will be made. It's better to make them fast and adjust than to follow out a predetermined plan through to absolute failure.
Some architects oppose agile-based methodologies. These tend to be the architects who are more design oriented who distrust an iterative and/or distributed development environment without solid well-thought out blueprints to follow. Again, the issue is how much needs to be determined on the blueprint and what can be deferred to iterative cycles where experience and re-prioritzations dominate.
Large-scale projects are making more use of teams working in parallel to each other. One enterprise architect noted, "five teams iteratively developing five products in parallel." This argues for some blueprint from which to work.
Service-based development methodologies such as the OSIDs provide some relief to this dilemma.