Agility means flexibility

2022

Lada

Brůnová

Each project and user is unique. At Futured, we do not want to be an application factory, so we approach each project individually. If the client is open to this, we proceed in the development of the application in an agile way.

What is Agile Development

To develop agility means that the application It arises continuously. You can proceed in very small steps, when the functions: will suggest → implements → validates → will adjust→ will be joined by another.

In practice, however, it is much more common to start working on a larger unit that meets the most important needs of users and that you can test directly on them — it is called the application core aka THE MVP (Minimum Viable Product). The follow-up procedure is the same as we described: through continuous validation and modifications, additional functionalities are added to the kernel according to priority.

Thus, the resulting application may ultimately differ quite a lot from the original ideas of the submitter, but (when done correctly) covers the most important needs of the majority of users.

The main guide in which direction to go further is continuous feedback, both from the client and from the users.

The idea that we already know everything in the beginning is wrong

And this is the main reason for us to take the agile path.

For fix time fix price (FTFP) projects, the client must be able to describe exactly what product they want. But the market is constantly changingand develops, and users are demanding: they expect continuous improvement. What was good enough a year ago, it is already obsolete today.

How much does it cost

IN Agile Projects only the time actually worked is charged to the client. If the project is managed well, it can even save from the originally intended budget.

U FTFP Projects the final price, term and scope of the project are determined at the beginning of the cooperation. It sounds like a comfortable know-what-I solution, but financially isn't fair for either party. Even with a very good assignment and detailed analysis, the contractor is often unable to reveal all the details and pitfalls of the project, and as a rule, two scenarios arise:

The contractor does not want to undervalue the project, so often sets the price higher. If he manages to get the job done faster, however, he tends not to reflect this when invoicing — the client then pays for the work that did not happen.
If, on the other hand, the supplier does not estimate the price correctly and exceeds the time/capacity, he usually has two options — he will cover the costs on his own, or (and we hear this from clients quite often) he chooses the option where the client is forced to pay for more work.

Desire vs need

At Futured, we don't blindly fulfill a task — we enjoy thinking critically about it and looking for the best solutions. I think that's what real cooperation is about. Therefore, we help our clients fulfill the real needs of the project, which can sometimes be different from the original ideas and wishes with which it addresses us. However... they lead to a real goal: an app that moves the client's business and that people want to use.

Immediate feedback

At the core of agile cooperation is intensive communication with the client, who, in addition to the project manager, regularly meets with designers and specific developers, so he can translate business plans into a technically feasible form, and possibly be inspired by our experience.

How it practically works

The client is part of our Slack (or other tool that allows us to communicate as if we were working in an office), where he can add his questions or requests immediately. More conceptual debates then take place in the form of online meetings. But we also meet in person, we like to take a trip to Vienna or Lausanne to get to know the clients from another side.

The frequency and form of meetings is based on the client's need and interest, but generally we like to see each other at least once every two weeks.

Disadvantages of Agile Development

A certain degree of uncertainty brings discomfort: I don't know for the crown exactly how much it will cost. I don't know what exactly the result will look like... Applications (and software in general) but not rEady made solutions. It is precisely its perfect adaptation to the needs of users that is the unique value that agile development makes possible.

The FTFP variant may seem attractive to the client — he knows the budget and the application delivery date. As a rule, soon after the start of development, it is discovered that the market or the needs of the client/users are changing. FTFP projects then often end up with the client getting something they “don't need”.

The first agile project? Three tips to feel comfortable in it

Get feedback from another client on the agency.
Start small (MVP) and test yourself if the chemistry works and you have a good feeling about the assembled team. So good that you entrust him with an important part of your business.
If you are afraid that the application will be significantly more expensive than you intended in the introduction, do not be afraid to define the budget ceiling. You want to keep track of how much of it is already spent/how much money is left.

When to say NO to Agile Development

At Futured, we believe that if expectations are clearly set, agile development is the right solution for both parties. But its use is more problematic, for example, for government contracts that have a final price. But even there, part of the budget can be left for functionalities that crystallize during the development of the application foundation, thus leaving your hands free.

Case study: Agile (together) working on DECATHLON applications

Using the example of the DECATHLON client, for whom we have been developing several applications, we will outline how agile cooperation can look in practice.

As an introduction, it is important to remember that each client and project is unique, so do not take this example as a manual. Reality is much more colorful and plastic. That's what agile is all about: flexibility.

DECATHLON Click & Collect

You leave for an adventurous holiday and the forecast reports rain. You need a raincoat, but you don't want to run around the shops unnecessarily. And there is little time left for delivery from the eshop...

The solution can be a combination of both: You choose the goods at the e-shop and pick them up at the store in an hour. When you arrive at the branch, the attendant clicks on the tablet several times and knows exactly what package to hand over to you, including whether it has already been paid or not. But the application will help even with more complex situations of returning goods to the warehouse.

This is exactly the kind of app we have developed for DECATHLON. And we continue to improve it.

What Agile Collaboration With Decathlon Looks Like

The Decathlon team approached us with an idea for an application for which they had a defined monthly budget. The subsequent creation of a specific assignment was carried out in close cooperation with us.

In the initial (most intensive) phase of the project, we took over the client's idea, which also included the requirements of the store staff, and our design team prepared hand in hand with the developers the optimal way to implement them, so that the use was intuitive for the salespeople and the development was not unnecessarily complicated and expensive.

After each addition of new functionality or changes, the DECATHLON IT department collected feedback from the staff at the stores, and combined the comments with us into a new assignment.

So we didn't waste our time on something that potentially no one needs.

Instead, we focused on meeting the needs and removing barriers of specific people who work with or will work with the app.

Although the foundation of the application has been done for more than a year, we are still working with the Decathlon team to develop additional functionalities that simplify the work of salespeople. You can now pay, change the price, or return the order to the central warehouse directly in the application. And DECATHLON has big plans for the future with her.

The collaboration takes place organically and seamlessly.

The client is part of our Slack, so in case of a new question or need, he simply writes a message to a common channel, where he will be contacted either by the project manager or directly by the developer. For larger requests, we arrange an online call, where we specify everything and ask for “details”. Then we estimate the time required and after the calculation is agreed, we get to work.

So cooperation is very flexible for both sides.

‍