El Shu-Ha-Ri en Scrum

Qué es el Shu-Ha-Ri en Scrum

Lo primero que debemos hacer es desmitificar esta expresión, puesto que se trata de pensar en cómo hacer que el sentido común sea la práctica más y mejor aplicada en un entorno Scrum.

La idea es que, cuando queremos madurar en la aplicación de Scrum, lo que queremos no es “ser los mejores aplicando Scrum”, sino “hacer bien, o muy bien, nuestros proyectos, para los que pensamos que aplicar Scrum puede ser conveniente”. Esa es la idea que perseguimos.

Así que, ¿qué implica esto en la práctica? Que debemos recorrer estos 3 pasos denominados Shu-Ha-Ri.

Shu, aprender

Pensemos en cuando éramos niños y queríamos aprender a montar en bicicleta: de nada servía que nos “leyéramos el manual de cómo se hace”, saber la teoría puede ser conveniente y hasta necesario a veces… pero definitivamente no es lo que determina que después lo vayas a hacer correctamente. Pues bien, ése primer paso es el “Shu”, es decir, aprender.

¿Qué debemos aprender? Pues lo básico de un enfoque Scrum: generar un backlog de proyecto, dimensionarlo a alto nivel, montar un roadmap con iteraciones de igual capacidad y sobre él un mapa de productos mínimos viables; a partir de ahí, planificar cada iteración, ejecutarla, y validar su resultado con una review, para terminar cada iteración con una buena reunión de retrospectiva.

Además, podemos apoyarnos en la daily stand up, el uso de un tablero kanban (esto es opcional, aunque muy conveniente), y otras prácticas.

Todo esto es un conocimiento técnico, es decir teórico, de momento basta con “saber que en eso consiste una iniciativa con Scrum”. Si no sabemos nada de esto, no podemos arrancar un proyecto con Scrum, aunque tengamos un facilitador (Scrum Master) que guíe al equipo en el proceso: para empezar a trabajar ya deberíamos contar con la formación suficiente acerca del proceso, y permitir que el equipo dedique su esfuerzo a definir y construir el alcance del proyecto.

Pero, ¿verdad que no basta con “saber cómo se hace” algo, para hacerlo bien? Se trata de empezar a aplicar de forma práctica, empírica, este conocimiento.

Ha, romper las normas

Imaginemos que nos sabemos a la perfección “el libro de Scrum”, y aplicamos a rajatabla cada una de las prácticas y reglas que están definidas: cada día la reunión de 15 minutos en la que se coordinan los miembros del equipo de trabajo; iteraciones de igual duración, cada una de ellas acabando en una reunión de “demo” para mostrar el cumplimiento de los criterios de aceptación de los requisitos del sprint backlog; una “retro” para generar un plan de mejora accionable a corto plazo, etc… pero si con eso basta, ¿entonces por qué no salen bien todos los proyectos, simplemente llevando a cabo esas prácticas? Porque el quid de la cuestión está en aplicarlas buscando las buenas ideas que solucionan los problemas para este proyecto, este equipo de trabajo concreto, en este momento, con estos requisitos, con este presupuesto, para este cliente y con estas circunstancias…

Y ése es el paso que debemos dar: adaptar, ajustar, aterrizar a la realidad las buenas prácticas, para que se traduzcan a buenas ideas que realmente funcionan.

Dos ejemplos bien claros:

• Supongamos que el equipo de trabajo utiliza un tablero kanban que refleja adecuadamente el estimado y el incurrido de las tareas, el estado de cada una, la correspondencia entre tareas y requisitos, dependencias entre tareas, dependencias entre requisitos, quién hace qué (a quién está asignada cada tarea), dependencias o “atascos” con personas externas al equipo, incidencias, etc… y que además de ser un tablero bien diseñado, el equipo sabe utilizarlo. Así que: ¿acaso no está claro quién está haciendo qué, qué hizo ayer y qué pretende hacer a continuación? ¿Acaso no está ya señalado si alguien tiene algún problema o atasco? Entonces… ¿qué valor añadido aporta la daily stand up, además de repetir lo que ya es obvio a la vista de todos, durante 15 ó 20 minutos al día (más el tiempo de ir y volver a la reunión)? ¿No puede ser, y es, una buena idea, eliminar esta reunión siempre y cuando no aporte valor?

• Supongamos que el equipo de trabajo hace las demos (reviews, según el léxico puro en Scrum) al final de cada iteración, para mostrar al product owner que se cumplen los criterios de aceptación de cada requisito. Pensemos en esto un segundo: Si fue el product owner quien definió estos requisitos (así debe ser, puesto que para eso participa en el proyecto), ¿acaso no debería saber ya qué se va a encontrar en la review? Es decir, si el equipo sabe que está cumpliendo los criterios de aceptación (que lo sabe, puesto que por eso lleva a la review su demostración), y el product owner también sabe cuáles son… ¿Acaso no basta con que una persona muestra al product owner dicho resultado? Si el equipo está compuesto por 12 personas… ¿No estamos desperdiciando 11 horas de incurrido, cada semana, por el hecho de que haya 11 personas que asisten a una reunión que ni les aporta valor, ni en la que ellos aportan ningún valor? 11 horas pueden sonar a poco, pero… en un proyecto anual con 52 iteraciones semanales, estamos hablando de 11x52=572 horas de trabajo nada menos… ¿cuántas cosas más útiles se pueden hacer en 572 horas de trabajo?

Cuando hablamos de “Ha, romper las normas”, es a éste tipo de cuestiones a las que nos referimos, a plantarnos hasta qué punto la supuesta buena práctica formal nos ayuda en la práctica… y por tanto hasta qué punto la tenemos que ajustar o simplificar para que aporte su mejor valor.

El éxito del proyecto consiste en cumplir un alcance sin pasarnos de presupuesto ni de fecha límite, no en seguir escrupulosamente teorías o metodologías, que deben existir como guion general pero no como recetario de trabajo.

Ri, innovar

Si hemos llegado al “Ha”, entonces lo tendremos más fácil para seguir abriendo la mente, y es cuando vamos a sacar el mejor valor de un estilo propio de gestión de proyecto. Debe ser el momento de empezar a preguntarnos “¿por qué no…?”, por ejemplo:

• ¿Por qué no utilizamos el mismo tablero kanban para todos los proyectos que este equipo desarrolla a la vez? El reto aquí es tener una definición de hecho similar (para que las columnas del tablero sean las mismas). Con ello, ¿por qué no podemos visualizar el estado de las tareas de requisitos de backlogs de proyecto diferentes?

• Si queremos saber si el proyecto será un éxito, ya desde el inicio del mismo (para evitar sorpresas finales y problemas de aceptación, ¿Por qué no aplicar una técnica como las Personas (arquetipos) contra los que mapear los requisitos, y así enfocar desde el inicio la definición de estos requisitos y los responsables de su aprobación?

• Si tenemos dificultades en la elaboración del backlog (porque nuestro product owner no se sabe explicar, porque no sabe lo que debería, porque no le entendemos, o simplemente no tenemos product owner accesible), ¿por qué no aplicamos design thinking para generar prototipos cada vez más refinados, hasta que dejemos de llamarle prototipo y empecemos a llamarle backlog o producto mínimo viable? Y así un infinito etcétera… Es hora de olvidarse de lo que dicen los libros de metodologías, e inventar prácticas y soluciones a cuestiones que siguen pendientes de resolver.

Recordemos que innovar no significa sentarse en una mesa para que un grupo de personas pase el rato disparando ideas creativas y más o menos novedosas… eso es una reunión de diseño o de creación de producto o de proceso; innovar es buscar y encontrar la solución a un problema práctico que hay que resolver.

En Scrum y en agile en general, innovar implica una consecuencia práctica, empírica, utilizable a corto plazo (en la siguiente iteración, sin ir más lejos). Así que podemos decir que “Ri, innovar”, sería la etapa en la que nos atrevemos a desafiarnos como equipo y nos preguntamos “¿por qué no…?” para buscar la máxima eficiencia y productividad a cada práctica, cada reunión, cada evento y cada iteración.

Qué es el Shu-Ha-Ri en Agile

Scrum es una metodología particular dentro del mundo agile; si se puede aplicar Shu-Ha-Ri en Scrum… ¿por qué no aplicarlo a cualquier ámbito agile? De hecho, con esta misma pregunta ya lo estamos haciendo: ¿Qué podemos aportar nuevo en un enfoque Lean, o Kanban, o FDD, o DSDM, o Crystal, o cualquier metodología propia de cualquier empresa?

Se trata de conocer el fundamento teórico (Shu, por qué las buenas prácticas se consideran como tales), ajustar esas prácticas a la realidad del proyecto (Ha, romper la norma básica para poder aplicarla), y plantearse qué más o qué menos se puede hacer para conseguir los objetivos (Ri, innovar sobre la realidad del proyecto).

Uno de los principios fundamentales de agile es empoderar al equipo, que éste tenga el espacio de trabajo que necesita y la libertad de movimientos para desarrollar el trabajo. Pues bien, la idea detrás de Shu-Ha-Ri tiene mucho que ver con hacer madurar y crecer al equipo como tal: primero guiarlo por la práctica básica para que el equipo camine sólo; después ajustar las costumbres a la realidad del proyecto para mejorar en eficiencia… y, por último, que el equipo crezca y se potencia a sí mismo, desafiando su status quo, atreviéndose a probar y adaptar nuevas ideas que les impulsen en el alto rendimiento.

Shu-Ha-Ri en el sector IT

Y si Shu-Ha-Ri aplica perfectamente en Scrum en particular, y en agile en general… ¿acaso no tiene todo el sentido aplicarlo en todo un sector como el IT? Por supuesto que sí, y veamos ejemplos de cada nivel para hacer pensar a los profesionales de este campo:

Shu

Algo que dicen todas las “buenas prácticas”, como algo elemental que debemos conocer y seguir, es el test driven development (TDD): primero escribimos las pruebas, de tal forma que si desarrollamos el código que las supera, podemos decir que dicho código cumple con lo que se espera. Pero un poco más allá: ¿Y si esas “pruebas” son las que ratifican que se cumplen los criterios de aceptación de los requisitos? Estaríamos aplicando la buena práctica de una forma directa y efectiva.

Ha

Un poco más allá de las buenas prácticas como TDD, vamos a plantearnos los casos de sistemas de información o aplicaciones en las que “solucionar cualquier cosa es muy complicado, no hay documentación, el código está lleno de copy paste, hay código muerto…” y un largo etcétera. A esto lo denominamos deuda técnica, es decir, el trabajo adicional que supone un sistema teniendo en cuenta que éste fuera perfecto, con código perfectamente limpio y documentación exacta y completa.

A mayor deuda técnica, más inmanejable es un sistema, más difícil es solventar cualquier problema, incidencia o nuevo desarrollo, incumpliendo las estimaciones y los plazos con frecuencia. Pues un equipo de trabajo que se propone no generar nueva deuda técnica estaría aplicando este nivel “Ha”, puesto que busca la mejor idea concreta por su tecnología o tipología de proyecto, más allá de las simples buenas prácticas.

Ri

Apartir de aquí, invito al lector a que se plantee sin miedo… ¿qué más se te ocurre para hacer las cosas un poco mejor? O quizá sea más fácil: piensa en el último problema que has tenido en tu proyecto IT: ¿alguna entrega fallida, un plazo incumplido, incidencias excesivas en producción, incumplimiento de acuerdos de nivel de servicio…??

Pues el nivel “Ri” consiste en aplicar, de una vez por todas, el sentido común y el esfuerzo de mejor por encima de cualquier teoría o práctica (o costumbre!) predefinida: dile a tu cliente que su entorno de pruebas no es el adecuado, o dile a tu jefe que la herramienta que estáis utilizando no funciona, o reconoce que técnicamente el equipo no maneja alguna cuestión y hay que cambiar algo, o deja de redactar un documento técnico que consume horas y horas, pero que nadie se lee, y provoca que no se dedique el tiempo necesario a otras cuestiones más importantes para cumplir plazos o compromisos… plantearse todo esto es a lo que debemos aspirar como equipo, ya sea en un entorno IT o en cualquier otro.

El nivel “Ri” en Scrum, en agile, y en general, consiste en estar convencido de que hacer cosas diferentes y mejores nos llevará a conseguir resultados diferentes y mejores. Y en este camino también nos convertiremos progresivamente en mejores profesionales.