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.

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”.

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).

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.
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.
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.

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.