Implementing Waterfall vs Agile

Answers

• Options

  David_Singleton Member Posts: 5,479

  2016-02-14 edited 2016-02-14

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

  David Singleton
  

  0
• Options

  David_Singleton Member Posts: 5,479

  2016-03-14

  So anyone?

  David Singleton
  

  0
• Options

  Miklos_Hollender Member Posts: 1,598

  2016-04-25

  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.

  1