Por mucho tiempo se ha estado buscando la combinación que mejor funcione y que permita que múltiples equipos Scrum puedan trabajar de manera productiva. Los creadores de LeSS, siguiendo un enfoque de experimentación, acabaron descubriendo que cosas no funcionan y cuales pueden tener buenas chances de funcionar.
Es precisamente porque con Scrum no hay receta cierta que muchos errores se acaban repitiendo una y otra vez. A lo anterior hay que sumarle el síndrome del “yo soy diferente” que básicamente consiste en creer que por alguna razón lo que no le funciona a nadie a mí me acabará funcionando bien.
Entrando en tema, en LeSS existen elementos que centralizan y otros que descentralizan. La idea de los centralizadores es crear alineación y seguir una linea común y desde luego los descentralizadores están para proveer autonomía y fomentar la creatividad. En este post hablaré de solamente un par de estos elementos centralizadores.
Un solo Product Owner para todos
Dentro de Scrum básico ya se veía desde hace décadas que la figura de un PO empoderado, visionario, emprendedor y que concibe el producto de manera sistemática, acaba siendo fundamental para llevar a buen termino el trabajo de varios equipos.
Desde luego lo anterior no quiere decir que el PO no escucha a nadie, por el contrario esta en constante comunicación con todos los equipos, interesados, clientes, usuarios, etc., pero al final del dia es el/ella quien tomas las decisiones de producto.
Visto desde la perspectiva opuesta, tener múltiples POs acaba creando dos grandes problemas:
- Una jerarquía accidental con múltiples niveles donde la comunicación fluye rápidamente de abajo hacia arriba pero no necesariamente igual de bien en la dirección contraria
- La demora en la toma de decisiones pues estas deben ser consensuadas en largas reuniones
Todos o nadie querrá ser ese PO
Si el salario, privilegios, poder de decision e influencia están concentrados en ese único PO, desde luego que todos en los equipos (o fuera de ellos) ambicionarán esa responsabilidad.
Es ahi donde precisamente LeSS propone hacer cambios sistémicos profundos dentro de la organización para que la figura del PO sea influyente y decisiva mas no jerárquica y burocrática.
En el extremo opuesto, ¿qué hacer cuando nadie quiere ser ese PO? La respuesta a la pregunta anterior puede ser el síntoma más no la causa raíz, quizás la verdadera razón resida en que la organización no crea productos innovadores, sigue recetas antiguas o simplemente castiga y busca responsables.
Al explorar las causas raíz quizás se desvelen ante nosotros las verdaderas razones por las cuales nadie de buena gana se quiere aventurar a ser el PO de varios equipos.
Un unico repositorio sin ramas
La idea de que cada desarrolladores es libre, feliz y más productivo avanzando en solitario con su copia local de código es simplemente eso, una idea; idea qué por cierto ha probado una y otra vez ser contraproducente. Desde luego en este punto comenzarán Ustedes a pensar en contraargumentos como:
- Es que así hemos trabajo siempre
- Es que la gran empresa X a la que miramos con admiración trabaja de esta manera
- Es que el manager de desarrollo, que hace 15 anos es manager y no desarrollador, nos dijo que trabajemos así
- Es que en la universidad yo trabaja así y a eso estoy acostumbrado
- Es que yo hago mi parte y luego veré como integro (si llego a integrar mi trabajo con el de los demás)
- Y la clásica, este no es un problema para nosotros porque somos “diferentes”
Acortaré el camino y les daré la respuesta a sus males: todos los desarrolladores, en todos los equipos Scrum, todos los dias, en incrementos muy pequeños, integran su código sobre un repositorio que no tiene ramas.
Si lo anterior es difícil de entender vuelva a leerlo y verá que el problema no esta en el entendimiento de la oración sino en lo contraintuitivo que suena. Contraintuitivo porque estamos acostumbrados a hacer lo contrario de lo simple, disciplinado y ordenado.
La pesadilla de la integración
“Ya terminamos nuestras historias, solamente nos falta integrarlas”, ¿habrán escuchado de casualidad la frase anterior? De haberla escuchado quizás se hicieron preguntas como las siguientes:
- ¿Cuánto tiempo tomará integrar todo?
- ¿Porque no integramos antes?
- ¿Y después de integrar recién vamos a poder probar si todo funciona?
- ¿Qué vamos a mostrar en el Sprint Review de los equipos si nada esta integrado?
- Y una pregunta existencial aún más profunda, ¿porque será que los desarrolladores desarrollan su código sin integrarlo continuamente?
Facilitaré la vida de mis lectores respondiendo solo a la última pregunta, los desarrolladores no integran su código frecuentemente porque piensan que integración continua es igual a una herramienta que compila el código de todos.
En LeSS redescubrimos un viejo concepto de eXtreme Programming, integración continua es integrar continuamente al final de cada ciclo corto e integrar siempre sobre el repositorio central.
Si lo anterior llega a ser entendido, digo realmente entendido, y practicado con una disciplina espartana, finalmente habremos despertado de la pesadilla de la integración.
La despedida
Así como existen elementos de centralización organizativa, como es el caso de tener un único PO, y elementos de centralización del trabajo técnico, como es el tener un único repositorio sin ramas, existen muchos mas elementos centralizadores dentro de LeSS – elementos que espero poder describir a futuro en otro post.
Sin embargo este juego de centralizar algunas cosas y descentralizar otras requiere un cambio profundo y la motivación para mantener este cambio. Al final LeSS, como herramienta de rediseño sistémico, lo que pretende es precisamente hacer que la forma cómo las organizaciones se estructuran cambie y de esta manera impactar el trabajo mismo y consecuente la organización de múltiples equipos Scrum.
