Software development methodologies

Hi! During the last two interviews, I was asked about the software development methodologies. It is not the most important and complex question, but it would be nice to have a cheat sheet. In this article, I will try to give you the definition of development methodology and we will compare those I have personally dealt with and those I were asked about.

Software development methodologies

The software development methodology is a description process of the way the product will be built. Thus it is one of the methods of a team development organization. There are many different models of such a process and each of them describes its own approach. Thus, we cannot emphasize the only one which should be used within each project as everything is pectoral. I offer to discuss three of them.


Waterfall (cascade) is one of the oldest methodologies and it stands for strict and consistent execution of all the stages, each of which should be ended before the beginning of the next one. It means that the transition to the next stage is a full final completion at the previous stage. You can see on the image that firstly we analyze the task (here we form the project structure), then coding and testing. Returns to the previous stages are not provided. It is recommended to use this system in small projects where you know the requirements preliminary and there is a low probability of its changing.



  • Complete and consistent documentation at each stage;

  • Ease of use;

  • Stable requirements;

  • Preliminary budget and deadlines.


  • A large amount of documentation;

  • Not a flexible system;

  • No opportunity to return.


Scrum is a software development methodology which is based on dividing the whole process into iterations. At the end of each iteration, the team is ready to provide a product demo version. The image below provides you with the information that the team goes through all development stages simultaneously. Thus, it gives you an opportunity to have a project ready part at each iteration final.



I want to shortly explain in simple words the essence of the methodology. However, there are a lot of terms. I recommend you to learn the essence as you will definitely master the terms after a while.

All the development process is divided into sprints (2-3 weeks). There is a backlog (list of tasks) both for the whole development period and for each sprint separately. Each task has its own story point (complexity index).

Each process participant has his own role:


  • A scrum team is a team working on the project (developers, QAs, designers).

  • Scrum master is a person who cares about compliance with proper Scrum rules.

  • A product owner is a customer.

Due to the fact that this system largely focuses on communication, there are a lot of meetings:


  • Stand-up is a brief meeting, held daily. All team members take part in the meeting and each participant answers 3 questions: what did you do? What will you do? What are those aspects that slow down the process?

  • Planning is done at the beginning of the sprint and this spring determines the tasks that should be performed during the following sprint.

  • Retrospective – held at the end of the sprint and its essence – find out what was done well and what could be improved.



  • The client can monitor the result during the development process.

  • Daily control over the development process.

  • Ability to make changes during the development process.

  • Good communication with all team members.

  • A small amount of documentation.



  • Hard to estimate the efforts and the price required for the development.

  • Hard to define the narrowest points before the development.

  • The necessity to involve each into the other team members development.


Kanban is a complex system built on the performing team tasks process visualisation. The primary idea is to reduce the number of tasks that are currently being performed (in the “Doing” column). In Scrum, the team is focused on successful sprints, but in Kanban, the task takes the first place. This methodology is pretty good for those projects that are in the support stage where the main functionality has already been developed and minimal improvements and bug fixing are required.


In Kanban, all the tasks are performed individually. It means that the task goes through all the Kanban board stages. Once it is completed, it can be shown to the customer.


Kanban board consists of columns, each of which is a separate development process. Some columns (for example, in progress) impose restrictions on the number of pulls that can be there. This helps to easily and quickly find problem areas in the distribution of tasks. The picture is an example of the most just such a board. The number of columns and names may vary, I will name the most common:


Методологии разработки ПО - 4

  • To do is a list of tasks to be performed

  • In progress are those tasks that are currently in progress.

  • Code review are those tasks finished and sent for a review.

  • In testing are those tasks that are ready for testing.

  • Done are those tasks completely finished.




  • Ease of use.

  • Visibility (helps to find the narrow points).

  • High team involvedness in the process.

  • High development flexibility.



  • Unstable tasks list.

  • Hard to implement within the long-time projects.

  • Absence of strict deadlines.


In my opinion, those people who hold the managing position or want to hold it should fundamentally know the software development methodologies. At least the basics should be known by all the team members. It is an integral part of the development process and is used not only in It sphere.

Thanks for spending time to read our article, I hope it was useful for you. We tried our best to describe only the key moments as affordable and as short as possible. Thus, the article is comprehensive. We would be glad to get your feedback and answer your questions. Peace!

Leave a Comment