We Don’t Need Another Software Methodology

It seems that every few years, someone comes up with a new development methodology.

Let's take a look:

  1. Agile Software Development Methodology
  2. Crystal Methods Methodology
  3. Dynamic Systems Development Model Methodology
  4. Extreme Programming Methodology
  5. Essential Unified Process Methodology
  6. Feature Driven Development Methodology
  7. Iterative and Incremental Development Methodology
  8. Join Application Development Methodology
  9. Kanban Development Methodology
  10. Lean Development Methodology
  11. Rapid Application Development Methodology
  12. Rational Unified Process Methodology
  13. Scrum Methodology
  14. Spiral Methodology
  15. Software Development Life Cycle Methodology
  16. Waterfall Methodology

Should I continue…?

“LOOKING FOR SOMETHING
WE CAN RELY ON
THERE'S GOTTA BE SOMETHING BETTER OUT THERE” (Tina Turner — We Don’t Need Another Hero — Mad Max Thunderdome)

Do we really need all these? Are they really adding value and/or saying anything new or different? Or are they just repackaging some basic concepts and principles with a prettier new wrapper?


For years I’ve been maintaining the following point about product development and software methodologies:

They are great for the person creating them: they get to sell you all the books, training seminar, certifications, etc. But unless your teams or organization have exactly the same culture, structure, dynamics and other characteristics similar to those present in the methodology author’s company, then you are at best: trying to fit a square peg into a round hole. Given a big enough round hole the square peg will fit in, but fitting in and being a good fit are not the same thing!

Many times, during conversations with other people in the hi-tech industry, the question comes up : What development methodologies do you use?

My answer is always the same: “I’m familiar with most but I don’t subscribe to anyone in particular. Put me in a room with a group of smart people, tell us what we need to accomplish and we’ll figure how to get organized and what processes we need to complete our task.”

Truth be told, there are a lot of good things (and some pretty bad ones) to be learned and even used from some of these methodologies.

After years of working with product and software teams, reading countless books and articles on the subject, I started to form my own approach to product development (notice that I call it an “approach”, not a “methodology”)

Looking at my product development approach you can see some aspects of Agile, Lean and Waterfall in it.

I grabbed some principles from a few methodologies, borrowed some concepts from books and then made up my own ideas to fit the needs of my users, my company, my teams and finally myself.

“Good artists copy, great artists steal.” — Pablo Picasso

I love how much more open and transparent the tech industry has gotten over the last few years. Companies are sharing their corporate values, career ladders, management and growth best practices.

But copying these, do I dare say, methodologies verbatim is risky. Like data without context, practices without understanding their underlying foundation and reasons for being are pretty much meaningless, open to erroneous interpretation and in some cases fatal.

In my post about ignoring the competition, I made the point that unless you know why your competitors are doing what they are doing and what results they are getting it’s too risky to copy their moves.

Similarly, just because a methodology is being effectively used at some company or startup that you admire doesn’t mean that, when applied to your own team, it will yield the same results.

To be perfectly clear: I think it’s absolutely fine to see what best practices and methodologies other people and companies in your industry (or different industries, as long as you see the value) are using and experimenting with them, but I’d keep the following ten points in mind:

  1. Try to understand the context and situation under which they are being utilized
  2. Don’t expect to get the exact same results
  3. Don’t try to fit them exactly as they are into your organization or teams
  4. For that matter, don’t force them in. Communicate them out first, gather feedback and then proceed as needed
  5. Be flexible! Fit the practice/methodology to your team. Not the other way around
  6. Experiment, iterate, A/B test different implementations to see what works best
  7. Don’t be afraid to drop the practice or methodology if it doesn’t add value
  8. Come up with some of your own unique ideas and practices. Then give back into the community by sharing them
  9. Practices and methodologies need to feet the current environment under which they are being implemented and utilized. As few things ever remain the same (specially in hi-tech), be ready to evolve and make modifications (even if it means completely dropping the practice) as time goes by and the needs of your customers, company and teams change
  10. Finally, keep a Zen mind (beginner’s mind), be ok with making mistakes and learning from them. If you do this, you can only stand to make a better process and a better organization, which, at the end of the day should be the driving purpose of these principles and methodologies
Processes is how to get things done. Bureaucracy are processes that get in the way of getting things done!

Please feel free to share some of your product and software development principles, ideas and lessons learned (including mistakes) in the comment section.

“ALL WE WANT IS LIFE BEYOND
THUNDERDOME” (Tina Turner — We Don’t Need Another Hero — Mad Max Thunderdome)
One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.