December 29, 2005 | John Rusk | 2 Comments In my on-going quest to answer the question “What is agile development?”, here is a point-by-point comparison with traditional development.I’ll label the traditional approach with “T”, and the agile approach with “A”… Iterative vs Waterfall T: Serial (“waterfall”) development is best (or at least normal/acceptable) A: Always use iterative development Workflow T: Design, Build and Test follow each other, in that order A: Design, Build and Test influence each other, so they should be concurrent and iterative Requirements Quality To ensure requirements are well-defined and well-understood: T: document them thoroughly; users see the system when finished A: document them concisely; users see the system early and often Knowledge Transfer To ensure everyone understands the system: T: Place importance on written documentation A: Place importance on frequent verbal communication; regular working releases; and clear, readable source code Team Composition T: Team members should be specialists (BA, Designer, Developer, Tester etc) A: Team members should be generalists (each with their own particular strengths) Team Size A successful process is one that: T: Organises a large team A: Gets the same output from a small team Planning T: Make a Gantt Chart at the start; maintain it during the project A: Make a Task/Feature List at the start; maintain it during the project Monitoring Measure progress: T: against the Plan A: against the Task/Feature List (tracking which ones are completed). But don’t just monitor your progress; also monitor the quality of that progress by testing and releasing regularly. Managing Change It’s hard to change software that’s already written, so: T: Control or minimise change A: Make change easier Predicting Completion Predict final completion date and cost using: T: the updated Gantt Chart A: the team’s progress to date Process Definition To help people successfully follow it, the development process should be: T: thoroughly documented A: concise and memorable Process Improvement Process improvement is best driven by: T: metrics A: the people involved Philosophy T: Software development is a construction process, so making detailed plans is advisable. A: Software development is a creative process, so making detailed plans is unrealistic. Instead, agile processes make less-detailed plans and manage risk through iteration, continuous quality control, and feedback. Success is T: Meeting the initial predictions of cost and schedule A: Delivering value for money