Scrum, Kanban, Lean, XP, or Waterfall: How to Choose Your Optimal Development Methodology?

When selecting the right development methodology, we should consider the following. People and interactions or processes and tools? Working product or documentation? Willingness to change or adhere to the original plan? In this article, you’ll find the answers.

The project requires numerous decisions throughout development. One of them is choosing the proper management methodology. In development methodologies, there is often the battle of titans: Scrum vs. Kanban vs. Lean XP vs. Waterfall. Each of them aims to ease the completion of the project, but when talking about their differences, some features make them unique. Today, we’ll journey through the landscapes of these methodologies by revealing their strengths and pitfalls. Our research is to help you select the ideal fit for your unique projects and teams. Picture this: Scrum moves forward thanks to structured sprints, while Kanban calmly flows with its focus on regular improvements. Lean, emphasizing optimizing efficiency and minimizing software engineering waste, stands firm with XP, championing code quality and secure development for software engineers.

Each project is unique regarding time, costs, team, stakeholders, deliverables, and technologies. The software development methodology should be chosen in accordance with these specific features but not because some framework is popular.

I want to help you decide which software development methodology to choose. Together with Keenethics Project Managers, I have compiled this ultimate project management guide. Here, you’ll find out how to choose the best development methodology that suits your needs, resources, and interests.

So, here is the plan of what I am going to talk about:

1. Waterfall vs. Agile
2. Scrum, Kanban, Lean, and XP as top software development methodologies based on Agile
3. Agile vs. Scrum
4. Kanban vs. Scrum
5. Kanban vs. Agile
6. Final remarks

For each software development methodology that I consider, I will outline:

1. Brief history overview
2. Methodology basics
3. Pros and cons
4. Typical usage
5. Example 

Waterfall vs. Agile 

Waterfall and Agile are the two dominant but very different approaches to project management. Waterfall is an old-fashioned, traditional approach, and Agile is a more modern, flexible, and popular approach.

The first decision you have to make when choosing the project management methodology is whether you want to go with the old-but-gold rigid approach or the modern and flexible one. Let’s look at both more deeply before you answer this question for yourself. 

Waterfall

Brief history overview

Waterfall is a linear software development approach, the first mention of which dates back to 1956 when Herbert D. Benington gave a speech at the Symposium on Advanced Programming Methods for Digital Computers. However, Bennington didn’t use the name “Waterfall,” nor did Winston W. Royce — the computer scientist who allegedly formalized the Waterfall approach for the first time in his 1970 article.

Waterfall model. Retrieved from http://www-scf.usc.edu/~csci201/lectures/Lecture11/royce1970.pdf 

This is what the very first version of Waterfall looks like, according to Winston W. Royce. At least, this is how most people interpreted his article.

Software development methodology basics 

In modern-day Waterfall, the software development process consists of 6 major stages:

1. Collecting system requirements
2. Analyzing requirements and creating models and schemas
3. Designing software architecture
4. Coding the software
5. Testing and debugging software 
6. Managing operations: installation, migration, maintenance, and support

Importantly, the previous stage must be fully completed for a new stage to start. Otherwise, there is no chance to return to any of the finished levels or run any two simultaneously. The exception to this rule is the Sashimi model — one of the approaches to Waterfall allowing for stages to overlap.

Sashimi model. Retrieved from International Journal of Industrial Engineering and Management (IJIEM), Vol.1 No 4, 2010, pp. 163 – 172

Pros and cons

In Waterfall, planning and designing processes are more straightforward since the customer and the development team agree on the project deliverables from the beginning of the product development. The customer can stay away from development — there is no need for them to be constantly involved. The overall scope of work and all the expenses are known in advance. Respectively, the team can easily measure the progress and accurately predict project costs. So, the Fixed Price model suits Waterfall best.

 At the same time, it’s difficult, if not impossible, to collect and analyze all the project objectives and requirements and formulate them so that they won’t be changed later throughout the project development process. However explicit the project requirements are, the final product may not be what customers expect unless they’re involved at each stage of the project development, which isn’t the case with Waterfall.

Typical usage

If you have a small project with clear deliverables that aren’t likely to change, you’re limited in time, and your team consists of well-experienced developers resolved to work hard, Waterfall will fully meet your needs. However, if you aren’t sure about project requirements, redesign, redevelopment, and retesting will make your project costs rocket.

Example

The Education System Platform project we have built used Waterfall. Even though it was a huge and complex system, we managed to plan the work and write clear, well-detailed requirements.

Who is the Waterfall best suited for?

Waterfall isn’t well suited for projects with changing goals and deadlines. It’s not flexible enough, so it can be challenging to change something after completing one of the stages. This model isn’t also suitable for projects related to research, experimentation, and innovation since they often require iterations and improvements. Contrary, Waterfall is a practical approach for projects with clear goals and well-defined requirements that are unlikely to change throughout development. It’s an ideal fit for products with clarity in all procedures established beforehand for a structured, step-by-step progression through various phases.

Agile

Brief history overview

The history of Agile isn’t the usual one. It didn’t emerge as a philosophy from which different software development methodologies evolved. By contrast, a few like-minded PM methodologies appeared and united to advance the philosophy of Agile.

The first attempts to create a philosophy of lightweight and flexible software development date back to the 1960s, shortly after Waterfall emerged. Then, in 1995, Scrum was introduced. Extreme Programming (XP) and feature-driven development (FDD) appeared in 1996 and 1997, respectively. In 2001, the creators of Scrum, XP, FDD, RAD (rapid app development), UP (unified process), and DSDM (dynamic systems development method) came together and issued the Agile Manifesto.

The Agile Manifesto. Retrieved from agilemanifesto.org

In 2011, the Agile Alliance created the Guide to Agile Practices, known as the Agile Glossary and Terminology. Nowadays, it’s the ultimate source of knowledge about Agile philosophy.

Software development methodology basics 

As the name suggests, Agile is a software development methodology that lets the team adjust to any changes in the working process quickly and easily. The software development environment may be rather turbulent, while the ideas, resources, or plans may take an unexpected turn. So, it’s necessary to be flexible to avoid undermining or postponing project success. One of the twelve central principles of Agile is to harness change even in the late stages of the development process to ensure the customer’s competitive advantage.

Any agile methodology consists of Waterfall-like iterations, which repeat until the product is satisfactory from the perspective of business logic, code quality, and user experience. Also, it always leaves room for changes in plan, scope, resources, or deadlines. Iteration and flexibility are the two key competitive differences between Agile and Waterfall.

Besides, Agile focuses on people and interactions rather than tools and processes. A self-organized, self-disciplined, and cross-functional team that can adjust a project development plan promptly is the core of this framework. Yet, it doesn’t mean that there is no room for managers. Well, there isn’t. Agile is based on leaders, not managers, who can create a productive working environment, motivate and inspire their team, and keep track of project progress without making their team members feel pressured or closely watched.

Pros and cons

In Agile, the customer is involved in each development process stage, so the requirements are adjusted in a timely manner, and the final product is fully satisfactory. If the project has strict time limits, Agile gives an opportunity to quickly develop and release the most basic version, which may be built upon later on. Also, identifying and fixing all the bugs may save much time and money.

Meanwhile, Agile won’t work for customers who don’t want to be engaged throughout industrialization project development but simply want to get the final product. Even though Agile does greatly optimize the process of making changes, additional time and cost expenses are unavoidable. Since the Agile methodology is iterative by its nature, frequent refactoring may be necessary. Otherwise, the quality is going to suffer badly.

Still, Agile is more effective than Waterfall — may Waterfall supporters forgive me for this statement. The software development process can be compared with a long drive from home — the idea — to your dream city — the final product. Imagine that before leaving home, you choose a route, plan all the stops, and claim you’ll arrive at your destination at 8 p.m. 

If you follow the Waterfall approach, you can’t change the route or add any new stops. However, what if there are roadworks on your route? What if there is a traffic jam? Or what if you feel tired and need to take a break from driving but can’t do that because the next stop is planned in two hours? Even if you make it to your destination in time, you’ll be tired, angry, and frustrated. 

Meanwhile, if you choose to follow the Agile approach, you can adjust the route if you learn about roadworks or traffic jams. You can take a break when you want to and miss a stop if you have no need to stop. There are no guarantees that you’ll make it to your dream city in time, but at least your trip will be more enjoyable and comfortable.

Typical usage

Agile works for any project. In particular, if you have a large team working on a complex project with no set-in-stone deadlines, Agile is the path to take.

Scrum, Kanban, Lean, and XP as Major Agile Methodologies

The list of four major Agile-based methodologies includes Scrum, Kanban, Lean, and XP. How to choose a software development methodology for your project? Let’s have a closer look at each of those.

Scrum    

Brief history overview 

As I mentioned earlier, the Scrum methodology was introduced in 1995 by Ken Schwaber and Jeff Sutherland. However, the term was coined in 1986 in the Harvard Business Review article “The New New Product Development Game.” 

In 2009, Schwaber and Sutherland released The Scrum Guide, which was later updated in 2016. However, to celebrate the twenty-fifth anniversary of Scrum, the authors introduced the Scrum Guide update on November 18, 2020. And it’s one of the few good news pieces that 2020 has brought. 

Many would say that Scrum is the best software development methodology — otherwise, it wouldn’t be so popular. I won’t say “the best,” but this methodology is definitely a huge game-changer.

Software development methodology basics 

Scrum is a software development framework that is frequently considered to be synonymous with Agile. Indeed, it’s a project management model according to which developers plan their work, update their objectives, and review their progress. However, calling Agile and Scrum the same thing is a mistake.

The fundamental difference between Agile and Scrum rests in how the latter uses certain roles (Developers, Product Owner, and Scrum Master), events (The Sprint, Sprint Planning, Daily Scrum, Sprint Review, and Sprint Retrospective), and artifacts (Product Backlog, Sprint Backlog, and Increment). 

In Scrum methodology, Developers aren’t necessarily software developers. Scrum can be used in other industries as well, so Developers are the team of people who execute Scrum objectives. The Product Owner is responsible for maintaining the Product Backlog and maximizing the product value achieved from the development process. Usually, it’s a person on the project client’s side. The Scrum Master is the person who makes sure that all Scrum events are held properly, and all Scrum principles are implemented.

As for the artifacts, there are two backlogs. The Product Backlog is a list of tasks for future sprints, while the Sprint Backlog includes tasks assigned for the current sprint. Scrum is an iterative managerial framework, and if the team faces an unplanned task, they need to wait until the end of the sprint to fix it. Each Backlog commits to a goal — a 2020 Scrum Guide update. That is, if all the tasks in the Product Backlog are completed, the Product Goal is achieved. If all the tasks in the Sprint Backlog are finished, the Sprint Goal is achieved. The third Scrum artifact is Increment — “a concrete stepping stone toward the Product Goal”. The Increment is a task to be completed — a feature to be implemented or a problem to be solved. This task can be considered completed once it meets the Definition of Done.

The product development timeframe is called sprint, starting with Sprint planning. The development team has to answer the main question: as a user of this system, which functions/services/experiences/values do I want to get? During Sprint planning, team members collectively decide on the Sprint Goal and Product Backlog items to pursue. Every working day, the team holds Daily Scrum meetings where they discuss achievements of the previous day and goals for the following one. At the end of each sprint, team members conduct a Sprint Review — where they present their results to the product owner and receive feedback — and a Sprint Retrospective — during which they discuss the latest sprint and offer improvements for the future one.

Pros and cons

The greatest advantage of Scrum is that it offers clear rules of the game. Scrum isn’t hard to learn, and once the team is on board with it, everybody knows what to expect from others and what is expected from them. The Daily Standup format is as clear as day, and Sprint Retrospective questions are simple and understandable. However, Scrum isn’t a methodology that works at all times. Ken Schwaber and Jeff Sutherland acknowledge that, for Scrum to be effective, the rules of the game have to be closely followed. The Scrum Guide starts with the words, “Each element of the framework serves a specific purpose essential to the overall value and results realized with Scrum. Changing the core design or ideas of Scrum, leaving out elements, or not following the rules of Scrum, covers up problems and limits the benefits of Scrum, potentially even rendering it useless.”

Typical usage

Scrum can be used for projects that involve a team of 5 to 10 people — large enough to be productive but small enough to be easily managed. It’s a suitable methodology for projects where the client is actively involved in development.

Example

We have used Scrum on our Banker Advisor project. For our client, it’s a passion project, so he wanted to be actively involved. The project goal was to create a valuable rather than a commercial product, so the requirements changed constantly.

For the Banker Advisor project, we decided to use Scrum because there was no complete vision of the final product, and our company had to conduct profound research before we started the development itself. Based on our experience and continuous testing, we have managed to create a product that fully satisfies a user’s expectations

Agile vs. Scrum

Reviewing its pros and cons is a good way to determine which methodology best suits your team.

Agile can attract teams because it helps them define easy-to-understand goals and do what is sufficient for the project. Monitoring the progress of the project is easy. The teams can release regular updates and development changes daily. Furthermore, what can be compared with effective, open communication? It’s one of the best ways to achieve the required goals. However, Agile has drawbacks, and one of them is the time commitment needed to complete tasks. Also, documentation poses a challenge; maintaining records of various iterations and implementations can lead to confusion if something goes wrong during the development.  

With Scrum, teams learn and refine their approach through sprints, devoting all their attention and time to specific sprint tasks. In Scrum, no team leader presupposes the team should work out all the details themselves. Sometimes, it may lead to disorganization. Furthermore, this methodology lacks substitutes, hindering progress if an unforeseen departure from the team occurs.

Agile has no set of rules, whereas Scrum does. When selecting the right methodology, you can focus on flexibility. We recommend using Scrum if the scope of project requirements will change and evolve. This methodology is ideal when you need continuous feedback, especially for studying uncharted work. It’s suited for projects with no required fixed release date, offering project teams autonomy and enabling regular software deliveries.

Agile suits projects where the end product isn’t precisely defined, accommodating flexible scopes and ongoing changes during development. It optimizes rapid deployment and harnesses developers’ autonomy and adaptability. As a benefit, for enhanced scalability, teams can combine elements from both Agile and Scrum principles.

Kanban

Brief history overview

The term “Kanban” was coined in the 17th century in Japan, meaning “a shop sign”. In Japanese, “kan” stands for “sign,” and “ban” stands for “board”. As a project management methodology, Kanban appeared in 1956 when Taiichi Ōno — the father of the Toyota Production System — started using paper cards for tracking demand. This system used swimlanes and WIP limits to illustrate the product cycle from manufacturing and distribution.

Software development methodology basics

Kanban is a software development framework based on Lean and Agile. It’s a methodology for the teams that are able and willing to collaborate and manage themselves. Kanban enables the team to identify and eliminate potential bottlenecks even in the early stages of the development process. The essential difference between Kanban and Scrum rests in the fact that, in Kanban, the work flows continuously through the system, and in Scrum, it’s organized into distinct timeboxes. It makes Kanban more suitable for projects where the requirements may be suddenly changed or added.

The major Kanban concepts are Kanban Board, Kanban Cards, and Kanban Swimlanes. As for the board, it can be both physical and digital, and it’s used to visually represent the development process. The cards visualize particular tasks and goals that need to be done and communicate the progress to the team. The swimlanes are the categories (visual columns) into which the cards are classified. Usually though not necessarily, these columns are titled “To Do”, “Doing”, and “Done”.

The key idea of Kanban is to make sure that the needs and interests of the customer are met, to reduce waste to a minimum, and to prevent unnecessary features from being developed. Kanban nurtures nine essential values:

1. Transparency
2. Balance
3. Collaboration
4. Customer Focus
5. Flow
6. Leadership
7. Understanding
8. Agreement
9. Respect

Now, Kanban dictates six major principles:

1. Start with what you do now
2. Encourage acts of leadership at every level
3. Agree to pursue improvement through evolutionary change
4. Focus on your customers’ needs and expectations
5. Manage work by letting people self-organize
6. Evolve PM policies to improve business outcomes

Finally, Kanban offers six practices that help you implement these principles and values:

1. Visualize workflow with Kanban board 
2. Limit work in progress — set WIP limits for each column to avoid bottlenecks
3. Manage flow, identify and address bottlenecks and blockers
4. Write explicit, simple, well-defined, and flexible policies
5. Use feedback loops: quarterly strategy review, monthly operations review, monthly risk review, bi-weekly service delivery review, daily Kanban meeting, weekly replenishment, and delivery planning meeting.
6. Improve collaboratively and continuously.

Pros and cons

Development teams like Kanban because of the flexibility and freedom it offers. Unlike in Scrum, in Kanban, the team does not commit to implementing a specific scope in a certain timeframe. However, such a lack of time planning and commitment requires the team and the client to have a high level of trust.

The second possible drawback of Kanban rests in the fact that the team can make the Kanban board overly complicated. The idea of Kanban is to make the project development flow streamlined and straightforward. Yet, if the team decides to visualize every stage and substage of the project development process, the board will be cluttered and hard to manage.

Finally, if the Kanban team does not implement and follow work-in-progress limits, the idea of Kanban becomes pointless and loses its value. So, Kanban should be implemented carefully and entirely.

Typical usage

Kanban should be used by project teams who would like to / need to:

• Release anytime
• Change priorities on the go
• Avoid estimates
• Avoid iterations
• Visualize the flow

EXAMPLE

On OneReach, we use Kanban because this methodology allows us to focus on consistent delivery of newly developed functions without spending too much time on discussions. Also, due to visualization as one of the major principles of Kanban, we can timely identify project bottlenecks and eliminate them.

Kanban vs. Scrum

While Scrum operates through short sprints, usually lasting 2-3 weeks, Kanban is more flexible, allowing rapid priority changes. In the case of Scrum, the team focuses on a task list for each sprint and moves it toward completion. The unfinished tasks shift to the next sprint, creating a new sprint scope. In the case of Kanban, new requirements are a priority. If the developer deploys a certain task, but some bugs appear, the team sets new requirements, and the developer accommodates them swiftly in short timeframes. 

In Scrum, the tasks are estimated in story points or hours, allowing the manager to estimate the team’s performance for two weeks. On the contrary, Kanban has no assessment or teamwork speed. It counts only the cycle time for a task, that is, how much time passed from when the task was taken to work until it was deployed. Kanban aims to coordinate and align work with the team’s capacity efficiently. Its distinctive feature is the Kanban board, which visually represents the workflow. The board segments tasks into “to-do,” “in progress,” and “completed” categories, offering flexibility to add more elements for enhanced progress tracking. Tasks transition across columns reflect the progress within the team’s workflow. The Kanban board makes problems like bottlenecks highly visible, enabling the team to address and resolve them promptly.

Which approach should you choose? Scrum and Kanban solve different problems. With Kanban, you get a strict sequence of tasks and a uniform workload by following a detailed plan to create the perfect product. If you don’t have a specific plan, with Scrum, you gradually develop and improve the product by accomplishing small sprints. Although the final product may differ from your planned one, it will best meet the users’ needs and expectations.

These approaches passed the test of time, so when selecting between them, the choice shouldn’t be definite. Hundreds of teams use hybrid models influenced by Scrum and Kanban. You can add more powerful capabilities by understanding what works for the team. Allow backlog items to progress to the “Completed” stage, then gather feedback from the team about what worked and what didn’t. Embrace Scrum and Kanban, ask the right questions, and discover the fulfillment of embracing Agile practices.

Kanban vs. Agile

With Kanban and Agile, we can work in many small steps rather than big ones and gradually track the progress with greater certainty. 

The biggest difference between Agile and Kanban is in task planning. While Agile methodology has fixed sprints, Kanban makes visualizing and optimizing workflow easier without prescriptive roles and time-bound events. In terms of planning, Agile approaches divide work into iterations, where each of these iterations is a unit of delivery. Agile teams can track the rate of progress by counting iterations and use that assessment in their planning. This way, they agree on priorities and capacity in their work. 

Kanban is a less structured approach compared to Scrum or Agile. It’s a model in which changes are implemented through incremental improvements. The main method in Kanban is a visualization of the tasks via the Kanban board, which allows team members to see the status of the tasks and the scope of planned work. Kanban saves information about the person responsible for the task, a brief description of the work done, and an estimation of the time required. The model is efficient for teams where all work processes are established and need only improvement without changing the system. It makes it easier for team members to track the lifecycle of work tasks. The team focuses on the current tasks, and even if the product owner changes their priority or plans some new tasks, it won’t interfere with the team’s work. 

Both methodologies share common attributes and values, focusing on achieving progress incrementally. But from a planning perspective, task management with Kanban is much simpler. 

Lean

Brief history overview

The history of Lean is intertwined with the history of Kanban. In fact, Kanban emerged on the basis of the Lean philosophy, which was developed by a Japanese motor corporation Toyota in the middle of the 20th century. Toyota’s manufacturing pipeline was very long, so there was a lot of waste. Lean was developed to help the company reduce this waste.

Software development methodology basics 

Optimizing efficiency and minimizing waste are the two pillars of lean software engineering. To say that differently, the Lean methodology is aimed to provide a software product of the highest quality while using the least possible amount of resources. 

The methodology recognizes three types of waste, also known as 3M’s: 

1. muda — all the activities that do not add value to the product, such as overproducing, over-processing, fixing product defects, waiting, multitasking
2. mura — non-uniform actions and irregularities. For instance, if a UX designer spends too much time creating the product design, developers may have to code in a rush and the QA process will be neglected because of a lack of time. 
3. muri — impossible tasks, emotional pressure, and overburden. For example, to optimize the efficiency of a team, it is necessary that they do not feel stressed and perfectly understand what they need to do and what tools they should use. 

Unlike other methodologies, Lean does not impose any specific processes or artifacts but dictates a set of principles that a business should abide by:

1. Define Value — understand which customer’s problem you will solve 
2. Map the Value Stream — define how exactly you will solve the customer’s problem
3. Create Flow — turn the value stream into a streamlined pipeline
4. Establish Pull — limit work in progress and enable continuous and timely delivery
5. Pursue Perfection — encourage and facilitate continuous process improvement

To ensure that these principles are met as fast as possible, the team may start with MVP development, which is a rough but important draft of the final product.

Pros and cons

Lean is very different from Scrum or Kanban in a way that it is descriptive rather than prescriptive. Scrum and Kanban are easier to implement and follow because there are clear rules and roles.  

Typical usage

Lean is mostly used by teams that aim not to push something to the market fast but rather to develop a perfect idea and test it thoroughly with the market. In fact, Lean can become a perfect methodology for an MVP development team.

XP (Extreme programming)

Brief history overview

Extreme Programming as a PM methodology has been invented and shaped by a team of engineers on the basis of Chrysler Comprehensive Compensation System (C3). The first and most famous person in this team is Kent Beck — the lead software developer at C3 and the father of XP. He introduced XP in 1996. Ron Jeffries, Ward Cunningham, Don Wells, and Martin Fowler consulted Beck and championed his idea. 

Software development methodology basics

The goal of XP is to improve the quality of code and the quality of life for the project developers. Extreme Programming has the potential to apply the developers’ knowledge and skills to the fullest. XP is often referred to as “a ring of poisonous snakes” or “a house of cards” because it comprises twelve major practices and none of them should be omitted.  Similarly to Kanban and Lean, XP aims to reduce waste to a minimum and to focus on the objectives for today rather than for the future.

 The five essential XP values include:

1. Communication — sharing knowledge with the team
2. Courage — taking decisive actions that will bring the team closer to the expected result
3. Respect — working together successfully
4. Simplicity — doing only necessary things
5. Feedback — identifying areas for improvement

Also, there are three roles in Extreme Programming:

1. The Customer
2. The Developer
3. The Tracker (team lead or Project Manager)
4. The Coach (external consultant) 

The twelve major practices of Extreme Programming are:

1. The Planning Game — The team conducts release planning and iteration planning.
2. Small Releases — The team frequently releases well-tested software features to their end users.
3. Metaphor — The team shares a common vision of how the program works.
4. Simple Design — Design is performed not before development but with development, and design discussions involve the whole team.
5. Testing — Each feature is covered with at least one or more automated acceptance tests.
6. Refactoring — Software developers continuously work on removing code duplication and increasing code cohesion.
7. Pair Programming — The software is developed by two programmers using the same computer. 
8. Collective Ownership — Any pair of developers can improve any piece of code anytime.
9. Continuous Integration — The team keeps the system integrated at all times.
10. 40-hour week — The team should work no more than 40 hours per week.
11. On-site Customer (Whole Team) — The Customer is working hand-in-hand with developers so the team doesn’t leave business needs out of attention.
12. Coding Standard — The team creates and follows a uniform code standard for all the code to look like it was written by a single, very skilled developer.

Pros and cons

Extreme Programming is the most prescriptive PM methodology among the ones mentioned in this article. It can be both advantage and disadvantage — depending on the project specifics.

Typical usage

Extreme Programming is the most suitable for projects with dynamically changing requirements, small, co-located development teams, and technology that allows for automated testing.

Final Remarks

Agile methodologies aren’t the exclusive ones that a software development team may use. Although more and more teams decide to give up on the Waterfall methodology because of its simplicity and stiffness, there are cases when this is the framework that would suit your project the most. If NASA still successfully uses Waterfall, why wouldn’t you even consider it? 

So, what is the best software development methodology? There is no “best methodology for software development”. There is a methodology that suits your project best.

If you have considered Waterfall, and you do find the suggested project flow useful, but you would want more flexibility — consider doing Scrum or Kanban. Both methodologies make use of the same project development pipeline, but they give you more freedom in terms of requirements and deadlines. At the same time, these methodologies give you tools that would help you not to turn freedom into chaos.

Once Scrum and Kanban seem to be too prescriptive for you, try doing Lean. If, by contrast, Scrum and Kanban aren’t prescriptive enough, go with Extreme Programming. Both Lean and XP aren’t as common as their counterparts, but they surely have a lot to offer.

The most important point is “don’t be afraid to try”. If you have tried Kanban, and it doesn’t work because the team ignores WIP limits despite all your efforts to enforce them, suggest moving to Scrum. Also, listen to your team members. Even though you’re the project manager, developers and QAs can have a lot of great ideas as to how to improve the process. 

Final takeaway: Do not lock yourself inside a certain PM methodology. A methodology isn’t a castle for you and your team to hide in. It’s a large and beautiful ship that helps you get closer with each passing day to your final destination.