The Curse of Traditional Software Development Methodologies

I’ve realized that very few teams follow the waterfall methodology by the book. However, I think that most shops try…really, really hard. Of course we WANT to define every requirement and scenario that could possibly happen. Once that’s complete, THEN we can start building. And, if there is a new scenario, or “missed” requirement (heaven forbid), then the developers can point at the requirement gatherers and say “AH – HA!!! You screwed up, and now you must suffer the consequences!”.

Well, this is just silly, we all know that change happens, but yet we try to fight it every step of the way. That’s what requirements change management is, right? Its to prevent change, i.e. just say NO! To remain competitive in today’s marketplace, we just can’t think like this anymore.

Below is a list of beliefs that we (including myself) really wish was true. If they were true, our jobs would be so easy! Of course, it wouldn’t be as fun 🙂

  • The customer knows exactly what they want.
  • We understand what the customer wants.
  • We understand who the customer is.
  • We can define everything up front.
  • The technical team knows how to build what the customer wants.
  • We can accurately predict how long it will take to develop what the customer wants.
  • There won’t be any problems (or very few).
  • Documentation is a true measure of progress.
  • Nothing should change. If it does, it’s [fill in the blank] fault.
  • Hours worked is infinitely directly proportional to value delivered.

Okay, so none of these things are really true. Since we all like to pretend, we have failed over, and over, and over again. I believe that this failure in traditional projects has caused stereotypes to evolve, including:

  • The technical team is arrogant and lazy.
  • The technical team doesn’t care about the customer.
  • The technical team is lying. It can’t be as hard as they say.
  • The customer doesn’t respect the amount of work necessary to deliver what they want.
  • The customer is stupid.

This failure has also caused some pretty weird behaviors to spring up.

  • A tendency to over-specialize and divide ourselves into silos.
  • The desire to control and direct every move made by every team member.
  • Forgetting that development is creative and innovative and can’t be treated as a commodity (this causes some real bad implementation).
  • A culture of command and control.
  • The desire to create a process for EVERYTHING in an attempt to control.
  • A fear of sharing “too much” information with other silos…I mean other teams. If we share “too much” information, then the other teams may want “change”.
  • A fear of sharing too much information with the customer. Again, for a fear of change.

Please, stop the madness. Let’s stop pretending that traditional development works and start working together.