Agile development is a method, not a goal

Author Amr Elssamadisy talks about how his addiction to Agile development began nine years ago. He also explains why so many efforts to adopt Agile fail.

——————————————————————————————————————- 

I have to confess, I’m addicted to Agile development. My addiction started in 1999 back when I was with ThoughtWorks when eXtreme Programming (XP) saved our team’s collective behinds after a three-year project nearly tanked because all the up-front requirements, design and code components didn’t come together. We had hit the 90% done 90% of the time zone.

Upon adopting XP, we broke many of the rules. XP was designed for small teams (we were 80 people); XP wanted people collocated (the best we could do was stay on the same floor because we were so many); XP called for test-first development (we were an independent bunch of young developers, and many of us refused to do so). So we modified the practices and did what we could to survive. We wrote more of the application in six months than we had done in three years!

I was hooked. I’ve spent my career since then helping others out of software development messes using a myriad of Agile (and non-Agile) practices. This year makes my ninth year as an Agile convert; however, I’m not religious about Agile — not all practices are for all contexts.

The goal of software development teams should never be “Being Agile.” The goal should be to deliver software to help the organization further its goals. That’s why so many Agile adoption efforts fail — because there is/was a belief that once you are Agile everything will be great! The truth is, once you’ve found the development practices — regardless of Agile — to help you meet your organization’s goals in a better way, everything will be great.

Amr Elssamadisy is the author of Agile Adoption Patterns: A Roadmap to Organizational Success. To see a sample chapter, click here.