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 qué están haciendo los demás miembros, como esta progresando el Sprint para todos y observar cómo se siente la gente en ese día.
Lo anterior sólo será posible si la gente que participa en este evento está 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.
En el Sprint Planning la transparencia es necesaria para cosas tan vitales como que todo el equipo 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.
Al 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.
En el Sprint Review los clientes tendrán la oportunidad de ver y principalmente utilizar el Incremento en el cual trabajó el equipo de desarrollo durante el Sprint.
Cabe destacar que la única forma de realmente ver como el cliente usaría 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 insatisfacció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 desmitificar:
Primer mito, sólo el equipo muestra software funcionando pero el cliente no puede tocar el teclado.
Segundo mito, en este 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.
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 críticas hacia las personas o su trabajo.
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.
Artículo Original: https://percella.com/blog/