In a world where everyone has at least heard the words “Agile” or “DevOps”, and businesses rely on IT to simply exist, software development methodologies multiply and produce countless buzzwords and abbreviations: SDLC, RAD, FDD, and so on. What does the person launching a project need to know about them, though? We decided to look at some of these with a pragmatic eye – no wordy manifestos, just the business value and considerations about when to use what.
Understanding the various ways software development lifecycle can be organized is valuable not just for developers, but for all stakeholders in a project: it’s a story of interaction, communication, and successful delivery.
WHAT IS SDLC AND WHY IS IT IMPORTANT?
At the very foundation is the notion of SDLC – software development life cycle. Although it is commonly cited as a “methodology”, in fact, it is much more basic than that. The easiest way to explain SDLC is that it’s the mother of all software development methodologies, the elemental division of work into stages:
- Requirement analysis
- Planning
- Software design (and architecture design)
- Development
- Testing and QA
- Deployment
- Maintenance
The different methodologies, such as waterfall, Agile, and so on are essentially ways of arranging these different processes within a project: one by one, in iterative cycles that are shorter or longer, deciding what goes concurrently with what, and so on.
Why, then, is SDLC so important to consider if it’s so fundamental and intuitive? First of all, without it, no methodology can be truly put to use with all its benefits. Secondly, this fundamental awareness allows to eliminate common pain points. In a survey by StackOverflow, the top challenges for developers were (a) unrealistic expectations – at 34.9%, (b) unspecific requirements – at 33.5%, and (c) inefficient processes – at 30.3%. Viewed by the customer, these translate to costly misunderstandings and remakes, as well as longer deadlines and poorer overall quality. Consideration of SDLC is the way to avoid these and make the processes clear.
Additionally, with the right SDLC practices, the project is less reliant on specific people, and more flexible. In a 2022 report, 73% managers encountered “knowledge silos” at least once a week – eliminating these results in a more coordinated, stable project.
THE OVERVIEW OF SD METHODOLOGIES
Today’s landscape of software development methodologies is one that embraces plurality and diversity. The question “What is the best methodology in software development?” does not really have a single answer. There is no clear “winner” regarded as a silver bullet or panacea by the entire community; from year to year, different approaches may be at the top of the pack, but there’s no longer a one-size-fits-all. This is understandable: as customers from more industries are coming with projects that differ drastically, you cannot just hope one methodology will match all the expectations.
- Software development methods worldwide 2021 | Statista
Below, we’ll start by doing a short recap of the “big ones” like Agile, Waterfall, and more – and then proceed to the more “exotic” and less “buzzwordy” software development methodologies that all have their niches.
The most popular methodologies
Waterfall
This is the classic of software development methodologes, as it simply arranges the SDLC stages one after another – completing a previous stage “unlocks” the following one. Taking an analogy from a classic sci-fi movie, you aspire to build, say, a space station – plan everything – build it – test it by shooting at a planet – and then hope there is no vulnerability in the central reactor that a certain Luke Skywalker could hit, destroying the station so you’ll have to build another one to “fix the bug”.
As is obvious, the big drawback is that changes are extremely costly to implement, so this lack of flexibility narrows the application of this otherwise intuitive methodology.
Agile
Perhaps the most famous of software development methodologies, Agile SDLC originated as a response to the traditional waterfall, when software development went fully commercial and hit the changing landscape with dynamically changing requirements. To minimize risks, Agile development life cycle adopts an iterative-incremental model, that is, the process is split into small parts (sprints) that correspond to user stories/functionalities that the customer wishes to add to the initial MVP (minimum viable product). The MVP is then improved incrementally, with the maximum effort toward customer satisfaction.
Agile is more than just that, though – there is an entire philosophy behind it to emphasize communication and human aspect in the development. The different aspects of Agile (Scrum, Kanban, etc.) are recombined in different other methodologies that fall under the broad definition of “Agile” but differ in their final implementation (see below).
Water-Scrum-Fall
As the name implies, Water-Scrum-Fall (otherwise known as Wagile) is the combination of waterfall with Scrum. While, by now, many developer teams are comfortable working with Agile, the business side of the processes often tends to gravitate towards the more traditional models. The result is a hybrid model that has waterfall-style planning and high-level execution, but works in sprints with retrospectives and other Scrum practices on the inside.
Spiral
A “spiral” methodology is essentially Agile without the people-centric philosophy, taking just the iterative-incremental approach. Starting with the minimum, each loop of the incremental spiral (each iteration) goes through four stages: determining objective – identifying and resolving risk – development and testing – preparing the next iteration.
Lean
Another methodology quite close to (and combined with) Agile, Lean focuses on minimizing what’s called “waste” (muda) in the development process – unnecessary actions, features, interactions, etc. These are identified using the technique of value stream mapping. The methodology is also known for its “decide as late as possible” approach, emphasizing flexibility and ease of changes.
DevOps
This methodology, with its name being a portmanteau of “development” and “operations” aims at connecting these two usually siloed processes. Essentially, DevOps takes the stages of SDLC that come “before” maintenance, and immerses them into maintenance and actual use, so that developers push updates based on feedback in smaller cycles, without waiting times, eliminating the common “it worked in my environment, who knows why it does not work here” problem.
More SD methodologies
Now let’s look at some of the more niche methodologies that many professionals swear by nevertheless – even though they are not as frequently used outside the software development industry.
Rapid Application Development (RAD)
This methodology reflects the need for fast creation of applications with emphasis on user experience. This is done by following four stages: first, very concise requirement collection, then user design, then actual construction, and finally, cutover. At the user design stage, developers work in close collaboration with the users, presenting quickly assembled prototypes that showcase the functionalities (these are created with low-code methods). Once there’s a full picture, the prototype is constructed into a working application ready for cutover.
Extreme Programming (XP)
An Agile framework, XP focuses on how to make developer teams quicker and more efficient by pushing the recognized practices, like code review, to the extreme. For example, code review is continuous (as in pair programming), releases are more frequent for better flexibility, and pragmaticism is encouraged with the YAGNI (“You Aren’t Gonna Need It”) principle, meaning features are not developed until they are explicitly proven necessary – no costly assumptions.
Feature-Driven Development (FDD)
This offshoot of the broad family of Agile methodologies acts feature by feature (akin to user stories in Scrum). After an overall model is built, it’s split into a list of features, each of which can be implemented within a 2-week sprint. The three subsequent stages are to plan by feature (assigning ownership as of classes) – design by feature – and build by feature in small, dynamically staffed teams. These features are then unit-tested and assembled.
Crystal
Originally designed for IBM in the 1990s, Crystal is a framework that emphasizes communication and the human factor. Whereas instilling certain methodologies or workflows by force may not always be a good idea, Crystal works to enhance the natural, organic cooperation models for teams of different sizes. These sizes correspond to different versions of the framework, from Crystal Clear software development (small teams, short projects) through Crystal Yellow, Orange, and so on. Regular delivery, osmotic (uninterrupted, continuous) communication and reflection are at the core.
Big Bang
The Big Bang methodology is unique in that it has no specific methodology or process. Like the bang that started the universe out of nothing, here you just take whatever is there, without real planning, and start doing the thing. It’s a high risk approach, but sometimes it is preferable for small projects and teams.
Dynamic Systems Development Model (DSDM)
This Agile framework was initially designed to bring more control and discipline into the RAD software method (see above); while it’s still iterative and incremental, and still uses prototyping, it emphasizes control. Time and budget are fixed from the start, there is the EDUF (enough design upfront) principle, timeboxing (splitting into smaller tasks to perform at deadlines), and rigorous prioritization (must, should, could, won’t have).
HOW TO CHOOSE THE METHODOLOGY?
When discussing a software development methodology, the second question after “What is…?” is typically “when to use…?” – it is now universally recognized that no single method or framework is applicable in 100% of cases, so for the sake of better management and outcomes, it is better to choose the methodology that matches the project.
The factors that determine when to use some new Agile methodology, when to use DevOps, when to use RAD, etc. are multiple:
- Size and duration of project. For example, shorter projects, where the requirements are not likely to change many times, are implemented well enough with waterfall or lean approaches, but longer ones may require more agile practices.
- Changing requirements / risk. Naturally, this makes the project team gravitate more towards Agile in some of its incarnations, such as Extreme Programming.
- Desired frequency of deliveries. On the one hand, if the deliveries need to happen often, Agile or DevOps methodologies are more recommended.
- The client’s readiness to collaborate. Some of the methodologies on the Agile part of the spectrum presuppose very close collaboration with the customer and/or end users. For example, Rapid (RAD) relies on someone to review the prototypes. On the other hand, some projects naturally don’t require that or deem that necessary.
- The industry of the project. Some high-regulated industries, for example, may completely nullify the benefits of DevOps software development, while some industries can really encourage the use of XP or even “Big Bang” type methodologies.
- The holism / modularity of the systems involved. Some projects have the potential to split the system into modularized, “quarantined” units that are developed and tested each one by itself, whereas some projects can’t allow for this.
In short, it takes a good look into the specifics of the project at hand to determine which of the methodologies would be used to the best result. Many experienced managers no longer claim their teams work “strictly in Agile way” or “using FFD/RAD/XP methodology” unless they work with very specific types of projects. In most cases, however, the methodology is dictated by the situation itself, and everyone uses a sort of hybrid between the best practices from several methodologies.
HOW TO BENEFIT FROM SOFTWARE DEVELOPMENT METHODOLOGIES
The large number of different methodologies out there is largely due to the fact they are essentially recombinations of the same principles and best practices, “packed” together into workflows based on what is prioritized. To be able to extract benefit from them, one needs to realize that each one has its advantages and drawbacks – and then carefully apply these to the situation at hand.
In practice, this also involves understanding how much effort will be necessary to make the team work with a certain methodology. After all, e.g. Scrum needs an entire team member solely to ensure the principles of Scrum are observed, and there are many variations in-between Waterfall and Agile partly because Agile methodology implementation needs training. Fetishizing a methodology to the extent that the business actually pays (in money or opportunities) to implement can be risky if you are not sure the methodology is going to pay off.
A largely safe way to benefit from the different methodologies in place is to collaborate with outstaff teams, especially those working with multiple projects within 3-5 industry niches. Such providers, teams, and individual developers are reasonably familiar with different methodologies simply because they have worked with widely different projects. An individual team member may have strong opinions about this or that framework or workflow, but they are more than likely to be familiar with it and work effectively under it.
This, by the way, is one of the often overlooked benefits of agile software development outsourcing: once you have a service provider that’s used to working with your industry, you can use their expertise to settle on the methodology preferences for this or that type of the project. You can learn more about outstaffing services at MWDN here.