13 software development methodologies explained

This post was originally published on April 26, 2019, and updated most recently on September 14, 2020.

As difficult as creating and prioritizing a product backlog is, choosing the software development methodology you are going to use to tackle it may be harder. While every methodology will ensure that software meets its requirements, each comes with its own unique set of pros and cons. So to help you choose, we’ve created a definitive guide to the most popular software development methodologies out there today. Let’s dive in!

The waterfall model

Waterfall is the oldest methodology on the block. It substantially simplifies the software engineering process into a linear process diagram, where the completion of the previous task is necessary for the engineer to be able to move onto the next one.

Pros:

• Easy to understand, which makes it perfect for beginners.
• Easy to manage because each phase has its own deliverables and review processes.
• Quick to implement for smaller projects where the requirements are well understood.
• The simple design allows for easy testing and analysis.

Cons:

• It’s only suitable when precise, up-front requirements are available.
• It’s not suitable for maintenance projects, or longer, ongoing ones.
• Inflexible: once you release the application, you can’t go back and modify.
• You can’t produce any working software until the entire cycle is complete.

Prototype methodology

The key’s in the name here: it allows developers to create a prototype so they can demonstrate functionality to clients and make modifications according to their feedback. It’s a little like creating an MPV: you start with a pared-down version before investing time and money into creating the real thing.

Pros:

• With this methodology, you can give clients an early feel for your software and then incorporate their feedback into your final design.
• Because you identify risks and issues earlier on, you also reduce the risk of failure.
• Lots of early communication between the client and the software team strengthens the relationship.

Cons:

• Prototyping can be expensive. On the other hand, prototyping does reduce risk, so you could potentially minimize your budget further down the line.
• Early involvement with the client could be a bad thing: they may interfere and demand changes without fully grasping the project in its entirety.
• Too many modifications can disrupt the dev team’s workflow.

Agile software development methodology

The brainchild of 17 tech pros and their Agile Manifesto, this popular software methodology focuses on adaptive planning, evolutionary development, and continual improvement through flexible response to change. The end goal is early software release with a lower risk of bugs or issues.

Pros:

• It’s an adaptive approach that responds to changing requirements quickly and efficiently.
• Constant feedback drastically minimizes risk later on.
• Continual communication improves transparency between the client and the team.
• It focuses on working with software, which means there is less documentation to worry about.

Cons:

• Scope creep and a lack of focus can become an issue if the brief is unclear.
• A lack of documentation can increase the risk of miscommunication.

Rapid application development (RAD)

The aim here is to provide quicker, higher-quality results than you could achieve with any of the other options. It’s related to the Agile development methodology, insomuch as it emphasizes working software and user feedback in favor of planning. In a nutshell, it’s less talking, more testing.

Pros:

• Helps reduce risk due to early issue identification and client feedback.
• Frequent feedback improves transparency between the developers and the client.
• Having users interact with the prototype results in a better-quality product later on.
• Less planning and documentation helps speed up development.

Cons:

• Reduced features due to timeboxing, which is when features are pushed back to later versions to finish a release in a short amount of time.
• It’s not suitable for small budget projects because modeling costs and automated code generation can be high.
• It’s a relatively new and therefore risky methodology.
• The team needs to be great at working together for this fast-moving process to be a success. Although investing in cloud-based project management software can work wonders when it comes to helping teams collaborate more effectively.

Dynamic systems development model methodology

This methodology has its roots in the RAD model outlined above. It’s an iterative approach that emphasizes continuous improvement and plenty of user involvement. Rather than being focused solely on software development and code, it incorporates project management and project delivery — which is the reason it’s often used for non-techy projects. Its main goal is to provide the product or service on time and within budget.

Pros:

• Users are highly involved in the development process so that they can get a feel for the software early on.
• Improved transparency and incremental development reduce risk.

Cons:

• DSDM is costly to implement because it requires over ten dedicated roles, not to mention frequent testing
• It isn’t suitable for smaller organizations due to the high number of roles needed.

Spiral model

This model focuses on early risk identification. Developers begin by examining potential issues early on when the project is still small-scale. They then assess the risks involved in evolving the project and make plans to either keep the project as it is or address the problems and then move forward onto the next iteration of the ‘spiral.’

Pros:

• The team puts a lot of time and energy into risk analysis, which minimizes the chance of problems later on.
• It’s an effective model for large, critical projects.
• It’s flexible and allows for additional functionality to be added at a later date.

Cons:

• It can be expensive due to high levels of analysis and development.
• The success of the entire project is dependent on successful risk analysis. Failure to properly navigate this phase could jeopardize the whole thing!
• There’s no defined finish, which means the project could potentially go over time and budget if not managed carefully.

Extreme programming methodology

Extreme programming methodology (also known as XP methodology) is used when dev teams need to create software in an unstable environment, such as when customer requirements are rapidly changing. It involves frequent ‘releases’ in short development cycles, and ‘checkpoints,’ during which they might add new customer requirements.

Pros:

• There’s lots of client involvement, which improves transparency and strengthens client-team relationships.
• Frequent checkpoints help developers establish schedules and plans.
• There’s lots of frequent feedback, which helps minimize risk and add improvements

Cons:

• This model requires frequent meetings, which can be expensive for both parties.
• Frequent changes can be disruptive for the developers. It also means it’s tricky to calculate time and cost estimates.
• The cost of changing requirements at a later stage in the project can be high.

Feature-driven development (FDD)

FDD is an iterative development process that blends many industry practices. As the name suggests, the focus is on organizing software development around features. The main goal is to deliver working software to the client as quickly as possible.

Pros:

• Five simple processes (develop model, build feature list, plan, design, and build by feature) provide structure and give a good overview of the project.
• This type of model is built on set standards used within the software development industry, which makes it easy for developers to understand quickly.

Cons:

• Its complexity means it’s not suitable for smaller projects or teams.
• A lot of responsibility is placed on the lead developer, so they need to be highly trained and ready to act as coordinator, designer, and mentor.

Joint application development methodology

This development system was initially used to design computer-based systems before it migrated over to software development. It involves continuous interaction between the users and the dev team to work out the different systems and business requirements while the software is in development. The main aim is to involve the client in the development side of things as much as possible via collaborative workshops called JAD sessions. The focus of these meetings is on the business objective, rather than the technical details.

Pros:

• Lots of communication means increased transparency and collaboration.
• This approach produces large amounts of high-quality information in a short period.
• JAD decreases the time and costs associated with the requirements elicitation process.
• Teams can resolve issues immediately.

Cons:

• Frequent meetings and workshops can be time-consuming, not to mention expensive.
• It also requires lots of planning and scheduling; otherwise, it wastes more time than other methodologies.
• This approach requires strong leaders and experienced developers to ensure workshop focus and productivity.

Lean development methodology

This methodology takes the principles of lean manufacturing (decrease costs, effort, and waste), and applies them to software development to decrease programming effort, budget, and defect rates. It offers developers an excellent conceptual framework, as well as strong values and principles based on established rules. It’s also more flexible than any other type of agile methodology.

Pros:

• Improved efficiency speeds up development and reduces the overall cost of the project.
• Faster development means the dev team can deliver more functionality in a shorter period.
• The dev team has more decision-making power, which empowers the individuals and helps motivation, and therefore progress. The lean approach follows the Agile Principle of “Find good people and let them do their own job.”

Cons:

• Success depends on the team’s discipline, commitment, and technical ability. Additional training may be required to make sure the team is up to scratch.
• This methodology requires a business analyst to ensure documentation is correct and understood by everyone involved.
• Too much developer flexibility can lead to a lack of focus which could, in turn, damage the workflow of the entire project. This is where good project management software can really help matters.

Rational unified process (RUP) methodology

This is an adaptable process framework teams can tailor to their organization. The RUP has determined a project life-cycle consisting of four phases (inception, elaboration, construction, and transition), each with its own milestone and objective.

Pros:

• It helps team members identify and resolve project risks that are associated with the clients’ evolving requirements through careful request management and review.
• It’s scalable, and therefore suitable for any sized team or project.
• Frequent reviews help maintain focus and improve client-team transparency.

Cons:

• The development process is complex and requires a highly skilled team.
• Continual component testing and integration increases complexity and could result in more issues during the testing phase.

Scrum development methodology

This one’s best for fast-changing projects with asap deadlines. It’s designed for teams of three to nine members, who split their work into chunks — i.e., sprints — to complete within a set time (usually two weeks.) Every day, the team reviews its progress in stand-up meetings called daily scrums.

Pros:

• It speeds up the development process and can bring slow projects back on track.
• Decision-making is largely in the hands of the dev team, who work at their own pace. This helps them focus and improves motivation.
• It’s flexible, which allows for frequent updates and changes.
• A daily meeting helps managers measure individual productivity. It also improves collaboration and productivity within the team.

Cons:

• It is good for small, fast-moving projects but not suitable for larger ones.
• This methodology needs an experienced team who are working in close proximity to each other. Trainees and time differences could push the project delivery date back.
• Team members should have broad skills, allowing them to work on tasks outside their area of specialization. Some team members may, therefore, require additional training.
• Dividing product development into short sprints requires plenty of careful planning.

DevOps deployment methodology

DevOps is a newer methodology that is being implemented more and more into teams. The word ‘DevOps’ is a combination of the words ‘development’ and ‘IT operations.’ It works by continually running processes, tests, and releases to decrease the time it takes to develop and be released to market. A large focus of DevOps is on organization and collaboration between all the different departments involved to keep the project running smoothly, efficiently, and to stop any bugs from slipping through the cracks and making it to customers.

Pros:

• You decrease the time from development to market
• Fewer bugs or failures make it through the process, making it an efficient and accurate process
• Much of the process is automated, helping to speed up the process and allowing the team members working on the project to use their work time more purposefully

Cons:

• All departments have to be operating within the same environment to properly integrated the process
• Different industries have different regulations in terms of how much testing you have to do before a product can move to operation
• Not all clients want continuous updates to their systems

Final thoughts

While choosing a methodology isn’t easy, a little research and planning go a long way. Compile your own list of strengths and weaknesses about your team. See which methodologies complement your team’s working style and abilities. Then, narrow your options further by comparing which models would best serve your clients and projects.

Trying out some of these methodologies on a trial basis is easier for some than others, so be sure you’re ready and able to commit, review, and pivot if necessary. Over time, you’ll discover which methodology (or a mixture of them!) works for your team.