Motivation for iterative development

This post was originally published here.

I’ve been asked by many teams now, “why iterative development?”  I have a lot of strong, but not well-formed ideas why I like iterative or Agile processes over waterfall processes.  But in Craig Larman’s book
“Agile and Iterative Development: A Manager’s Guide”, he provides a nice list of motivations (with explanations and evidence) for choosing iterative development:

• Iterative development is lower risk; the waterfall is higher risk
  • Early risk mitigation and discovery
    • Accommodates and provokes early change; consistent with new product development
      • Manageable complexity
        • Confidence and satisfaction from early, repeated success
          • Early partial product
            • Relevant progress tracking; better predictability
              • Higher quality; less defects
                • Final product better matches true client desires
                  • Early and regular process improvement

                    • Communication and engagement required

                      • “I’ll know it when I see it” required
                      I’m not a fan of force-fed processes, whether they are Agile or waterfall.  Any kind of process needs buy-in from all stakeholders involved in a product or project, from the business to the developers.  Craig’s book supplied the ammunition I needed to gain buy-in from business and development people who were only used to waterfall processes.

                    For those interested in introducing iterative development to your team, I’d start with Craig’s book, then more detailed books about specific processes you’re interested in.