When you come across the need to hire a custom software development company, you might have plenty of questions regarding its workflows. One of them can be related to development methodologies: how will your team approach the delivery process? Such terms as ‘agile’ and ‘scrum’ have become buzzwords in the IT world, but what do they mean, how are they related to software projects, and anything else? So let’s straighten it out.
What is a software development methodology?
Every project involves several traditional stages: they are common for every development process. The set of these stages is also called the software development lifecycle. Here is how it usually looks for creating a brand new product from scratch:
- Planning: the stage where you prepare an action plan, consider all information for the future product, simply put, thinking over the idea.
- Analysis: this stage puts you closer to the development phase. It involves creating specific requirements and planning how much time and money you will need to proceed.
- Design: it’s all about how the product will look and work. On this stage, the development team decides user interfaces, architecture, app features, etc.
- Development: now that you know all system specifications and have a complete design idea, you can start coding. After this stage is over, the product must be ready to use, but it’s not the end yet.
- Testing: before you release your software, you need to make sure it works perfectly fine, so the testing stage is responsible for finding all major and minor bugs and fixing them.
- Maintenance: the app is successfully released! Still, every software needs regular updates, so this post-release stage remains for the rest of the app’s existence.
These stages might seem a very straightforward development plan: a team can simply perform the tasks step by step and thus develop a ready product. However, the process might turn out to be much more complicated. For instance, sometimes, you need to get back to a previous stage or proceed with two steps simultaneously. Thus, every team requires a particular methodology to organize the process conveniently for both product owners and developers.
Traditionally, software development methodologies are divided into agile and waterfall. The main difference between these two types is the level of flexibility. Let’s look at each of the types in more detail.
The waterfall methodology came to the software development industry from construction and manufacturing industries: it does remind of a house building. When you need to construct a building, you need to create a building design, lay the groundwork, erect walls, etc. In the end, you have a house, ready to live in. The waterfall development model works the same: it is a rigid sequence of steps. You don’t jump to the next step until the previous one is done and don’t usually turn back to the earlier phase after it was finished.
Here is a simplified scheme that vividly shows how it works:
Planning -> Analysis -> Design -> Development -> Testing -> Maintenance -> Ready software
When to use the waterfall methodology?
The waterfall software development methodology has faced much criticism lately. Statistics show, Agile models are used by 44% of companies today, and many think that the Waterfall is becoming a kind of an atavism nowadays. However, it didn’t go away, and, what is more, it has a range of indisputable advantages:
- The project has strict and well-managed deadlines and a fixed budget;
- The project involves detailed documentation for each phase;
- Step-by-step development helps minimize budget variance and delays;
- A product owner and a development team have a clear-cut idea of the final result.
What can go wrong, then? Almost nothing, if the team is working on projects that:
- have precise technical requirements;
- don’t imply any changes arising during the development process;
- migrate to another platform, e.g., remain the same.
However, suppose you need to create an MVP (e.g., the minimum viable product — an app with only the core features) for a startup. If you are not the most tech-savvy person, you most likely have just a vague idea of how your future app or website will look and function. Besides, the primary purpose of the MVP is to collect feedback from your prospective customers and change some features or add new ones according to their actual demand. In other words, you don’t have precise technical requirements, and your product does imply changes. Here is when agile comes to the stage.
Agile combines a group of software development methodologies based on an iterative approach. Unlike the waterfall model, Agile implies breaking the whole process into short increments, allowing making changes almost on the go.
Agile is not, strictly speaking, a methodology: it is more about the overall approach and a set of principles. Here are the four fundamental values and 12 principles of the Agile Manifesto, published by software developers in 2001:
- Individuals and interactions over processes and tools;
- Working software over comprehensive documentation;
- Customer collaboration over contract negotiation;
- Responding to change over following a plan.
- Satisfying customers through early and continuous delivery of valuable work;
- Breaking considerable work down into smaller tasks that can be completed quickly;
- Recognizing that the best work emerges from self-organized teams;
- Providing motivated individuals with the environment and support they need and trust them to get the job done;
- Creating processes that promote sustainable efforts;
- Maintaining a constant pace for completed work;
- Welcoming changing requirements, even late in a project;
- Assembling the project team and business owners daily throughout the project;
- Having the team reflect at regular intervals on becoming more effective, then tuning and adjusting behavior accordingly;
- Measuring progress by the amount of completed work;
- Continually seeking excellence;
- Harnessing change for a competitive advantage.
You can read more about Agile teams in our dedicated article.
In short, Agile is about a flexible and customer-focused approach that puts people and communication between them in the first place. Let’s now discuss how these work on the examples of the four most widespread agile-based methodologies.
Scrum is one of the top popular agile software development methodologies, and it became almost a synonym to the Agile term. Here are the basics of Scrum:
- Sprints. The team works in short iterations: they are called sprints in Scrum. Every sprint doesn’t exceed four weeks. Most modern development teams prefer 2-week sprints.
- Sprint Planning Meetings. Before every sprint, a team determines a goal and plans what it must do with Daily Meetings. The team gathers for fifteen minutes every day to discuss current tasks or issues that may prevent them from success.
- Sprint Retrospective. The team meets to discuss the sprint results, things that went wrong, and what, on the contrary, was done perfectly. It helps understand what a team needs to change to be more productive during the next sprint.
- Small teams. A Scrum team doesn’t usually exceed nine members. They have wide expertise in various development areas, which makes the team interchangeable.
- Self-management. Scrum teams don’t have a manager in a traditional sense: instead, there is a Scrum-master role. Scrum Master doesn’t rule the team members but ensures that everyone understands current tasks and work in harmony.
- Precise team roles.
Unlike the waterfall model, Scrum development implies that the sprint result is a ready-to-use product: for instance, a part of an app that a startup can already show to an investor. Working in sprints prevents both sides from disappointing: a client gets a readily visible result that they can test and estimate.
The main advantage of the Kanban methodology is transparency and visualization of every single development stage. Visualization is where Kanban starts: all processes are fixed at a special Kanban board with stickers or tickets. It can be a standard wall-mounted board, but digital ones are more common among IT teams: plenty of Kanban board solutions like Trello, Asana, or Jira.
A Kanban board usually has three basic columns:
- To Do: all tasks that need to be done; all of them are sorted by priority;
- In Progress: what tasks are being done now and who is responsible for them;
- Done: finished tasks.
There might be more columns, of course, depending on a project's nature, but the main point always remains the same: everyone is aware of what is going on and sees the scope of work.
Unlike Scrum, Kanban implies shorter iterations: while a team must complete a particular set of tasks within two weeks in Scrum, new tasks and updates can arise daily in Kanban. Although Kanban boards help prioritize tasks, this priority can change every time you need it. It allows even bigger agility than Scrum, quicker delivery, and thus closer communication and better understanding with a client.
Many teams combine Scrum and Kanban, using Kanban boards for planning Scrum sprints.
Extreme programming (XP)
Extreme programming has much in common with Scrum: it also implies working in short sprints from two to four weeks and teams of up to ten people. However, this methodology is more about practices than working principles. In other words, if Scrum suggests how a team should organize its workflows, XP answers the ‘What to do’ questions. Here are some basic XP practices:
- Planning Game. This practice is what exactly makes XP an agile methodology, and it’s about quick planning of releases. In XP, developers always work together with a client. The client provides the team with their wishes regarding the product-like app features and fixes them on paper or digital cards. These wishes are called customer stories, and it helps developers develop a working plan. In simple words, a customer is responsible for ideas, and a team takes care of solutions.
- Pair Programming. Pair programming is as straightforward as it sounds: the code is created by two developers. One of them works on the principle, while another revises it, following the process. As a result, programmers avoid crucial mistakes, and every team member is well-versed in how the whole system works: the pairs are not fixed, and, on the contrary, team members constantly shuffle.
- Small releases. XP methodology suggests that new product versions must be released as often as possible.
- Simple design. Like most agile methodologies, XP implies that you don’t know all details of the final product, and tasks may change within the development process. It becomes possible with the simple design practice: when developers focus on the basics and avoid complicated solutions.
- Test-driven development. In XP, developers write automated unit tests before they write the code. The code shouldn’t pass the test: otherwise, it means that you test something that already exists, or the test itself is irrelevant. The next step is to create a new code that will pass the test by any means. When it’s ready, a team can proceed with refactoring.
- Refactoring. Extreme programming strives to keep it simple, remember? The refactoring practice implies simplifying the code and making it easy to understand.
SAFe: Scaled Agile framework
SAFe is a relatively new framework, and it combines principles from agile and waterfall software development methodologies. It’s mainly used for large projects when a single Scrum team is insufficient.
The SAFe structure is pretty complicated as it’s used for large projects: the whole team size may reach 100 members or more. The system consists of several SCRUM teams of nine people working in Program Increments (5 sprints). This structure of several teams is called Agile Release Trains, managed by a Product Manager, a Software Architect, and a SAFe Release Train Engineer.
SAFe can use Kanban practices, too, but overall, it’s a methodology allowing to scale SCRUM approach and combine more professionals without extending a minimum team size, suggested by SCRUM.
We at Geomotiv managed to adopt the best principles of Agile: it allows us to stay transparent for our clients and deliver the products they exactly want to see.
An agile approach to software development presupposes using practices and methods bui...
If you are interested in getting a high-quality product, you should be aware...
MVP (or a minimum viable product) is a product with a minimum set...
In simple words, scalability shows how easily your product can grow and change...
Let's overview the biggest tech trends. They will probably be adopted by most...
Monolithic apps seem to lose their popularity in contrast to microservices, which all...