Conformar equipos ágiles cuando estamos trabajando con Scrum es un reto. ¿Cómo decidimos quien debe ir en cada equipo? ¿De que manera podemos extender Scrum a la organización y mantener la agilidad?
Hace unas semanas durante una charla para OnTech Innovation una de las asistentes me lanzaba esta pregunta en Twitter.
Jeronimo, por favor me indicas si existen técnicas de división de equipos, cuando ya se trabaja Scrum y Kanban? Escuchamos sobre la técnica (split and seed – split and grow) pero no encontramos casi información del tema. Gracias
— Monica Martinez H (@monicaromartine) September 26, 2019
Equipos auto-organizados. No equipos donde todo el mundo haga de todo.
Cuando usamos Scrum para lidiar con problemas complejos, podemos caer en dos tentaciones diametralmente opuestas: Distribuir el trabajo en trozos de acuerdo a los equipos que tenemos actualmente (Fron-end, Back-End, Data, etc…) e ir haciendo Sprints en el que el trabajo de unos recae en otros.
Otra opción es tener equipos donde todo el mundo haga de todo. En realidad, en Scrum no es ni lo primero, ni lo segundo, ni nada en medio de los dos.
Cuando Scrum fue descrito por primera vez en el New New Product Development Game, los investigadores Takeuchi, Nonaka y Ken-Ichi Mai observaron que los equipos de alto rendimiento que estudiaban tenían precisamente todos los perfiles que necesitaban para entregar algo terminado, funcionando y que el cliente valorara en un periodo muy corto de tiempo.
¿Como podemos conseguir identificar cuales son las skills necesarias para entregar un incremento de valor, terminado, en 30 días o menos? Es más fácil de lo que creemos. Sólo hay que preguntarle al equipo que trabaja en ese producto.
A pesar de que pueda parecer sorprendente, las personas que desarrollan un producto son las que más saben cómo organizarse para sacarlo adelante.
Para aquellos que temen que los techies se centren sólo en su área, esa es precisamente una de las problemáticas que resuelve Scrum.
Scrum proporciona los límites, la transparencia y la capacidad de inspección y adaptación para asegurar que la auto-organización funciona. Cuando un equipo de desarrollo tiene que entregar un incremento terminado en 30 días o menos, pone el foco en qué necesita para que eso ocurra.
Hace un año y medio, escribí un artículo sobre las diferencias entre distintos tipos de diseño de equipos.
En realidad nada ha cambiado mucho desde entonces, más allá de que sigue siendo difícil entender que para cambiar nuestra forma de entregar valor a los clientes, tenemos que cambiar la forma en que organizamos el trabajo.
Split and Seed y Seed and Grow.
Cuando nos planteamos escalar Scrum a distintos equipos de nuestra organización, se suele acudir a los métodos por los que Mónica pregunta en su Tweet: Split and Seed y Seed and Grow.
Con este método, se toma un equipo pequeño que establece un núcleo o un core y se divide.
En el primer caso (Split and Seed), una vez que el equipo está establecido, se divide en dos equipos que se utilizan como base para hacer crecer otros equipos, a modo de mitosis de equipo.
En el segundo caso (Seed and Grow), se toman algunas personas de un equipo que ya está funcionando y se utilizan como semilla para hacer crecer otro equipo, a modo de esqueje.
Este método plantea dos problemas: ¿Quien decide como se mueven los miembros de un equipo a otro? ¿El Agile Coach, el Scrum Master, el Propio Equipo?.
El segundo problema es que podemos partir de un equipo de alto rendimiento para terminar con dos equipos mediocres o que no funcionen en absoluto.
El método del becario
Una alternativa, que Jeff Sutherland llama “El modelo del amigo del equipo”, es introducir a un nuevo miembro del equipo de desarrollo, que se encarga de empaparse de la cultura, forma de trabajo y experiencia del mismo con el objetivo de graduarse y formar su propio equipo más adelante.
Un equipo de desarrollo identifica uno o varios compañeros, que trabajaran con ellos durante un periodo de 4 a 6 sprints.
Su papel durante este tiempo será aprender y participar en las actividades del equipo sabiendo que su permanencia tiene una fecha de caducidad en el tiempo. Cuando pase ese tiempo, serán los encargados de ser el pilar fundador de un nuevo equipo.
En ocasiones a estos equipos que admiten nuevos miembros se les llama “Equipos de bienvenida” o “Training Teams” y tienen una alta cultura de colaboración que puede ser expandida a nuevos miembros.
La decisión del número de Sprints que permanecen en el equipo es una decisión personal. Cuando están listos, pueden migrar al nuevo equipo.
La ventaja de este método es que asegura que no se rompe un equipo de alto rendimiento ya existente, tiene un impacto menor en el delivery actual y permite un crecimiento de acuerdo a las capacidades de contratación de la organización. Sin embargo, es un método extremadamente lento para aquellas organizaciones que quieren escalar Scrum rápidamente.
El observador
Otra opción, basada en el modelo anterior, es incorporar nuevos miembros como observadores. La principal diferencia es que mientras en el método del becario participan activamente de las labores, entrega y eventos del equipo, en este modelo sólamente actúan como observadores.
La principal ventaja de esta última opción es que la incorporación de un observador es mínimamente disruptiva.
Pueden continuar con se trabajo como hasta ahora sin tener que centrarse en enseñar a un nuevo miembro del equipo.
A pesar de todo, el efecto del observador puede ser disruptivo para equipos existentes. A nadie le gusta sentirse observado.
Puede tener consecuencias inesperadas cuando los nuevos miembros crean sus equipos e implementan lo que creen que han observado.
Lo más importante: Medir Siempre
Durante todo el proceso de escalado a equipos con Scrum, es importante medir el estado y la salud del equipo. El health check de Henrik Knieberg en Spotify puede ser un buen comienzo. La importancia de medir el estado de los equipos radica en que una manzana podrida en una cesta de fruta acabará rápidamente con todos los esfuerzos por mantenerla en buen estado.
Lamentablemente el crecimiento rápido en pocas ocasiones tiene buenos resultados. Si además se están adoptando prácticas que requieren de un alto grado de auto-organización, como Scrum, es necesario dejar que los equipos y la organización maduren a su propia velocidad.
