Andábamos dándole vueltas a cómo desarrollar una política de precios adecuada a una agencia de desarrollo web con una estructura de trabajo basada en Scrum Methodology. Y de pronto nos hemos encontrado con este pedazo de artículo, A Fair Pricing Model for Agile Software Development Contracting de The Ruhr Institute for Software Technology, University of Duisburg-Essen en 2012.
“The recognized lack of helpfulness of complete up-front system specifications has led to the rise of agile development methods such as Scrum, where voluminous specifications are replaced by quick iteration cycles. At first sight, the continuous refinement of prototypes in tight collaboration of users and developers seems like an ideal solution to the difficulty of specifying a complete system beforehand. While the model lends itself naturally to in-house projects, clients and service providers have however found it hard to transfer to the commercial domain:
For an agile project, it is virtually impossible to set a fixed price — since the project scope and the required solutions materialize only gradually, and prototyping implies performing a considerable amount of work that does not make it into the final project, but is discarded, the actual effort is hardly foreseeable. A fixed-price contract would thus expose the service provider to the complete project risk, while the client is tempted to keep adding bells and whistles along the way at no additional cost.
On the other hand, running agile projects on pure time and materials contracts is equally undesirable: While these seem more fair at first sight (since the payment corresponds exactly to the work done), they actually incentivize service providers to blow up the development effort and neglect quality control at the client’s expense. The project risk thus lies fully with the client.
Again, neither situation is satisfactory for both parties. It would therefore be desirable to find a contracting model that has a built-in risk limitation mechanism for the service provider, and a built-in cost limitation mechanism for the client.”