Implementing Waterfall vs Agile

David_Singleton

Many many years back waterfall was the way to go. It's what we did, and it's the way Navision (USA at least) were pushing partners to implement. ... Times changed and the push was for Agile. Agile fits the typical Navision customer from The PC&C days much closer than Waterfall. But both need certain circumstances to work ideally. I guess most partners work to some sort of Hybrid. But more and more I am seeing clients that want to implement using Agile methods, but in reality they are still rigidly locked into Waterfall. The issues that keep popping up are typically

• fixed price requirement
• Limited availability/access to the key users at the client
• limited flexibility in scope of the contract to remove unneeded line items from the Gap/Fit

I like this little Picture I found which does a quite neat comparison.

is it just me? Is it the market I am in, or are customers trending to moving back to fixed price/fixed contract/fixed deliverables?

David_Singleton

PS: Sorry for cross posting, but I am not sure who is reading what these days.

David_Singleton

So anyone?

Miklos_Hollender

Neither. They both sound too official, something perhaps people say they do but they don't actually do unless they work at such big businesses that "covering their butts" with unnecessary documentation is valued higher than cost-effectiveness. At €1000 a day, it is essential for an SMB that every hour bought should be used on the unavoidable tasks like development or key-user training. As a result things like documentation suffer. There is no possibility to make a detailed plan, so it is not Waterfall, because nobody spends €10K on planning alone (not in SMB) and it is not really Agile because it tends to be fixed price.

In general, any methodology is only used if 1) people need to cover their butts i.e. in case of some kind of failure they can sort of save themselves by pointing to having done things by the books 2) they are not smart enough and need some kind of a crutch. In all other cases, methodology is at best used as an inspiration for in-house rules or decisions, but it is mostly just in-house rules and decisions.

Generally from a development viewpoint you could say that a project is a self-contained output of code that has only limited interaction with other aspects of the software system. In this sense, an ERP implementation consists of dozens of such mini-projects, and they are small enough that their cost can be estimated without detailed plans as each are around 1 to 5 days. The whole system basically never gets planned as such.

The dirty (or not so dirty) secret behind all this is that things a far less systematic as they look like. ERP theorists always talk about business processes, but in reality people don't work so much in processes. They just do tasks. And the ERP implementation is large about making each task as quick and easy as possible.

Consider a task like handing item/customer master data. It is not known at the beginning of the implementation how it will be done and nor is it a true agile process. It's simply more like we know it is Joe from Order Processing who does this, and we budget 3 days for this, during those 3 days Joe learns how to do it manually, and will propose a few developments, like let me read them from Excel or let me copy a template item or something of this sort, which will speed up his work and then roughly that's it. It is a task, not a process, the job of the developer is to enable the person who does the task to do it as automatically as possible. And as the automation of one such task is one small sub-project, it is so small that no particular planning is necessary. It's Just Do It.

Certainly this view of ERP is different from the theory taught at the uni. The trick is, we can allow ourselves the luxury to not have to plan out a whole system in detail, to design all the big-picture connections, because Microsoft already did it. So instead of the guys who design cars, we - at least at an implementation phase - are more like the guys who "pimp" cars - replace a steering wheel with a racing one, add wings, add rims, add racing seats etc. things that don't affect the systematic aspects.

Of course in case of large add-ons it is not so. When I was building add-ons I really enjoyed that I had to think in a big picture way. In that case it was largely Agile. We did not need to plan the cost in advance so of course it was.