Why is it better to launch the basic product (MVP) than to improve it endlessly. Agile approach.

Read the article and learn how agile supports building digital products starting from basics and why it’s so important in software development.

Where did the need for agile come from? The reasons vary, but one of them is to make the process of building digital products logical, and thus more efficient.

Agile way of thinking, its frameworks, events and all principles, we incorporate into our work schedule, are aimed to help us reach our goals. The decision to rely on them is based on the fact that agile practices guard the project, by making sure that it follows the proper structure. The way agile shapes the process has been recognized (what has been empirically tested) as the most effective in software development. 

That’s why we pay attention to follow the agile rules. We believe in their efficiency. 

Why are software projects not about creating an ideal product? 

Agile supports the process of creating software products in many ways. One of the most important aspects regards prioritization in order to deliver value with the product. It means that the main project goal is to build working software that has a strong base in the form of quality core functionalities that are useful for users. This is the minimum the software has to offer to increase the chances of being successful and fitting into the market. In other words, the first and crucial goal of software development is to launch a product that is a solid proposition for the consumer. If this base objective is reached then the product can be improved and polished with additional features. But first, a solid base is a minimum to achieve.

Building perfect, have-it-all products as an initial goal is not a sensible approach to building software products. Why?

Firstly, it is too risky. A full product (the one packed with features) is expensive and time-consuming to build. If later it turns out that such an ideal product does not meet the requirements of the market (which can happen for various reasons), it means wasted money and time resources.

As already mentioned, Agile makes sure (through its practices and tools) that the product has value – for the user and the business. This is all to minimize the risk of missing the market.

However, it happens that sometimes despite the work on value, the product does not hit the market. Reasons for that may vary:

• external factors, 
• bad competition analysis, 
• wrong value prioritization, 
• little knowledge about the user or undefined important business value

Software development is a complicated and generally complex process. And if something may go wrong, it’s always better not to spend all the budget. This way, the conclusions after the launch can be drawn, and the product can be improved. By delivering a first version of the product positioned on the most important values ​​only, we can produce a product cheaper, observe how the market reacts to it and then improve it.

Let’s take as an example the situation when building a bike with a limited budget and wanting to profit from its sale as quickly as possible. It is much better to build the bike core first – wheels, frame, and spinning wheel, and not start with colorful and ultra-light fenders. You must be aware of what is most important in the product (without which it will not work), to be assured you have enough money to build the core. Therefore, it’s more logical to build a solid bike and start selling it, and out of the profits, produce another improved series with colored and lightweight fenders.

An assertive approach to clients’ ideas 

Patience and order based on planned and logical actions are the basis for delivering good software products. That is why, willingly or not, we need to work assertively with the client’s ideas that often arise unexpectedly during the project.

Aiming to deliver quality and valuable software products, we rely on the path the agile set with its frameworks and principles. This is the reason we won’t be eager to change the course if it will disturb the logic of the process.

First of all, we want to have the product’s core delivered. If it is done, then we can start creating the additional and nice-to-have elements. How does this relate to the real-life example? When being in the middle of building the core functionalities that bring real value, we won’t stop the process in order to deliver an additional element the client requires to have straight away. Our experience and tested frameworks we use to develop solutions, lead us on a different path. It clearly states two things: elements prioritized as core must be produced first + one thing at a time.

Of course, agile is about embracing change. It means that we can sit with the client and refine priorities. If they will change, and we all agree on seeing that as sensible, we will proceed from the next iteration with new priorities leading the work. These rules, although they may seem inconvenient to the client, take care of the product. They set the most important goals that must be achieved in the first place.

A good software product needs a client on a board

Our experience clearly shows us that it is better for the project if the client actively participates in the process. It’s a good thing for a few reasons. First of all, the client knows about the business and the users the most. The client is familiar with the context and the competitors’ products. The client is the resource of requirements, the whole team talks through and prioritizes. Therefore, the engaged stakeholder is a great boost for the project to succeed. The quality software product simply needs its owner to be aside when the product is born.

The other important aspect, however, is that the development team is the entity that brings the ideas (requirements) to life (to physical product). They are experienced, they know the process, the methodology, the technology, and all that is needed to build a product. That is why the best project teams consist of experts and clients.

The smooth collaboration between them relies on transparent (and frequent) communication and reliability between the two sides. If the team claims the increment will be delivered or tested the following day, it should be. If the client has made a commitment to give feedback in one day, it should happen. To make the whole process of software development stable, a lot of elements have to match. Without the client’s feedback, the team doesn’t know what to improve and how to plan the work. That is why regular communications and meetings are needed to be with all parties involved.

The software project needs a client also to cope with the change. If the priorities change the team has to know and understand the situation to shift gears. For this, the project needs communication based on transparency, as the consequences of the change must be clearly stated. Each change affects other elements that are already in progress or planned. Doing new things delays (or eliminates) others, so again, the most important thing is not to lose sight of the core – the most important elements that must be created. 

Agile frameworks help to succeed. How?

Agile is equipped with frameworks that allow the development team to deliver a software product with value, by providing an effective workflow that brings order into the process. The most popular frameworks are scrum and kanban. Their routine can be alternately reused, depending on the needs. Scrum, for example, is very good for delivering new products. Kanban, in turn, is a great tool to provide maintenance within one project or to deal with various tasks coming from different projects. 

Agile frameworks are useful methods worked out by industry experts to provide the best software. Still, frameworks alone are not enough to achieve the goal. The primary supporting factor needed to make this happen is the environment based on trust, collaboration, and transparency. One thing cannot exist without the other.

Frameworks’ practices that work for us 

Scrum and kanban, both of them, offer many useful practices assisting in delivery quality software. Some of them appear in both frameworks, and some are specific to one way of working only. However, as already mentioned, development teams working in agile can combine methods from different frameworks. The idea is to adapt the most beneficial tools that make the team’s work easier and help to deliver the best product possible. For us, the most important practices are:

Limited WIP (Scrum and Kanban)

Work in progress defines the amount of work the team does at once. Too many open tasks, the greater the chance of not finishing them or reducing their quality. The healthiest direction is: we do one thing first, finish it, evaluate the results, and then move on to the next.

Meetings (Scrum)

It may seem that software development is mainly about coding, but that’s not entirely true. To code well, the team needs to know what, why, and what are the risks. That is why the meetings are so important, including daily meetings but also these one summarizing sprints. Without discussing the work, we cannot draw conclusions, without conclusions it is difficult to improve results. Additionally, meetings are truly valuable with the client involved. This is where the vicious circle may begin: no stakeholder at the meetings, no feedback. Lack of feedback means a lack of conclusions, and this results in a stalemate in adjustments.

Backlog prioritization (Scrum and Kanban)

A quality backlog is the result of the cooperation between the client and the team (mostly the product owner). It’s a base with requirements defined from the users’ perspective. Each requirement has to have value behind it, so it will be easier to prioritize them (or as it is in Kanban to classify them) and plan the work. The priorities (classification) can change. However, they must be re-discussed and understandable, and the consequences of changes in priorities clearly presented – the new priority means that another thing awaits.

Summary thoughts

It is significant for us that our clients understand why we work the way we work, and therefore we try to educate and explain the process and work with a change. We want clients to understand that it is not possible to build a good software product, constantly changing a project’s scope and adding new elements without delaying others. Such practices increase project risk, increase time, and expand budget.

Our aim is to build the best possible products that help clients to succeed, which is why we rely on proven agile methods. To make this happen we need clients on our team. It means that we want to cooperate with clients, discuss, and understand what they need. Our priority, however, is always to have a solid foundation as a target – a product with a value to be able to safely bring to the market. Observing the product – how it is doing on the market, and then responding to new emerging needs and introducing improvements is another task that we love, and are ready for.