Resumen Agile Coaching main

Resumen Agile Coaching


El libro Agile Coaching de Rachel Davies y Liz Sedley es un manual para entender cómo hacer coaching a un equipo que pretende ser Agile.

sdcoachMini

El público objetivo de este libro sería cualquier persona que desee enseñar a un equipo a ser Agile, principalmente Agile Coaches y Scrum Masters.

El libro está dividido en 4 bloques principales:

  • Inicio al coaching
  • Planificación y comunicación
  • Calidad en el desarrollo de software
  • Aprender del feedback

Es un libro fácil y rápido de leer (menos de 200 páginas). Está escrito en un lenguaje muy ameno, con algo de teoría pero principalmente con ejemplos muy básicos y anécdotas personales de las 2 autoras. A través de estas situaciones cotidianas interiorizarás el papel del coach.

De este libro he sacado 2 joyas que guardaré en mi caja de herramientas de Scrum Master y que utilizaré en mi día a día:

  • Una definición impecable del rol del coach dentro de una organización en el primer capítulo
  • El método PROPER para afrontar cualquier cambio que quieras introducir en el equipo, basado en PDCA con un enfoque experimental

Si todavía no tienes el libro y quieres comprarlo, puedes hacerlo en el siguiente enlace de afiliados. A ti no te costará más y me ayudarás a mantener este blog.

Sin más aquí tienes mi resumen “Agile Coaching”.

Resumen Agile Coaching

ASPECTOS BÁSICOS DE COACHING

1.Empieza el camino

Tareas de un agile coach:

  • Estar alerta de cómo funciona el equipo
  • Dar feedback al equipo de cómo funciona
  • Educar y formar sobre agile
  • Facilitar sesiones agile
  • Dar ánimos y ayudar cuando las cosas no salen como queríamos

Hábitos:

  • Liderar dando ejemplo
  • Mantener la calma y autocontrol
  • Establecer un ritmo sostenido y realista
  • Utilizar un lenguaje inclusivo, nosotros mejor que tú y yo. Compartir información mejor que criticar o aconsejar. Evitar generalizaciones y etiquetas.
  • Aprender todo el tiempo, sobre todo de los errores. Dejar que el equipo aprenda por sí solo. También leer y asistir a eventos (te permitirá practicar tu speech). Comparte con otros agile coachs.

Es importante que te identifiquen como un coach, que un manager te presente. Si no preséntate tú mismo,  mostrando los beneficios de agile y lo que tú como coach vas a ofrecer.

Para saber por dónde empezar, seguir una aproximación agile, método PROPER:

  • Problema
  • Opciones (al menos 3)
  • Experimento con una opción
  • Revisar si ha funcionado, si no aprender

Introducir cambios que mejoren los resultados del equipo lleva tiempo, no desesperes, utiliza y comparte los small wins.

Es difícil también tomar el papel de coach que da consejo y deja que el equipo haga en lugar de hacerlo tú mismo. Una alternativa es hacer de líder-coach desde las trincheras. Esto te dará un mayor respeto del equipo porque serás uno más,  pero dificultará que el coaching sea tu principal preocupación y ver la big picture.

Revisa constantemente tu labor en el equipo: ¿es más agile que hace un mes? ¿Cuál ha sido mi contribución?

Cuando llevas mucho tiempo con un equipo o en una compañía,  es muy probable que te contagies del entorno y pierdas frescura. Da un paso atrás e identifica los puntos de mejora que te parecían ‘comunes’. Si el equipo ya es maduro y no hay puntos de mejora, es hora de irse.

2.Trabajando con la gente

Es necesario establecer conversaciones con los individuos del equipo para hacer coaching. Lo 1° es saber escuchar al otro sin juzgar y con atención.  Cuando te vengan a ver, deja lo que estés haciendo y escucha con atención. Buscad un sitio tranquilo para crear un espacio seguro.

Céntrate en los hechos aunque escuches opiniones. Haz preguntas clarificadoras y repite lo que te han contado para demostrar que has escuchado y que has entendido correctamente.

No pienses en tu respuesta mientras hablan, sino en qué motivación hay detrás de la conversación,  si quiere consejo, un favor, ayuda, empatía, si está triste o enfadado.

Cuando acabe la conversación es necesario un seguimiento. Es posible que necesites seguir investigando o contrastar información antes de comprometerte a una próxima acción.

Las mismas reglas de escuchar activamente e ir repitiendo lo que dicen sirven para las reuniones de equipo.

Cuando seas tú el que hable (por ejemplo para dar feedback) utiliza primero los hechos y después marca claramente cuales son tus observaciones. No te olvides de dar feedback positivo también.

Especial cuidado con los conflictos. Si son leves deja primero a ver si los resuelve el propio equipo. Utiliza Comunicación no violenta: observación, sentimiento,  necesidad,  petición. Como mediador nunca debes tomar parte. Intenta describir la situación desde el punto de vista del equipo. Si hay un conflicto en mitad de una reunión haz una pausa para que la gente se calme. Después pregunta si podemos seguir con la reunión o creen necesario primero tratar primero el conflicto.

Utiliza gradientes de opinión (1 es bloqueo y 5 es apoyo total) para averiguar si hay consenso o no sobre un cambio a introducir.

3.Liderando el cambio

Los cambios deben ser progresivos, sin prisas. Coge un problema y propón una solución.  Después otro. Si apuntas a demasiados problemas te identificarán como alguien negativo y te ignorarán.

Trata de convencer antes de ponerlos en marcha. Dales confianza hablando de otros equipos que lo hicieron con éxito antes. Acompáñales para explicarles cómo empezar.

Para provocar cambio es mejor hablar y convencer primero sobre el problema.  Después expón tu solución.  Prepárate para obtener siempre algo de resistencia,  pero persevera y explica por qué crees que es una buena solución (pros y contra, retorno de inversión…)

Otra forma de generar cambio es hacer preguntas tipo ¿Qué podemos hacer para que no se repita? Utiliza también preguntas para poner a prueba las convicciones y políticas de la empresa ¿de verdad está prohibido probar? Evita usar la pregunta ¿por qué? mejor enfocarse a las soluciones y posibilidades. Utiliza el verbo pensar en las preguntas ¿cuánto tiempo llevas pensando en este problema? ¿has pensado alguna solución? Utiliza 5 whys para averiguar las causas raíz de un problema.

Cuando tengas que guiar no hagas preguntas, ya que si la respuesta no es la que esperas y los corriges parecerá que no has escuchado su respuesta. En general, no hagas preguntas si ya conoces la única respuesta.

Crea un grupo de estudio,  una reunión informal con 5-10 personas dentro o fuera de horario en la que se rota al orador y éste explica un capítulo de un libro y lo discute con el grupo.  Estos estudios después pueden desencadenar acciones. También funcionan las tech talks, o enviar a alguien del equipo a conferencias y que después comparta lo que ha aprendido con el equipo.

Como coach del equipo, enseña primero como se facilita y después deja a otro que facilite mientras observas. Intervén solo cuando sea estrictamente necesario, y deja tu feedback para el facilitador para el final. El facilitador es más efectivo cuando no tiene un papel protagonista en la discusión.

4.Construyendo un equipo agile

Lo primero es que se conozcan. Para ello utiliza las dailies y retros, e incluso algún acto social fuera del trabajo como comer juntos.

Para construir confianza,  lo mejor es ser transparente y abierto, hablando de tus emociones y de tus errores. Puedes hacer una dinámica para que cada uno cuente una historia personal al resto, o usar un test de Belbin o Myers-Briggs y compartir los resultados.

El entorno debe ser seguro, el error no puede ser castigado.

El entorno de trabajo ideal no existe, pero podría ser un espacio abierto para el equipo (y nadie más), una zona de relax y una sala de reunión donde discutir sin molestar.  Cada equipo debe personalizar el suyo a sus posibilidades y necesidades.

El equipo debe estar junto, sin importar qué rol tiene cada uno.

Debe estar motivado, tener backlog y plazos razonables aunque retadores. También espacio para pensar, mejorar e innovar. Ej: gold cards, fedex days. Celebrad las ocasiones, un fin de release, una puesta en producción, puntuación record en el market. Encuentra los factores de higiene que desmotivan (ej: café malo, máquina de agua, laptops lentos, salario decente).

Agile Coaching Plants

PLANIFICANDO COMO EQUIPO

5.Dailies

Cuando el equipo es autoorganizado, se escuchan los unos a otros, y no se entra en detalles, es un signo de buena daily. Evitar el formato report al responsable.

El motivo para hacerlas de pie es que así tardan menos tiempo. No tiene que ser en una sala de reuniones, mejor delante del tablero. Si no hay más remedio, utilizar un tablero portátil.

El equipo debe mantener la conversación en el plan y en el propio equipo. No intervengas demasiado como coach, para no parecer el director ni el único interesado.

Al daily debe ir todo aquel que de alguna manera interviene o quiere estar informado del plan y de las tareas que deben completarse, incluso PO, clientes, product managers, etc. La información debe ser de interés para todo el grupo, si no lo es trátala con un grupo más reducido al final. Apúntalas en una pizarra o en postits para que el equipo pueda priorizarlas.

El coach aporta valor actuando como la consciencia del equipo, recordando los compromisos cuando nota que el equipo se aleja de ellos. El foco del equipo está normalmente en las historias, y es común olvidarse de fechas, compromisos, eventos y acuerdos. El coach debe recordarlos cuando sea necesario dejando a la vez que el equipo sea auto-organizado.

Si alguien llega tarde, no repitas información para que se actualice, no es justo para el resto. Tampoco extiendas la daily más de los 15 minutos, cíñete a las 3 preguntas y no des detalles, o incluso haz subequipos.

Tampoco dejes que un Project Manager o similar secuestre la daily para su beneficio.

6.Entendiendo qué construir

Las historias de usuario (User Stories, US) se diferencian de los requerimientos porque están hechas para que el equipo haga preguntas, no para aceptarlas sin más. La historia crece y se transforma a través de las preguntas.

Ron Jeffries dice que una US = 3 Cs: Card, Conversation, Confirmation.

Las conversaciones permiten evolucionar las US, dividirlas, y anticiparlas con el tiempo suficiente. La responsabilidad del coach es que estas conversaciones se lleven a cabo.

Es mejor trabajar con tarjetas físicas que con software y proyector, ya que se promueven mejores conversaciones y es más fácil planificar. Es normal (y muy sano) romper varias tarjetas en cada reunión de planificación, fruto de cambios o de dividirlas de forma distinta.

Para equipos nuevos con US es bueno utilizar la plantilla “Como … quiero … para …”. Ayudan al equipo a hacer las preguntas correctas, sobre todo aquellas que nos acercan al usuario final.

Los detalles de las US se escriben con tests. Para planificar solo es necesario escribirlos en la tarjeta, después pasarán a ser tests automáticos.  El equipo debe ayudar a que estos tests se escriban y sean completos, sobre todo los casos extremos fuera del happy path. Es un trabajo en conjunto. Se puede usar la plantilla “Dado … cuando … entonces ..” (given … when … then …). Una US no es documentación, se pueden hacer fotos de las tarjetas y sketches pero la mejor documentación siempre serán los tests automáticos.

7.Planificando

El coach tiene que asegurar un buen uso del tiempo en la sesión de planning. Dependerá del equipo (si es maduro o nuevo) y de las US (simples o complejas). La reunión debe empezar explicando el objetivo de la iteración o release. Anima al equipo a dividir las US, ya que son más fáciles de estimar y más probables de que se construyan bien. Cuando el dev team discute los detalles técnicos y estima no es necesario que el cliente esté presente. También deben haber conversaciones sobre el diseño técnico de la solución. Utiliza flipcharts para que sean colaborativas.

Si las reuniones de planning se alargan, es mejor separar la parte de refinar las US en reuniones aparte.

Si las US son muy grandes (más de 2 días), se pueden dividir en tareas. Esto tiene la ventaja de que es mas fácil que el equipo se reparta el trabajo o que salgan casos de test adicionales. Sin embargo, si el equipo ya tiene claro lo que debe hacer no es necesario. El coach ayuda al equipo con preguntas: ¿hay que modificar la bbdd? ¿Dependemos de algún componente de terceros? …

Para estimar es necesario saber lo que hay que hacer, así que es posible separar la discusión de la US por la mañana y la estimación por la tarde,  para dar tiempo de ver algo de código. Si aún no sabemos suficiente, usa SPIKEs.

Usa planning poker para que todo el equipo participe en la estimación. Usa una matriz o escala de estimaciones con US estimadas por el equipo como referencia.

Puntos Historia en escala de estimación

Se puede construir un panel donde se tenga la foto de lo que se va a construir para las siguientes releases (con estimaciones de las US que van en cada iteración). Para ello tanto las estimaciones como los planes deben ser realistas, no optimistas. Deja siempre un margen. Si planificas para varios meses utiliza themes además de US para cosas muy grandes. Cuando tenemos el plan de la iteración se debe trasladar al panel. No es necesario trasladar las tareas a la herramienta electrónica, recordar al equipo que el foco debe estar en los entregables.

Como coach, asegúrate de que:

  • Los clientes se preparan la reunión de planning con lo que quieren (si es necesario con reuniones previas)
  • No se fuerza al equipo a coger más de lo que pueden abordar (wishful thinking)
  • No se cambian los planes a mitad de iteración
  • La velocidad del equipo es estable (aunque a veces hay variaciones, sobre todo al inicio)

El objetivo de estimar y planificar es poder tener foco en construir lo que aporta más valor y limitar el WIP con iteraciones. Esto lo hacemos normalmente cuando hacemos productos, si estamos haciendo mantenimiento de algo ya construido es mejor usar kanban, sin estimar y centrado en optimizar el flujo.

8.Hazlo visible

Los documentos electrónicos solo son útiles cuando están abiertos. Por eso los radiadores de información físicos son más útiles.

El primer radiador es el tablero, dividido en columnas que reflejan los estados de las US y tareas. Si no puedes tener un tablero, puedes poner pegatinas encima de la tarjeta de la US formando un gusano de colores (uno por estado). Asegúrate de que el panel es legible en la daily, y que el equipo comparte entregables y no se centran solo en “su parte”. Mejor si el tablero te lo puedes llevar a las reuniones.

Es necesario informar visualmente quién está haciendo qué, para detectar bloqueos y cuellos de botella.

Asegúrate de que siempre hay material para informar de nuevas tareas o bloqueos.

Otros ejemplos de radiadores son los iteration burndowns o release burnups.

Cualquier información para que sea útil tiene que estar actualizada.

seedling-1062906_Mini

CUIDANDO LA CALIDAD

9.Conseguir que se llegue al Done

Como los equipos infantiles de fútbol que van todos detrás de la pelota sin actuar como equipo para marcar goles, los equipos de desarrollo tienen que aprender a coordinarse para diseñar, desarrollar, validar y entregar como un equipo.

Es responsabilidad del equipo que se pruebe todo, no solo de los testers. Los testers ayudan con los casos más extremos y a automatizar los tests. El testing es algo vital para un equipo y olvidado con frecuencia.

Ayuda tener la definition of done, un listado de cosas que se deben cumplir para considerar algo hecho: tests escritos y pasados, documentación actualizada, código revisado y checked-in, etc.

Si se encuentran bugs antes del “done”, el coach ayuda al equipo a decidir si pasa a la siguiente iteración. Involucra al cliente si es necesario. Un bug siempre es una oportunidad para mejorar el proceso actual, tenlo en cuenta en las retrospectivas.

El coach anima al equipo a buscar feedback del tester y del cliente cuanto antes mejor. El trabajo del tester debe ser prevenir bugs (en la iteración), no recolectarlos después.

Nuevamente ser demasiado optimistas al planificar hace que después debamos sacrificar calidad, como coach debes enseñar al equipo que se puede decir “no”.

10.Guiando el desarrollo con tests

Como coach uno de los mayores retos es romper el bucle developer-tester a la hora de dar por ok un software.TDD te permite construir software sólido y que los testers centren sus esfuerzos en detectar casos extremos en lugar de trivialidades recurrentes. TDD requiere sin embargo mucho tiempo para establecerse.

Empieza haciendo que el equipo se familiarice con los tests automáticos antes de empezar con TDD. Puedes usar el ciclo PrOpER visto en el primer capítulo. El equipo debe estar de acuerdo en conjunto antes de empezar. Una posible táctica son los coding dojos. Utiliza las reglas de Michael Feathers para guiar al equipo: un unit test no habla con BBDD, ni necesita red, ni necesita tocar ficheros de configuración, ni toca el sistema de archivos, ni necesita correr por separado.

Recuerda al equipo en la reunión de planning que dejen tiempo para experimentar y aprender TDD. Igualmente el cliente deberá estar informado. Está bien comenzar escribiendo tests para el código nuevo o modificaciones. Tambien escribiendo los tests después de codificar, si los resultados son buenos. Encuentra el mejor compromiso con el equipo.

En conjunto con TDD se usa también integración continua, una forma de trabajar que consiste en hacer chechin del código con mucha frecuencia (cada 2 o 4 horas) y que siempre compile y pasen todos los tests. Para ello los tests deben correr rápido (máx. 10 minutos).

Es recomendable que el equipo empiece integrando asíncronamente, cada uno que quiera integrar que coja un token y pase los tests antes de hacer checkin. Cuando todo esté listo avisa al equipo para que el siguiente pueda integrar. Cuando el equipo esté habituado utilizad entonces una herramienta para integraciones asíncronas. En este caso, asegurad que cuando se rompe la build el feedback es inmediato y visible para que quién la haya roto tome la responsabilidad de arreglarlo inmediatamente.

11.Código limpio

Utiliza diseño incremental para simplificar la estructura del código a medida que escribe nuevo código o tests, de forma incremental. El diseño debe ser simple y basarse en las necesidades actuales, y no tratar de tener en cuenta todos los posibles casos futuros. Evita también el no invertir tiempo en mejorar el diseño en cada US para ir rápido. Esa velocidad solo será en el corto plazo. Usad sketches para las discusiones de diseño.

Utiliza también refactoring para mejorar el diseño, como parte del desarrollo, para mejorar la legibilidad del código y eliminar duplicidad. El refactoring es equivalente a ordenar de vez en cuando tu casa, si no lo haces frecuentemente tu vida en casa se complicará rápidamente ya que no encontrarás nada y te costará más moverte por la casa.

La propiedad compartida del código es necesaria para que cualquiera pueda tocar cualquier parte del código. Para facilitarlo propón al equipo usar un mismo estándar de código. A evitar también los especialistas que son los únicos que tocan el módulo “X”.

Todo lo anterior se potencia con pair programming, o programar en parejas. Las parejas deben ir turnándose cada pocos minutos, e ir cambiando de parejas cada pocos días. Ping pong pair programming asegura que los roles de piloto y copiloto se intercambian con frecuencia.

Como coach, puedes utilizar pair programming para enseñar a los desarrolladores de un equipo,  pero hazlo siempre respetando su rol y explica bien siempre el por qué de tus acciones.

Agile Coaching Resumen

ESCUCHANDO EL FEEDBACK

12.Demostrando resultados

Aunque no tengas nada que enseñar, o salgas a producción, o el cliente ya haya visto el incremento de producto, la demo debe celebrarse e incorporar valor a los asistentes.

La demo debe ser siempre al acabar la iteración. Si alguien importante no puede venir, es posible convocar otras sesiones adhoc.

Planifica los pasos que el equipo debe dar para una demo exitosa (preparar build, datos para la demo, comprobar la red, etc.)

El cliente puede empezar la reunión explicando el objetivo de la iteración. Después es el equipo el que debe llevar la reunión,  demostrando lo que han construido. Intenta que todos participen, pero sin forzar a nadie.

Durante la demo, asegúrate de que el feedback se captura, tanto el negativo como el positivo. Al finalizar la sesión repasa los puntos con los asistentes y las US que se dan por “done”, y si es necesario habla sobre como hacer una release con el incremento de producto.

Si al llegar a la demo vemos que no hay nada “done” y que hay muchos bugs, sopesa la posibilidad de cancelar la demo con el equipo.  A veces es mejor cancelar y que el cliente no sienta que pierde tiempo, y otras es mejor enseñar igualmente lo hecho y recibir feedback. Sobre todo, que no quede la impresión de que la demo no aporta valor.

13.Retrospectivas

Las retrospectivas son reuniones donde el equipo mejora de una iteración a otra. Si las retros no están funcionando, es muy posible que no se estén facilitando correctamente.

Tienen 3 fases principales:

  1. Insight, donde analizas la iteración. En esta parte es importante escuchar a todo el mundo, la historia del equipo es la suma de historias individuales. Puedes usar un timeline, un sismograma de emociones o una galería de arte (cada uno dibuja una metáfora de lo que siente).
  2. Foco en lo que deberiamos mejorar. Repaso de lo que ha salido y elegir en qué centrarnos. Importante hacer análisis de causa raíz. Dot voting es útil para elegir si hay mucho contenido.
  3. Ideas para un plan de acción. Las acciones mejor cuanto más pequeñas y concretas. Las acciones pueden ser por ejemplo recolectar más datos para entender mejor un problema.

Planifica el tiempo y los recursos necesarios para que la retro sea efectiva, igual que cualquier otra reunión.

Para que sea efectivo el plan de acción debe ser visible por el equipo, idealmente en el tablero.

Utiliza la “Prime Directive” para establecer un entorno seguro donde no se ataque directamente a las personas.

Cuando finaliza una release se puede hacer una retro con el equipo y toda la gente que de alguna manera interviene en el producto. Se pueden utilizar las mismas técnicas que con el equipo, pero normalmente son más difíciles de planificar y facilitar. Utiliza “safety check” para asegurar que todos están cómodos opinando sobre lo que ha pasado. Puedes dividir en subgrupos y después juntar conclusiones.

Hasta aquí el resumen del libro “Agile Coaching” de Rachel Davies y Liz Sedley. Si todavía no tienes el libro y quieres comprarlo, te recuerdo que puedes hacerlo en el siguiente enlace de afiliados. A ti no te costará más y me ayudarás a mantener este blog.

También te puede interesar...

Crea ya tu lista de impedimentos en Scrum El rol del Scrum Master incluye eliminar impedimentos, pero ¿qué son los impedimentos en Scrum concretamente?¿Qué debe hacer el Scrum Master?¿cuáles d...
Resumen User Stories Applied de Mike Cohn ¿Qué es una historia de usuario?¿qué elementos debe cumplir?¿cómo se crean? El libro User Stories Applied de Mike Cohn nos da respuesta a éstas y c...
El Rol del Scrum Master “Sí sí pero… ¿qué hace exactamente un Scrum Master?” Pregunta que me han hecho en repetidas veces, realmente es difícil de contestar, puesto que de...

Dejar un comentario

Tu dirección de correo electrónico no será publicada. Los campos necesarios están marcados *