Which Process Model is Best to Use In Software Product Development?

I recently saw a question on an internet discussion forum that asked “Which Process Model is Best to Use In Software Product Development?”.

Which Process Model is Best to Use In Software Product Development?

I’ve seen that kind of question come up over-and-over so it seemed like a good time to write a blog post to address it.

What’s Wrong With That Question?

There are at least a couple of things inherently wrong with that question to begin with:

    1. It implies that there is one process model that will work “best” in any possible software product development project

      If we just figure out which one is best, we can simply use that model for any software product development project you might imagine.  Wouldn’t that be wonderful if it were true?

      Unfortunately, software product development is not quite that simple.  You have to fit the methodology to the nature of the project  – you can’t just force-fit all software products to some universal development process.   And, that requires some good judgement, knowledge, and skill to know how to pick an appropriate model and adapt it as needed to fit a given project.  It isn’t as simple as having one universal model that works for all projects with a “cookbook style” checklist of what you need to do to make it work.

    2. It also implies that there is some way to easily make a determination that one model is inherently better than another.

      How would you make that judgement?  What would make one model “better” than another?  How can you make that determination objectively?

      There are many different factors that you might consider to determine which model is best but it certainly isn’t an easy determination to make.  It’s also difficult to create a side-by-side comparison of two models on the same project to really compare the performance objectively.

      That hasn’t stopped people from making a judgement that “Agile is better than Waterfall”. I’ve even seen studies that say that “Agile projects are statistically 2X more likely to succeed, and 1/3 less likely to fail than waterfall projects”.

      Reference to Standish Group 2018 Survey

      How do you make that determination?  How was “success” defined?  Was “success” really  defined the same way in both projects?

Which Process Model is Best to Use In Software Product Development?

So, what’s the real answer? Saying that “Agile is better than Waterfall” is like saying “A car is better than a boat”.  They both have advantages and disadvantages depending on the environment you’re in:

  • An Agile model tends to work best in projects where:
    • There is a relatively high level of uncertainty where a flexible and adaptive approach is needed to resolve the uncertainty as the project is in progress
    • Creativity and innovation are needed to maximize the business value of the solution
  • A traditional plan-driven model (what many people loosely call “Waterfall”)  tends to work best where:
    • There is a relatively low level of uncertainty, the solution is well-defined, and some level of planning and control are needed to maximize predictability of costs and schedules
    • The organization is not really  well-prepared to implement an Agile approach and/or the project team is not trained in Agile

The two factors that are making Agile so attractive in today’s environment are:

  1. A higher level of uncertainty in the environment
  2. Competitive pressures require more creativity and innnovation

However, that does not mean that there is no need for a traditional plan-driven model at all.  It would also be a mistake to think that there is a binary and mutually-exclusive choice between “Agile” and “Waterfall” as many people seem to think.

You have to fit the approach to the nature of the project and to the business environment.

Fit the approach to the project

There are many ways to create a hybrid model that blends Agile and traditional plan-driven project management principles and practices in the right proportions to fit a given situation.  And, sometimes it is necessary to do that to fit the model to the nature of the project rather than trying to force-fit a project to some arbitrary, predefined model.