La velocidad es uno de los temas de Scrum más discutidos online y offline. Sólo hace falta acercarse a la comunidad de Scrum Masters en Facebook para comprobar como muchas de las cuestiones planteadas están en la linea de la velocidad de entrega de los equipos de desarrollo de Software.
En muchas compañías, existen sofisticados métodos de estimación basados en la velocidad y yo mismo he tenido la oportunidad de usar -y odiar- hojas de excel que hacen estimaciones basadas en Puntos de Historia de usuario para intentar manejar la incertidumbre.
Es tal la obsesión que muchas organizaciones y Scrum Masters jóvenes hacen de la velocidad su arma de trabajo. Contar Story Points. Hacer proyecciones. Aleccionar al equipo a cumplir sus compromisos y a esforzarse más.
Sin embargo, leyendo la guía de Scrum, no hay ningún sitio donde se hable de velocidad. Concretamente, en Scrum se habla de estimar los PBIs (Product Backlog Items) como parte del proceso para refinarlos y que estén listos.
Es la asignación de Puntos de Historia junto con el popular planning póquer y la obsesión insana por evitar cualquier tipo de riesgo lo que lleva a las organizaciones que usan Scrum a hacer todo este trabajo de presión y previsión que es, en la mayoría de los casos, inútil.
El motivo por el que estimamos en Scrum es simple: El desarrollo de Software es complejo, e incluir a muchas personas en crear una pieza de algo complejo, añade más complejidad todavía. Las estimaciones son una herramienta para facilitar una conversación.
Uno de los miembros de mi equipo de desarrollo considera que un ítem conlleva 2 puntos y otro considera que conlleva 12. Parece claro que uno de los dos se está perdiendo algo. Quizás el primero no esté considerando todos los aspectos contenidos en la Definition of Done. O por el contrario, el segundo puede estar obviando una solución mucho más simple que la que tenía en mente. Esta estimación nos ha facilitado una conversación.
En Scrum no importa la velocidad. Lo que importa es entregar software terminado al final de cada Sprint. Y poner ese Software enfrente del cliente lo más tempranamente posible. Esos datos, junto con algunas herramientas, nos pueden dar una fiabilidad bastante buena de nuestra predicibilidad para los próximos meses. Los puntos de historia no. Las estimaciones no. Estos solamente son herramientas para tener una conversación.
Un buen punto de partida es echarle un vistazo a la guía de #NoEstimates que contiene múltiples enlaces a técnicas alternativas de previsión de entrega que están al margen de puntos de historia. En Kanban, también utilizamos herramientas estadísticas como las simulaciones de Montecarlo que nos dan un nivel de fiabilidad bastante bueno sobre la capacidad de cumplir fechas y compromisos.
Para esto hacen falta datos. Intentar estimar sin tener al menos tres o cuatro medidas (Sprints terminados) es simplemente una locura. Dependiendo del modelo estadístico que utilicemos necesitaremos entre tres y veinte medidas para poder dar una previsión con un alto nivel de fiabilidad.
Un problema nuevo
Esto nos lleva a un problema nuevo. Necesitamos datos fiables y en mi experiencia, lo que los equipos de desarrollo entregan en muchas organizaciones es simplemente cero. Nada. Desde no completar los requerimientos funcionales hasta no cumplir los requerimientos de puesta en producción.
Es por eso que antes de empezar a pensar en velocidad, tenemos que cumplir Scrum e introducir cuantas prácticas de ingeniería sean necesarias para así poder tener estimaciones fiables.
Quizás el principal problema es que cuando enfrentamos a los que toman decisiones en las organizaciones con la realidad de los datos de sus equipos, no quieren admitir que el problema no es la velocidad, sino que el Software que se desarrolla no cumple, ni ha cumplido nunca, un estándar de calidad para ponerlo en producción.
A pesar de todos nuestros Scrum Masters, Estimaciones, Project Managers y compañía, en realidad nunca hemos dejado de hacer Software como si de hacer un puente se tratase.
Es mucho más fácil hacer estimaciones a ojo y llamar a esa información velocidad. Pero eso no es Scrum. Porque en Scrum la velocidad no importa. Importa el software terminado.