¿Qué es el "Squad Health Check Model" de Spotify?
Muchas empresas experimentan con diversas posibilidades para evaluar y visualizar dónde se encuentran sus equipos. Normalmente, esto se hace con la ayuda de los llamados Maturity Models, es decir, modelos de madurez que representan un desarrollo a través de diferentes niveles.
Las intenciones detrás de estos modelos suelen ser positivas – por ejemplo, cuando managers, responsables de liderazgo o coaches en organizaciones más grandes quieren tener una mejor idea de dónde debería estar su foco en cuanto a mejoras y problemas, o cuando quieren ayudar a sus equipos a ser más reflexivos para que también puedan concentrarse mejor en sus propias mejoras.
Sin embargo, preferimos llamarlo “Health Check Model” (modelo de chequeo de salud) en lugar de “Maturity Model”, ya que este último suena... bueno... un poco condescendiente. Además, la mayoría de nuestros modelos no incluyen el desarrollo a través de diferentes niveles. El público objetivo principal es el propio equipo y no la gerencia.
La mejora de la organización a menudo es como un juego de adivinanzas (¿cómo se sabe qué hay que mejorar? ¿Y cómo se sabe si algo está mejorando?). Un enfoque sistémico con una visualización clara puede reducir este juego de adivinanzas al mínimo.
Bien, ¿pero funcionan realmente estos modelos?
Depende. En algunos casos, estos modelos pueden ser realmente útiles. A veces es más bien “meh” – las personas cumplen con su deber y participan en workshops, encuestas, etc., pero los datos resultantes se ignoran.
Pero ten cuidado. Hemos visto cómo estos modelos se convirtieron en verdaderos monstruos en algunas empresas; una herramienta sistémica de opresión que causa suboptimización y miedo. Los managers utilizan el modelo de madurez para evaluar y enfrentar a los equipos entre sí, y los equipos ocultan sus problemas para quedar bien. ¡Y eso no es nada bueno!
Aunque el daño potencial probablemente es más probable que el beneficio potencial, SÍ EXISTE un beneficio potencial y hay formas de evitar un desastre.
En Spotify experimenté con esto durante algunos años y encontré formas que funcionan bastante bien (es decir, más ventajas que desventajas) – en el mejor de los casos son “útiles”, en el peor “meh”, y hasta ahora nunca han sido un “desastre”. También implementamos este Health Check Model en algunas otras empresas y obtuvimos resultados similares, por lo que pensé que era hora de escribir un artículo al respecto.
¿Para quién está pensado el Health Check Model?
En el Health Check Model de un Squad (nuestro término para un pequeño equipo de desarrollo interdisciplinario y autoorganizado) hay principalmente dos stakeholders:
1) El propio Squad
Al discutir los indicadores individuales, los miembros del Squad pueden comprender mejor qué funciona para ellos y qué no. La amplia gama de preguntas les ayuda a ampliar su horizonte. Quizás son conscientes de los problemas de calidad del código, pero no han pensado realmente en el valor desde la perspectiva del cliente o en cuán rápido pueden aprender. Además, se muestran tanto las cosas buenas como los puntos negativos.
2) Personas que apoyan al Squad.
Los managers y coaches que trabajan fuera del equipo (o al menos parcialmente fuera del equipo) obtienen una visión general de todas las cosas que funcionan y las que no. Adicionalmente, pueden reconocer patrones entre diferentes Squads. Cuando tienes docenas de equipos y no puedes hablar con cada uno sobre todo, un resumen así puede ayudar a descubrir cómo aprovechar mejor tu tiempo y con quién hablar sobre qué.
Ser consciente del problema es el primer paso para resolver un problema. Este tipo de visualización hace mucho más difícil ignorar un problema.
Cómo lo hacemos en Spotify
Principalmente hacemos tres cosas:
Realizamos workshops en los que los miembros de un Squad discuten y evalúan su situación actual según diferentes aspectos (por ejemplo, calidad, diversión, valor, etc.)
Creamos un resumen gráfico del resultado
Ayudamos a los Squads a mejorar
Tenemos diferentes variantes. Una la llamamos simplemente “Squad Health Check Model”, otras se llaman por ejemplo “Fluent@Agile Game” o “Quarterly Reflection”. El “Health Check Model” es una versión mejorada de la encuesta trimestral “Autonomous Squads” que fue mencionada en 2012 en el artículo Scaling Agile @ Spotify.
Aquí hay un ejemplo real del Health Check Model de un “Tribe”:
Aquí se muestra cómo 7 Squads diferentes evalúan su propia situación. Los colores muestran cómo está actualmente (verde=bien, amarillo=algunos problemas, rojo=muy mal). Las flechas indican la tendencia (¿está mejorando o empeorando?).
Si miras el diagrama con atención durante unos minutos, notarás algunas cosas interesantes:
En las columnas puedes reconocer las principales diferencias entre los diferentes Squads. El Squad 4 está satisfecho con prácticamente todo. El Squad 2 tiene muchos problemas, pero hay una tendencia positiva en casi todos los puntos.
En las filas puedes reconocer patrones sistémicos. Cada Squad se divierte en el trabajo (¡y la tendencia sigue subiendo!). La motivación no parece ser un problema. Sin embargo, el proceso de release presenta problemas y la base de código tampoco se ve muy bien. Con el tiempo, eso seguramente también afectará el factor diversión en el trabajo.
En el panorama general se puede ver que casi todas las flechas apuntan hacia arriba; en todo el diagrama solo hay 2 flechas hacia abajo. Esto significa que el proceso de mejora (el proceso más importante de todos) parece estar funcionando.
Esto es, por supuesto, solo una representación aproximada de la realidad (“Todos los modelos son incorrectos, pero algunos son útiles.” – George Box). Por lo tanto, es una buena idea verificar todo una vez más antes de tomar medidas concretas.
¿Realmente todo va tan bien en el Squad 4 o son simplemente optimistas y no ven sus problemas? La mayoría de los Squads piensan que entregan valor a sus clientes, ¿pero cómo lo saben? ¿Se basa esa afirmación en un deseo o en feedback real de los clientes?
El Squad 4 de nuestro ejemplo fue formado apenas una semana antes de que se realizara el Health Check. Por lo tanto, definitivamente todavía estaban en la fase de orientación (también llamada fase de Forming o fase de luna de miel). Por esta razón, tanto el Squad 2 como el Squad 4 necesitaban mucho apoyo.
La facilidad de entrega fue un gran problema aquí. Así que se puso más foco en cosas como Continuous Delivery y pronto se pudo ver una mejora significativa.
Por favor recuerda que este es un modelo de autoevaluación; basado en la honestidad y la opinión subjetiva de los miembros del Squad. Por lo tanto, solo funciona en un entorno de confianza donde las personas pueden estar seguras de que sus managers y colegas actúan en su interés. Recopilar los datos es bastante fácil – lo principal es que no debería haber razones concretas para no hacerlo.
Afortunadamente, en Spotify existe un entorno de confianza así y los managers y coaches se esfuerzan mucho en comunicar que esta es una herramienta de apoyo y no de evaluación de los Squads.
Cómo recopilamos los datos
Hemos experimentado que las encuestas online son un desastre total para estos fines. Esto se debe principalmente a que no permiten una conversación, y eso es lo más valioso del proceso. Mientras los miembros del Squad conversan, se obtienen más conocimientos, y el coach descubre cómo puede ayudar a los Squads de manera efectiva. Los datos por sí solos solo muestran una pequeña parte del panorama general, lo que puede ser engañoso.
Así que organizamos (normalmente agile coaches) workshops con los Squads y fomentamos una conversación directa sobre los diferentes indicadores del “Health Check Model”. Una a dos horas suelen ser suficientes para esto.
Para la facilitación utilizamos un set de las llamadas “Awesome Cards”. Cada carta representa uno de los indicadores e incluye tanto un “Example of Awesome” (ejemplo de algo genial) como un “Example of Crappy” (ejemplo de algo malo).
El set normalmente consta de unas 10 cartas. Aquí el ejemplo de un set completo:
Para cada pregunta, se les pide a los Squads si se ven más cerca de “Awesome” o de “Crappy”. Para facilitarles ponerse de acuerdo sobre un color para los indicadores y la respectiva tendencia (estable, tendencia ascendente/descendente), utilizamos métodos básicos de workshop como por ejemplo Dot Voting.
Aquí están las cartas como descarga PDF
Lo mantenemos bastante simple con tres niveles (verde/amarillo/rojo). La definición exacta de la codificación de colores puede variar, pero se basa en las siguientes afirmaciones:
Verde no significa necesariamente que todo sea perfecto. Solo significa que el Squad está satisfecho y actualmente no ve una gran necesidad de mejoras.
Amarillo significa que hay algunos problemas que deberían resolverse pero que no son un desastre.
Rojo significa que algo está realmente mal y necesita mejorar.
Sí, estos son datos subjetivos. Teóricamente, cada Squad es libre de incluir también datos objetivos (tiempo de ciclo, número de defectos, Velocity, etc.). Sin embargo, muy pocos lo hacen. Esto se debe a que los Squads también tienen que interpretar los datos objetivos y decidir si significan que tienen un problema o no. Al final del día, por lo tanto, todo es subjetivo. Si algo se siente como un problema, es un problema.
A veces combinamos esto con retrospectivas, por ejemplo seleccionando una carta y luego pensando en acciones de mejora para ella.
¿Qué preguntas se deberían hacer?
Si miras los ejemplos mencionados anteriormente, verás que las preguntas no siempre son las mismas. Esta es una buena guía:
Las preguntas deben cubrir una amplia gama de perspectivas diferentes.
Estas preguntas son solo un punto de partida, una preselección ejemplar. Los Squads son libres de decidir si quieren eliminar, añadir o cambiar preguntas si creen que tiene sentido.
Intenta limitar el número de preguntas a aproximadamente 10 preguntas. Con más preguntas, rápidamente pueden surgir solapamientos, por lo que estas pueden eliminarse.
Hay que asegurarse de que las preguntas se refieran al entorno en el que trabaja un Squad, y no a datos duros (como por ejemplo la Velocity). Esto hace que todo sea menos amenazante y enfatiza una vez más que se trata de apoyo y mejora, y no de evaluación.
Nuestra suposición (sea verdadera o no) es que un Squad tiene una motivación intrínseca para tener éxito y ofrecer el mejor rendimiento posible dadas las circunstancias.
¿Con qué frecuencia medimos la salud de los Squads?
Como hemos dicho, tenemos diferentes modelos a los que recurrimos, por lo que varía mucho. Aún no hemos encontrado un “intervalo de tiempo perfecto” para estas cosas (y probablemente nunca lo haremos).
Trimestralmente parece ser un buen punto de partida. Mensualmente es probablemente demasiado frecuente (a la gente le resulta molesto rápidamente y los datos no cambian lo suficientemente rápido). Dos veces al año parece ser demasiado poco frecuente (en medio año puede pasar demasiado). Pero como hemos dicho, siempre varía.
Conclusión – Lo que debes tener en cuenta si quieres probar esto
Un modelo así PUEDE ayudar a impulsar mejoras. ¡Pero también puede poner patas arriba toda una cultura empresarial si no se hace correctamente! Por lo tanto, siempre se debe proceder con precaución.
Aquí hay algunas directrices que aumentan la probabilidad de éxito:
Ten claros los motivos para introducir el modelo. Siempre debería tratarse de mejora, no de evaluación.
Deberías recopilar los datos principalmente a través de comunicación personal, no mediante encuestas online. Este proceso debería ser interesante y divertido.
Involucra a los equipos en la aplicación del modelo y déjalos hacer ajustes según sus necesidades.
La aceptación del equipo es más importante que la consistencia de los datos. Si el equipo A elige un conjunto de preguntas ligeramente diferente al equipo B, está bien (aunque el resumen sea un poco menos claro).
Asegúrate de que no haya incentivos para hacer trampa. No debería haber razones para que un equipo quiera presentarse mejor de lo que realmente está.
Encuentra una forma sencilla de visualizar los datos. Cuanto más obvia e intuitiva sea la visualización, mayor será la probabilidad de que se utilice.
Intenta no comparar a los equipos entre sí. Si el equipo A evalúa los puntos principalmente con verde y el equipo B mayormente con rojo, eso no significa automáticamente que el equipo A sea “mejor”. Igualmente podría significar que el equipo A tiene un contexto más fácil, es más optimista o que el equipo B es más honesto respecto a las dificultades. Sea cual sea la razón, simplemente significa que el equipo B necesita un poco más de apoyo. La actitud del manager debería ser “¿Cómo puedo ayudar?” y no “¿Por qué sois mucho peores que los demás?”.
Haz un seguimiento. Haz preguntas como: “¿Os ayuda este modelo?”, “¿Si dejáramos de hacer Health Checks, los echaríais de menos?” o “¿Cómo podríamos hacer este modelo aún más útil?”. El modelo (y la forma en que lo aplicas) necesita mejorarse continuamente.
