Muchas veces pensamos que por el hecho de poner a personas juntas, pedirles que le pongan un nombre al equipo, asignarles un backlog, automáticamente se convierten en un equipo (1), y no solo eso, creemos que al primer sprint el equipo va tener la velocidad (ej: 50 puntos por sprint) que planearon - http://www.lecciones-aprendidas.info/2017/12/un-cuarto-metodo-para-estimar-la-velocidad.html - y que con esa velocidad podremos terminar en una fecha determinada el primer release ( ej: si el primer release se estima en 350 puntos, lo tendremos en 7 sprints).
La verdad, esto es lejano de la realidad, los equipos toman un tiempo en crearse y madurarse - tal vez 8 sprints, más o menos, y esto dependerá de muchos factores - y alcanzar un buen desempeño, en este post compartiré las razones por las cuales esto se presenta y algunas recomendaciones para ayudarte en este proceso.
1. La Curva de Tuckman
Este modelo muestra las diferentes etapas por las cuales pasa un equipo (2), ella muestra el esfuerzo que toma lograr el mismo estado de desempeño inicial en el cual se formo el equipo. Solo imaginémonos haciendo parte de un equipo de fútbol, rugby, baloncesto, voleibol, musical - en fin cualquier equipo - y el esfuerzo que nos toma acoplarnos, las veces que debemos jugar / tocar juntos para sentirnos cómodos los unos con los otros.
2. La Curva del Cambio o Curva "J" (fuentes: Elisabeth Kübler-Ross, Albretch, David Viney y otros)
 |
| Ver fuente (3) |
 |
| Ver fuente (4) |
 |
| Ver fuente (5) - Un excelente post- |
Las causas por las cuales se transita esta curva son muchas, pues cuando llegamos a un nuevo proyecto se vienen cambios como:
- El nuevo proyecto (obviamente)
- Conocer una nueva tecnolología
- Conocer a mis compañeros
- Conocerme interactuando con mis compañeros
- Conocer un nuevo negocio
- Conocer una nueva metodología
- Conocer una nueva empresa y sus reglas
- Conocer los nuevos sistemas
- Conocer la forma de interactuar en esa organización.
Lo que nos demandará inevitablemente avanzar por esta "J" del cambio y desempeño.
y por último (aunque no sé si sea la última causa, puede que existan más)
3. La Zona de Reducción de Riesgos en TI de Cockburn
Esta curva ya la habíamos discutido en otro post anterior - ¿Cuándo usar Ágil? o ¿Cuándo se Comienza a Generar Valor un Proyecto Ágil (4)? clic aquí - y observábamos que cuando un equipo supera la zona de adquisición de conocimiento la generación de valor fluye a ritmo constante, por lo tanto, aunque los equipos conozcan:
- la metodología,
- el lenguaje de programación
- y la tecnología que están manejando,
- nuevas reglas de negocio
- los sistemas con los que interactuarán
- la interacción para la empresa en la que estan comenzando a trabajar (suponiendo que son proveedores, aun si son internos pero todos son nuevos)
Ahora, habrá mucha más fricción si:
- la tecnología es nueva
- es primera vez que trabajan como equipo
- es primera vez que interactúan usando la metodología o framework de trabajo
Unas Cuantas Conclusiones
- Es inevitable pasar por la zona de baja productividad
- En mi experiencia, he observado que los equipos logran llegar a la Fase Normalización de Tuckman aproximadamente entre 4 y 8 sprints - sprints de duración de dos semanas-, antes no. Si alguien tiene mejores datos al respecto agradecería mucho los compartiera.
- El periodo de 4 a 8 sprints podría ser más largo pero he observado que los ciclos continuos de feedback aceleran el proceso de maduración, permitiendo avanzar rápidamente en la curva J - ver este post donde afirmo que Scrum es un modelo de Auto-Coaching de equipos http://www.lecciones-aprendidas.info/2018/08/scrum-como-modelo-de-auto-coaching.html -.
- Se requiere de un buen liderazgo situacional del Scrum Master para que este periodo sea cubierto de forma exitosa. - ver este post Como enseñando a montar en bicicleta - Cómo llevar a tu equipo a la autoorganización http://www.lecciones-aprendidas.info/2015/11/como-ensenando-montar-en-bicicleta-como.html -
- La verdadera velocidad o capacidad del equipo debe considerarse después del ciclo de estabilización, o sea, después del quinto o noveno sprint según el caso.
- Recordemos que el Product Owner, el Scrum Master y el Equipo de Desarrollo, son un equipo por lo tanto, todos están padeciendo los efectos de este inicio y acople.
- Luego de estabilizada la velocidad o capacidad del equipo, la forma de incrementarla poco a poco es:
- promoviendo la excelencia técnica
- no escribiendo código basura, apestoso o "crappy code"
- removiendo la deuda técnica y haciendo refactors estratégicos
- aplicando las prácticas ágiles de desarrollo (pair programming, tdd, propiedad colectiva del código, etc)
- implementando las mejoras identificadas en las retrospectivas
- tener retrospectivas exitosas que le permitan al equipo avanzar en la dirección correcta - ver post http://www.lecciones-aprendidas.info/2017/02/scrum-master-como-continuar-la-mejora.html
- trabajar la felicidad del equipo
Cerrando, Qué recomiendo
- No es una buena estrategia estar armando y desarmando equipos, se pierden estos procesos de acople, un principio importante a aplicar llevarle proyectos a los equipos en vez de armar equipos para los proyectos, es muchísimo más productivo para todos.
- Recomiendo que al menos la mitad más uno de los integrantes del equipo sean entre Semi-senior y senior, esto acelera los procesos de formación de equipo y reduce considerablemente la creación de código basura debido a inexperiencia de los Juniors, pues los desarrolladores maduros le hacen mentoring a los nuevos - esto es de bastante importancia en equipos que desarrollan software -
- Hacer consciente a las organizaciones que comienzan con scrum, o con cualquier marco ágil, que sus equipos agiles no van a ser "super- ágiles" y "super productivos" por el simple echo de que los pongamos juntos, con un tablero lleno de post-it, Jira u otro software instalado, un Product Owner y un Scrum Master, es cierto van a ser mejores que en cascada o tradicional, pero es un hecho las primeras velocidades son lentas, y se requiere de acompañamiento incrementarlas.
- Se recomienda hacer las proyecciones de cuando se va a entregar el producto luego de la fase de estabilización, antes no tiene sentido hacer proyección alguna,
- Liderazgo situacional es clave en este tipo de procesos. Sugiero se revise esta colección de post Tips para Comenzar con un Equipo Scrum - http://www.lecciones-aprendidas.info/search/label/comenzando%20con%20scrum proporciona herramientas útiles en el proceso de maduración y estabilización de tu equipo.
Hasta acá este compartir. Bienvenido el feedback.
Saludos Ágiles
Jorge Abad.
Notas, Comentarios, Observaciones y Referencias
- Les recomiendo este artículo de Martín Alaimo - http://www.martinalaimo.com/es/blog/hacia-un-equipo-real - y la serie de "Hacia un Equipos Real" - http://www.martinalaimo.com/es/blog/tag/equipos-reales-.
- Explicación de la curva de Tuckman en este post: Equipos Estables por sobre Pool de Recursos - http://www.martinalaimo.com/es/blog/equipos-estables
- Curva de Cambio - http://activaconocimiento.es/curva-de-cambio/
- Las fases que vivimos ante un cambio -https://elpais.com/elpais/2013/12/16/laboratorio_de_felicidad/1387150998_138715.html
- Falsos Positivos (agárrense que vienen curvas) https://wynwin.wordpress.com/2013/05/10/falsos-positivos/
