by Steve Endow
To the Agile Advocates (tm) who will immediately protest "Of course it is!" before reading on, I ask:
Hear me out.
Reference: What is Agile Development?
Reference: Manifesto for Agile Software Development
Book: Agile Project Management for Dummies 3rd Edition
Book: Agile Estimating and Planning
Book: Scrum: The Art of Doing Twice the Work in Half the Time
Disclaimer: I'm not an Agile expert. I'm someone who has tried to learn about Agile (on several occasions) and tried to understand if and how some Agile practices might be used in the projects I work on. I'm asking lots of questions, for which I'm having a difficult time finding answers on my own through part time self-study.
"Agile Development". It sounds cool. It sounds compelling. If you've ever suffered on a long, complex project that was over budget and seemed like it would never end, you'll likely appreciate some of the benefits that Agile claims to offer. You'll read the Principles behind the Agile Manifesto and say, "Yes, please!"
It definitely appeals to me.
But then there is the reality that I personally work in. Over the last 26 years, I have done consulting and development work mostly for "mid-market" customers in the US. Based on my years of experience, admittedly with organizations and teams that didn't have "best practices", I'm having a difficult time trying to map Agile practices to the mid-market ERP projects that I typically encounter.
My inquiry is not about whether Agile is good or bad. I'm trying to understand if Agile is a good fit, or even a viable option, for my customers and my projects.