jueves, 19 de abril de 2018

¿Cuáles son los aprendizajes de las primeras PI Plannings?

Plan de equipo en simulación previa
Llevo ya unas pocas PI Plannings a mi espalda y con ello un montón de aprendizajes. Previamente a la primera PI Planning formo a los roles principales, como lo son los Propietarios del Producto y los Scrum Masters, para prepararlos para el evento mediante una simulación de 2 iteraciones con todas los artefactos y prácticas que conlleva.

Después de la formación solemos introducir algunos ajustes y cambios, creyendo adaptar la práctica lo mejor posible a nuestra realidad. El aprendizaje principal lo resumiría en que SAFe tiene prácticas de PI Planning muy maduras y experimentadas, y que todo lo que dejes fuera emerge por si solo de forma natural... aprendizajes fueron:

No pensar en los objetivos ampliados (stretch objectives): un plan a nivel de tren es muy complejo, hay dependencias y todo el entramado de planes requiere mecanismos para garantizar el éxito. Para que los equipos puedan garantizar la construcción de lo importante necesitan margen, necesitan no comprometerse con todo y saber qué dejar fuera en caso de no llegar con todo a final de PI. De forma natural, y por pura necesidad, acabamos introduciendo a lo largo de la primera PI Planning dos zonas para las historias de usuario, una para las comprometidas y otra para las no comprometidas.

Representar las dependencias sólo con post-its sin cuerdas: Una de las problemáticas que detectamos fue que los equipos no entendían la diferencia entre dependencia y riesgo. Decidimos representar las dependencias por códigos numéricos por pares apuntados en los post-its de ambas historias de usuario dependientes entre si. Esta forma de hacerlo invisibiliza las dependencias, ya que estas son la relación entre las historias, la dependencia es la cuerda. Sin cuerda una dependencia puede entenderse como un riesgo.

Scrum de Scrums: es importante mantener un ritmo sincronizado en todos los equipos, para ello SAFe propone puntos de situación cada hora. No lo hicimos así, y ocurrió que algunos equipos acabaron antes que los demás y se produjo una sensación de desconexión y caos, que hizo que los demás equipos corrieran y probablemente hayan tomado decisiones a la ligera.

PI Planning en un solo día: es importantísimo cerrar bien, el resultado de la PI Planning ha de ser sólido, hay alrededor de 100 personas implicadas y hemos de garantizar obtener el plan mejor resuelto, el más factible, el que tenga las mayores probabilidades de éxito. SAFe marca dos días de planificación, pensamos que con uno solo sería suficiente y resultó que al final del mismo todos estaban muy cansados. Fue una jornada agotadora y al final de la misma los acuerdos y la toma de decisiones fueron rápidas y posiblemente a la ligera, y sabemos muy bien que las decisiones a la ligera son malas decisiones.

Se nota mucho en el ambiente porque todo el mundo quiere acabar y todo se acelera de una forma que no es coherente. En vez de que cada equipo expusiera su plan a toda la audiencia, invitamos a que todos visitaran los planes de los demás y solo echaran un vistazo a los tableros. El alineamiento del tren resultó ser mucho más pobre de lo esperado, nadie había reparado realmente en los objetivos de los demás equipos. Los Business Owners deberían haber puesto valor de negocio a los objetivos, y en vez de ello simplemente habían aceptado los planes. La conclusión fue que para cerrar bien es necesario estar frescos y presentes, si no cerramos bien lo haremos inevitablemente a lo largo del PI de forma mucho más costosa.

Saltarse la votación de confianza a mano alzada: en una primera PI Planning un Scrum Master mencionó que era mejor no hacer la votación ya que todos estaban cansados y no sería una votación muy realista. Tenía razón, así que no la hicimos. La votación de confianza es importante ya que trae a la luz asunciones ocultas, parece que todos hemos trabajado bien y estamos encantados, pero si hubiera algunas voces que tuvieran algo importarte que decir, y permanecen calladas, podemos poner en riesgo toda la PI Planning, ajenos a que hubiéramos podido evitarlo.

De tanto en tanto hacemos votaciones de confianza en las planificaciones de sprint para revelar al equipo la confianza que tiene en su plan. A veces alguien levanta solo 2 o 3 dedos, le invitamos a exponer sus preocupaciones y en la mayoría de los casos se trata de algún malentendido o una carencia de información que se resuelve en minutos. Lo importante es que esa persona, que no creía en el plan, después si cree, y por tanto su compromiso se ve reforzado.

Quiero resaltar que cada una de las PI Planning que he vivido ha sido un completo éxito y ha aportado aprendizajes muy valiosos. He participado en varias transformaciones ágiles donde cada una de estas planificaciones ha establecido conexión entre áreas y equipos, de forma que han acelerado notablemente el flujo interno. Su mayor aportación fue crear y reforzar la estructura de colaboración dentro de las compañías.

sábado, 14 de abril de 2018

¿Cómo hacer una retrospectiva que haga emerger un camino de crecimiento para el equipo?

Para impulsar a los equipos, sea cual sea su naturaleza, y hacer team-building intencional, en lo que hay que poner el foco es en las relaciones entre las personas, luego trabajar el objetivo del mismo como equipo y diseñar los pasos para caminar en esa dirección. En Agilidad se trata de equipos como:
Una forma de revelar el equipo a si mismo es que cada uno de los miembros haga una constelación en papel del equipo. Cada persona dibuja en una hoja de papel un circulo, que representa al equipo, y en el que después coloca los elementos y las relaciones entre estos elementos según la siguientes instrucciones:
Instrucciones constelación en papel
Las constelaciones de los miembros individuales se colocan en una pared y todos visitan las de los demás sin mediar palabra. Ocurrirán muchas cosas en las mentes de los miembros, ellos saben muy bien como es su equipo y descubrirán nueva información y asunciones equivocadas en las constelaciones de los demás.

Se hace una segunda ronda, ronda en la que probablemente todas las constelaciones hayan convergido. Estas se colocan en otra pared y esta vez los miembros pueden conversar sobre las diferencias, pero solo lo suficiente para dibujar una nueva constelación común y consensuada en una hoja de rotafolios. No todos tienen que estar totalmente de acuerdo con la constelación común, ahora si, deben de aceptarla y sentir que llegar a ella les hará mejorar como equipo.


La segunda fase de la dinámica consiste en diseñar el camino de la constelación actual a la constelación que ha diseñado el equipo. En individual todos escriben en post-its cosas que creen que se deben de modificar, añadir, soltar y mantener en el equipo actual. Cada miembro menciona sus post-its de uno en uno, y en conversación y consenso, el equipo decide cuales se colocan en la siguiente matriz de cambio y continuidad:
Matriz de cambio y continuidad
Lo ideal es hacer la matriz sobre un tablero u hoja de rotafolio para dejarla, una vez finalizada la actividad, en una pared cercana a la zona de trabajo del equipo, de manera que irradie continuamente y los cambios ocurran de forma natural en el momento adecuado.

Al principio de las sucesivas retrospectivas corrientes, y mientras queden post-its, se repasa brevemente la matriz para quitar aquellos post-its que ya se hayan cumplido, o aquellos que el equipo considere que se han de desechar. Esta forma de retrospectiva inicia un puente entre lo que es el equipo actualmente con a donde decide llegar, actividad muy útil en equipos que no encuentran su camino de crecimiento.

domingo, 8 de abril de 2018

¿Cómo soluciona Scrum las 5 disfunciones del equipo?

Pirámide de las 5 disfunciones - gracias Gertru
Recientemente asistí a un meetup del club de lectura Madriagil en el que hablamos sobre las "5 disfunciones de un equipo", libro en el que su autor, Patrick Lencioni, nos revela los cinco problemas que impiden que incluso los equipos más brillantes funcionen.

En este post pretendo hablar sobre como Scrum soluciona estas disfunciones. Las 5 disfunciones están estructuralmente conectadas, se muestran en una pirámide, como la de la imagen de la izquierda. Para que se pueda resolver una disfunción determinada, tiene que haberse resuelto la que está en su base.

El éxito de los equipos ganadores está en su funcionamiento óptimo, este dependerá del comportamiento, y recordemos que el comportamiento de miembros y equipos dependerá del entorno que les rodee, y ahí es donde como Scrum Masters tenemos nuestro cometido principal.

Empezando por la base de la pirámide las disfunciones son:

1. Falta de confianza: esta surge por el miedo o la falta de disposición a mostrarse vulnerables ante los demás miembros del equipo. Esto lleva a no abrirse a los demás y a no aceptar errores y debilidades, lo que a su vez impide la construcción de relaciones de confianza.

Como Scrum Masters hemos de crear y garantizar un entorno seguro para el equipo, un entorno donde no tengan miedo a equivocarse, donde equivocarse sea una oportunidad para aprender y por tanto para mejorar. Todos somos vulnerables, en este entorno seguro los miembros del equipo acaban descubriendo que compartir las debilidades y las dudas es enriquecedor, ya que en equipo se puede lograr respuestas a cuestiones insospechadas. En un entorno seguro el equipo comparte el compromiso y los objetivos, muestra hipertransparencia y se involucra plenamente en las retrospectivas.

2. Miedo al conflicto: la falta de confianza propicia la segunda disfunción, el deseo de mantener una armonía artificial que bloquea la aparición de conflictos productivos. En este caso los equipos son incapaces de entregarse a discusiones vivas y apasionadas sobre sus ideas, opiniones y perspectivas, y sus conversaciones son descafeinadas y sus comentarios cuidadosos.

Un buen Scrum Master alienta a la discusión de desacuerdos, a ser valientes y a tener coraje para exponer la opinión de cada cual, y así enriquecer las perspectivas de cada miembro y reforzar el objetivo común.

3. Falta de compromiso: la falta conflicto propicia la tercera disfunción, ya que sin exponer y debatir las verdaderas opiniones de forma abierta y apasionada pocas veces se produce claridad y consenso, lo que irremediablemente lleva a la falta de compromiso. En este caso puede ocurrir que los miembros del equipo fingan estar de acuerdo en las reuniones.

Trabajando la claridad en el equipo el Scrum Master lleva a que sus miembros se comprometan mutuamente entre si, así como con las partes interesadas externas, de forma que los miembros acepten de verdad las decisiones que toman, y que se comprometan con ellas, incluso con aquellas que votaron en contra.

4. Evitación de responsabilidades: con la falta de compromiso con un plan de acción se produce esta cuarta disfunción, los miembros de equipo no son capaces de responsabilizarse con su desempeño y su comportamiento. Hasta los miembros más proactivos y motivados suelen vacilar antes de llamar la atención a sus compañeros sobre acciones y conductas contraproducentes para el bien del equipo.

Como Scrum Master hemos de trabajar los acuerdos y directrices de actuación del equipo. Estas nacen, se consensuan y se explicitan en las retrospectivas, así cada miembro se coresponsabiliza de cumplirlas. Por otra parte los interesados, la presión entre compañeros (peer pressure) y la revisión de los resultados del sprint también generan responsabilidad.

5. Falta de atención a los resultados: la falta de toma de responsabilidades propicia que necesidades individuales como el ego, el estatus personal, el desarrollo de la carrera personal, el reconocimiento o las necesidades del departamento se sitúen por encima de las metas colectivas del equipo, y por tanto del éxito del mismo.

A través de la mejora continua el equipo ganador evoluciona a través de un objetivo común, los resultados del producto se revisan empíricamente al final de cada sprint y cada release, y los resultados de mejoras en la forma de trabajar con cada una de las retrospectivas.
Y ahí estuvimos, debatiendo sobre el libro y mucho más temas relacionados y no relacionados :)
En el meetup también vimos el test que creó Patrick Lencioni y que publica en su libro, que sirve como herramienta de diagnóstico para un equipo, y que por cortesía de CREZCOLAB está disponible en formaro pdf aquí.

domingo, 1 de abril de 2018

¿Qué técnica de retrospectiva es apropiada para tomar feedback del equipo y mejorar su eficiencia?

"Te Boat" del kit de retrospectivas de Spotify Labs - Thanks to
Martin Österberg, Behnosh Esni, Sara Rabiee & Zuza Majkowska
Si queremos trabajar la eficiencia de un equipo podemos utilizar la dinámica de retrospectiva conocida como "el barco" o "el velero". Trata de representar al equipo como un barco tomando rumbo a una isla con rocas dificultando el camino, la dinámica se basa en un análisis DAFO (Debilidades, Amenazas, Fortalezas y Oportunidades).

El barco es una metáfora del equipo, la isla y las rocas representan influencias externas, y el sol es la zona para los agradecimientos.
  • Debilidades: el ancla representa las debilidades internas del equipo, lo que lo frena, lo que lo limita y bloquea.
  • Amenazas: las rocas y tiburones entre el barco y la isla representan las amenazas, impedimentos o riesgos externos al equipo que pueden complicar el camino del mismo.
  • Fortalezas: Las velas representan las fortalezas del equipo, lo que lo hace fuerte, aquellas cosas que lo hacen avanzar.
  • Oportunidades: La isla a lo lejos representa el objetivo a alcanzar, el objetivo del sprint, una release, el estado ideal, donde el equipo es bien visto y el cliente está encantado con el trabajo.
  • Agradecimientos: No podía faltar el sol, una zona para que los miembros puedan dejar agradecimientos por cosas concretas a sus compañeros.
Dinámica de la retrospectiva
Resultado de una retrospectiva hecha con la técnica del barco
Todos los asistentes identifican por individual elementos de las cinco zonas del tablero y los escriben en post-its. Usualmente el Scrum Master cronometra 5 minutos para esta actividad. Les suelo decir a los asistentes que no tienen que esforzarse para sacar elementos, los importantes están ahí en nuestra cabeza. Esforzarse suele ser buscar lo que no está.

Habiendo escrito todos sus elementos, los asistentes se levantan uno a uno y colocan sus post-its en el tablero. Con cada post-it dan una breve explicación, y si hubiera elementos anteriores similares o iguales, los colocan agrupados junto a estos. Puede que en este punto se produzca algún debate sobre el grupo de elementos, es el momento de ventilar, de celebrar éxitos y llorar fracasos.

Cuando tengamos todos los elementos colocados y agrupados, identificamos cuáles son los prioritarios para buscar acciones de mejora, podemos hacerlo mediante una votación con tres palitos o puntitos por asistente, y que cada cual distribuya como considere.

Finalmente hacemos un brainstorming de ideas para sacar acciones de mejoras siempre enfocadas a llevarnos a nuestro destino, llegar la isla, a lo que hayamos definido como nuestro objetivo.