Una cifra inicial / An initial figure

A los que se nos suele preguntar sobre las ventajas de SCRUM nos resulta a veces difícil dejar claro sus límites. Centrados como estamos en resaltar sus puntos fuertes y en ilustrar las mejoras que aporta, no debemos olvidar que SCRUM no es una solución mágica para todos los problemas que pueden sobrevenir a un equipo de desarrollo. En las propias presentaciones de SCRUM ya se menciona muchas veces que no es una bala de plata (silver bullet en inglés).

El otro día, en un curso, un alumno me preguntó varias veces sobre un problema muy habitual en el mundo de las tecnologías de la información. Qué hacer cuando se necesita determinar el coste de un proyecto que aún no ha empezado, sea porque hay que venderlo o porque nos lo pide el departamento comercial o la dirección. Proporcionar una estimación inicial del coste de un proyecto (y el compromiso que ello implica) es un tema espinoso y potencialmente muy peligroso cuando no se conoce exactamente lo que se debe realizar.

En el mundo Agile, se estima de forma iterativa y así se evita realizar todas las estimaciones al inicio del proyecto, cuando el riesgo y la incertidumbre es más alta. Porque... ¿Acaso sabemos antes de empezar un proyecto lo que se debe realizar? La respuesta es no, excepto en contadas ocasiones.

Pero, ¿Qué hacer cuando no se puede estimar de forma iterativa, cuando es imprescindible calcular esa cifra porque por ejemplo debemos hacer una oferta? ¿Cómo nos puede ayudar SCRUM en esa situación?

La respuesta no es fácil. Si se han pactado una serie de funcionalidades muy específicas que no se pueden variar y las estimaciones dadas son malas, seguiremos teniendo un problema. SCRUM no es un método de estimación, sino una metodología de desarrollo que asegura que se aporta el máximo valor al cliente a lo largo de una serie de iteraciones. En el caso de que se tenga que presentar al cliente un presupuesto cerrado, SCRUM no te ayuda a calcular el coste de la funcionalidad acordada. Ayuda a que, partiendo de ese presupuesto, se dé al cliente el máximo valor posible.

Como discutimos con mi alumno, en este caso el presupuesto es una restricción. Una restricción previa que nos determinará, por ejemplo, la duración del proyecto. A partir de dicha restricción, ofreceremos el máximo valor al cliente. Es más, gracias a la naturaleza iterativa en la que al final de cada iteración se demuestra el producto al cliente, no sólo aseguramos el máximo valor sino que el cliente puede cambiar de opinión y guiar el desarrollo.

Es importante que el cliente entienda que en ese presupuesto se pactan una serie de funcionalidades (el primer Product Backlog) y que desde el momento en que se empieza el desarrollo, puede guiar su evolución. Puesto que es el mismo cliente el que puede cambiar de opinión y sustituir funcionalidades pactadas a cambio de otras que se ha dado cuenta que son más importantes, cobra importancia que el contrato con dicho cliente permita esta forma de trabajar: un contrato Agile.

Some of us, who are often asked about the advantages of SCRUM, might have problems to identify its limits. Focused as we are in highlighting the strengths of SCRUM and illustrating its advantages, we can't forget that SCRUM is not a magic solution to all the problems that a software development team must face. Regarding this, in many presentations it is often mentioned that SCRUM is not a silver bullet.

Some days ago, in a SCRUM course, a student asked me about a common problem in our software development world. ¿What can we do when we need to determine the cost of a project which has not started yet?. For example, because we have to prepare an offer. Create an initial estimation of the cost of a project (and the commitment it represents) is a difficult matter, potentially very dangerous when people estimating are not very clear on what to develop.

In the Agile world, the estimation is done iteratively, thus avoiding doing all the estimations in the beginning of the project, when the risk and uncertainty are higher. Because... ¿Do we know exactly what we will be developing at the beginning of the project? Not many times... actually, rarely.

So, ¿What to do when this iterative estimation is not possible, when we need to provide this initial figure? ¿How does SCRUM help in that situation?

The answer is not easy. If a set of functionalities has been signed off by the customer, these functionalities cannot be changed and the initial estimations are wrong, we will still have a problem. But, starting from this restriction, SCRUM still assures that we will give the maximum value to the customer. If you give the customer a fixed-price contract, SCRUM does not help you to calculate this price. It helps in that, given this price, the customer makes the most of it.

As we discussed with my student, this budget can be seen as an initial restriction. A previous restriction that will determine, for example, the duration of the project. From this restriction, we will offer the maximum value. And, given the iterative nature of SCRUM, since you demonstrate the product to the client at the end of the iteration, the client can change his/her mind and guide development.

It is important that the customer understands that you can previously agree a set of functionalities (the first Product Backlog), but from the moment development starts, he/she can guide its evolution. In this case, it is important to have a contract that accommodates this behaviour. Regarding this, here is an excellent article about it (in Spanish): an Agile contract.