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.

Advertisements

About Andre Simones
I am a founding partner of One80 Services that specializes in agile training, small business and startup guidance, and custom development. My goal is plain and simple. To see others succeed. I want to teach you how stop doing the things that aren't working and give you tools that will empower you to succeed on your own.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: