¿Qué es el autodiseño de equipos?
La autoorganización es un proceso en el que alguna forma de coordinación surge de las interacciones entre los componentes de un sistema inicialmente desordenado.
En las empresas de organización jerárquica, el diseño de la organización y su coordinación la realiza el management, por lo tanto no existe la autoorganización, aunque habitualmente sí existe en aquellas actividades que son delegadas por el management.
Durante la investigación para la creación de este artículo, lancé una encuesta para conocer el grado de popularidad del autodiseño. Aunque la muestra es limitada, me pareció positivo que casi 2/3 de las respuestas afirmaran haber realizado el autodiseño para muchos o todos los equipos de una autoorganización, cifra que excede la de mi experiencia.
Las respuestas de colegas como Michael Küsters, Martin Hinshelwood o Willem-Jan Agelling, me aportaron visiones más potentes que las que yo he podido ver en cliente. Podéis revisar de nuevo el enlace de la encuesta para ver los datos actualizados.
Según el diagrama anterior, inspirada en el modelo de autoorganización de Gunther Verheyen [1], la autoorganización presenta varios niveles:
- Autogestión: las personas deciden como hacer el trabajo, pero no el diseño organizativo, p.e. el de los equipos.
- Autodiseño: las personas deciden como agruparse para realizar el trabajo, según su criterio.
- Autodirección: las personas deciden aspectos como los objetivos organizativos y las condiciones del trabajo.
El nivel más habitual de autoorganización en las organizaciones ágiles es el de autogestión. La dirección dota de unos objetivos y de unos recursos a los managers, y éstos diseñan sus equipos. El autodiseño comienza cuando las personas deciden en que equipos trabajar, ya sean equipos estables o «equipos líquidos», con capacidad para cambiar de miembros según la evolución del trabajo.
¿Cómo planificar un proceso de autodiseño?
¿Estamos preparados para el autodiseño?
En primer lugar se debería evaluar si el autodiseño es posible en esta organización y en este momento. Es imprescindible un soporte nítido de la Dirección y que la organización esté preparada, en aspectos como p.e.:
- Haber trabajado con equipos ágiles durante algunos años.
- Haber acompañado al management en la delegación y empoderamiento de los equipos.
- Tener equipos que estén a favor del autodiseño.
A veces la Dirección no confía en que el proceso no vaya a funcionar por algunos rasgos de conducta que observa en los equipos, como baja colaboración entre equipos, poca proactividad o visión de conjunto. Según Michael Küsters [7], esto suelen ser razones sólidas para no iniciar un proceso aumplio de autodiseño.
Como en muchos cambios organizativos, un paso para ganar el apoyo de Dirección y limitar el riesgo es hacer un piloto para formar un nuevo equipo. Otra opción es que la Dirección pueda experimentar el autodiseño en eventos como las hackhatons, y mejor si se realizan en la propia organización.
¿Qué enfoque seguir para organizar el autodiseño?
Una vez que existe el apoyo de Dirección, se puede comenzar a planificar en serio el proceso de autodiseño. El primer paso es definir qué equipos pueden optar a ser autodiseñados. Tres opciones para hacerlo son:
- Dejar los equipos como están, y permitir a las personas cambiar de equipo. Esta opción plantea el menor riesgo y puede ayudar a la organización a conocer la implicación con los equipos, así como las necesidades de cambio de las personas.
- Diseñar los nuevos equipos según la estrategia de la organización, p.e. equipos para nuevos productos, o para cubrir una parte del «customer journey». Esta opción tiene más riesgo, pero va en la dirección de mayor crecimiento para la organización.
- Dejar a las personas proponer los equipos. Esta opción favorece la confianza en las personas que será necesaria para seguir en el proceso de autodiseño.
Finalmente es la Dirección que habrá de escoger la combinación de estas opciones que considere viable, y en caso de percibir riesgo se puede comenzar por unos pocos equipos e ir creciendo según la experiencia.
El proceso más habitual de autodiseño es el conocido como el «Mercado» (marketplace en inglés) que aparece en las referencias [2], [3], [4] y [5]. El Mercado consiste en que una vez definidos los equipos que se autodiseñaran, se organiza un evento presencial en en cual algunos roles preasignados (normalmente el Product Owner y el Scrum Master) explican (en modo «venta») las metas de sus productos e iniciativas, y los developers deciden a equipos quieren ir, considerando unas reglas y límites establecidos previamente. Se realizan varias rondas hasta que se considera que se ha alcanzado un autodiseño que cumple los objetivos.
En mi experiencia directa, solo he podido participar en eventos parecidos al Mercado con uno o dos equipos. La dinámica del evento es parecida a la que explican los autores referenciados más abajo, pero con menos riesgo y mucho más sencilla de planificar y realizar por ser con muy pocos equipos.
Otro proceso que uso Microsoft con hasta 600 desarrolladores fue un híbrido entre selección del management y autodiseño, que me contó Brian Harry (Technical Fellow), fue el siguiente:
- Los líderes presentaron sus planes y estructura de los equipos que proponían en un evento largo de varias horas.
- Los miembros de los equipos tenían varios días para pensarlo, hablando entre ellos y haciendo preguntas a dichos líderes.
- A continuación, dichos miembros hacían su petición con un orden de tres posibles equipos a los que querían ir.
- Finalmente los managers trataban de acomodar las peticiones de las personas en equipos equilibrados. La mayoría lograron su primera petición, una parte significativa la segunda y solo unos pocos la tercera.
Aunque este proceso no es tan potente como el «marketplace» que veremos a continuación, fue muy apreciado por los trabajadores.
¿Cómo preparar el evento «marketplace»?
Todos los autores coinciden en la importancia de la comunicación previa al evento. Para evitar al máximo los malentedidos, las conductas indeseadas, las dudas o la desconfianza en el proceso de autodiseño, es vital explicar bien aspectos como:
- Los objetivos del proceso.
- Los principios para tomar decisiones
- Las reglas y límites.
- El criterio de éxito del proceso.
- Cómo se procederá despues del evento.
Definir las reglas, los límites y los principios del evento es fundamental para éste fluya adecuadamente, p.e.:
- Los equipos tienen que ser preferentemente autónomos y tener entre 3 y 7 miembros.
- Se tiene que cubrir unas capacidades mínimas (p.e. 2 front-end, 2 back-end, 1 tester y un especialist de sistemas)
- No pueden quedar equipos infradotados ni equipos sobreasignados.
- En caso de duda, el bien del equipo o empresa prima a mi interés propio.
Tanto en mi experiencia como en la de otros que han desarrollado estos procesos [2], [3] y [7], es importante que las reglas sean tan pocas como claras. Muchas reglas frenan la potencia del proceso y la autoconfianza de los miembros de los equipos. Las reglas confusas pueden causar que los managers necesiten corregir el proceso posteriormente, restándole igualmente credibilidad y confianza.
Un plan de facilitación puede ser muy útil para que los facilitadores trabajen de manera común, y un simple poster con las reglas colgado en la pared puede ser suficiente para los participantes en el evento de «Mercado».
Ejemplos de paneles de mercado de autoselección de Dandy People y Flowdays.
¿Cuál es la estructura y dinámica del evento?
La estructura habitual de los eventos tipo Mercado de autodiseño, según [2], [3], [4] y [5] es sencilla:
- Presentar los objetivos, estructura y reglas del evento.
- Los Product Owner presentan las iniciativas para las que buscan developers.
- Se repiten ciclos de autodiseño, evaluación de resultado y búsqueda de mejoras.
- Se finaliza el evento, presentando los resultados y explicando los siguientes pasos.
Para no extenderme demasiado en el artícul me centraré en los puntos menos evidentes:
Los ciclos de autodiseño
La principal herramienta de los evento tipo Mercado son los paneles con las características y miembros de los equipos que hemos visto un poco más arriba que contienen p.e. tanto el nombre y objetivos del equipo, como sus necesidades de perfiles.
Las actividades de estos ciclos son:
- El un tiempo breve (p.e. entre 5 y 10 minutos) las personas escogen a que equipo quieren ir.
- Se revisa si se han cumplido los objetivos, típicamente conseguir definir todos los equipos cumpliendo las reglas, principios y límites. Habitualmente los Product Owners revisan el estado de cada equipo, y cualquier miembro del evento puede hacer observaciones.
- Finalmente, se hace una mini-retrospectiva: cualquier miembro del evento puede proponer mejoras.
La finalización del evento
Como en todo proceso ágil, buscamos:
Transparencia en el proceso y aprendizaje, como pasa en las Retrospectivas de los Sprints. Por ello se recomienda reservar una parte final de la sesión para que todos los participantes busquen puntos fuertes y débiles sobre el funcionamiento de la sesión, así como propustas de mejoras, respecto aspectos como:
- Claridad del proceso y la información.
- Facilidad para tomar las decisiones.
- Comodidad con el resultado final.
Y además es importante dejar claros los siguientes pasos, como pasa en las Revisiones de los Sprints, en este caso:
- Dejar claro cuando se van a desplegar los equipos, y que pasos previos se darán.
- Como se va a coordinar el proceso y como se realizará la comunicación.
¿Cómo desplegar los resultados del evento?
Una vez concluido el taller de autodiseño, tenemos una propuesta de equipos que debe respetarse al máximo posible. Es conveniente que un grupo centralizado siga dando soporte a los equipos que se van formar y centralicen la relación con la Dirección y la comunicación.
Durante el periodo de despliegue de los nuevos equipos, que se recomienta que no pase de 2 o 3 meses [2], las actividades de soporte a estos equipos son:
- Seguimiento de los impedimentos para lanzar los equipos, p.e. la dedicación a otros equipos que no se puede liberar.
- Reuniones o contactos asíncronos y periódicos entre los equipos ya creados para compartir experiencias.
- Actividades de creación de los equipos, como definición del manifiesto de equipo, formaciones iniciales comunes, observaciones entre equipos para aprender entre ellos, etc.
Conclusiones
En este artículo he revisado los procesos de autodiseño de equipos, desde la exploración inicial con dirección hasta la preparación, realización y seguimiento del taller de autoselección. Para ello me he basado en mis experiencias (varias, pero centradas en la creación de nuevos equpos) y en las de algunos coaches conocidos (que han incluido la creación de múltiples equipos en paralelo).
Algunas conclusiones de lo explorado son:
- El autodiseño es un síntoma de una cultura ágil madura.
- El autodiseño es coherente con una cultura de equipos autogestionados.
- El autodiseño tiene efectos más allá de la creación de los equipos, como el rol del management para con los equipos, o la información de la que dispone RR.HH.
Recursos para saber más
- Niveles de autoorganización, según Gunther Verheyen.
- Creating Great Teams, por Sandy Mamoli & David Mole
- Self-organising a new organisation — the Marketplace, de Willem-Jan Ageling
- Team Selection: Manager Selection or Self-Selection? de Sunil Gulia
- Self-organization Chefs, de Ziryan Salayi
- Self-selecting teams on a small scale, de Magnus Dahlgren
- Encuesta en Linkedin sobre Autodiseño
- Lessons Learned from Self-Selection Reteaming at Redgate