But the overall design still has to have a sensible foundation. I think you say that in your message, but it's being lost in the rest. If there are multiple develoeprs invovled, having a clear picture of where you are going and what the goal is will save time and duplication of effort. I like the concept of short, plannable sprints and being able to get better at time estimation. I think those are valuable skills -- but not without the planning and business analysis first. Joe

The only point I disagree with in your e-mail is that no one keeps unmotivated people around... perhaps it's just some of the shops I've been in, but there certainly are "less" motivated people. There are the load-bearers, the superstars who carry 80% of the weight, and then there are folks who carry 2 or 3%... part of it is the superstar who is overdedicated and part of is there are some who just can't be bothered with a sense of urgency, especially in a break-fix scenario (which does happen, regardless of the design methodology). Those people should be (but rarely are) removed from the team to bring in folks with a better fit, but that doesn't always happen. Joe

I think this is dangerous thinking... that only code can be a complete blueprint, especially for anything that goes anywhere near a database. If you don't take the time to architect and have a shared vision of what the underlying infrastructure will be (in our house analogy here, where you'll place the sewer lines, the water pipes, the electrical, the phone lines, etc.) I have seen entirely too many databases "architected" by procedural programmers who know nothing of how a database works, only to come back months or years later to find out that the entire thing needs to be re-designed in order to perform properly. This generally leads to a significant amount of rework time that could be better spent creating new things and features, based on a good foundation. The bottom line to me is that Agile doesn't give enough emphasis on proper advanced designing (although it doesn't directly preclude it either); waterfall places too much emphasis on design and being code complete before build/release. A combined method that allows for a proper design and architecture up front (especially on apps involving a database, and even more especially if that application/database will have significant amounts of data and users -- something large scale) will be much more efficient than trying to recode thousands of things later. Starting from the same page (document) that says "Where we're starting from" leads to a much better finished product. Changing the color of the roof later doesn't matter, as long as it's still a roof. Joe