Introducción
Los pilares de Scrum (inspección, adaptación y transparencia) inspeccionan grandemente el comportamiento de las personas en los eventos y desde luego trazan la linea matriz a la hora de emplear los artefactos.
Cabe señalar que más importante que un evento ocurriendo a tiempo es importante que durante el evento realmente ocurra la inspección y la adaptación posibilitada por la transparencia.
La adaptación, inspección y transparencia son mecanismos poderosos que con el tiempo pueden (y deben) alterar para mejor la forma de los eventos y artefactos.
Inspección, Adaptación y Transparencia en los Eventos de Scrum
En el Daily Scrum el equipo tendrá la oportunidad de verse las caras y sincronizar para el día. Más aún, los miembros del equipo tendrán la oportunidad de escuchar que acerca de que están haciendo los demás miembros, como esta progresando el Sprint para todos y observar como se siente la gente en ese día.
Lo anterior sólo será posible si la gente que participa en este evento esta realmente presente en el momento (física y mentalmente). Al estar presentes en el momento se incrementan las chances de inspeccionar el trabajo y proponer adaptaciones pero desde luego lo anterior no seria posible si no existe un alto grado de transparencia y confianza para decir las cosas [Rubin12].
En el Sprint Planning la transparencia en necesaria para cosas tan vitales como que todo el equip manifieste que realmente ha entendido del Objetivo del Sprint. La inspección permitirá al equipo hacer preguntas que clarifiquen su entendimiento de que hay que hacer y la adaptación permitirá crear un plan que parezca realista en ese momento del tiempo con el conocimiento que se tiene disponible.
Inspeccionar cualquier plan creado durante el Sprint Planning ya durante el Sprint es vital hacer adaptaciones pues de esta forma se añadirá realismo. Añadir realismo a un plan creado, en lugar de defenderlo a capa y espada, se alinea mejor con la agilidad [Auer02].
En el Sprint Review los clientes tendrán la oportunidad de ver y principalmente utilizar el Incremente en el cual trabajó el equipo durante el Sprint.
Cabe hacer notar que la única forma de realmente ver como el cliente usuaria el producto es hacer que éste lo utilice, escuchar sus comentarios, dialogar y observar sus reacciones y expectativas.
De hecho lo anterior ofrece la oportunidad perfecta para tener transparencia, inspeccionar el grado de satisfacción (o no satisfacción) del cliente y realizar las adaptaciones necesarias en el Product Backlog.
Existen varios mitos acerca de este evento que vale la pena nombrar con el afán de desmitificarlos:
- Primer mito, sólo el equipo muestra software funcionando pero el cliente no puede tocar el teclado
- Segundo mito, en esta evento el equipo muestra software funcionando para el Product Owner que luego en otra reunión posterior le mostrará el producto al cliente y luego volverá al equipo con la retroalimentación que recoja
- Tercer mito, el cliente sólo ve software funcionando en estos eventos y no debe ser molestado durante el Sprint
En la Retrospectiva del Sprint una vez más la transparencia será vital para que cada miembro del equipo pueda manifestar su opinión sincera e inspeccionar todos juntos como equipo factores tales como:
- el Sprint en general
- el equipo
- las relaciones e interacciones entre miembros del equipo
- las relaciones e interacciones con personas externas al equipo
- las relaciones e interacciones con el cliente
- su forma de trabajo
- los resultados que se alcanzaron
- los puntos a mejorar
Si bien es cierto que la lista anterior podría seguir creciendo y nunca está completamente definida el objetivo es cultivar el espíritu de mejora continua [Ohno13].
Será precisamente ese espíritu de mejora continua el que hará que el equipo busque sin descanso eliminar desperdicios, construir un producto de calidad y mejorar en la práctica de su oficio.
Las retrospectivas tendrán como uno de sus resultados principales el proveer ideas para realizar adaptaciones para el siguiente Sprint. Otro de los resultados de una retrospectiva es la celebración, aprecio y reconocimiento por las cosas que salieron bien en el Sprint.
Las retrospectivas no son sin embargo eventos en los cuales la gente del equipo deba quedarse callada mientras haya uno o dos que dominen la discusión. Tampoco es un evento en el cual se deba tener violencia en la comunicación, ataque o criticas hacia las personas o su trabajo [Lencioni02].
El ciclo de transparencia, inspección y adaptación debe también aplicarse a las retrospectivas para que así el equipo las vaya mejoran con el pasar del tiempo.
El Sprint y el Incremento
Comencemos recordando que en Scrum un Sprint es un periodo de tiempo, generalmente menor a cuatro semanas, durante el cual el equipo trabaja de manera alineada para construir un Incremento del producto.
Durante el Sprint el Objetivo del Sprint no debería cambiar porque sino el equipo podría acabar construyendo varias piezas desconectadas del mismo producto.
Tener un objetivo que sea lo suficientemente amplio pero que no cambie en su esencia permite mantener el alineamiento del equipo y contribuye a la consistencia del mismo.
Un objetivo que no cambia también puede contribuir a que el cliente tenga claridad respecto a que esperar al final del Sprint. Nótese en este punto que el alcance no es lo mismo que el objetivo, la idea siempre es pensar Lean y lograr el mismo objetivo pero con menos alcance.
La salida del Sprint es una pieza de software bien construida cuyos componentes cumplen con la Definición de Terminado y esta en condiciones de ser utilizada, más aún puede ser instalada y ejecutarse establemente en un ambiente de producción.
Lo anterior es de vital importancia porque:
- permitirá recolectar retroalimentación real de los clientes y usuarios
- hará evidente la capacidad y conocimiento del equipo
- llevará al equipo un paso más cerca de la visión del producto
Liberar públicamente un Incremento del Producto tienen repercusiones en otras áreas del negocio como: mercadeo, legal, finanzas, infraestructura, y otras; por tanto ésta es una decisión que debe ser tomada por el Product Owner.
De hecho es el Product Owner que en función del mercado, la infraestructura, los clientes y otros interés, dede trazar la estrategia de liberaciones públicas. Cualquiera que sea la frecuencia de liberaciones públicas definidas en esa estrategia no excusa al equipo de construir un Incremento del Producto potencialmente liberable al final de cada Sprint.
Sprint Planning
El evento de Sprint Planning se divide en dos mitades, la primera de ellas a la cual llamamos simplemente Sprint Planning One se enfoca en entender y discutir el quese hará durante el Sprint.
El que del Sprint esta alineado con el Objetivo del Sprint y normalmente es el Product Owner quien puede explicarlo mejor al equipo.
Nótese que la explicación del que esta conectada más al porque el cliente necesita las funcionalidades que se implementarán en el Sprint y como éstas potencialmente contribuirán valor al producto.
La explicación se debe mantener en un nivel de abstracción lo suficientemente alto como para no entrar en la minucia y extender ésta parte de la reunión demasiado. Hablar de la minucia es precisamente el trabajo de comunicación que deberán hacer ya dentro del Sprint los desarrolladores con los clientes a mediada que avancen con la implementación.
La segunda parte del Sprint Planning, que es llamada de Sprint Planning Two, el Equipo de Desarrollo se concentra en discutir como se organizaran para realizar el trabajo y cuanto de este es factible terminar en el Sprint.
Lo anterior implica que el Equipo de Desarrollo deberá descomponer items grandes, incorporar realismo estimándolos, y postergar para después items menos importantes [Beck00].
Las estimaciones no deben buscar la precisión y menos aún ser utilizadas por los jefes como un compromiso al cual estarán sujetos los miembros del equipo. Si esto acaba ocurriendo la tendencia lógica será que los desarrolladores inflen sus estimaciones como mecanismo de defensa.
En lugar de lo anterior la idea con las estimaciones es que se utilizaran como un indicador interno del equipo para tener una percepción de que podría o no caber dentro del Sprint.
Más importante todavía que las estimaciones es tener presente en este evento y durante todo el Sprint el concepto de flujo que se apoya grandemente en tener piezas pequeñas de trabajo moviéndose constantemente [Goldratt14].
Las estimaciones pueden realizarse usando diferentes técnicas y unidades pero el principio básico es mantenerlas simples y ligeras para que estimar y reestimar no sea un proceso penoso y conflictivo.
En mi experiencia las estimaciones con unidades de tiempo medidas en semanas, días, y horas es la que mejor funciona puesto que el tiempo es una unidad universalmente entendida y no conlleva ambigüedad [Jeffries00].
Al final del Sprint Planning Two el equipo debería acabar teniendo un plan no extremadamente detallado y con estimaciones precisas, sino más bien un plan lo suficientemente bueno como para hacer sentir a los miembros del equipo confiados en que podrán implementar los items más valiosos de su Sprint Backlog durante el Sprint [Patton14].
Daily Scrum
El Daily Scrum es diferente de una reunión tradicional de reportes de status debido a que:
- No tiene la aspiración de reportar sólo con palabras el estado, impacto y calidad del trabajo que se esta realizando
- No es para hablar acerca de un plan estático creado hace tiempo y como se está avanzando en función de ese plan
- Debe ocurrir con la gente parada en un circulo, cara a cara, sin laptops ni celulares, y distantes del lugar donde ocurre el trabajo (gemba)
El simple hecho de que este evento se realizará lejos del gamba ya conlleva de por si un grado de subjetividad pues el equipo no estará mirando el trabajo. Para que la inspección se vuelva realmente efectiva después de esta reunión habrá que “ir y ver” el trabajo [Ohno13].
Quizás uno de los grandes aportes de este evento es que hace que todo el equipo reconozca que para estar realmente empapados del trabajo necesitan ir y ver donde realmente ocurre, pero para permanecer comunicándose efectivamente y sintiendo el lado humano del trabajo necesitar pararse en un circulo para hablar, reír y compartir.
Por otro lado este evento tiene algunas restricciones introducidas con el fin de hacer que fluya mejor para el Equipo de Desarrollo, éstas restricciones son:
- No jefes o gerentes presentes
- Sin dispositivos electrónicos de ningún tipo
- Debe terminar dentro de un timebox de sólo 15 minutos
- No esta permitido culpar o juzgar a otros miembros del equipo en el círculo
- Sin “superiores”, todos somos iguales en el círculo
Para mantener este evento dentro del tiempo límite existen ciertas técnicas que pueden ayudar:
- Hablar solamente acerca de los logros de ayer, los objetives para hoy y los impedimentos sólo si existiesen
- Todos hablando cara a cara en un círculo
- Posponer para después conversaciones largas
Sprint Review
El Sprint Review es el evento formal en el cual el equipo presentará el Incremento a los clientes o usuarios finales para validar hipótesis y ver si el producto está avanzando en la dirección correcta.
La definición anterior ha causado muchos problemas y confusiones pues muchas veces se ha entendido como el único momento en el cual los clientes pueden ver el producto en construcción.
Volviendo a los pilares fundamentales de Scrum (inspección, adaptación y transparencia) nos daremos cuenta que la idea es tener retroalimentación constante y ésta se logra mostrando el producto lo más frecuentemente que se pueda (idealmente cada día y varias veces dentro de cada día).
El otro gran componente esta en el verdadero significado de “mostrar”, la retroalimentación más realista viene de clientes que tocan el teclado y el mouse e interactuan con el producto.
Sin embargo, tener el Sprint Review al final de un Sprint es un excelente punto de inicio para equipos que están empezando con Scrum ya que ayuda grandemente a acercarse al cliente y crear el hábito de que debe ver el producto mientras se esta construyendo.
Existen algunas actividades clave antes y durante de este evento:
- Preparar un salón y tener toda la logística preparada para que el clientes pueda interactuar con el producto
- El Equipo Scrum observara detenidamente como el cliente interactuará con el producto
- El Producto Owner deberá explicar, generar y responder preguntas acerca de como el Incremento se conecta con los objetivos del negocio
- El ScrumMaster facilitará el evento para hacer que fluya de forma dinámica, entretenida y productiva para todos
A su vez este evento producirá algunos resultados clave:
- La validación de que el producto está avanzando en la dirección correcta y se necesita perseverar por algunos Sprints más
- La indicación de que el producto no esta cumpliendo las expectativas del cliente o no va en camino de resolver sus problemas por lo cual el producto deberá pivotar
- La apreciación de las capacidades técnicas reales del Equipo de Desarrollo que les permite construir software cumpliendo con la Definición de Terminado
Continuando con la anterior, el trabajo del Product Owner y del equipo en general se basa en un conjunto de hipótesis que mientras más tiempo tarden en validarse más riesgo implicarán, de ahí la importancia del Sprint Review como mecanismo a través del cual los clientes usarán el producto para dar retroalimentación oportuna.
Sprint Retrospective
Este evento de retrospectiva persigue que el equipo en su conjunto reflexionen acerca de sus prácticas, métodos, interacciones y disciplina para ver como podrían mejorar para el siguiente Sprint.
Al ser un evento de autocrítica y a la vez de valoración de lo que salió bien, require de valores cruciales como transparencia, sinceridad y empatía.
Precisamente será labor del ScrumMaster facilitar este evento para fluya dentro del respeto a los valores nombrados.
Responsabilidades adicionales del ScrumMaster como facilitador de este evento incluyen:
- Ayudar al equipo a mantenerse enfocado al rededor del tema central que es la inspección del equipo mismo, sus procesos y dinámicas internas
- Mantener la discusión balanceada entre lo positivo del Sprint pasado y los puntos a mejorar
- Ayudar a que el equipo mantenga la discusión alrededor de los problemas sin culpabilizar a nadie y más bien hablando de como se podrían mejorar las cosas
- Mantener las retrospectivas vivas, dinámicas y entretenidas usando técnicas de facilitación efectivas y continuamente innovarlas [Roden15]
Existen acuerdos que ayudan a que el ScrumMaster pueda contribuir con los puntos anteriores, dos de los más importantes en mi experiencia son: hacer que esta sea un evento privado de sólo el equipo y mantenerlo corto (menos de 45 minutos).
No tener retrospectivas o simplemente tenerlas pero mal facilitadas acaba degradando el poder creativo y la cohesion del equipo, pues problemas subyacentes se vuelven cada vez más agudos hasta el punto de fracturar las relaciones interpersonales y consecuentemente el trabajo mismo.
Las retrospectivas podrían también llegar a realizarse en función de los sucesos que las disparen, es decir en lugar de solamente tenerlas en un evento formalmente programado para el final del Sprint el equipo podría tener reuniones cortas y puntuales cada vez que identifiquen un punto de mejora tal como lo hacen en Toyota [Womack07].
Product Backlog
Para el Product Backlog el Product Owner tiene las siguientes responsabilidades:
- Liderar su descubrimiento inicial con la participación de clientes y patrocinadores clave
- Mantener el Product Backlog vivo y siempre reflejando su entendimiento más actualizado del producto, el mercado y el cliente
- Ordenar el Product Backlog de manera de centrar el tiempo y capacidad del Equipo de Desarrollo en los items que vayan a retornar más valor una vez implementados
A su vez para el Product Backlog el ScrumMaster es responsable de:
- Hacer coaching a los dos otros dos roles para que vean el Product Backlog como una herramienta valiosa de comunicación y ordenamiento de trabajo que va contribuir valor
- Hacer coaching a los dos otros roles para que juntos mantengan el Product Backlog pequeño y con solamente el mínimo necesario de detalle
Finalmente los Desarrolladores para el Product Backlog serán responsables de lo siguiente:
- Proveer estimaciones y principalmente reestimaciones que contribuyan realismo
- Refinarlo semanalmente en el evento de Backlog Refinement Meeting
- Clarificar sus items con los creadores originales del requerimiento
Las responsabilidades anteriormente nombradas para cada rol sirven también para hacer énfasis en que el Product Backlog, al igual que los demás artefactos de Scrum, son elementos articuladores entre los roles.
El Product Backlog como tal debe tener las siguientes características:
- Es dinámico y cambiará constantemente en función del aprendizaje del equipo y el descubrimiento del cliente
- Esta ordenado y se reordenará constantemente con el afán de poner la energía del equipo en la implementación de primero los items más importante para el negocio
- Es finito y alcanzable en un horizonte cercano de tiempo
- Es público y cualquier miembro del equipo puede verlo y editarlo pero solo el Product Owner puede cambiar el orden
Muchas veces las metáforas son útiles para que un equipo acabe entendiendo un artefacto y lo aplique adecuadamente en el día a día [Auer02]. En tal sentido he encontrado útil asociar el Product Backlog con la metáfora de una lista de supermercado que lógicamente es dinámica, se ordena por prioridades dictadas por tiempo, dinero y preferencias, es finita, y es visible para toda la familia.
Dentro del Product Backlog existen componentes a los cuales prefiero llamar simplemente items que deben cumplir con ciertas características:
Están orientados al cliente
- Contribuirá valor al producto una vez implementado
- No se detallan usando documentos sino que se conversa acerca de ellos
- Se deben descomponer en items más pequeños que puedan ser implementados manteniendo un flujo constante
De manera general podemos considerar que los items en el Product Backlog son marcadores de posición para tener conversaciones acerca de ellos y su potencial valor en el producto. El punto es que esos items son promesas de conversaciones en lugar de documentos estáticos escritos a detalle [Larman17].
Sprint Backlog
El Sprint Backlog tiene las siguientes características esenciales:
- Es creado por el Equipo de Desarrollo que lo utilizará activamente durante el Sprint
- Contiene solamente información primaria para no sobrecargarlo demasiado
- Puede contener estimaciones que son indicativas pero no compromisos inamovibles
Es más que seguro que el Sprint Backlog ira cambiando a medida que los desarrolladores empiecen a trabajar en los items para el Sprint.
Por lo anterior los desarrolladores son totalmente responsables de reestimar las tareas −en las cuales se descompusieron los items− cuando lo crean necesario, seguir descomponiendo, o cambiar el orden de las tareas.
Sin embargo el Product Owner debe ser necesariamente consultado si tales cambios implicaran un impacto en la profundidad o anchura del alcance de la implementación del item.
Definición de Terminado
Tener una Definición de Terminado común a varios Equipos Scrum se hace necesaria por las siguientes razones:
- Brindará claridad para todo el mundo acerca de qué se considera realmente terminado lo cual eliminará posibles malos entendidos y desconexiones
- Ayudará a que los equipos se comuniquen mejor a través del código ya que todos llamarán terminado a lo mismo
Aún cuando todos los equipo parten de una Definición de Terminado común es posible que algún equipo decida modificarla para hacerla más estricta o para llevarla cada vez más cerca a un ambiente de producción [Humble10].
No se puede decir que una Definición de Terminado sea buena o mala, pero si es cierto que ers más valiosa cuanto más cercana está de poner código en producción en tiempos cada vez más cortos [Forsgren18].
De manera más general, un equipo Scrum puede decidir modificar su Definición de Terminado por los siguientes motivos:
- Un equipo encontró una Definición de Terminado aún más poderosa y ahora desea contagiar a otros equipos
- Durante su retrospectiva un equipo observó que su Definición de Terminado no es lo suficientemente estricta o todo lo contrario
- En el Sprint Review se están presentando items con deuda técnica o funcional
Conclusiones
Inspección, adaptación y transparencia son mecanismos poderosos que Scrum emplea dentro de su forma de trabajo adaptativa que busca acomodarse bien al cambio del alcance.
Cambio que a su vez ocurre por la naturaleza dinámica del mercado y/o por la incertidumbre respecto a que esperan realmente los clientes que haga el producto para ellos.
Estos tres pilares están presentes en los eventos y artefactos de Scrum y deben ser empleados por el Equipo Scrum como parte de su diario accionar.
La carencia de estos pilares no sólo limitara Scrum sino que trae consigo el riesgo de creer −inocente o mal intencionadamente− que se esta haciendo Scrum cuando en realidad es Scrum sólo de nombre.
Finalmente, Scrum no se basa en herramientas pesadas ni caras sino que tiene como eje motor al equipo y su sistema de principios, creencias y valores.
Bibliografia
Rubin02 Rubin K., 2012. Essential Scrum: A Practical Guide to the Most Popular Agile Process, Addison-Wesley
Auer02 Auer K., Miller R., 2002. Extreme Programming Applied, Addison-Wesley
Ohno13 Ohno T., 2013. Taiichi Ohno’s Workplace Management, McGraw Hill
Lencioni02 Lencioni P., 2002. The Five Dysfunctions of a Team: A Leadership Fable, Jossey-Bass; 1st edition
Beck00 Beck K., Fowler M., 2000. Planning Extreme Programming, Addison-Wesley Professional
Goldratt14 Goldratt E. M., 2014. The Goal: A Process of Ongoing Improvement, The North River Press
Jeffries00 Jeffries R., Anderson A., Hendrickson C., 2000. Extreme Programming Installed, Addison-Wesley Professional
Patton14 Patton J., 2014, User Story Mapping: Discover the Whole Story, Build the Right Product, O’Reilly Media
Roden15 Rosen 15., 2015, Fifty Quick Ideas to Improve Your Retrospectives, Neuri Consulting LLP
Womack07 Womack J., Jones D., Ross D., 2007. The Machine That Changed the World: The Story of Lean Production– Toyota’s Secret Weapon in the Global Car Wars That Is Now Revolutionizing World Industry, Free Press; Reprint edition
Larman17 Larman C., Vodde B., 2017. Large-Scale Scrum More with LeSS, Addison-Wesley
Fowler02 Fowler M., 2002. Patterns of Enterprise Application Architecture, Addison-Wesley Professional
Humble10 Humble J., Farley D., 2010. Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation, Addison-Wesley
Forsgren18 Forsgren N., Humble J, Kim G., 2018. Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations, IT Revolution Press