Agile, Waterfall, and SDLC

                As an Agile fan, specifically interested in Lean, Six Sigma, Scrum, and DevOps, I find it interesting to observe all of the different methodologies that they are interconnected (Okoro, 2016), built upon the Agile Manifesto, supporting the same principles and customer focus (Beck et al., 2001). Agility is the ability to change and react quickly (Betterworks, 2021).  Agile, in software development, is a set of methodologies and management practices that allow organizations to adjust to the changing customer-driven marketplace, which is volatile, uncertain, complex, and ambiguous (VUCA).  Agile has since been adopted to many other business practices beyond software development such as project management (Denning, 2016).

                Agile is based is described by four values:  “individuals and interactions over processes and tools,” “working software over comprehensive documentation,” “customer collaboration over contract negotiation,” and “responding to change over following a plan” (Beck et al., 2001).  In other words, Agile is meant to deliver product as quickly as possible, responding to customers changes rather than sticking to a firm contract for a thoroughly designed and quoted solution.  Agile is also defined by 12 principles which reiterate the value of customer satisfaction and adapting to customer change hile being as efficient and effective as possible (Beck et al., 2001).

                Systems development life cycle (SDLC) is a model used in software development and project management.  SDLC typically flows through a project identification and selection process, a project initiation and planning stage, systems planning and selection, systems analysis, systems design, and systems implementation and operation (Valcich et al., 2008).  Note that nothing regarding SDLC’s focus stages mention the customer nor adaptation and change.  SDLC basically pushes a project through analysis, planning and requirement-finding, design, development, testing, deployment, and upkeep and maintenance (Gillis, 2019).

                SDLC requires that the team has a clear outlook on the entire job, resources needed, costs, and timelines.  SDLC also requires that project managers have a budget for the project, and clearly defined standards and goals.  SDLC also allows for rework and for developers can redo something (Gillis, 2019).  SDLC suffers because it makes assumptions at the beginning of the project that it cannot change and flex around later.  It is rigid in its processes and inefficient, testing only at the end of the project, leading to Agile usually being less expensive (Gillis, 2019).

                Waterfall, the original systems development life cycle model, was the typical approach to software development before Agile was developed.  Waterfall is the idea of thoroughly planning out a software release and linearly until the project is complete (Towner, 2022).  Typically, waterfall projects are scoped with firm requirements and design and a fixed budget.  Agile projects are usually more incremental and iterative improvement, able to be changed at any time, with a flexible budget (Shultis, 2019).

                SDLC approaches like waterfall create a final product that looks like the original plan because it is rigid in scope, and design.  Agile projects are typically undefined at the beginning.  The goal of an SDLC project is to create a completed product, while the goal of agile is to create a minimum viable product to iterate and improve from.  SDLC is usually well documented, while Agile values outcomes more than documentation.  SDLC is usually slower to produce a working product, while Agile creates working products during the entire development cycle (Shultis, 2019).

                Agile is appropriate for designing a modern cloud-based web application or mobile application that must change to the market during its development.  In this approach, Agile is ideal because it gives the flexibility to add or remove features and reprioritize functional parts of the application on the fly.  SDLC, on the other hand, is more appropriate for mission-critical military and spaceflight applications where meticulous attention to detail and fitting a tight specification is necessary.  SDLC leaves little room for improvisation and change, so it is ideal for projects that are more important to plan and consider all of the requirements.  Agile, on the other hand, leaves room for innovation and evolution of the product.

                An organization applying Agile could experience drawbacks such as problems with scale, since large enterprise scaling with Agile is more complicated.  Organizations with Agile may suffer from drawbacks of lack of documentation and the trial-and-error innovation pains that come from an iterative process (rather than a methodically planned out product).  Organizations using Agile may suffer from lack of clear and cohesive planning and vision and goals.

                An organization with SDLC will suffer from lack of speed to market and long testing (and debugging) cycles at the end of the process before deployment.  SDLC organizations will suffer more expensive development and maintenance.  Most of all, SDLC organizations are ignorant of the customer’s needs and do not change along with a turbulent market (Lucid Content Team, n.d.).  SDLC organizations have a clearer goal and well-defined project, but their project will be slower, more expensive, and less in alignment with customer demands.


Beck, K., Beedle, M., Bennekum, A., Cockburn, A., Cunningham, W., Fowler, M., Grenning, J., Highsmith, J., Hunt, A., Jeffries, R., Kern, J., Marick, B., Martin, R., Mellor, S., Schwaber, K., Sutherland, J. and Thomas, D. (2001). Manifesto for Agile Software Development. Retrieved from

Betterworks. (2021, October 15). What is agility in business? Retrieved from

Denning, S. (2016, August 13). What is Agile? Forbes. Retrieved from

Gillis, A. (2019, June). Systems Development Life Cycle (SDLC). TechTarget. Retrieved from

Lucid Content Team. (n.d.).  The Pros and Cons of Waterfall Methodology. Retrieved from

Okoro, J. (2016, February 10). The Universe of “Agile” Methods [Video]. YouTube. Retrieved from

Shultis, G. (2019, August 29). Agile vs. Waterfall: Pros & Cons, Use Cases, & More. Retrieved from

Towner, J. (2022, June 27). What is the Difference Between Agile and Waterfall? Retrieved from

Valacich, J., George, J., Hoffer, J. (2008). Modern Systems Analysis and Design, 5th Edition. Retrieved from

Published by Art Ocain

I am a DevOps advocate, not because I am a developer (I’m not), but because of the cultural shift it represents and the agility it gains. I am also a fan of the theory of constraints and applying constraint management to all areas of business: sales, finance, planning, billing, and all areas of operations. My speaking: I have done a lot of public speaking in my various roles over the years, including presentations at SBDC (Small Business Development Center) and Central PA Chamber of Commerce events as well as events that I have organized at MePush. My writing: I write a lot. Blog articles on the MePush site, press-releases for upcoming events to media contracts, posts on LinkedIn (, presentations on Slideshare (, posts on the Microsoft Tech Community, articles on Medium (, and posts on Quora ( I am always looking for new places to write, as well. My certifications: ISACA Certified Information Security Manager (CISM), Certified Web Application Security Professional (CWASP), Certified Data Privacy Practitioner (CDPP), Cisco Certified Network Associate (CCNA), VMware Certified Professional (VCP-DCV), Microsoft Certified System Engineer (MCSE), Veeam Certified Engineer (VMCE), Microsoft 365 Security Administrator, Microsoft 365 Enterprise Administrator, Azure Administrator, Azure Security Administrator, Azure Architect, CompTIA Network+, CompTIA Security+, ITIL v4 Foundations, Certified ScrumMaster, Certified Scrum Product Owner, AWS Certified Cloud Practitioner See certification badges on Acclaim here: My experience: I have a lot of experience from developing a great company with great people and culture to spinning up an impressive DevOps practice and designing impressive solutions. I have been a project manager, a President, a COO, a CTO, and an incident response coordinator. From architecting cloud solutions down to the nitty-gritty of replacing hardware, I have done it all. When it comes to technical leadership, I am the go-to for many companies. I have grown businesses and built brands. I have been a coach and a mentor, developing the skills and careers of those in my company. I have formed and managed teams, and developed strong leaders and replaced myself within the company time and again as I evolved. See my experience on LinkedIn here:

Leave a Reply

%d bloggers like this: