When it comes to starting a software development project there are two main topics people worry about. The first one is always about costs, and the second about how long will it take to develop the product.
It is natural to be worried: suddenly you need to assign a budget to a new provider you don’t know. You will be signing a contract without getting anything tangible in return. The only tool to lower levels of uncertainty is to ask for an estimation of the project.
The problem is that large estimations can be a double-edged sword; there’s a high probability of being wrong. Lots of factors might interfere when it comes of making an accurate estimation. For instance, the requirements might be incomplete at the beginning of the project or you may be forced to change them during the development process. Don’t get me wrong, making an estimation is really important, but tiding tightly to an initial one could produce friction to both sides of the engagement and make it fail.
Here at this stage is when the Agile Engagement begins shinning and showing its advantages. Companies get a virtual team in a time/material approach. The team develops the product using the Agile framework: a backlog is created with the list of all the requirements. Then the work is divided into sprints that usually last a few weeks. Estimations are done with a planning poker session at the beginning of each sprint and then the teams take a portion of the user stories and analyze them in detail. At the end of each sprint, a piece of working software is delivered.
In this kind of engagement you have to resign total certainty, because almost any estimation can change in little or big amount. However, the “Agile” key is that each estimation is based only on the portion of the product to be delivered in the next few weeks. This way, the impact of any possible mistake is reduced enormously.
It’s just as the Salami technique used for Negotiation. The principle of this tactic is to divide a big goal by “slicing” it into smaller goals. But in this case both parts are aware of the strategy. Agile engagement enables to build trust step by step; companies can step back any time if they are not satisfied. And, in case they do, they will have functional software in their hands anyway.
Personally, I’m an Agile fan like many of my colleagues. I’m sure their reason it’s the same as mine: we all want to work in projects that achieve success. And, basically, that’s what Agile does, it benefits not only stakeholders but also the client and the development & QA team. I encourage you to give it a try and rely on it to experience a really enjoyable software development cycle.