The four steps Dave gives in the video are the observations of someone practiced at distilling heuristics. Experts often speak very few words with very few specifics, for a simple reason. The words they use are weighted with all the meaning of all the things that led to them. For someone with much less experience to discern meaning from them, that person must constantly be examining their own work as they do it, thinking about how it might connect with or diverge from those words.
That's generalization for you, though. It says more, less clearly.
Regarding the Agile Manifesto, he's not said they were wrong, Dave's saying that the main principles of the manifesto are being ignored.
From his blog post:
[quote]
Let’s look again at the four values:
- Individuals and Interactions over Processes and Tools
- Working Software over Comprehensive Documentation
- Customer Collaboration over Contract Negotiation, and
- Responding to Change over Following a Plan
The phrases on the left represent an ideal—given the choice between left and right, those who develop software with agility will favor the left.
Now look at the consultants and vendors who say they’ll get you started with “Agile.” Ask yourself where they are positioned on the left-right axis. My guess is that you’ll find them process and tool heavy, with many suggested work products (consultant-speak for documents to keep managers happy) and considerably more planning than the contents of a whiteboard and some sticky notes.
[/quote]
Dave then goes on to give his heuristic as a replacement for all the consultant BS that emphasizes the very things that are supposed to be less important.
He's really saying pay attention to the requirements, check your progress toward them frequently, and every-so-often, check that they're really still the requirements. As for code structure, technology selection and so on, he as much as came out and said to work with an architect or a master developer to help make those choices correctly.
He was again correct when he said that all of software development practice boiled down to making things that were easier to change over the long run. So when other factors don't rule it out, choose in favor of flexibility.