Software development methodologies 101: which one is better suited to your project?

What drives the choice of a software development methodology? Each methodology has its own unique characteristics, advantages, and disadvantages. Some of them are flexible and lightweight, while others presuppose more strict rules. It is impossible to determine which of them is better because a specific development principle is chosen for different tasks, products, and ideas. Simply put, different methodologies shine in different situations.

Here at MindK, in choosing a methodology for a project, we mostly rely on the type of project, requirements, goals, and customer expectations. Let’s take a look at the main methodologies, how they are managed, the methodologies we used on our projects and why.

What is a software development methodology (and why is it important)?

Before we move to the types of methodologies, it’s better to nail it down first with terminology. We noticed great confusion about methodologies on the web, more specifically, methodologies are often mixed up with software development life cycle models and software development frameworks. All of them have very similar, but quite different meanings. To be on the same page from the beginning, let’s puzzle them out.

Each product has its own life cycle. Software development life cycle (or SDLC) presupposes the stages of the development process. It starts the moment you make a decision to develop an app or solution.

SDLC models (also called process models) are an illustrative representation of the software life cycle which represents stages required to make a software product. Software development methodology, in turn, determines how these stages are implemented, how they are managed, and the principles they are based on.

This means that you can think of a software development model as a description of stages the product goes through during its life cycle and what happens at each of them. While a software development methodology is a set of methods for managing the development process, including rules, techniques, and principles that make the development as efficient as possible. Finally, development methodology is the application of a particular model in practice.

The software development methodology helps to:

• understand how to implement an idea and create a valuable product for business;
• choose methods and an action plan that reduces errors during development;
• save money by minimizing the number of changes and speeding up the process thanks to a clear-cut action process;
• allocate tasks within the team, depending on methodology;
• determine the workflow, form requirements for the product, and so on.

Apart from models and methodologies, there are also software development frameworks. As opposed to a methodology that demonstrates a well-thought-out, defined, repeatable approach to run the project, a framework is flexible enough to adapt to changing conditions or be customized for your company.

Source: activecollab.com

There is no official classification that will help you to get a comprehensive overview of all the SDLC models, project management methodologies, and frameworks, but keeping their differences in mind is very helpful in not getting lost and confused among the variety of terms.

After clearing up the terminology, it’s time to move to the most popular software development methodologies used.

The most commonly used software development methodologies and frameworks

Waterfall methodology: the predictive one

For a long time, Waterfall was the go-to approach in terms of 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 only goes forward, like water in a cascading waterfall. The team moves one step at a time, making sure their work is complete before flowing onto 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, some of our first-time clients prefer to sign fixed-cost contracts for developing a Minimum Viable Product (MVP) in order to reduce risks with a new partnership.

What’s more, after heavy upfront planning and a lengthy discovery phase, you won’t have to spend much time getting involved in the development process when choosing Waterfall.

Some project managers considered 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 the often unexpected effects of suggested changes on the entire system.

Here at MindK we still have some Waterfall projects, however, more and more of these projects are shifting to iterative Agile methodology (reviewed further in this article).

One such project is CHOO, a member management system for Norwegian associations. First we used the Waterfall methodology, then, for system redesign and product improvements, we followed a more iterative approach. It allowed us to develop an event management module in a short timeframe, crucial for the client because of the pandemic. The event module easily arranges online and offline courses, conferences, meetings, and other activities.

The main reason for such a shift to Agile is the changing business environment. To stay up to date in the current climate, at MindK we sometimes use hybrid approaches to software development that include a mix of Waterfall and other methodologies, as well as modify the 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.
+ Detailed 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 methodology: the responsive one

Change is all around us – technologies change, markets undergo radical shifts, users discover new things to do with their time and money. To survive in these uncertain times, developers, as well as business owners, needed a more flexible approach to building software, one which focuses on releasing a small product as quickly as possible and gathering lots of useful feedback.

Instead of building software in one go, Agile splits the project into several iterations, each lasting 1-4 weeks. By splitting the whole project into manageable iterations, the team collects more requirements and reduces the risk of not satisfying user needs.

During the iteration, 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. As a result, you quickly validate or disprove assumptions and can immediately improve the product.

High-risk features can be delivered first so Agile 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.

Here at MindK, we like Agile and its flexibility too, especially in these turbulent times. Over 85% of projects at MindK are delivered using Agile methodology and Agile frameworks, like Scrum or Kanban, which excel in mid-to-long-term projects that have incomplete requirements or a high degree of uncertainty.

If you want to learn more about how to manage an Agile project and the role of the client in the process, we highly recommend downloading our e-book Decision Maker’s Guide to Agile Product Development. It 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.

Speaking about Agile would be incomplete without mentioning its most popular frameworks (especially since most of these frameworks we use on our projects). Among the key Agile frameworks are Scrum, Kanban, and Extreme Programming. Let’s see what they are all about.

Agile framework: Scrum

Scrum is 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.
• 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.

From 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.

An illustrative example of the solution we at MindK developed with Scrum is Bridge, an operating system for global hiring. We developed an MVP in just 3 months fully remotely. It means that after such a short period of time the client was able to deliver a basic version of the solution to the market and investors, as well as collect feedback.

We consider that the right choice of the framework was one of the key factors for success because the product was developed during the pandemic in terms of high business uncertainty.

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 in terms 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 the client’s part.
– 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: 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 such as 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 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).

All these were the reasons we turned to Kanban on the project CEMAsys, a SaaS platform, that helps companies manage and report sustainability and environmental information. Initially, when we developed the solution, we used Scrum. After the release, the client sent a number of change requests and new features, some of which were urgent and critical. That’s why planning sprints turned out to be challenging. What’s more, the client could not wait for 2-3 weeks until the end of the sprint to get critical features. With Kanban, we are able to deliver features one by one without a need to make upfront sprint planning.

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.
– Absence of 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 regularly on our projects. At the same time, there are lots of other approaches used by developers around the globe.

Agile framework: Extreme programming

Extreme programming (XP) is one more popular Agile software development framework 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.

As you can see, XP focuses mostly on engineering practices instead of project management. As far as it is an Agile framework, it focuses on short development cycles and user feedback. The goal 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.

Agile framework: Lean development

Lean is another Agile software development framework that takes inspiration from the Toyota Production System. The system removed any activity that didn’t contribute towards the car’s functionality, making the manufacturing 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 seven principles:

This iterative approach is based on seven 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.

DevOps methodology: the collaborative one

DevOps is a software development methodology focused more on the deployment process than on management. It is focused on enhancing collaboration between different departments, such as development, quality assurance, and operations.

If IT professionals from different departments work separately and don’t know and understand each other’s tasks, the release of new applications becomes lengthy. Simply put, when all the departments collaborate, it allows faster development.

A DevOps process can be visualized as an infinite loop with the following steps: plan, code, build, test, release, deploy, operate, monitor, and – through feedback – plan, which resets the loop.

In a nutshell, DevOps means that the development team creates software that perfectly meets client requirements, deploys quickly, and runs on the first try. If writing software quickly is easy, developing a solution that works is another story.

To release a working solution, the methodology uses continuous integration and automation tools that drastically improve the efficiency of software development and operation. So, here are the basic principles of DevOps:

1. Automation – automate as much as possible (and what is impossible, too), so that all processes of testing, developing, deploying, rolling out updates, collecting feedback are carried out automatically.
2. Collaboration that allows speeding up development. This principle also emphasizes the direct connection between the DevOps ideology and the needs of the business – the sooner the customer receives the final working product, the higher is the efficiency and competitiveness of the business.
3. Continuous improvement is tied to continuous delivery. It enables DevOps teams to push updates that improve solution efficiency. Continuous testing allows the team to fully control the process and quickly respond to emerging problems.
4. Client orientation is based on the short feedback loops. As far as the DevOps practices presuppose rapid collection of user feedback through means of real-time live monitoring and rapid deployment, the product is developed around user needs.
5. Availability of strong standards necessary to not turn the development, testing, and operation into “chaos”, but allow automation of each stage.

At the heart of DevOps methodology is a DevOps Engineer. He works on synchronizing all stages of creating a software product: from writing code to testing and deployment. Here at MindK, we have a dedicated DevOps department. Our DevOps specialists are responsible for any automation of tasks associated with configuring and deploying software solutions.

Adoption of DevOps practices allows us to break the wall between departments. However, understand that the DevOps transition doesn’t happen overnight. If you are interested in finding more about how to adopt DevOps, check our article on what is important for successful DevOps transition, where our CTOs and solution architects share their insights and best practices.

We also help our clients to set up DevOps practices in their processes. For example, for one of our clients, we successfully helped to migrate the project to microservices architecture. As a result, the client saved thousands of dollars per month, while releases became more predictable, secure, and faster.

Explore the full case study →

If you want faster time to market, better product quality, and lower operational costs – check out how MindK can help you with our DevOps services.

DevOps pros:
+ Fewer silos and improved communication among IT departments.
+ Provides quick bug fixes.
+ Rapid improvement based on feedback.
+ Requires less development time and ensures dependable releases due to a shared codebase and continuous integration.

DevOps cons:
– Implies both organizational and IT departmental changes, including new skills and roles.
– An investment of time and money, at least initially.
– Requires well-coordinated teamwork.
– Needs scaling DevOps across multiple projects and teams.

Choosing a software development methodology for your project

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

However, there is no one-fits-all methodology. 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.