8 popular software development methodologies—with pros and cons

---

Development methodologies equip teams with the guiding principles and processes they need to build a product. A methodology defines how every element of the product will be delivered—this includes the practices and philosophies that product teams, particularly the development team, need to follow.

Some methodologies get into the technical weeds of how to build a product while others focus on team management practices. These prescriptive methodologies define processes, artifacts, roles and day-to-day practices that, when applied correctly, yield a set of results that can have a great impact on products and product teams. Other methodologies are just general philosophies or a list of principles that can be applied using different tactics.

These development frameworks are meant to provide a smoothly paved road for both developing a software product and guiding product teams to success, with the caveat that not all product teams are the same, and no two products go through the same development journey.

These methodologies are usually nontechnical, with a few exceptions: they’re mostly concerned with processes, people and internal operations, rather than the weeds of software development, design and business.

There’s lean, agile, scrum, kanban, waterfall and everything in between. But which methodology is the best one for your organization and your product team? This guide is here to help you with that.

Ready to start building better roadmaps? Check out our in-depth guide.

Choosing a development framework

Most of these methodologies and frameworks aren’t meant to be standalone, all-in-one prescriptive handbooks with a compendium of granular practices for teams to follow. Teams usually work with a combination of these principles depending on what the organization and the product need.

Before you consider the idea of your organization transitioning to any of these methodologies, make sure to evaluate the following:

Available resources: How much time does your team have to learn how to implement a new methodology without affecting their output negatively? How much money can you invest in the training? Is the effort of implementing a new framework worth it?

Potential constraints and risks: Does your organization have the flexibility to go through changes? Other constraints include type and size of the team, where the product sits along the lifecycle, and the size and the maturity level of the organization.

Tool and methodology compatibility: Evaluate the tools in place at the product level and check if they would work well with your framework of choice. Are you and your team ready to give them up for something that better fits the methodology?

The truth is there is no one-size-fits-all when it comes to development frameworks, and it all depends on a variety of individual factors. In the end, however, the framework you choose should do the following:

1. It should deliver the highest value to the users without making the work more difficult for the product and development teams
2. It should be a good match for the organization’s business, operations and product goals
3. It should eliminate constraints, risks, waste of resources and generally improve the product development process. This means faster time to market, higher user satisfaction and more empowered development teams.

Up next, we break down the pros and cons of each methodology to help you evaluate which framework would suit your organization.

1. Lean development

Lean product teams are focused on one thing: improving the quality of their output. This doesn’t mean more features or a flashier design—it’s about finding a sustainable value that addresses real user problems using regular experimentation. Lean product management is about creating products that your customers will use often.

The idea of failing early to succeed sooner is deeply embedded in the processes that make up a lean approach. Lean practices in product development are mostly focused on these main principles:

1. Creating a deeper understanding of user needs. Make them a priority when it’s time to put together a requirements document

2. Reduce waste. This includes bottlenecks and resource drainage. If your users wouldn’t pay for it, it’s a waste of your time, money and team efforts. Lean identifies the following three types of waste elimination:

• Muda: Removing parts of the process that don’t add any value to the customer (directly and indirectly)
• Mura: Removing variances at the operations level to ensure the quickest, smoothest processes
• Muri: Removing overload. By doing this, teams become less stressed and more productive when they’re working at a comfortable pace

3. Always be validating (ABV): To do this, leverage the first principle. Use user feedback and research to iterate and validate ideas and do it constantly.

4. Increase data visibility and transparency: Create knowledge bases and repositories for teams and stakeholders to see. Share the results of validation experiments so everyone can learn from them.

Ideal for: Companies and organizations that have a good development process in place but would benefit from applying lean values at the internal management process level

Advantages of lean development

• Eliminating waste leads to an optimized product development process, which leads to reduced resource drain. Lean can help organizations save on the most important resources at the business level: time, money and effort
• It can help product teams gain a deeper understanding of what customers seek in a product by focusing on observing their behaviours, empathizing deeply with the problems they’re trying to solve, and turning feedback into actionable experiments
• It speeds up the learning process, which then speeds up the feature delivery process.
• It improves team productivity by addressing wasteful practices
• Easily scalable

Disadvantages of lean development

• It’s highly dependent on the skills, discipline and qualifications of team members. Everyone involved should be equipped with the technical skills they need to succeed at the individual level before they can work as a lean team.
• It requires the perfect amount of documentation. When there’s too much of it, your team is creating waste. When there’s not enough documentation, and no business analyst to ensure that everyone understands them, you’ll face scope creep.
• Even though lean principles are scalable, lean processes pose other risks like a lack of precision, which can lead to losing focus on the objectives that matter the most to the organization

If you lean development sounds like something your organization would benefit from, check out our in-depth guide where we go over the lean processes you can use to apply lean development.

2. Scrum

Scrum is a framework—a defined process with tactical practices—for implementing agile development. Agile development is about achieving rapid software delivery using short experimental feedback loops, iterations, and agile teams that work efficiently together.

Scrum is also influenced by lean concepts like deep user understanding and collaboration, checking the process regularly to optimize it, empowering teams, and favouring frequent small releases over infrequent large releases by working within 2-4 week time boxes of work called sprints.

The official Scrum Guide outlines a set of values that are the core of Scrum:

1. Commitment to achieving high-level and team-level goals
2. Courage to solve every problem, no matter how complex
3. Focus on the work defined during the sprints
4. Openness with stakeholders about the challenges faced by the team

When these values are implemented by everyone, the pillars that make up the Scrum methodology are brought to life. These three pillars are:

1. Transparency. Offering visibility into the product, business and organizational goals and how each team member is responsible for their delivery
2. Inspection. Frequent checks to make sure that current team efforts are aligned with product, business and organizational goals
3. Adaptation. Making changes as soon as possible when those deficiencies in the process are found

At the tactical level, product teams implement these values and build these pillars by working with a set of Scrum events, roles and artifacts.

Ideal for: Smaller sized teams working on products with constant change in requirements and solutions-to-be-delivered, have multiple and frequently used communication channels with clients and end users, and cross-functional teams.

Advantages of Scrum

• Greater customer and user satisfaction. User feedback is quickly turned into testable, functional results
• Flexibility and adaptability. Scrum creates an environment where changes and new requirements can be added easily
• Team morale and satisfaction are higher. Teams that are committed to implementing values and pillars of Scrum feel more connected to the higher-level goals of the organization
• Reducing resource waste. Teams identify the risk of wasting resources like time, money and effort by delivering tangible functional features early on

Disadvantages of Scrum

• Resource estimation. Because of the lack of an end-to-end view of the product development process, it’s hard to accurately estimate how much time, money and effort teams will spend
• Best for small teams and fast-moving projects. Large organizations can still implement Scrum, but they need a rigorous and committed framework that helps them do that like SAFe and LeSS
• No hard deadlines. This makes it difficult to say when an update or release will be released
• Requires a highly knowledgeable team. And if the team isn’t well-versed in how to use Scrum values and practices, the organization has to invest in training initiatives.

Check out our libray of 35+ roadmap templates. Access them for free by signing up for a Roadmunk trial.

3. Kanban

Kanban, like Scrum, is another agile framework that focuses on early continuous releases and creating highly collaborative and efficient product teams. Unlike Scrum, Kanban doesn’t have any predefined roles and events, it’s flexible when it comes to making changes and relies on continuous delivery over time-boxed sprints.

There isn’t a specific set of rules for Kanban, only a few general principles:

1. Visualize the workflow. Specifically, everyone's daily tasks in context with each other’s work
2. Limit work in progress (WIP). Doing this helps eliminate bottlenecks and prevents teams from working on too many things at the same time
3. Improve the workflow. Moving onto the next thing in the backlog as soon as the current task is finished

In terms of artifacts, Kanban uses a board that’s designed to visualize the work that goes into each stage of the product development process. The initiatives are categorized into three columns: To Do, In Progress, Complete.

Ideal for: Smaller product teams that would like a steadier, more consistent output of deliverables without massive team restructuring and training

Advantages of Kanban

• Helps identify time and resource deficiency. This is achieved by providing a visual way of mapping everyone’s tasks (using the kanban board) and optimizing the work in progress (WIP) so teams are always working on prioritized tasks.
• Faster, continuous delivery. This allows product teams to make changes where needed based on ongoing user feedback. This creates an environment where teams feel like they’re working on initiatives that users truly want.
• Teams feel they have more control over the process. Teamwork isn’t dictated by any one particular leader. It’s chosen using a pull-based system where the parameters for prioritizing initiatives are clear and understandable
• Flexibility and versatility. Because kanban doesn’t define timeframes for when work should be delivered, there’s room for priorities and requirements to change based on ongoing user feedback.

Disadvantages of Kanban

• Too many tasks. If there are too many tasks, it can create a bottleneck whereby teams can’t move forward until those tasks are completed
• Kanban board mismanagement. Constant monitoring is required to make sure that it stays up to date and clutter is kept at bay
• Lack of timeframes Kanban relies on optimized workflows to achieve the delivery of any given initiative. This means there’s no way to establish deadlines or a timeline for delivery.
• New tool implementation. In large organizations and enterprise companies with multiple teams and initiatives, implementing Kanban tools can get complicated.

4. Extreme programming (XP)

Extreme programming is one of the most specific development frameworks when it comes to defining and optimizing the workflow of the engineering team. It emerged as a framework for building software in environments that are rapidly changing and where customer involvement is high.

The goals of using XP are to improve the technical side of the product development process using a set of engineering practices. But before we get to what those practices actually are, here are the core values XP relies on:

1. Communication. Improving the channels of communication between users and team members. No need for extensive and rigorous documentation, instead, face to face discussions are essential to exchange learnings.
2. Simplicity. Simple designs and simple coding help everyone save on resources (time, cost, effort) in the long run.
3. Feedback. Establishing highly functional feedback loops among the development team and with users, then acting on that feedback immediately and make changes where needed.
4. Courage. Changing from an established development framework to XP can be scary. XP asks that development teams have the courage to evaluate and question their processes, results and are ready to take on any new changes and responsibilities
5. Respect. Everyone should respect their fellow team members, the user’s needs and expectations. Everyone works together to accept and formulate feedback with the aim of identifying the best solutions.

The way XP helps teams achieve these core values is by defining a set of development processes and practices that cover four pillars:

1. Feedback: Constant and understandable feedback that teams can apply quickly. There are four principles that fall under this category: pair programming, planning game, test-driven development, and a practice called Whole Team
2. Continuous processes: Continuously improving the code, iterative development, and working on small incremental releases that happen in short cycles
3. Shared code understanding: Using the simplest design possible, using standardized formats for style and format of coding, and collective code ownership
4. Optimal work conditions for engineers: Because XP requires a high level of efficiency and product quality, it’s important that developers always work at their best. By limiting work to 40 hours per week, teams can prevent burnout.

The “extreme” part of the name of this methodology comes from how much these practices demand from the engineering team. These steps aren’t just a blueprint for completing deliverables, they’re meant to optimize every aspect of the coding, design and team communication processes.

Ideal for: Smaller teams with high levels of customer participation. Teams must be able to adapt to the changing requirements that come from having highly prioritized communication channels with users.

Advantages of Extreme Programming

• It’s user-centric. XP places a lot of emphasis on the involvement of the users, ensuring that the product is something they’ll use frequently because it addresses real needs
• Short development cycles. These result in early and continuous feedback that engineers can then use immediately and learn lessons from.
• It creates highly collaborative teams. By encouraging close team collaboration and open communication channels with users, it creates high-performing development teams.
• Visibility and accountability. Under XP, developers have clarity around how their individual work contributes to the greater organizational goals and how much progress is being made.

Disadvantages of Extreme Programming

• It’s very technical. Because of the rigorous and prescriptive nature of XP and its heavy focus on the software development side of management, it’s not as accessible as lean development, scrum and kanban.
• There’s no flexibility. XP employs a set of mandatory practices (see the practices listed above) like continuous integration, test-driven development, and pair programming. Teams must adhere to those these practices in order to call their work XP
• Too code-centric. XP doesn’t prioritize design, and its principles and practices are almost entirely about the coding of the software.
• It requires highly functional teams. Due to the lack of hierarchy and management, development teams have to be highly effective, focused and involved.

5. Feature Driven Development (FDD)

This agile methodology is an iterative and incremental development framework that works best with large software teams. It borrows some agile elements from Scrum and Extreme Programming like improved team collaboration, visible progress tracking, optimizing and prioritizing based on user needs, and developing and testing features in short iterations. Some even say FDD is just Scrum/XP on a large scale.

The methodology is broken down into 5 important processes

1. Develop an overall model: Domain and development members build an initial object model under the guidance of someone with the relevant experience
2. Build a features list: Using the information in step 1, take a list of features that can be completed in two-weeks time
3. Plan by feature: At this stage, teams need to build the features in order of priority, dependencies and availability of resources
4. Design by feature: The chosen feature is then designed under the leadership of a chief programmer who also determines the priorities and who needs to be involved
5. Build by feature: Once the design review is completed, the team begins to work on building user interfaces and feature prototypes

Ideal for: Product development teams operating in a large organization and who’d like to go agile using a scalable methodology that delivers clear and measurable outcomes.

Advantages of Feature Driven Development

• Works well with large teams and it’s easily scalable
• It addresses the problems in the development process that specifically affect developers like code ownership and visibility of progress
• The work is more manageable and the deliverables ship earlier thanks to the five-step process
• Working within the manageable two-week iterations reduces unforeseeable risks
• Clearer requirements and visibility of progress

Disadvantages of Feature Driven Development

• It’s not made for small teams with only one developer
• The person leading the development team needs to be a highly-functional and experienced leader
• It’s challenging to learn and implement. Teams need practice, dedication and determination to be able to fully implement all the steps
• It’s too easy to build “nice to have” features rather than features that address real needs

Other popular software development methodologies

6. Rapid Application Development (RAD)

Rapid Application Development (RAD) is a framework that prioritizes rapid prototyping, fast and iterative releases of said prototypes, and quick feedback over long phases of development and testing cycles. The RAD framework also puts heavy emphasis on minimizing time spent planning and maximizing user feedback at the prototype phase.

It’s made up of four defined stages or phases:

• Planning Requirements: at this stage, developers and designers figure out the requirements for the work and get stakeholder approval
• User Design: Using prototype iterations, users work closely with the development team to ensure that what they’re building is meeting their needs
• Rapid Construction: The approved prototypes from phase 2 are then turned into functional, working models. User design and rapid construction are repeated as often as necessary and until the team finds the best solution possible
• Cutover: The implementation phase. Full-scale testing and training take place at this stage.

7. Dynamic System Development Model Methodology (DSDM)

DSDM is an iterative methodology that operates under the agile umbrella. Its main goal is to align all efforts and initiatives with the strategic goals of the organization, and to deliver real benefits that will have the most impact on the business. Like RAD, it employs an iterative, incremental approach to building software. And, like RAD, it uses the same four phases of development: feasibility and business study, functional model and prototype iteration, design and build, and implementation.

The main difference between RAD and DSDM is that DSM uses more formal reporting and requirement reporting. The eight principles of the DSDM methodology are:

1. Focus on the business need
2. Deliver on time
3. Collaborate
4. Never compromise quality
5. Build incrementally from firm foundations
6. Develop iteratively
7. Communicate continuously and clearly
8. Demonstrate control

8. Spiral model

The Spiral framework puts a lot of emphasis on risk awareness and management. Under this framework, development teams work in spirals that are repeated until the final product is ready to be delivered. The product is improved upon over time in small phases, and teams constantly work on updating it according to their new learnings.

The spirals are made up of four distinctive quadrants:

1. Identification and planning of requirements: This includes identifying resource availability (time, effort, costs) and understanding system requirements
2. Risk analysis: Evaluate all the available solutions and they’re potential risks like cost and time slippage. A risk mitigation strategy is then developed
3. Development and testing: Coding, testing and deploying take place
4. Review and plan: At this stage, users are involved in testing the solution and providing feedback. Teams then take that feedback and plan the next spiral

Start building beautiful + collaborative roadmaps with Roadmunk. Signup for a free trial here.