Reading: SDLC (Adaptive vs Predictive)

Reading Time: 7-10 minutes

Background: What is an "SDLC" or "Project Life Cycle"?

When we develop a new IT system or update an existing system, it typically requires a number of important yet different activities. These activities can be grouped into what we call phases when they are related and are working towards the same goal. e.g. You can have tasks that are related to the system's Planning, Analysis, Design, Construction (aka Build), Review (aka QA or Testing), Deployment, and Support. When we combine all these phases of a project, we call it the System Development Life Cycle (SDLC) or the Project Life Cycle.

It’s possible you’ve already heard the term "life cycles" in previous classes or in your job experience but it's important to clarify a few terms of may have heard. Agile, for example, is one philosophical approach to the SDLC that has grown more common over recent years. Within the Agile philosophy, there are different specific frameworks (e.g. Scrum, Kanban) that help you implement your project according to the Agile philosophy. Another method you may have heard of is Waterfall, which is an older methodology that has become decreasingly utilized. Our goal in this reading is not to endorse one type but to provide a clear definition of 1) common types of phases and life cycles, 2) their rationale, and 3) the pros/cons of each option so that you can better understand which philosophy fits best when planning and executing your projects.

Phases: More on phases and activities within them

Most SDLCs will contain some aspect of the following phases:

Project Initiation – identify a high-level need and secure approval to initiate a project to develop a solution. Note, in this class, potential clients submit proposals to us prior to the semester.
Planning – this involves high-level planning for 1) scope (to confirm it's a feasible project), 2) resources (building and assigning a team), and 3) schedule (setting a general timeline of when the project should start and end). Note, in this class, this is all done by your Instructors ahead of the semester. Each professor maintains a portfolio of projects by section.
Analysis – here we gather information to identify problems and their root causes in order to devise the solution that will best support the user.
Design – this phase focuses on prototyping and designing the new system components based on the insights and requirements gathered in the Planning and Analysis phases.
Construction (aka Build) – during Construction, we are "realizing" the designs by actually creating the solution. While this may entail writing coding, it could also entail configuring a packaged (i.e. prebuilt) solution like Salesforce. Typically in this phase, testing in some form is included to ensure individual parts work on their own and when assembled to create the combined overall system.
Quality Assurance (aka QA or Testing) – in many SDLCs, Quality Assurance (QA) is typically included with Construction. It's best not to completely decouple Build and Test. They should always be one and Build without Test should not occur. Sometimes people created an additional phase of testing after testing individual units and assembling them. This could include a more thorough end-to-end system test, user testing, security testing, performance testing, load testing, etc…
Deployment – deployment is the act of moving your tested, user-approved software into a final production environment where it can either be released to users or held in staging until you're ready to release the software to the users for their use.
Support (aka Maintenance) – After deploying any software, someone will need to own the activity of identifying and collecting software bugs and/or potential feature updates. These bugs or updates will need to be prioritized. If considered high enough priority, some IT Team would then design, build, test, and deploy these changes. This is less of a "project phase" and more of a post-project phase that will continue in perpetuity after you've deployed and the project is over. You technical entire a Support phase after you've deployed any support to your users.

What are the types of Life Cycles?

When defining the types of life cycles, many will distill it down to two approaches (i.e. Waterfall vs Agile). In reality, it’s a bit more nuanced than just choosing between these two approaches. It’s important to also note that both types of life cycles contain most of phases we’ve noted above. The key difference between Agile and Waterfall is the way each handles changing scope in the project and that scope is broken up in the project delivery. As we noted above, there are many ways to approach an Agile project. What we will do here is break down projects into two overall approaches: Predictive and Adaptive.

A Predictive approach to a project assumes that we can predict all the steps we need to take and therefore devise an approach or plan based on this. The most common predictive method is known as Waterfall. This method is an SDLC approach that assumes the phases can be planned sequentially at the start of the project and then executed with little to no overlap. The Adaptive approach accepts the likelihood that project scope can and will change due to a number of reasons (changes in personnel, business process, priorities, etc…). To deal with this unpredictability it breaks the scope into smaller pieces and deploys more iteratively. The philosophy of Agile (which is directed by the Agile Manifesto Links to an external site.), suggests delivering software every couple of weeks or months but ultimately suggests we shoot for the shorter timescale). Within this vein, concepts like Xtreme programming and Continous Integration would advocate deploying multiple times a day and still be considered "Agile". The Bimodal approach looks at ways to embrace some predictive structure (e.g. quarterly scope release goals) while also trying to live out as much of the Agile principles as possible in our scope delivery.

A bit more on Waterfall: The Waterfall model of SDLC looks something like the figure below. Typically after each phase ends the specifications are locked down and must be signed off before the project can move into the next phase of work. A common issue with this approach is when a scope during a downstream phase (i.e. Build) changes due to a number of reasons, hereby invalidating the work done in previous phases. This causes a slowdown and a need for rework which is likely to push the scheduled go-live of your project back and/or cause budget overages. It’s important to note that waterfall does work well when projects are either shorter in length and the scope is clearly known, for example, you’re upgrading the OS of your web servers or doing a database migration.

MIS 374's approach to projects

In this class, we’ll be embracing a more adaptive approach that we generally refer to as an Iterative Method grounded in the Twelve Principles of Agile. We take an adaptive approach because in most cases, a project's scope definition is never fully static and is more commonly is a moving target that is in flux.

Iterative is a term that describes breaking up the project scope into smaller chunks that are easier to design and build than it would be to complete and deploy all the scope. Agile is actually a type of iterative method. So we will be learning and embracing Agile principles throughout the project and delivering software frequently and in an iterative fashion.

If you google “Agile SDLC”, you’ll likely find something that looks similar to what we have below. All SDLCs will have some initial inception phase to identify the overall project solution and break it up into shorter iterations called "sprints". In our iterative method, we’ll strive to not have one big deployment but many smaller deployments which reduces overall risky since it builds in repeated testing and learning from constant deployment.

Closing Thought: Agile is easier said than done

You may be asking yourself, “Why doesn’t everyone just use Agile or Iterative methods?”. The reason is not that there is a lack of awareness or resources about Agile. Being "Agile" is a lot like practicing healthy eating habits. Just because we know generally how to do it, doesn't mean it's easy to actually do it.

In fact, the reason many companies struggle to embrace an agile, iterative approach to software development is that many IT people have been trained in a predictive manner. It is hard to break this pattern. Also, not only does your IT group need to embrace the “agile mentality” but your business users must too. If your IT team wants to deliver software every two weeks but your business users would just rather do requirement creation sessions once or twice a year, this won't likely work.

Being “agile” means embracing things like frequent (even daily) face-to-face communication as the team, delivering working software often, embracing (even welcoming) change, and constantly adapting as a team to continuously improve throughout the project. To do this, it has to be engrained not only in the culture of your team but your entire organization.