In traditional contracts applied to software development the risk is that between the supplier and the customer the exchange value isn't fair: Agile contracts change the cards in play.
A few months ago in this article I was talking about how apps that you use avery day are made. In it I also I listed some software development methods that are now considered almost obsolete, explaining generally how the Agile methodology, the one we use at DevInterface, works. This methodology, in comparison to others, comes from a whole new mentality and aims to bring value to people, thanks to a relationship of complete trust between supplier and customer.
The new way of working has brought with it some needs which are not only about the different organization of tasks, but also about the key instrument that governs the relationship between supplier and customer: the contract.
In traditional contracts, prices and times for the realization of an application were defined firstly, and this caused several disadvantages for both parties involved: from developers side could happen that a certain function requires more time than expected to be implemented ( and they were then paid for 10 hours of work when instead it took 20); also the risk concerned the supplier since the customer paid only for completed application and sometimes only if it met what they had agreed many months before. Unfortunately, doing like this, made easy to lose sight of what the customer really wanted because the interactions and comparisons were very few, so he came to the creation of the following type:
- win-lose: win for the customer which obtained a software whit the caaracteristics that he wanted, but lose for the developer that had worked the double earning less than what he really deserved;
- lose-win: lose for the customer that came up with a useless software but he still had to pay for it, win for the developer that received the payment;
- lose-lose: useless software for the customer that didn't pay the developer which had been working months for nothing per il cliente che non pagava e produttore che aveva lavorato gratis per mesi.
This does not agree at all with the Agile development, therefore it had to be created an alternative way to define contracts, in line with the goal of building value for people: a win-win situation, where both supplier and customer gain greater advantage in a climate of complete cooperation, mutual trust and thus exchange value.
In which way?
While the traditional contract was seen as a way to protect itself from any failures of the other side, the Agile contract is a tool that allows the parts to come meet each other, according to the needs of each. The developer needs to first understand in depth the objectives of the customer to hand over an application in line with them; also it must have time to build this app. In turn, the client needs to "touch" the product to maintain high confidence in the developer and of course to see if it is following the right path. As we have said in several articles, the Agile software development is characterized by work sessions more or less long (sprints), followed by release of portions of working software, and regular interactions with the customer who can give its feedback on the work during construction. The developer has the opportunity to understand the deep desire of the customer, and the customer can understand how it's progressing the development of the app.
Replacing the traditional contract where they establish early deadlines and prices, we have an Agile contract where the customer pays a portion of working software at the end of each sprint. In this way the risks outlined above are minimized, because:
- it is unlikely that the developer is not able to meet deadlines, because of having the restricted time windows will be easier to calculate the time it takes to perform a specific task;
- If the customer sees that the development is not going as he wished, he may inform the developer that will easily fix the problems identified;
- if the customer does not pay, the supplier will only lose the money agreed for a sprint, decreasing exponentially the risk; in this way the customer will also be encouraged to pay the sum because otherwise the development of the software in question wouldn't continue.
This approach helps to limit the failures of the parts involved in the contract and to minimize the risks for both, encouraging instead mutual trust.
What do you think about this contract mode? Do you think that there are better ways to negotiate a sfotware development agreement? Let us know in the comment section below!
Thanks for reading the article.
For further informations contact us here or on Facebook or Twitter, where you can follow us to keep updated with our articles.
.jpg)
