Choosing the right development methodology allows you to deliver the most value to your clients. What works for one development group would make another shudder. This is what we call an SDLC vs Agile debate.
Teams that work in an Agile environment worry about the rigidity of waterfall. Likewise, organizations using a waterfall approach wonder what is getting missed with Agile.
Despite the opposition in approach, each development method uses the basic tenants of the SDLC. The difference is the team tweaks each phase to work within their framework.
The seven stages of the software development life cycle:
- Planning
- Requirements Analysis
- Prototyping
- Development
- Testing
- Implementation
- Maintenance
With waterfall, which has a traditional view of the SDLC, each phase has dedicated time and people. A more Agile view of SDLC blurs the lines between many of the stages and doesn’t dedicate time to each one. Both views have their place, and both serve different types of projects well.
Right now you might be asking “well, which one is right for me?”. To figure it out, let’s take a look at traditional SDLC vs Agile SDLC and highlight the four differences that matter most.
1. Phases vs Sprints
Traditional phases
The unit of work for traditional SDLC is the phase. A phase is one of the seven stages we shared earlier — for example, planning or prototyping.
Each phase requires different amounts of time and the involvement of different people. The time needed will depend on the project, but you will never see a balanced amount of time spent on each phase.
You can’t estimate the length of time each phase takes ahead of time. It is impossible to know how long something will take to test until you understand what you are making.
Agile SDLC Sprints
The Agile interpretation of SDLC uses a different unit of work: Sprints. A Sprint is a time box for completing a body of work. It has a consistent duration regardless of the work.
During this unit of work, which often lasts two weeks, your team carries out all the necessary work. Any given Sprint might involve requirements gathering, development, and testing. During a single Sprint, you engage the entire team for its duration.
Key differences include:
- Phases don’t have a fixed start or end date. Sprints have a predictable start and end date.
- Sprints involve the entire team. Phases only need the people required for that phase.
- You know the number of phases you need at the start of the project. You cannot predict how many Sprints you will need.
- The impact of fixed calendar events is knowable with Sprints. For example, Christmas week will impact Sprint #30. You can’t know which phase it will affect using waterfall.
Whether phases or Sprints are going to be better for your team will depend very much on the makeup of your company. When management needs to keep a tight watch on things, phases are easier than Sprints. If consistent output is essential, Sprints work better than phases.
Pro Tip: Code faster with TextExpander
TextExpander makes it easy to save commonly-used code snippets, documentation comments, and more — then insert them anywhere you type with a simple shortcut or inline search.
Click here to learn more.
2. Project tracking
Tracking a project managed with waterfall is relatively straightforward. Any given project will be in one of seven phases at any given time.
Your team might be working on one project in one phase, and another team a separate project in another.
But Agile doesn’t use the term project in the same way. With this approach, a single team is generally working on a specific product or a service, but might have several projects on their plate at the same time.
For example, during any given Sprint, your team might work on several projects at once, all for the same product. You might add some event tracking, while someone else makes database improvements as part of a performance project.
This makes tracking a single product harder since many projects impact it.
Tracking a project is essential; it engages stakeholders when they can see progress. If your product has several owners, an Agile approach will keep more people happy. When there is one owner or only a few stakeholders, a more traditional approach can work well.
3. Flexibility
A traditional view of SDLC isn’t flexible. During the development process, new findings don’t get incorporated into previous steps.
With waterfall, for example, a new feature after the requirements analysis phase has to wait. Once your team delivers the project, a new project can start to incorporate the new feature.
This approach makes change expensive, which isn’t always a bad thing. Knowing each phase as one chance to make a positive impact can focus work on that phase. Less change reduces unknowns in the later stages, making them more predictable.
The more Agile view of SDLC, however, is flexible. With frequent change anticipated, you can introduce a brand new body of work in the next Sprint that bears no relation to the previous Sprint’s work.
This makes change much less expensive, which encourages more collaboration and the testing of more ideas. Because change happens fluidly, it does make it harder to know when to call a project done.
There are positives and negatives to having your project be flexible. A positive aspect of Agile is that you can enforce rigidness by putting ideas into an ice-box. Waterfall doesn’t have a similar option for making things more flexible.
4. Outcomes meeting expectations
Once a project has completed the requirements analysis, your team can set expectations, make claims and inform other departments of your plan. For example, if your project requirements outlined the need for a mobile app, you can let your marketing team know to start planning to market an app.
Matching outcomes to expectations is easy when working within waterfall. Every new phase builds on the old phases, so you can state the old phase as fact.
Later in the process, you can start to make bolder claims. Once testing is complete, there will be no more development so writers can begin documenting how new features work.
Some people appreciate bold claims. Executives in particular need high-level overviews and statements they can take into meetings.
Agile practitioners tend not to make such claims. The nature of Agile development means things are often in a state of flux until the last minute. You can still commit to short-term statements, such as, at the end of the next sprint, the contact form will be in place.
If your project needs to make statements early on that it sticks to, a traditional approach will make sense. But, if you can set expectations to suit the current best thinking on a project, an Agile approach will pay dividends.
This isn’t black or white
In our experience, the question of choosing a traditional SDLC vs Agile approach isn’t black or white. There is nuance, and what works for one team and project might not work for the next.
The four differences we’ve shared aren’t the only differences. They are the ones that make the most significant impact on how you manage your project. Which of the four do you think is the most important for your team? Let us know in the comments.
