Aquí viene la segunda parte de esa serie de post que comenzó la semana pasada sobre equipos auto-organizados, si no leíste la primera parte, te recomiendo que lo hagas antes de empezar con esta segunda.
Y si leíste la primera parte hace unos días, te recuerdo que estábamos repasando y comentando experiencias propias, y ajenas, en lo que refiere a malas interpretaciones del concepto, tan ágil, de la auto-organización, el primer post trató aquello de que… “1) Todos, cualquier miembro del equipo, puede hacer cualquier cosa… pero resulta que nadie la hace, todo el mundo pensaba que alguien lo haría, pero nadie lo hizo. No hay un responsable, somos muchos… pero realmente ninguno” y en este segundo vamos con…
2) Todos, cualquier miembro del equipo, puede hacer cualquier cosa… y entonces llega el que menos sabe, se pone con algo crítico… y la lía
Si, sí, ya sé, habrá por ahí algún “fan boy” de la auto-organización que dirá que todo el mundo debe saber hacer de todo, es decir, la más famosa mala interpretación del concepto multifuncional (tema al que ya le dedicamos su momento en aquel post de los equipos modernos de desarrollo son multifuncionales, así disparan la velocidad y la productividad), que suele acompañar a la auto-organización. Pero la realidad es otra y, por pura lógica, salvo que jamás entre nadie nuevo a tu equipo… siempre habrá alguien más novato que otro.
Si en tu equipo la auto-organización es que cualquiera puede hacer cualquier tarea, entonces llegará el día que la persona que menos conocimiento tiene sobre una tarea, con mucha iniciativa y ganas, se pone con dicha tarea… y la lía (póngase en lía, y pongo casos de 233 Grados de TI, tirar un servidor, se carga una plataforma, manda un correo con errores a cientos, miles, de usuarios y se lía parda, etc.).
A este respecto, y seguro que en 233 Grados de TI leen esto con gran cariño y alguna sonrisa, y lo digo en serio, sólo en mi experiencia en estos últimos años, con esto de que todo el mundo puede hacer cualquier cosa, he visto caer bastantes varios servicios en producción y cometer algunos errores de los que aún hoy seguimos sufriendo y de los que aún hay quien nos los recuerda cuando nos ve.
En el otro extremo está que siempre lo haga el de siempre, eso ya lo conocíamos, pero esto nos lleva a la alta dependencia de personas, los Rambos, o los Pacos que hacen todo mientras los demás miran, tema que también tratamos en ¿Es posible evitar que solo unas pocas personas tengan el 100% del conocimiento de un proyecto?
Analizando los anteriores párrafos, parece obvio pensar que la solución a este problema es a) que las tareas críticas sólo las haga quien tiene conocimiento para ello y b) que más de una persona esté capacitada para hacerlo. Obvio.
El mundo del desarrollo software ha ido, desde años inmemorables, poniendo nombre a técnicas para difundir el conocimiento de un proyecto y evitar la alta dependencia de personas, técnicas que deberías plantearte como antesala antes de tirarte a “la piscina” y decir que ahora todos somos auto-organizados.
Ejemplo de ello es la escalofriante, para muchos gerentes, “pair programming” (¿Beneficios del pair programming? ¿Dos programadores en un solo ordenador es perder medio equipo?), que ayuda, entre otros, a que más gente tenga conocimiento de ciertas tareas. Para los que no pueden ni escuchar algo como lo anterior “-¡Dos personas por ordenador es tirar un 50% de la productividad!”, en fin, existe el “pair review”, revisión por pares, alguien hace algo y otra persona, posteriormente, lo revisa (un caso de estudio sobre esto viene en el libro de How Google Test, del que hablamos en el Caso de estudio: Cómo hace Google sus planes de pruebas (y los hace en menos de 10 minutos)). E incluso está el Mob Programming: un único ordenador para todo el equipo (más allá del pair programming).
Porque recuerda que en esta profesión las cosas se aprenden haciendo, vamos, que alguien te las puede escribir en un papel… pero yo no me fiaría mucho de que lo escrito sirva para que otra persona, sólo leyéndolo, sepa hacerlo.
Como decía eXtremme Programming, si quieres que el conocimiento se comparta, lo que allí llamaron la práctica del “Shared understanding”, rodéate de las siguientes prácticas: Coding standard (buenas prácticas de programación), Collective code ownership (que todo el código sea de todo el mundo), Simple design (mantenlo simple) y System metaphor (que se pueda explicar con facilidad).
Oh, este post, de nuevo, se me alargó demasiado… habrá un capítulo III
Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.
También soy profe de la Universidad Rey Juan Carlos.
- Más allá del Management 3.0: 12 prácticas (de muchas) que no están en M 3.0 - 25 enero, 2024
- Más allá del Management 3.0: Otros muchos patrones para equipos Ágiles - 18 enero, 2024
- Años 30, Ohio (EE.UU.) y el Agile Product Management - 11 enero, 2024