In my previous post I’ve (what, again?) shared some statistics about success and failure rates of software projects in general and ERP projects specifically. It seems that ERP projects fare somewhat worse than generic software projects, which I stated might have a lot to do with how requirements are handled.
Agile is an unpopular word in ERP world. We, the ERP people, love the glory and the thunder of The Waterfall. It has worked for us since forever, after all. Yes, we’ve all seen it fail every so often, but we’ve learned to learn from failure, and we know there is no better approach. Don’t we?
Frankly, I am not completely sure we do.
For starters, what is agile? Most of people who don’t know it think of it as some sort of laissez-faire approach to software development: there aren’t fixed requirements up front, so there is no order, there is anarchy.
If you thought about agile in the same way, take a look at Agile Manifesto. It doesn’t sound all that bad, does it?
You can put many of the agile principles to work on the ERP projects by following these simple steps:
Obviously, most of these don’t have anything to do with a methodology itself, you can do these with Sure Step or without it. Contrary to popular belief (of those who don’t understand agile), agile isn’t about anarchy, or about laissez-faire. It’s a very structured approach which asks for much more discipline than waterfall. With waterfall, you just need to follow the pre-defined steps. With agile, you need to think of each your step before you make it. Agile is to waterfall what lean production is to mass production.
Over this week, I’ll elaborate on all the points above, a topic a day. Please drop by, and share your thoughts. This is most controversial topic that I ever touched, as for many people ERP and agile simply can’t go into the same sentence. Please, feel free to disagree, and do it loud – there is a comments form an inch further below, use it, it’s simple!
Share your thoughts, let’s discuss!