Waterfall vs. Agile – A Series in Finding the Right SDLC for Your Organization

by

Agile-v-Waterfall-hands

If you have been following my blogs lately, you will notice a defined theme…a mantra if you will about me which is that I believe in my heart that no project should fail.  With proper communication, expectation setting, risk management and professional project management every project can be managed to successful completion.

Recently, we started debating the statistics about this though.  Within the IT world,  software development seems to fall into 2 camps:  Waterfall and Agile.  There are of course myriad variations of each PMLC/SDLC, but for simplicity let’s focus on these two opposing methodologies.  

A Waterfall project means that teams follow a defined iterative path whereby the scope is defined, the requirements are gathered, the solution is developed, tested and deployed directly in that order.  From a Pareto perspective, a waterfall project is going to spend about 80% of the time on requirements gathering to make sure the full totality of the solution is specified and understood.  The final product is not delivered to the end user until it is fully tested and “accepted” by the client.  However, due to the nature of waterfall, it could be quite some time until the full product is completely ready.  Herein lies one of they key pitfalls to the waterfall approach: 

  • If you are building a house, waterfall is a perfect methodology.  With some exceptions, the process of constructing a home is an iterative process.  First, the foundation.  Then lay water, gas and electric lines.  So on and so forth.  Each step must proceed the other.  There are no exceptions.  

  • Likewise, if you are building a plane, again, some tasks can be completed in parallel but only after a firm foundation has been put in place.  


In these situations, the process may look like this:  

waterfall

The notion of waterfall is that each process must complete before the next process can initiate.  Hence the term, “waterfall” to describe it.  

In these examples, again, qualifying with the phrase “for the most part” the requirements are not going to change, so the risk of the time it takes to build both a house and plane with complete quality does not present an undo risk. 

For software, however, far too often the time risk is the critical issue.  Though it may take 24 months to get a software implementation right, often a business doesn’t have 24 months to wait.  Hence, the fallacy of waterfall.  In the realm of software development there are few use cases where it works. There are few instances where a business can know the totality of its business requirements.  Moreover, there a few things a business can do to prevent their business requirements from changing once they are laid down. 

I will never forget my last waterfall project.  We spent 12 months preparing and reviewing and development and testing.  Each step of the way returning to the business to make sure we were on the right path.  Each time being told by the business that we were.  Then, on the day of delivery?  Re-organization.  My business sponsor was ushered out of the company and the new person took one look at our deliverable and declared it unfit for her needs.  The solution was dead on arrival. 

Agile development calls for a complete departure from this Waterfall perspective and accepts all these limitations.  It embraces them, I should say.  If one were to look at the Agile manifesto, they would see the following: 

agilemanifesto

Agile, in contrast to Waterfall, does not focus on building the full system all at once.  It focuses on identifying features that would provide defined value to the business and could be developed in a rapid fashion – typically evolving over 1-2 iterations called “sprints.”  A key distinction between waterfall and agile though is the presence of the business.  In Waterfall, the business sponsor is typically engaged at the front and tail-end phases of the project lifecycle.  They are there to help convey the requirements and agree to the design proposed by the technical team and typically go “dark”, if you will, until the deliverables has successfully emerged out of QA testing.  This span of time can be quite large.  Agile, assumes that this span of time without business involvement is just too much of a risk to bear.  Rather, it requires that the business remain directly partnered with the application development team to ensure that key the order in which functionality is provided is a result of their prioritization and their concurrence with prototypes that have been demo’d to the business sponsor successfully after every sprint has been completed.  

 A question we are often asked by our clients is which one is the best?  Which one do we recommend?  The answer is not simple.  Sometimes an organizations’ DNA drives us to the answer; sometime it’s a legal/regulatory thing; sometimes it’s a fit for purpose answer.  In either case, typically we will look at a few areas of your organization to guide us.   

  • Level of Business Involvement in the Application Development Process 
  • Maturity of Business Sponsorship 
  • Maturity of the Technical Delivery organization
  • Maturity of communication between these teams 
  • Maturity of Change Management methodologies 

This series on Waterfall, Agile and Organizational Readiness for Agile will hopefully help you gauge what is right for your organization.  

Stay tuned! 

Best, 

Jonathan P. Goldstein, PMP, MBA
McKinney, Texas

 

READ MORE

Fake Case Study: Jack of all trades vs. Master of One

Fake Case Study: Jack of all trades vs. Master of One

  Listen to any earnings call or executive presentation and you will likely hear the terms “top line” and “bottom line.” These are words used to describe a business’s performance. According to Investopedia, the words are defined as follows: Top line refers to the...

read more
Your Personality Is Showing

Your Personality Is Showing

There I was, minding my own business one evening, digging into my organization's SEO performance (as one does), when I came across something interesting. Search terms related to "MBTI" — or the Myers-Briggs Type Indicator, developed by Katherine Cook Briggs and Isabel...

read more
Lessons From a Change Manager Who Hates Change

Lessons From a Change Manager Who Hates Change

Hello. My name is Monique, and I’m a change manager who hates change.   After years of receiving “consulting therapy” from various mentors, I am now able to say these words out loud and proudly. But for a long time, it felt more like an admission of guilt. I mean, who...

read more
Creativity as a Cure

Creativity as a Cure

The topic of creative solutioning has been front and center these days as we talk more and more about organizational adaptability in the face of dynamic and uncertain times. For example, I recently read about a project that got me thinking about specific priorities...

read more
Thought Ensemble, a Pariveda Company — Why Now?

Thought Ensemble, a Pariveda Company — Why Now?

Big news over here as we close out the year - we have been acquired by Pariveda, a 750-person consulting firm in 12 markets across North America! We are now “Thought Ensemble, a Pariveda Company” and I’ll be serving as the Managing Vice President continuing to lead...

read more
Thought Ensemble Joins Pariveda Solutions!

Thought Ensemble Joins Pariveda Solutions!

Dallas, December 9, 2021 /PRNewswire/ -- Pariveda, a leader specializing in solving complex technology and business problems, announces the acquisition of Thought Ensemble. With the addition of Thought Ensemble, Pariveda now provides holistic business strategy,...

read more
Thoughts on Colorado’s Equal Pay for Equal Work Act

Thoughts on Colorado’s Equal Pay for Equal Work Act

It was about a year ago that we first started hearing about Colorado’s Equal Pay for Equal Work Act (SB19-085) and I knew it was going to be national news. We’d just gotten past the “Rocky Mountain High” jokes, and our lovely state was trying to break new ground...

read more
Disruption Is the New Normal

Disruption Is the New Normal

By nature, disruptors are not popular. “First they ignore you, then they laugh at you, then they fight you, then you win, then they copy you.” We have all heard some version of this quote, and we have all seen it play out in real life. We've seen it with building...

read more
What Would You Say You Do Here?

What Would You Say You Do Here?

“I deal with the … customers so the engineers don't have to! I have people skills!” That famous Office Space quote from Tom Smykowski cracks me up every single time. I know Toms. I’ve been Tom. Change the quote to say, “IT Team” instead of “engineers,” and there’s a...

read more