5 Popular Software Development Models with their Pros and Cons
Tags: Lean, Kanban, Scrum, Software Development, Waterfall

Software development models are numerous and suited for developing different types of software and applications. Choosing the right model is essential for delivering the expected results within the specified timeframes and under the planned budget. Quite the contrary, choosing the incorrect model or working without one can lead to prolonged timeframes, subpar product quality or an outright failure of the project.

Therefore, knowing the differences between the popular software development methodologies along with their pros and cons is essential for choosing the right one. Today we will provide such a comparison, so you will be able to make a grounded decision on what model fits your project requirements best.

These are 5 popular software development models used nowadays:

Waterfall

Scrum

Lean

Kanban

Feature driven development

In this article, we will describe these models, the projects they are best suited for and their pros and cons. While all of these models share the same phases of the SDLC (Software Development Life Cycle), there are distinctive features that set them apart and make them suitable for different types of projects and varying sizes of developer teams.

Waterfall

This is the oldest, most trusted and most straightforward of the software development methodologies. It resembles the waterfall, as each stage can be completed only after the previous one is finished. The stages include product requirement gathering, design and development of the software, testing, release and maintenance.

Waterfall pros:

Simple and functional project structure. Quick to accomplish, suitable for small-to-midsize projects (mobile games, etc.). Easy to test and analyze the feature realization.

Waterfall cons:

The project requirements should be precise and cannot be adjusted on the go. Product functionality cannot be tested and fixed mid-development, as no MVP is present. The model does not fit projects requiring intense maintenance.

All in all, Waterfall is a convenient methodology for a relatively small group of developers conducting typical one-time projects. These can be the projects with long development cycle and strict requirements, like medical hardware drivers or medical software for analysis processing, as well as software and applications for other industries where the error can cost human lives, not dollars. However, due to testing limitations and project management rigidity, Waterfall is currently losing popularity in favor of more flexible models.

Scrum

Scrum is the practical approach to Agile product development methodology. This paradigm states the development should be iterative, with an MVP (Minimum Viable Product) always available for testing after each iteration (which are usually 2–4 weeks long). After each iteration new features are added to the product until it is considered feature-complete and ready for release. Such approach to software development allows adjusting project requirements on the go, should the need be.

Scrum pros:

High adaptivity to requirements changes amidst the project management cycle. The product owner is constantly in touch with the team to maintain process transparency. As the testing takes place after each iteration, the bugs and unnecessary features are corrected quickly. Rolling back to a previous product version is quite easy.

Scrum cons:

As the product requirements can be adjusted often, they are rarely documented. This means the development can take a side turn if the product owner is not absolutely clear of the product requirements. Only senior developers can control such a project management model, meaning there should be at least one dedicated Scrum master in each team and they should keep a close look to ensure every developer’s work moves in the right direction. Initial timeframes are adjusted far too often and delivering the expected product precisely on time is not a thing happening often.

Scrum model of Agile methodology is great for rather smaller team working on the continuous development and implementation of new features for a long-standing product. Testing is thorough, iterations are fast, new features are delivered quickly and the product is operational at all times.

Lean

Lean software development model has its roots in Toyota approach to doing things: when you need to change something, do only the changes that bring the most VALUE, require the least EFFORT (budget) to be accomplished and take only 30% of the TIME planned. Such approach helped Toyota build a workflow able to switch their car constructing conveyors to producing another model of Toyota vehicles in mere hours, while the other manufacturers needed weeks to do it.

Lean pros:

The MVP is delivered quickly. The expenses are quite low. The team is motivated to make every product feature perfect, not simply accomplish the tasks.

Lean cons:

The documentation needs to be absolutely precise and a skilled analyst is needed to ensure 100% understanding of the requirements. This approach is suitable only for highly skilled developers with immense knowledge in the field; learning on the go is impossible and not acceptable, as it puts the project at risk. While highly motivated to deliver a polished product, the developers might lose focus on the initial objectives, so flexible decision making from the developers should be backed up with diligent process monitoring by the team lead or the analyst.

Lean software development methodology works wonders for renovating the long-time working product, like rewriting the engine using newest technologies, replacing the outdated interface with a top-notch functionality, etc.

Kanban

Kanban Board is an approach that can actually be used on top of any of the previous software development methodologies, though originally deriving from working under the Lean model. It concentrates on pinpointing the most important feature in development right now, shows the effort already spent on it, and helps to highlight the room for continuous improvement, helping to seek and find perfection in every product feature.

Kanban pros:

Limiting the work in progress (WIP) to the most important areas to keep the amount of change minimal at any given time and speed up the development process. Nearly zero investment in tools or additional training for your development team. As simple as sticky notes and a whiteboard, this visualization technique helps keep the hand on the pulse of the product development.

Kanban cons:

Sticky notes cannot predict the timeframes, so lengthy projects involving months of development benefit little of this approach. While simplifying the WIP, Kanban is no good for planning and can be completely overhauled by a model better suited for planning, like Scrum. Then, again, Kanban works best on top of Lean or Scrum, simply showing the flow of development and helping avoid the bottlenecks in it. As each Kanban Board task is equally important, this practice does not work in times of maintenance issues, as no urgency markers are present and the tasks cannot be prioritized.

Kanban is great for smaller team working on polishing a product, like running a business intelligence system, where constant system improvement is expected and drives value.

Feature Driven Development

In feature driven development or FDD model, features are the cornerstones of development. As the features are added, the new sets of requirements are introduced. This works best for larger internal teams of developers, working on the incremental improvement of a large-scale product. This approach is also quite often used as an interim workflow between a Waterfall and Agile software development methodologies.

FDD pros:

Works great for large-scale products requiring constant updating and always delivers value. Based on the best and well-documented software development practices, ensuring developers with any experience can find their role and successfully work on the project. The resulting features are always better than the initial ones

FDD cons:

This model cannot be used by smaller or one-man teams of developers, as well as for smaller projects with strict deadlines The success of this model relies heavily on having the highly-skilled team leads monitoring the process throughout the development cycles Documentation is scarce if any. The software owner gets the feature, yet its precise description is outside the scope of FDD model.

FDD model is best used by large teams of developers, working on constantly improving the performance of an integrated product, like a banking software. Nowadays it is quite popular, yet it still loses popularity to more Agile-like software development models.