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

Shifting Perspectives: 3 Learnings From a 3-Day Training

Shifting Perspectives: 3 Learnings From a 3-Day Training

About a week ago, I completed the second live (virtual) training in the process of becoming a Certified Professional Coach through iPEC. Once again, my mind was blown! It reinforced for me that virtual workshops can, and do, work, and, in a lot of ways, I prefer them...

read more
Finding My Work-Life Balance

Finding My Work-Life Balance

In my previous post, I told the story of how I got back into consulting after becoming a mom. All of the diverse experiences I had during that journey have helped me to find my work-life balance by… Defining Boundaries “Go home,” my first boss said 12 years back —...

read more
How I Got Back to Work After Being a Full-Time Mom

How I Got Back to Work After Being a Full-Time Mom

I Landed My Dream Job Throwback to 2014, I had completed my MBA, landed my dream job as a consultant, and was hoping that my new consulting career would exponentially ramp up my career growth for the next 5 years. This would position me to take on critical decision...

read more
Self-Awareness is Key to Belonging

Self-Awareness is Key to Belonging

In August of this year, as part of our annual company meeting, our team at Thought Ensemble participated in the foundational session of Diversity, Equity, and Inclusion (DEI) training led by Dr. Nika White, IOM, CDE (she/her/hers). One of the most meaningful moments...

read more
Finding Your Organization’s Magic Pixie Dust

Finding Your Organization’s Magic Pixie Dust

It is often said that organizational culture is like a fog — it is all around us; it impacts our ability to see, to move quickly, and to deliver; but we cannot quite put our finger on it. Indeed, some organizations see their culture as a byproduct of operations,...

read more
We’ve Refreshed Our Brand!

We’ve Refreshed Our Brand!

Why have we refreshed our brand, you ask? Well, as we have grown and matured as an organization, we felt that our previous brand elements no longer represented us as well as they could. You see, we founded Thought Ensemble back in 2008 to help companies better compete...

read more
Thought Ensemble’s Purpose — Inspired in 2020

Thought Ensemble’s Purpose — Inspired in 2020

I recently wrote about how company purpose is being tested and inspired by all the events of 2020. This topic is very real for us at Thought Ensemble. We’ve been thinking a lot about what really matters as we’ve navigated the...

read more
How 2020 Is Testing and Inspiring Corporate Purpose

How 2020 Is Testing and Inspiring Corporate Purpose

In August 2019, the Business Roundtable rewrote their statement of corporate purpose. I followed this with significant interest being that I have never forgotten the debates about corporate purpose in business school almost two decades ago. We were taught that the...

read more
Why Purpose-Driven Organizations May Struggle With Change

Why Purpose-Driven Organizations May Struggle With Change

I love working with companies who really want to make a difference, beyond just making money for their shareholders. I mean, making money is fun and all, but it is even more rewarding to join in on a just cause. Plus, as this HBR article explains, companies who have...

read more