En el artículo anterior vimos cinco ejemplos de un Daily Scrum disfuncional. Para que no tengas que pinchar te los recuerdo aquí.
- Es un reporte
- Respondemos a las tres preguntas
- Falta gente
- No ocurre sin el Scrum Master
- Nunca hay follow-ups
Hoy quiero centrarme en soluciones que no son obvias y los motivos por los que éstas situaciones pueden estar sucediendo.
Arranquemos.
Pedagogía de Scrum
Uno de los primeros pilares en los que tiene que centrarse un Scrum Master para poder habilitar el funcionamiento de Scrum como herramienta para ser más ágiles es que las personas que participan del proceso entiendan Scrum.
No puedes esperar que quienes participan o utilizan un proceso o herramienta para hacer su trabajo la utilicen correctamente si no entienden para qué sirve.
Una de las cosas más comunes que hago nada más llegar a una organización es preguntar: ¿Para qué estamos haciendo esto? ¿Por qué nos reunimos durante 15 minutos todos los días?
Habitualmente la respuesta esconde el problema: Para reportar que hicimos ayer, para sincronizarnos, para tener al día al Product Owner.
Es entonces, y sólo entonces, cuando podemos recordar que el Daily Scrum existe para inspeccionar el progreso hacia el Sprint Goal y adaptar nuestro plan en consecuencia.
Tras esto, la reacción que podemos esperar es descubrir el motivo de fondo que lleva a que el Daily Scrum sea inefectivo. La falta de un Sprint Goal hará que no tengamos el elemento central de este evento. Que no exista un plan que seguir durante el Sprint provocará que no tengamos nada que adaptar.
Inexistencia de un producto
Scrum es un framework magnífico para desarrollar productos que tienen que lidiar con problemas complejos.
Si no tenemos un producto, una planificación, un roadmap, una estrategia y un entendimiento compartido de cual es la visión de lo que hacemos, difícilmente podremos esperar que un equipo Scrum inspeccione un Sprint Goal para adaptar su plan de trabajo de 24 horas.
De hecho, si nuestro objetivo es utilizar Scrum para entregar algo que está cerrado en fecha, coste y funcionalidad, probablemente la disfuncionalidad del proceso con el que hemos definido el trabajo (alcance, tiempo y coste) termine trasladándose inevitablemente al trabajo que hacemos diariamente.
Es en este caso cuando lo que esperamos de nuestro equipo Scrum es que sean capaces de convertir requerimientos en código -u otro producto- a la máxima velocidad posible.
¿Es esto posible? Por supuesto.
¿Es esto útlil? Existe una duda razonable.
En primer lugar hay que tener en cuenta que en el mundo en el que vivimos realmente ya no existe el concepto proyecto, entendido como algo que tiene un principio y un fin. Por tanto, intentar gestionarlo todo con esa mentalidad sólo conlleva frustración e ineficacia a largo plazo.
En segundo lugar, un Product Owner capaz de crear, fomentar y transmitir una visión en torno a un producto es un activo increíblemente valioso para cualquier organización porque habilita la estrategia de esa misma organización y la conexión entre negocio y tecnología.
Esa batalla -la de negocio y tecnología- no existe. Son dos caras de la misma moneda. Una moneda que se acuña a través de productos. Porque los productos existen, queramos o no, y es nuestro deber sacarles partido con la máxima profesionalidad posible.
Falta de skills
Superados estos dos primeros problemas profundos puede ser que todavía nos encontremos con un Daily Scrum inefectivo. Y esto puede ser debido a que las personas que forman y hacen el mismo no tienen los skills o la motivación para hacerlo funcionar.
Sorprendentemente nunca me he encontrado con un equipo obligado a hacer Scrum en el que todos los miembros del mismo estuvieran desmotivados o se negaran a llevarlo a cabo.
Puede que una o dos personas no quieran participar del juego de Scrum y es labor de un Scrum Master facilitar que se integren o facilitarles una salida, pero sinceramente éstos no han sido los casos habituales que he encontrado.
En cualquier caso, si esta es la situación hay que valorar si realmente merece la pena hacer Scrum o intentar crear un clima de trabajo y colaboración antes de seguir adelante.
Cuando pienso en los motivos que relataba la semana pasada, creo que estos tres temas tocan todos de una manera u otra.
Al final, hacer Scrum es acordar trabajar bajo unas reglas de transparencia, inspección y adaptación.
Deja una respuesta