Imagine you want to order the development of an online store, service or B2B portal and choose a contractor. You have two applicants: IT companies with similar experience. Each with its own advantages: technology, team... But one of the companies claims an advantage: “We work on Agile!”
What does Agile mean to the customer: more profit? Or more trouble?
Agile is a flexible approach to software development. Here, the work is divided into a large number of small stages — sprints. A sprint can last from a week to a month, and the result of each sprint is something that the client can already work with — product increment. With this approach, it is easy for the customer to control each stage of work, and the result is maximally adapted to market requirements.
Benefits of the Agile approach
1. No paperwork
With Agile, there is no need for technical specifications, despite the fact that technical specifications often include the most important blocks for explaining the purposes of components and describes the overall plan.
Yes, sometimes a customer wants to work according to a clear technical specification, especially at the start of a project. But in practice, adjustments are inevitable: they did not sign an agreement with the system with which they wanted to integrate, but signed with another system, but they signed a different integration there. And business is generating new inputs. That is, in order to work according to the terms of reference, you have to overcome the following difficulties:
- draft and sign it very carefully. In practice, even if the customer is sure that all his requirements are described and understood as much as possible, on the second demo he will come up with the best solutions. But it will be possible to include them in the project only if a large reserve was initially included in the time estimate;
- spend budget and time developing a document, which is almost certain to be significantly adjusted;
- when making changes to the technical specifications, maintain a large layer of documentation, otherwise, the customer will not undergo an internal audit later (if the technical specification does not comply with what was implemented), and the contractor runs the risk of not receiving payment;
- don't delay writing it for many months. Large customers are often unable to approve technical specifications — approval is required with a large number of departments. Each department generates new requirements and is not interested in meeting deadlines (they have more important things to do). As a result, the specification for implementation takes a long time to develop and becomes obsolete during the development process;
- you still have to arrange regular demos, because testing all the functionality in its entirety takes a very long time, and usually there is no extra time;
- Contrary to popular belief, technical development usually does not reveal quality problems, because in agile development you add an increment of value to every sprint. And if the number of scenarios decreases over time or the cost of a sprint increases, this is one of the signs of poor quality (the worse the quality, the higher the cost of changes).
Simplicity of the contract: the agreement indicates a monthly acceptance of the amount of work in accordance with the details provided. A simpler agreement means faster approval and signing, while the document protects both the contractor and the customer equally.
The process is transparent. The customer is as involved as possible and controls every stage. No bureaucracy or delays — decisions are made quickly.
2. Moving “small steps” is cheaper and brings results faster
The product enters the market faster (in the form of an MVP), is easier to adapt to consumer needs.
Profits are always in focus. The goal is to quickly get your first profit from the MVP and increase it by better meeting customer needs.
Differences between Agile and project approach in web development
1. Product — MVP, Feedback, Improvements
Without Agile
There are planned indicators that must be strictly adhered to:
- project start date;
- project end date;
- budget.
First, the business hypothesizes what an ideal IT product should be like (an online store, a mobile application, a B2B portal...), then it is necessary to prepare a clear technical specification — the contractor will act on it. And after the contractor completes the work, the business takes the project into operation.
Even if you invited representatives from all departments to the interim demos, this won't help: only real users will start asking real questions. But the contractor is no longer interested in how the product will actually be used — it is important to ensure compliance with the technical specifications. The main thing for him is to do his part, meet the budget and deadlines.
But what if the terms of reference did not take into account any processes (and this, we emphasize, almost always happens)? During development, a more profitable substitute and an active competitor appeared on the market, and trends, exchange rates and other factors changed.
With Agile
Here, the project size is reduced to the size of a sprint. As a result of the sprint, a small amount of functionality appears that you can already use. Yes, we cannot influence the speed of programmers' work. But what Agile is definitely speeding up is the release of the minimum viable version of the product (MVP). It is possible to release an MVP on the market in 1-3 months, then start adjusting the functionality to business requirements, clarifying priorities on the go. This means that the resulting product will better meet users' expectations.
Once an MVP faces customers, we'll be able to quickly see feedback and adapt to new requirements. If it is unprofitable, we will not thoughtlessly stamp an unnecessary product, but will change it or create a new one. The same goes for every next version of the product.
In English, Agile means “agile”, “agile”, and this system itself means flexibility, mobility, and readiness for change. Improvements can be made regularly, rather than one-time, and at a lower cost. Therefore, the quality of the ready-made IT solution is maximally adapted to the customer's requirements. This is easy to track not only from reviews, but also from web analytics and usability analysis.
2. Process — transparency, quality, adaptability
Without Agile
The customer doesn't see what developers are doing exactly; a finished product that has been waiting for so long can be disappointing. If you stop the project earlier, you can be left with nothing, because you planned to get the result at the very end.
It is difficult and time-consuming to make changes to the terms of reference; you need a lot of approvals — bureaucracy. Sometimes drawing up an initial technical specification takes so much effort and time from the company that it seems impossible to redo it.
It is important for a programmer to complete the project on time, without taking into account the cost of maintaining and modifying the project later. This is a serious problem with the project approach.
With Agile
In Agile, there are no projects with deadlines; here, the product is at the forefront, and it can be improved in “small steps” as needed. But at the same time, the process is so flexible that you can stop it at any time and you will have a ready-made increment that is already working and interacting with the market.
The engineering culture is growing. We consider the movement in the project to be conditionally endless, so we will have to clear up the technical debt ourselves later. This motivates us to make the code initially beautiful and generally increases the contractor's motivation. After all, he is paid as long as it makes practical sense. And if most of the work is aimed at fighting technical debt, customer satisfaction will decrease.
At Agile, the development team is constantly in contact with the customer. Meetings are held daily. This gives us a lot of feedback that we respond to quickly. Of course, the customer does not always have the right time, in which case we send him a report to understand today's plans and the facts obtained yesterday.
3. Profits are always in focus
The main project risk is a non-return on investment. The main way to prevent this is to meet the needs of the end customer.
Without Agile
Are you ready to spend several months or even years creating a product whose profitability is questionable? Remember that the result of the classical approach will be visible only at the end.
With Agile
The team's focus is immediately focused on business goals. The more often new versions are released, the more often we get feedback from users and/or the market and do our best to increase profitability.
The return on investment and return on investment are the main thing. Agile will not allow you to spend time and thoughtlessly wasting energy (and therefore money) on unprofitable actions.
So, the main thing.
The benefits of Agile software development
The goal of the business is to make a profit. Software is often intricate systems (according to Agile methodology, they are systems with a large number of factors where the causal relationships are not clear).
For complex systems, it is more important for us to get feedback from real users faster, and at the moment we can confidently say that the development and management of any product is a complicated system. If you have clear and unambiguous tasks, it is quite possible to work according to the classical methodology: technical specifications, deadlines, and budget.
An important advantage of the Agile methodology: transparency
The customer has full control over the process, which means there will be no unpleasant surprises at the end.
Very often, corporate clients ask questions about how to deal with documentation. Its creation is integrated into sprints as a development process (there should be documentation for the task — we write) or as a fixed package of hours.
Agile principles in IT development help our clients stay ahead of the competition and remove the cream from any market. Examples of projects that were worked on using this method can be found in our portfolios.
