Choosing The Optimal Development Methodologyby@maxim.savonin
254 reads

Choosing The Optimal Development Methodology

by Maxim SavoninAugust 21st, 2019
Read on Terminal Reader
Read this story w/o Javascript
tldt arrow

Too Long; Didn't Read

The list of four major Agile-based software development methodologies includes Scrum, Kanban, Lean, and XP. Each project has its own peculiarities in terms of time, costs, team, deliverables, technologies etc. Here you will find out how to choose the development methodology which would best suit your needs, resources, and interests. We have consulted our professional Project Managers as for which methodologies they use while working on different projects. Here, we compiled this ultimate project management guide.
featured image - Choosing The Optimal Development Methodology
Maxim Savonin HackerNoon profile picture

Is Scrum as universal as it seems to be?

Nowadays, it is somewhat fashionable among software developers to say that they use a Scrum framework while working on their project. Yet, is Scrum as universal as it seems to be? No, of course, it is not. Each project has its own peculiarities in terms of time, costs, team, deliverables, technologies etc. Therefore, the software development methodology should be chosen in accordance with these specific features but not because some framework is popular or sounds impressive.

We have consulted our professional Project Managers as for which methodologies they use while working on different projects. Together with them, we compiled this ultimate project management guide. Here you will find out how to choose the development methodology which would best suit your needs, resources, and interests.

Agile – Fashionable Software Development

Let us start with the Agile methodology – the most topical and popular software development approach nowadays. As the name itself 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 is necessary to be flexible in order not to undermine or postpone the project success. One of the twelve central principles of Agile is to harness change even in the late stages of the development process in order to ensure the customer's competitive advantage.

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

In Agile, the customer is involved at each development process stage, so the requirements are timely adjusted, 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 later on may be built upon. Also, having timely identified and fixed all the bugs, one may save a great deal of time and money.

Meanwhile, Agile will not work for the customers who don’t want to be engaged throughout the process of 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.

The list of four major Agile-based software development methodologies includes Scrum, Kanban, Lean, and XP. Let us have a closer look at each of those.


Scrum is a software development framework that is frequently considered to be synonymous with Agile. Yet, it is, first of all, a managerial framework. It is a model according to which developers plan their work, update their objectives, and review their progress.

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

In Scrum methodology, the product development timeframe is called Sprint, and it starts with analyzing the projected user stories. The development team has to answer the main question: as a user of this system, which functions / services / experiences / values do I want to obtain? During Sprint planning, team members collectively divide the Sprint into a few tasks, both major and minor, so that the completion of these would ensure the optimal functioning of the system.

There are two Backlogs: a General Backlog is a list of ideas for future sprints, including tasks and user stories, while the Sprint Backlog includes tasks from the general one that are assigned for the current Sprint. Every working day, the Development Team holds Daily Scrum meetings involving Product Owner and Scrum Master – a person aimed at organizing the team around certain missions and plans – where they discuss achievements of the previous day and goals for the following one.

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. At the end of each Sprint, team members conduct a Review – where they present their results to the product owner and receive feedback – and a Retrospective – during which they discuss the latest Sprint and offer improvements for the future one.


Scrum by Jeff Sutherland

Essential Scrum by Kenneth S. Rubin

The Elements of Scrum by Christopher A. Sims


Similarly to Scrum, Kanban is a software development framework based on Agile, and it focuses on teams able and willing to collaborate and to manage themselves. These enable the team to identify and eliminate potential bottlenecks even in the early stages of the development process.

The major Kanban concepts are Kanban BoardKanban Cards, and Kanban Swimlanes. As for the board, it can be both physical and digital, and it is 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) that the cards are classified into. Usually though not necessarily, these columns are titled as “To Do”, “Doing”, and “Done”.

The key principle of Kanban is to reduce waste to a minimum and to prevent unnecessary features from being developed. Making sure that the needs and interests of the customer are met via ongoing communication is another major idea of Kanban. Unlike iterative Scrum, Kanban is continuous, which makes it more suitable for the projects where the requirements may be suddenly changed or added.


Agile Project Management with Kanban by Eric Brechner Practical

Kanban by Klaus Leopold

Essential Upstream Kanban by Patrick Steyaert


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: muda, mura, and muri. Muda comprises all the activities that do not add value to the product, such as overproducing, over-processing, fixing product defects, waiting, multitasking. Mura is about planning and scheduling the development process. 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. Muri means that, 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.

To ensure that these principles are met as fast as possible, the team may develop a Minimum Viable Product (MVP), which is a rough but important draft of the final product.


Lean UX by Jeff Gothelf

The Lean Startup by Eric Ries

Running Lean by Ash Maurya

Lean Software Development by Mary and Tom Poppendieck

XP (Extreme Programming)

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 essential XP values include communication, courage, respect, simplicity, and feedback.


Extreme Programming Explained by Kent Beck

Planning Extreme Programming by Kent Beck

Any other book by Kent Beck – the inventor of the XP methodology

Yet, Agile methodologies are not 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?

Waterfall – Traditional Software Development

Waterfall is a linear software development approach, which consists of 6 major stages.

Importantly, for a new stage to start, the previous one has to be fully completed. Otherwise, there is no chance to return to any of the finished levels or to run any two of them simultaneously (with the exception of the Sashimi model.

In Waterfall, planning and designing processes are simpler and more straightforward since the customer and the development team reach an agreement on the project deliverables from the very beginning of the product development. The overall scope of work and all the expenses are known in advance, and respectively, the progress can be easily measured.

At the same time, it is very difficult, if not impossible, to collect and analyze all the project objectives and requirements and to formulate them in a manner that they will not be changed later throughout the project development process. Prototypes and MVPs might help. Testing and debugging becomes more difficult if it is done after the integration of a product. However explicit the project requirements are, the final product may not be what the customer expected unless they are involved at each stage of the project development, which is not the case with Waterfall.

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

If you are interested in other useful readings on Business Development, Productivity and Career, or Tech Tips, check out our blog.

Thank you for reading, and I sincerely hope that you found it helpful!

Thanks to Tetiana Matviiok @ KeenEthics for helping with the article.