Exprimiendo Scrum: ¿Cuál es tu definición de equipo?
La problemática de la gestión de proyectos en las organizaciones que desarrollan software se deriva, simplificando el asunto, de dos situaciones: gestionar proyectos muy grandes o gestionar muchos proyectos pequeños. Todos estaremos de acuerdo en que cualquiera de estas dos situaciones es más compleja que la situación, más equilibrada, en la que tenemos un número limitado de proyectos con unas dimensiones limitadas.
De estas tres posibilidades, sin duda la más compleja es muchos proyectos pequeños. Los grandes problemas siempre se pueden dividir en problemas de tamaño medio y reducir así la complejidad, llevarlos a la categoría de ‘un numero pequeños de proyectos medianos’.
El por qué la situación más compleja se da cuando tenemos muchos pequeños proyectos es simple: tendemos a tener más cambios de contexto. Los cambios de contexto se dan al ‘pasar’ de un proyecto a otro y son tiempos perdidos. Si a un número grande de proyectos pequeños, unimos que no hay concepto de equipo, los cambios de contexto son continuos y la caída de productividad acusada. Cuando un proyecto está en manos de una persona y no de un equipo, esta persona inevitablemente es un cuello de botella. No voy ha hablar hoy de los cambios de contexto, en otra ocasión volveré sobre el tema, que ya he tratado, someramente, en alguna otra ocasión.
Cuando tratamos de implantar Scrum en una organización este problema de la gestión de proyectos también nos afecta de manera decisiva. Como hemos comentado se trata de un problema de cambios del contexto y el antídoto de Scrum para los cambios de contexto es el concepto de equipo autoorganizado y autogestionado. La idea clave es que un equipo autoorganizado y autogestionado puede elegir en que momentos introducir los cambios de contexto, y por simple sentido común elegirá los momentos idóneos. Siguiendo con esta argumentación se hace patente que es precisamente en entornos que presentan muchos pequeños proyectos en los que más dificultoso es implantar Scrum y en los que más atención se debe prestar a un tema clave: definir que es un equipo en tu organización.
En empresas con ‘muchos pequeños proyectos’, como la gran mayoría de las pequeñas y medianas consultoras, la gran dificultad pasa por encontrar que es un equipo para esa organización, en primer lugar, y en segundo lugar definir cuantos product backlogs se van manejar.
Para hacer esto, no hay una receta universal. Depende mucho de la cultura y organización actual de la empresa. Pero es la clave. Pensad que ahora solo existen individuos y tenemos que pasar de esa situación a una en la que el trabajo de reparta entre equipos, no entre individuos. Esa es la gran dificultad.
El principal problema que tenemos en la situación actual es el tiempo que se os va en cambios de contexto, insisto. Probablemente estemos en la típica situación de prioridades difusas, de atender a los fuegos, al cliente que más grita... el antídoto para eso es Scrum y su modelo de equipos. Por ahí empezaría yo, por ahí empiezo yo toda implantación de Scrum en este tipo de situaciones, definir los equipos.
Esa definición de equipos se puede hacer atendiendo a numerosos factores y es particular de cada caso, muchas veces no resulta evidente, pero es vital hacerlo bien. Podemos particionar los equipos por numerosos criterios: tecnología, cliente al que se dedican, proyecto (la más evidente)... Lo vital, en mi opinión, es que esas particiones sean verdaderas particiones, que no existan individuos que están en n equipos a la vez.
Yo suelo analizar las particiones que me salen según las leyes de las particiones de Roger S. Sessions, y da buen resultado:
1ª Ley: Las particiones deben ser verdaderas particiones.
2ª Ley: Las particiones deben ser adecuadas al problema.
3ª Ley: El número de subconjuntos en una partición debe ser adecuado.
4ª Ley: El tamaño de las particiones debe ser aproximadamente igual.
5ª Ley: Las interacciones entre subconjuntos deben ser mínimas y bien definidas.
Si lográis hacer bien eso, habréis dado un gran paso. Luego, a la hora de determinar el número de backlogs, el enfoque más simple es un equipo, un backlog, un product owner. Aunque no siempre es posible, es el enfoque más simple y el que siempre se debe perseguir.
Hay una manera muy simple de saber si hemos hecho esto bien: elegimos un desarrollador al azar y le preguntamos:
¿Tu a qué equipo perteneces?
¿Dónde está vuestro product backlog?
¿Quién son vuestro Producto Owner y Scrum Master?
¿Cuáles son los objetivos de tu equipo para este sprint?
Si recibimos respuestas ambiguas, es que no tenemos un modelo de equipos. Sin un modelo claro de equipos no es posible una correcta implantación de Scrum.
El enfoque más simplista de Scrum persigue un proyecto, un backlog, un equipo. Pero esto no siempre es posible en consultoras donde lo que hay son muchos proyectos pequeños que gestionar como un todo en lugar de algunos proyectos grandes que respondan al modelo simple de Scrum.
Este post, se inspira en una interesante conversación mantenida sobre este tema en la lista de Agile Spain, quizás queráis leer los pensamientos allí expuestos.
¡Espero vuestros comentarios!