So, set aside 15 minutes to learn what are the different software development methodologies, their pros, cons, and application cases.

Various methodologies present a set of rules, processes, and rituals we use to build software. Some of them are flexible and lightweight while others tell exactly how to build your product and manage your team.

Different models shine in different situations. So take a look at our software development methodologies list and find the one that fits your project!

Waterfall: the predictable one

For a long time, Waterfall was the go-to approach to development. It has rigid, well-defined processes that can be separated into 6 phases:

Each stage of development has its own set of deliverables and review criteria. The process can only go forward like water in a cascading waterfall. The team moves one step at a time making sure their work is complete before going to the next phase.

The process is predictable and allows for accurate budgeting and scheduling. This makes Waterfall a perfect fit for fixed-price projects. In fact, lots of our first-time clients prefer to sign fixed-cost contracts in order to reduce risks from a new partnership.

What’s more, after heavy upfront planning and a lengthy discovery phase, the client doesn’t have to spend much time getting involved in the development process.

Some project managers consider Waterfall one of the best software methodologies for distributed teams and working from home.

Yet, reality tends to change a lot. Few countries prepared for this pandemic, but here we are, working from home and hoping for a better future.

This crisis has shown that plans often become outdated as soon as you put them on paper.

If something bad happens as the team develops the system, Waterfall can be very bad at handling the necessary changes. A project manager has to receive approval from all stakeholders and look through a ton of documents to discover often unexpected effects of suggested changes on the entire system.

Here at MindK we still have some Waterfall projects (less than 15% of all projects). They are usually large, enterprise projects that last more than half of the year and require detailed planning and documentation.

The number of Waterfall projects has decreased over the years due to changes in the business environment. To stay up to date in the current climate, we modified our Waterfall process with some of the elements we like about other approaches like daily meetings, frequent demos, and early testing.

Waterfall pros:

+ Simple in management and execution.

+ Requires less time from the client past the discovery phase.

+ Ample documentation helps in onboarding new developers.

+ A great fit for fixed-price projects.

+ Easier to estimate the final budget/schedule for the whole project.

Waterfall cons:

– Requires a lengthy discovery phase to extract complete requirements.

– Long time-to-market.

– More likely to lead to a failed product (21% failure rate).

– Only suitable for stable markets; bad at incorporating change.

– The final product can deviate from client expectations due to unforeseen technical difficulties.

Agile: the responsive one

Change is all around us – technologies change, markets undergo radical shifts, users discover new things to do with their money and time.

To survive in these uncertain times, developers, as well as business owners, needed a more flexible approach to building software.The one which focuses on releasing a small product as quickly as possible and gathering lots of useful feedback.

In 2001 a group of industry experts gathered together to create the Agile manifesto which inspired a whole host of software development methodologies like Scrum and Kanban.

Agile is not a methodology per se, but rather a set of principles that guide software development.

Instead of building software in one go, it splits the project into several iterations, each lasting 1-4 weeks. During this time, the team designs, builds, and tests complete features that can be released as a working product.

The app is immediately valuable to users and can be improved in the next iterations.

After the first release, the team collects feedback and begins a new iteration. This allows you to quickly validate your assumptions and improve the product.

As high-risk features can be delivered first, this approach decreases the dangers of a failed project.

But its biggest strength is the ability to handle uncertainty and incorporate change into the project’s DNA.

These benefits made Agile a favorite among tech startups and companies outside Silicon Valley like Elon Musk’s SpaceX. Even in the government sector, 80% of large projects are built using Agile.

We like the Agile and its flexibility, especially in these turbulent times. Over 85% of projects at MindK are delivered using Agile approaches like Scrum or Kanban. They excel in mid-to-long-term projects that have incomplete requirements or have a high degree of uncertainty.

By splitting the whole project into manageable iterations, the team can collect more requirements and reduce risks of not satisfying user needs.

If you want to learn more about Agile, I highly recommend downloading our e-book that explains everything you need to know about this flexible approach and provides a detailed overview of its practices and tools.

Agile pros:

+ 2.5x lower risk of a project failure compared to the Waterfall model.

+ Frequent releases and feedback collection.

+ Good at handling requirements that change during development.

+ Early release of a working product.

+ High involvement of the client ensures the product fits her/his expectations.

+ Defects can be found earlier and fixed for a fraction of the cost.

Agile cons:

– Requires careful change management to prevent feature creep.

– No end-date for the development and no final price tag.,

– Poor choice for the fixed-cost model.

– Requires more experienced team members.

– Incomplete documentation can cause issues down the line.

Agile framework #1 – Scrum

Scrum isn’t a separate methodology, but rather an Agile framework for small cross-functional teams. At the heart of the framework are Scrum rituals that help the team to quickly react to the changes in requirements and iterate on user feedback:

• Sprint planning. Before the start of the iteration (also called Sprint), the team gathers with the client representatives to prioritize features according to their value/risk and plan the next 2-4 weeks of development.
• Daily Scrums are quick timeboxed meetings where each team member shares their progress on tasks, plans for the next day, and discusses any blockers. Regular meetings ensure that there are no surprises for the client, even during the pandemic.
• Demo after each iteration allows stakeholders to see the latest improvements to the product and reveal any defects.
• Retrospectives are usually held after each demo. During these meetings, the team will look back at the work they’ve completed during the iteration, discuss their missteps, and suggest improvements for the next Sprint.

All these rituals help build better relationships with the client and continuously improve development processes.

Unlike most website methodologies, Scrum doesn’t divide the team into developers and testers. Instead of project managers, Scrum has Product owners who try to maximize the value of the product and Scrum Masters who maintain Scrum rituals

In our experience, Scrum is great for quick MVP development and regular improvements to the product. It also requires careful Sprint planning and high involvement from the client.

Scrum pros:

+ Release of a working product every 2-4 weeks.

+ Can work with incomplete requirements.

+ Great balance of flexibility and short-term planning.

+ Daily meetings help the Product Owner to keep fingers on the pulse of development.

+ Higher product quality due to incremental testing.

Scrum cons:

– Doesn’t suit inexperienced teams with insufficient self-discipline.

– Requires regular communication and lots of time on part of the client.

– Scales poorly for larger teams.

– Changes in team composition make it harder to predict team productivity.

– Needs a buy-in from every team member.

Agile framework #2 – Kanban

Kanban is another popular Agile framework that’s far more flexible than Scrum.

The approach has its roots in the Toyota Production System and Lean Manufacturing that allowed Toyota to become one of the world’s top auto-makers.

Its central feature is a Kanban board – a simple to-do list organized as a Trello board or an old-fashioned wall full of stickers. Each sticker represents a different task or user story. As the team works on tasks, the stickers move between columns that represent different stages of work.

The board is typically limited in size to control the amount of work in progress and ensure the cards get across the board as quickly as possible.
There are no Sprints or Sprint planning. When the team completes a user story, the Product Owner simply pulls a new task from the backlog and places it on the board.

As a result, the team can release more often – 1-2 times a week.

Kanban shares several rituals with Scrum (Daily standups, demos for stakeholders, and retrospectives) but unlike the latter, Kanban can be easily applied to existing processes at your team.

In our experience, Kanban is a great fit for projects in the support phase.

Often, we receive a steady flow of change requests from the clients that aren’t connected with each other. Uniting such tasks with a common Sprint goal is pretty hard but Kanban allows us to keep working on the incoming fixes and make steady releases.

Kanban also shines in situations with incomplete requirements that are likely to change on a weekly basis (which makes accurate Sprint planning impossible).

Kanban pros:

+ Simple task management, developers work one story at a time.

+ Great flexibility with a focus on individual tasks (no Sprints and iteration planning).

+ Can be used even by larger teams.

+ Doesn’t need re-planning when requirements change.

+ Perfect for the maintenance phase.

Kanban cons:

– Easy to lose the direction of development.

– Requires self-management skills from developers to prioritize incoming tasks.

– No Sprinting can lower developer productivity.

– Great flexibility can prompt clients to change priorities too frequently.

– Hard to make accurate predictions and control the scope of work.

Scrum, Kanban, and the Agile-Waterfall hybrid are 3 development methodologies we use daily on our projects. At the same time, there are lots of other approaches used by developers around the globe.

Extreme programming (XP): the prescriptive one

XP is a system development methodology that encourages extreme professionalism and development rigour.

It was first formulated in Kent Beck’s 1999 book called Extreme Programming Explained.

It took some of the best practices around the time to extreme levels:

• Object-oriented programming.
• Code review.
• Refactoring.
• Test-driven development.
• Not writing features until you need them.
• Pair programming.
• Continuous integration.
• Unit testing, etc.

“The first time I was asked to lead a team, I asked them to do a little bit of the things I thought were sensible, like testing and reviews. The second time there was a lot more on the line. I … asked the team to crank up all the knobs to 10 on the things I thought were essential and leave out everything else.” – Kent Beck, Author of the Extreme Programming book series

As you can see, XP focuses mostly on engineering practices instead of project management.

Similar to Agile approaches, it focuses on short development cycles and user feedback. The aim is to make the design as simple as possible and account only for the current needs.

The design can later evolve to take care of the more complex needs.
Like Scrum, XP starts with iteration planning. Before writing the first line of code, developers would design acceptance tests that define exactly what the code must do according to the requirements.

After writing the acceptance test, two developers would sit together to implement the code and run it through the previously designed tests.
As a result, working code is shipped each week leading to quicker feedback loops.

In practice, few clients are ready to pay for pair programming making XP a rather niche approach. This is one of the reasons we don’t use it at MindK. Still, we have adopted some of its best practices like code review, unit testing, refactoring, and Continuous Integration/Continuous Deployment.

XP pros:

+ High transparency due to client involvement.

+ Great for projects in unstable environments.

+ Frequent checkpoints allow the team to produce accurate schedules.

+ Developers are personally committed to following plans.

+ Relies on some of the best practices in programming.

XP cons:

– Very prescriptive and requires great dedication.

– Difficult to implement, highly reliant on developer professionalism.

– Requires heavy client involvement and lots of meetings.

– Frequent changes can end up costly.

Lean development: the startups’ favorite

Lean is another Agile software development methodology that takes inspiration from the Toyota Production System.

The system removed any activity that didn’t contribute towards the car’s functionality making the process extremely efficient. This helped Toyota become twice as fast at assembling cars than any of its American competitors.

This iterative approach is based on 7 principles:

1. Eliminate Waste – cut anything that doesn’t add value to the product;
2. Deliver Fast – build a Minimum Viable Product (MVP) in a record time;
3. Delay Commitment – irreversible decisions are postponed until all necessary information is available;
4. Amplify Knowledge – lessons learned are incorporated in next iterations;
5. Build Quality In – test after each iteration to prevent defects;
6. Optimize the whole thing – focus on improving the entire team workflow.
7. Respect people – the team is given the freedom to make important decisions.

These principles made Lean Development a favorite among startups like Spotify that want to quickly build an MVP on a shoestring budget and deliver value with each release.

Lean pros:

+ Optimized for prototyping and early-stage startups.

+ Focus on fast development and business value.

+ Elimination of waste and improved efficiency.

+ Empowerment of the development team to take responsibility and make decisions

+ Shortest time-to-market.

Lean cons:

– Highly dependent on the team’s involvement and professionalism.

– The client needs to trust the team’s decisions.

– Relies on detailed documentation.

– Lots of freedom to the team can sometimes lead to a lack of focus.

– Needs a dedicated business analyst.

Spiral model: the risk-driven approach

Original diagram depicting the spiral model; source: Wikipeddia

Spiral model is a hybrid of Agile and Waterfall IT methodologies focused on early risk identification and mitigation.

The team starts at the center of the spiral, with a minimum set of requirements. They will then go through 4 phases of development:

1. Determining objectives. The team discusses the requirements with the client, estimates costs, identifiers alternative solutions, and plans the iteration.
2. Risk analysis and mitigation.
3. Development and testing of a software prototype.
4. Evaluation by the client.

Once the prototype passes the evaluation, the team will add fresh requirements and start a new loop. This allows developers to break large systems into smaller components building one feature at a time.

While we haven’t used the Spiral model in practice, many companies, including NASA and Microsoft, have successfully implemented the methodology on their projects.

Spiral model pros:

+ Best suited to large and high-risk projects with changing requirements.

+ Detailed risk analysis minimizes risks.

+ Easier cost estimation due to incremental development.

+ Functionality can be added or changed later in development.

Spiral model cons:

– Risk analysis is critical to success.

– Needs to be followed closely in order to succeed.

– Requires heavy documentation.

– Can get costly due to deep analysis and the lack of clear end goals.

– Time management is problematic due to the unknown number of loops.

Conclusions

Choosing the right methodology is one of the most important decisions about your project. After all, agreeing on rules and processes can save us from arguing endlessly over how things should be done.

No methodology fits every situation.

They all have their pros and cons, whether it’s Waterfall with its predictability and accurate budgeting, Scrum with its fast time-to-market and short-term planning, or Kanban with its extreme flexibility.

Sometimes, it might even be useful to combine elements from different software development methodologies. What matters is that you have measurable and repeatable processes that are flexible enough to embrace the necessary change.

And if you need some help in choosing the most appropriate application development methodology or seek an all-star team to realize your vision, you can always drop us a line.