My opinions:
When to be agile
- When you’re dealing with constantly changing requirements
- When there’s a lot of uncertainty about how to build the system
- When there’s a lot of variability - priority changes, multiple projects, etc
- When you want the team to “gel” quickly
- When you want the team to take ownership of their projects and tasks
- Pretty much all the time except the following:
When not to be (too) agile:
- When you’re building “infrastructure”
- Protocols/APIs
- Frameworks/Platforms
- When your client expects and is paying for a thorough analysis and extensive documentation
- When you’re building something “mission critical”
I’ll address these in more detail in follow-up posts.
Why not be agile on mission critical projects?
This post implies that agile development somehow produces lower quality products. It doesn’t. Or shouldn’t anwyay.
Why not adopt agile principles to reduce risk and improve visibility (important for mission critical projects I think), and adopt a zero defect mindset if that’s what’s appropriate for the project?
Variable scope != variable quality.
Kelly Waters
http://www.allaboutagile.com
Comment by Kelly Waters — August 21, 2007 @ 4:35 pm
Thanks for the feedback, Kelly.
It was exactly what I was hoping to see.
Tomorrow, I’ll explain why I feel this way, and hopefully spark even more conversation!
Comment by jb — August 21, 2007 @ 4:55 pm
Interesting post - I see forward to reading more. We are occasionally developing APIs/frameworks, and I have no idea why I shouldn’t want to do it in an Agile way…
Comment by Ilja Preuß — August 22, 2007 @ 7:38 am
[…] When to be agile, and when not to be […]
Pingback by Agile Daily - Today’s Top Blog Posts on Agile Development - Powered by SocialRank — October 1, 2007 @ 9:01 am