Este artículo pertenece a una serie de posts que hemos publicado sobre Scrum y gestión de fechas. Podéis leer el primero y el segundo. Vamos a analizar otras consideramos relacionadas con Scrum y las fechas.
¿Podemos reducir la calidad?
La calidad y cómo trabajamos con ella siempre nos deja cierto margen para el alcance. Es habitual el debate entre el Product Owner (quiero más alcance) y el Development Team (quiero más calidad). La deuda técnica la podemos gestionar de manera activa. Tratar de salir rápido y con mucha deuda nos puede generar muchos problemas.
Algunas preguntas que podemos hacernos:
- ¿Cuánto tiempo tardamos en corregir incidencias?
- ¿Cuánto dinero perdemos cuando se cae el sistema y no funciona?
- ¿Cuántas quejas de cliente tenemos que atender por errores nuestros?
- ¿Cuántas funcionalidades nuevas no podemos añadir a nuestro producto por estar atendiendo incidencias?
La respuesta a todas estas preguntas pueden hacernos pensar sobre la calidad que queremos tener en nuestro producto. Salvo en sistemas críticos como una central nuclear donde queremos una calidad total, debemos regular la cantidad de calidad que queremos.
Si tenemos datos de otros equipos de la organización, podremos tener argumentos sólidos a la hora de defender la importancia de la calidad en el desarrollo de software.
La deuda técnica nunca será cero, pero debemos de gestionarla para mantenerla en niveles bajos (azul). Si no gestionamos bien la deuda (naranja), todo el tiempo que el equipo invierte en solucionar problemas derivados de ellas, es tiempo que no invierte en nuevas funcionalidades que aporten valor a los usuarios.
Herramientas para gestionar fecha
El Product Backlog es el artefacto donde volcamos todo lo que sabemos de nuestro producto y lo que podría llegar a contener. Por su visualización en vertical, quizás no sea la mejor herramienta para poder trabajar fechas. Un artefacto que suelo utilizar con muchos equipos cuando tenemos que ver el futuro de nuestro producto es el Plan de Releases o Plan de Sprints.
Básicamente, consiste en añadir los diferentes PBIs ubicados en Sprints. Con esto, ya podemos hacernos una idea de si huele bien o no huele bien. Esta herramienta se actualiza en cada momento en el que trabajemos el alcance: Sprint Planning, Refinamiento, Sprint Review… De esta manera, podemos tomar decisiones a medida que aprendamos.
Es importante que tengamos en cuenta en esta herramienta el famoso cono de incertidumbre. El cono de incertidumbre lo que nos dice es que, cuanto más miremos al futuro más desviación tendremos sobre lo que estamos planificando. Por eso, el plan de releases puede ser peligroso si no gestionamos bien las expectativas.
Medir valor, el siguiente paso
Hemos expuesto diferentes situaciones muy centradas en las fechas. En Scrum hablamos de la entrega continua de valor. El concepto de valor es interesante que lo trabajemos además de las fechas que tengamos en la cabeza. Medir el valor y analizarlo en la Sprint Review nos puede ayudar a tomar decisiones en términos de rentabilidad o del impacto que nuestro producto está provocando. Cuando medimos el valor de un producto, centramos las decisiones en el valor del delivery generado y en esos casos la fecha pasa a ser una variable más. Podemos no cumplir una fecha y entregar mucho valor a la organización.
Para medir valor, utilizamos diferentes técnicas como Evidence Based Management que nos permite definir métricas que nos muestren el valor que genera nuestro equipo.
¿Cómo gestionáis las fechas en tu organización?
PD: Quiero dar las gracias a Coral, Laura Jiménez, Sergio del Mazo, Youssef Oufaska y Alberto Serrano por haberme ayudado a escribir este artículo, y sobretodo a trabajar este tema con mi cliente.
