Hace unas semanas tuvimos la oportunidad de escribir sobre la toma de requisitos en Scrum. Esther y yo estuvimos debatiendo mucho sobre este artículo que, de hecho, ahora es totalmente diferente al que escribimos originalmente. En paralelo, nuestro amigo Youssef Oufaska hizo el siguiente vídeo hablando del Definiton of Ready (DoR) y el Refinamiento.
You asegura que el Definition of Ready no haría falta porque ya tenemos el Refinamiento, que nos facilita una conversación en torno a lo que necesitamos tener para que un ítem entre en el Sprint. Si el refinamiento ya nos permite tener esa conversación, ¿para qué queremos tener un Definition of Ready que podría provocar que no conversáramos?
¡Conversaciones!
Esto me recuerda al libro de Mike Cohn, titulado User Story Applied. En este libro, Mike Cohn insistía en que lo más importante de una Historia de Usuario o User Story es la conversación: sin conversación, no hay user story. Si lo pensamos, puede tener sentido, porque si simplemente cogemos el análisis funcional, lo troceamos y lo ponemos con un formato centrado en el usuario y el valor, realmente tendría los mismos problemas que se presentaban en un análisis tradicional: confusiones, cambios continuos, falta de aclaraciones, interpretaciones etc.
El motivo es que no se garantiza un éxito porque usemos una plantilla diferente. Una gran diferencia entre una historia de usuario y lo que hemos hecho siempre es que debe ser negociable lo que significa que podemos conversar sobre ella y modificarla. Esta diferencia es importante, nos proporciona un cambio de paradigma: no estamos aquí para hacer software escrito en el formato como-quiero-para, estamos aquí para hacer software con valor, software que sirva para algo y que un usuario quiera. Por eso, tenemos que tener una conversación, pero no solo para aclarar el requisito, sino para estudiar la mejor manera de resolver una necesidad o un problema. Y esto implica que ¡Hay que involucrar a los desarrolladores en la creación de valor!
Los eventos son ventanas de oportunidad
Todo esto me ha recordado la importancia de los eventos en Scrum. En muchas organizaciones son mal-llamados “ceremonias”. El nombre ceremonia me transmite la idea de que, siguiendo unos pasos concretos, una receta mágica, obtendremos unos grandes resultados: ¡error! Los eventos son ventanas de tiempo que les damos al Scrum Team para que pueda realizar una acción concreta (foco). La Sprint Planning es una ventana para organizarnos, no para estimar. Es una oportunidad para inspeccionar sobre el Product Backlog, nuestro progreso y capacidad, el Definition of Done y las acciones de las retrospectiva. Con todo esto y una conversación (larga), obtenemos un plan (Sprint Backlog), un objetivo y una previsión que nos permiten organizarnos durante los próximos días.
La Daily Scrum es otra oportunidad para conversar sobre lo que hemos terminado, cómo vamos respecto al Sprint Goal y cómo nos vamos a organizar las próximas 24 horas para avanzar hacia los retos que tenemos por delante. Un consejo, si en una Daily Scrum se invierte más tiempo en hablar de lo que se hizo ayer que en lo que se va a hacer hoy, algo no funciona. Esto suele ser síntoma de que estamos reportando por encima de adaptarnos, que debe ser el tema principal en esa conversación que debemos tener en la Daily Scrum.
Durante la Sprint Review es donde se ve la gran diferencia. Una vez más, es una ventana que nos proporciona Scrum para tener conversaciones. Como vimos hace tiempo, los equipos menos maduros hablarán sobre el avance del proyecto, sobre el software terminado y sobre validar las partes terminadas. Realmente, Scrum propone que inspeccionemos y adaptemos sobre el propio producto y su impacto en el mercado: ¿alguien quiere lo que acabamos de terminar?, ¿cómo ayudan estas features a nuestros usuarios?… Esta oportunidad es clave, porque, si estamos fallando, la Sprint Review nos permite adaptar nuestra estrategia y nuestros esfuerzos para que el software sea el mejor posible.
Y por último, y no menos importante, la Sprint Retrospective. Hoy en día observo que los equipos se toman muy en serio el evento, inspeccionar y adaptarse para buscar hacer las cosas mejor. El problema, es que muchas veces lo que se ha trabajado en la Sprint Retrospective no se refleja en un cambio real, los equipos mantienen sus vicios y comportamientos. El mejor consejo es que no intentamos arreglar el mundo en una sola Retrospectiva. Con una mejora pequeña pero que la llevemos a cabo, ya estamos cambiando y ello nos permite inspeccionar y adaptar.
¿Cuál es el papel del Scrum Master en todo esto?
Explicando la teoría todo parezca muy bonito. Sin embargo, vivimos en el mundo de las prisas y el de tener a todo el mundo ocupado. Esto hace que tener tiempo para “conversar” sea un precio que las organizaciones no estén dispuestas a pagar, producir mucho sin inspeccionar y adaptar. Y este es el reto del Scrum Master, conseguir ese espacio. El otro día, una persona de una organización financiera me comentó que usaban dos horas y media para hacer la Sprint Review, la Sprint Retrospective y la Sprint Planning del siguiente Sprint. ¿No es un poco “escaso” ese tiempo para todo lo que tenemos que hablar? Necesitamos un Scrum Master que se centre en que las personas disponen del espacio suficiente para poder conversar, y después, les ayude a ser efectivos en dichas conversaciones. Para ello, podemos usar las Liberating Structures, que ayudan a este tipo de conversaciones.
Scrum y las conversaciones
Scrum no son pasos predefinidos, no son un método infalible que si lo seguimos como una receta obtengamos el mejor software posible. Scrum son oportunidades de hablar, oportunidades de charlar en torno a cómo generar un software que nos permita dar un buen servicio. No garantiza nada, pero sí que entiende mejor como funciona el mundo complejo donde tenemos mucha incertidumbre, por eso está teniendo éxito.
Y tú, ¿tienes conversaciones sobre cómo entregar más valor a tus customers?
