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.

sábado, 31 de marzo de 2018

¿Hay algún ejercicio para detectar como puede impactar un cambio organizacional a la motivación de las personas?

Recientemente asistí a un meetup del club de lectura de Madriagil en que hablamos sobre el libro de Management 3.0. Como taller basado en el libro, hicimos un ejercicio con los Moving Motivators que Jurgen Appelo inventó para reflexionar sobre la motivación y cómo se ve afectada por un cambio organizacional como lo es una transformación ágil. El ejercicio se basa en los diez deseos intrínsecos derivados de los trabajos de Daniel Pink, Steven Reiss y Edward Deci.

El ejercicio se hace en tres pasos:

Primer paso: ¿Qué motivadores son importantes para ti? Coloca las tarjetas en orden de izquierda (menos importante) a derecha (más importante).

Paso dos: ¿Cómo puede un cambio afectar a tus motivadores? Mueve la tarjeta hacia arriba para un cambio positivo y hacia abajo para uno negativo.

Paso tres: El cambio organizacional se refleja en tus motivadores. Cuando la mayoría de tus motivadores importantes disminuyan, o cuando suban los menos importantes, es posible que tengas que plantearte algo...

En el meetup aplicamos el ejercicio a un supuesto cambio organizacional que llevaría a nuestra compañía a una cultura como la de la empresa de desarrollo de videojuegos Valve, una de las empresas más ágiles del mundo, incluso teal según los paradigmas organizacionales descritos por Frederic Laloux.

Juego completo de cartas Moving Motivators de Managment 3.0
Cada participante averiguó los cambios en sus motivadores con una baraja propia, barajas cuyas tarjetas distribuimos cada uno en paralelo sobre sola mesa. El objetivo era saber cómo los cambios afectaban al grupo completo de participantes. Si el cambio concordaba potenciando los motivadores principales de la mayoría, el cambio sería muy bienvenido y fácil de implementar.

Después de los tres pasos cada participante "visitó" las tarjetas de los demás, y por turnos cada uno explicó a su orden de los diez motivadores. Esta técnica pone de relieve el interés del grupo y evita reuniones, además, nos ayudó entendernos y a aprender unos de los otros.

En general el cambio coincidió con los motivadores de los participantes, en muy pocos no fue así, me llamó la atención que no fuera así para aquellos en que las relaciones y la aceptación no son motivadores importantes. Por otro lado fue interesante percibir la diversidad que suele haber en los grupos, aunque pudiéramos pensar que todos los motivadores pudieran ser importantes, para algunos ciertas motivaciones no lo eran en absoluto, simplemente no les importan. Esa diversidad también se hizo patente porque las principales motivaciones resultaron bastante diferentes entre unos y otros. La diversidad es un de los factores que hace que los equipos sean mucho más que sus partes, y es muy valioso para un equipo conocer y entender las diferencias entre sus miembros, y ahí es donde el ejercicio puede resultar muy últi para un Scrum Master.

Descargas / Downloads

lunes, 26 de marzo de 2018

¿Cómo centrar a los participantes para una reunión?

Un cuenco tibetano que con su sonido nos lleva a la meditación
Uno de los problemas que observo una y otra vez en la fase inicial de las transformaciones ágiles es que en las reuniones, especialmente en las de nivel de escalado como PO-Sync y POCLAC, los asistentes vienen corriendo, acelerados y pensando en lo siguiente a la reunión. La convivencia de culturas y de reuniones ágiles y no ágiles crean estrés, una sensación de caos e incertidumbre con la que hay lidiar.

Suelen abrir sus ordenadores durante la reunión para contestar frenéticamente emails o atender otras cuestiones con lo que no estan realmente presentes... Una directiva me pidió ayuda, decidí pedir ayuda a mi compañera María para hacer una microsesión de 5 minutos de Mindfullness acompañada del sonido vibrante de un cuenco tibetano. Es sabido que esta vibración ayuda a reducir la ansiedad y aliviar el estrés, mejora la concentración, equilibra los hemisferios cerebrales, mejora la creatividad, alivia los dolores de cabeza, ayuda a equilibrar el sistema endocrino y equilibra y limpia el aura y los chakras de las personas. :-)

El cuenco que me ha encontrado a mi :-) - Gracias María
Antes de empezar la reunión dejamos el cuenco a la vista sobre la mesa para que todos lo vieran a medida que llegaran a la sala de reuniones; resultó que llamó la atención y preparó a los asistentes para abrir la mente a lo que vino después.


Un fuerte "gong" inició la sesión y todos se sentaron alrededor de la mesa de reuniones. Les invitamos a cerrar portátiles, poner los móviles en silencio y a sentarse de forma cómoda con los pies bien planos sobre el suelo.

Con un golpe suave y recorriendo el borde del tazón con un mazo o baqueta este vibró llevandolos a un estado de meditación. Con voz muy suave, apenas un susurro, guiamos a los asistentes en los diferentes pasos que deben seguir para lograr una relajación completa (técnica de modelado simbólico):
  • Cerrar los ojos.
  • Fijarse en la respiración, ser conscientes de las inspiraciones y expiraciones profundas con el diafragma; la respiración es la puerta de entrada de la meditación.
  • Fijarse en como el aire entra y sale por la nariz, en la diferencia de temperatura.
  • Entrenamiento autógeno, visualizando imágenes relajantes e imaginandonos en un lugar que nos relaje.
  • Dejarnos llevar...
Después de 3 minutos los asistentes estuvieron relajados y centrados, la sesión:
  • Cambia el cerebro de forma positiva.
  • Reduce la actividad de la amígdala (ira, estrés…).
  • Aumenta el funcionamiento de la corteza prefrontal (empatía, toma de decisiones).
  • Incrementa el aporte de oxígeno al cerebro, lo que beneficia también al aprendizaje.
  • No permite que nuestras emociones nos tomen de rehenes.
  • Nos ofrece un cambio de perspectiva en la manera de manejar los conflictos.
La reunión fue más resolutiva y creativa que nunca, a algún directivo se le erizaron los pelos, jajajaja... pero más de uno nos pidió la sesión previa para sus reuniones.

Mis agradecimientos a Patricia por dejarme el cuenco y a María, mi pareja, que me proporcionó material para el post :-*

jueves, 22 de marzo de 2018

¿Cómo incrementar la capacidad de un equipo ágil?

Los equipos ágiles son equipos ganadores - благодаря Sanya
Sabemos que no hay nada más potente que un equipo empoderado, autoorganizado, autogestionado y multifuncional que entrega software de valor, testado y funcionando con cada sprint y que opera bajo un marco ágil como Scrum. Pero, ¿qué hacer si quisiéramos aumentar la capacidad del equipo?

Los miembros del equipo son los responsables de ejercer influencia en la composición del equipo, haciendo recomendaciones sobre cómo incorporar o sacar personas del mismo. En cualquier caso si queremos aumentar la capacidad del equipo hemos de contar con él, al fin y al cabo sus miembros saben de la realidad de su entorno y son los mejores para encontrar soluciones. Para ello podemos plantear la necesidad en la siguiente retrospectiva, o también convocar una reunión ad-hoc.

Con una actividad de brainstorming el equipo propondrá ideas, quizá incorporar un miembro nuevo, una persona más de java o un maquetador, o quizá recursos o herramientas que puedan acelerar su velocidad

Seleccionada una de las ideas habremos de indagar con recursos humanos o con ingeniería los costes que supone al incorporación de un nuevo técnico o de una nueva herramienta. El Propietario del Producto es el responsable de la presupuestación de personas y recursos, él habrá de analizar el impacto de los costes asociados que darán más capacidad al equipo y aprobarlo o rechazarlo, quizá, hecho el análisis, no haya necesidad de incrementar la capacidad del equipo.

Si la solución fuera ampliar el equipo, recordemos que no debemos de pasar de 9 miembros, deberemos de contar con recursos humanos para que provean de técnicos con las habilidades demandadas, pero debe de ser el equipo quien decida la persona a incorporar, al fin y al cabo son ellos los que van trabajar con ese nuevo miembro.

sábado, 17 de marzo de 2018

¿Cómo lograr la atención en un evento?

Cuando como trainers, Scrum Masters o coaches ágiles conducimos algún evento o actividad de equipo o tribu, es necesario que en ciertos momentos el grupo escuche una explicación, una instrucción u cualquier otra información que queramos compartir. Imaginemos que en un Town-Hall, un bootcamp, un openspace o una clase necesitamos llamar la atención, en esas situaciones gritar no sirve, necesitamos una herramienta para crear silencio de forma rápida.

Para ello quiero mostrar una técnica de coaching muy simple, llamada silencio viral o silencio autoorganizadoExplico a todos los asistentes al inicio del evento que si en algún momento necesito dirigirme al grupo, voy a levantar una mano, y cuando ocurra esto todos levantamos la mano y a medida que lo hacemos dejamos de hablar para prestar atención. Esto será valido para cualquier persona que quiera dirigirse al grupo.
  • Una persona, trainer, coach o asistente que tenga algo que decir levanta su mano derecha.
  • Los demás asistentes también levantan su mano derecha, los coaches suelen estar más atentos y son los primeros en reforzar al iniciador. 
  • Todos los asistentes colaboran para lograr el silencio dando un ligero toque a aquellos compañeros que todavía sigan hablando, puede que no se hayan dado cuenta o simplemente que sigan hablando pese a tener la mano levantada.
  • Debemos de esperar a que todos tengan la mano levantada y haya absoluto silencio.
  • Finalmente el iniciador baja la mano y expone lo que tenga que decir.
Silencio viral o autoorganizado - cortesía de Pixbay
Es una buena técnica que fomenta el respeto por otras personas que deseen expresar algo, y también hace que aprendamos a escuchar.

El uso continuado de la técnica crea una especie de condicionamiento, que cuando se produce el estímulo y alguien levanta la mano, se produzca automáticamente el silencio, muchos de los agilistas que acudimos a eventos y ceremonias de Agilidad ya lo llevamos incorporado. :-)

miércoles, 14 de marzo de 2018

¿Cómo experimentar un proyecto con cascada y luego con Scrum?

Este es un ejercicio del curso Scrum de
El producto:
tarjetas de invitación de cumpleaños
Una de las formas más potentes para experimentar Scrum es hacerlo mediante la comparación. Primero experimentar la construcción de un producto por fases en cascada, para luego vivir la construcción del mismo producto mediante sprints que incorporen feedback y aprendizaje de forma natural.

Alexandre Magno ha ideado la simulación que expongo en este post, me parece excepcional, la hemos liderado juntos y la voy a incluir en mis cursos de Scrum. Para poner contexto explicamos a los asistentes que nuestro hijo quiere invitar a 12 amiguetes a su cumpleaños y necesita 12 tarjetas de invitación. Resulta que le hace mucha ilusión que las invitaciones tengan un payaso sonriente pintado en la portada.

Primera ronda de construcción en cascada

Dividimos a los asistentes en cuatro equipos, y a cada equipo le asignamos una tarea en concreto. Un quinto voluntario hará de tester.
Especialista de coloreado trabajando
  • Equipo 1: dobla y corta una hoja A4 en 2 cuartillas
  • Equipo 2: dibuja un payaso
  • Equipo 3: colorea al payaso
  • Equipo 4: prepara en la parte interior de la cuartilla áreas para el nombre del niño invitado, la fecha y la dirección de la fiesta
  • Tester: le damos el payaso original y comprobará la calidad de cada una de las tarjetas construidas
Pedimos a cada equipo una estimación del tiempo que piensa que necesita para desarrollar su tarea específica para crear 12 invitaciones, y los tiempos los apuntamos en una pizarra.

Las fases de construcción las harán de forma secuencial, el equipo 2 por ejemplo habrá de esperar a que el equipo 1 acabe completamente con su trabajo. En la simulación los equipos que no están trabajando estarán ociosos, no es buena cosa. En la realidad esos equipos, o sus miembros, probablemente estén trabajando en otros proyectos, situación que tampoco es deseable, porque cuando el equipo que está en curso haya acabado seguramente el equipo que les siga estará en otra cosa que no habrá acabado todavía. Lo que suele ocurrir en nuestras realidades es que estamos llevando a los equipos al trabajo, y eso no siempre cuadra, ya que planificamos los proyectos en función de la disponibilidad de las personas.

Tablero con los tiempos estimados, que suman 19
minutos, y los tiempos reales de ejecución que
suman aproximadamente 11 minutos
Cuando el equipo 2 haya terminado su trabajo, nos paramos y preguntamos a la sala cuál es el % de progreso. Según los tiempos estimados versus los hechos, suelen decir que están alrededor de un 30% de trabajo hecho, pero no es cierto ya que no probablemente no habrá ni una sola invitación terminada.

Es buen momento para trabajar la diferencia entre proyecto y producto, por tanto que en la gestión de proyectos medimos el progreso por las actividades hechas, y que en Scrum medimos el progreso por los incrementos de producto terminados.

Una vez el equipo 3 haya acabado de colorear los payasos, introducimos un cambio, explicamos a los asistentes que resulta que los niños dicen que sería guay si algunas de las invitaciones tuvieran en su portada a Mickey Mouse.

Los asistentes a la simulación protestarán, dirán que habría que volver empezar desde cero, que no pueden ni aprovechar el trabajo del equipo 1, las hojas dobladas y cortadas en cuartillas, porque el proceso es en cascada y todas las cuartillas ya tienen pintadas al payaso...

Si insistimos en que los niños están demandando a Mikey dirán que es un cambio de alcance, y que es posible si como cliente estamos dispuestos a desembolsar una cantidad similiar al proyecto original. Como ocurre con nuestros clientes en la realidad, un cambio tan pequeño como introducir a Mickey, se convierte el inviable y como cliente nos conformamos con payasos en todas las invitaciones. :-(

Simulación en la que solo 1 de los 12 payasos pasó calidad
Los equipos siguen trabajando en el proyecto original y acaban por construir las 12 invitaciones.

Finalmente entra en escena el tester que comprueba las invitaciones una a una, comparándolas con la original. Como ocurre en un proyecto en cascada, no podemos obtener feedback hasta el último momento, y como  no hemos tenido oportunidad de contrastar, las invitaciones no cumplirán con la calidad y este suele desechar muchas invitaciones... Mostramos y debatimos sobre las diferentes problemáticas que ha detectado el tester.

El equipo 1, cuya tarea es doblar y cortar, suele sentir que ha hecho un buen trabajo, que el fallo no está en ellos, su responsabilidad solo era doblar y cortar y eso está bien hecho.

Los que dibujan y colorean payasos probablemente se sientan mal, porque los fallos o carencias de calidad seguramente estén en sus tareas. En la realidad la situación empeora cuando para solucionar el problema las empresas segregan responsabilidades y definen nuevos especialistas con la idea de garantizar la calidad. Se crearán especialidades como el dibujador de caras de payaso, o el coloreador de pelo... en definitiva una sobrecarga de especialistas y de especialidades que reducirá toda colaboración en y entre los diferentes equipos.

Segunda ronda de construcción con Scrum
Definición de hecho y un cuadro con las
invitaciones que cada equipo estima por sprint
La segunda ronda trata de la construcción de las 12 invitaciones mediante 4 sprints, en los que cada equipo construye tantas invitaciones como considera le puedan caber en un sprint de minuto y medio.

Les damos una hoja A4 a cada equipo y le invitamos a que trabaje como equipo autoorganizado y multifuncional, y que construya invitaciones de principio a fin. En una pizarra anotamos cuantas invitaciones creen que pueden hacer en el primer sprint. Es el momento de introducirles que el el primer sprint es de calibración y que trata principalmente de encontrar su capacidad real, su velocidad.

Suele ocurrir que en el primer sprint no hayan aprendido todavía a colaborar, y a final del mismo no haya ninguna invitación terminada.

Entre sprints hacemos una retrospectiva de medio minuto donde les invitamos a hablar sobre como han trabajado, que ha ido bien, que no y que busquen al menos una mejora para el próximo sprint. Es el momento en el que como trainer podemos incluir dos sugerencias:
Equipo coloreando verdaderamente de forma ágil,
todos focalizados a la vez en la misma invitación
  • Introducir un límite WIP de 1, instarles a que hagan una invitación tras otra y no inicien varias invitaciones a la vez
  • Y recordarles que el trainer es a la vez el Propietario del Producto, y que en cualquier momento pueden pedirle feedback
Ocurrirán cosas como lo que se puede ver en la foto de la derecha, los equipos encontrarán caminos para la colaboración, llamarán al Propietario del Producto para enseñar las invitaciones y tomar feedback, mejorarán las invitaciones con cada sprint y también mejorarán la forma de como colaboran. Se generará un ambiente alegre y colaborativo con un campo emocional muy energético... lo suelen pasar muy bien.

10 invitaciones exitosas resultantes de los 4 sprints, todas
ellas son un éxito desde la perspectiva del contento de los niños
En el segundo sprint introducimos la petición de los niños de pintar algunas invitaciones con Mickey en la portada. En este punto los asistentes descubren que introducir a Mickey no tiene coste añadido alguno, como mucho puede pasar que haya que descartar alguna invitación de payaso no terminada.

La disponibilidad del Propietario del Producto y la interacción con el mismo hace que florezca la creatividad de los equipos y se produzcan invitaciones cada vez mejores para su propósito: ser atractivas para los niños y animarles a venir a la fiesta de cumpleaños. :-)

Esta simulación permite introducir los conceptos subyacentes al proceso de Scrum y compararlos con los procesos en cascada que conocen de su día a día. A lo largo de la formación, o acompañamiento posterior, podemos referirnos a situaciones vividas en la simulación, referencias que en la mayoría de los casos son muy esclarecedoras y fáciles de comprender para los asistentes, y ayudan potentemente a fijar el conocimiento recién obtenido.
Mis agradecimientos a los asistentes al curso del noviembre de 2017 por ilustrar este post

miércoles, 7 de marzo de 2018

¿Un coach ágil es un rol a tiempo completo?

Cortesía de Pixabay
Como ya hemos visto, un Scrum Master está comprometido con el proceso y las personas de los equipos, un coach ágil solo está involucrado con estos equipos, pero está comprometido con el equipo de equipos o tribu, y con la transformación ágil de la que forma parte.

Un coach ágil tiene sentido en una compañía cuando está al frente de al menos 5 equipos de desarrollo, de una tribu de alrededor de 50 personas. En ese escenario el coach ágil es absolutamente necesario a tiempo completo, por supuesto durante la implantación pero también durante toda la consolidación de la Agilidad, que suele ocurrir en alrededor de los primeros 21 sprints.

Empezará liderando los primeros pasos en Scrum, luego acompañará a aquellos equipos con más dificultades reforzando relaciones e involucrando a los interesados, lidiará con impedimentos mayores en las fronteras de la tribu, especialmente con directivos de otras áreas no ágiles. Ese tipo de impedimentos requieren mucho tiempo de un coach ágil porque ha de lidiar con directivos, que suelen ser muy ejecutivos, y con las frustraciones de los equipos. Finalmente establecerá y asentará los eventos a nivel de tribu, como reuniones de sincronización de Propietarios del Producto, planificaciones cruzadas con todos los equipos y otros como reuniones de desarrollo de tribu y sus equipos como lo es POCLAC por ejemplo.

Tiene que estar continuamente zambullido en el sistema desde una perspectiva holística, sentir el latido de cada equipo y conocer su campo emocional. En momentos de cambio, que son frecuentes en una transformación ágil, se hace necesario el acompañamiento de personas y coaching de los equipos ya que es cuando más conflictos y malentendidos se suelen producir. Si como coach ágil detectamos un problema de forma tardía, cuando te pones a ello, este ya ha iniciado su propio camino, ha divergido de la Agilidad y costará más tiempo y esfuerzos corregirlo.

Ha de asistir a todas las reuniones clave, cuando se produce una crisis ha de estar y las crisis son imprevisibles. Es especialmente importante que asista a las que no sean ágiles, esas son peligrosas ya que en estas puede ocurrir que se tomen decisiones no alineadas con la Agilidad. Una disfunción importante es cuando el coach ágil confronta a otros con la realidad no ágil y luego no está parea acompañarlos en la resolución, como por ejemplo poner sobre la mesa la falta de entrega en las revisiones de sprint y luego no estar...

Una de las responsabilidades más importantes del coach ágil es redefinir las estrategias de transformación y redirección a todos los niveles en base a los resultados de la mejora continua, hacer seguimiento de la evolución y tomar las medidas adecuadas. Si el coach ágil no está a tiempo completo tendrá el foco en lo trivial, en los problemas más evidentes, en cosas como si se aplica correctamente Scrum, perdiendo de vista los problemas de fondo, donde realmente un coach ágil puede aportar valor y hacer que la transformación ágil sea un éxito.

La carencia más común en las empresas españolas es la gestión de personas. Es por ello que un coach ágil aqui es mas importante que en otros países, somos muy flexibles en cultura y sociedad, y aunque la Agilidad sea más fácilmente comprendida aquí, es mas fácil que los directivos diverjan y vuelvan a sus roles anteriores, como por ejemplo que en Chapter Leads y Propietarios del Producto emerjan comportamientos de jefe de proyecto. Un directivo alemán o inglés habrá aprendido su nuevo rol e intentará no salirse de sus responsabilidades con Agile, aunque no lo comprenda.