Desafiando la aplicabilidad absoluta de Scrum
Si muchísimos agilistas conocen, citan y acuerdan con las ideas de Brooks en “No silver bullets”, ¿por qué en muchas situaciones se sigue viendo a Scrum como sinónimo de agilidad, como la manera natural de lidiar con la complejidad, o como la “navaja suiza” de los marcos ágiles?
Hay algo que todavía no termino de descifrar, y que pareciera llevar a creer a muchas organizaciones que la agilidad es: trabajar en células, adefinir un PO que vele por el backlog, asignar un SM que acompañe al equipo, trabajar “autoorganizadamente” (y lo pongo entre comillas porque las interpretraciones de lo que es autoorganización cambian radicalmente de una organización a la otra) y aplicar ciertas reuniones y artefactos que se mencionan en la guía Scrum en la práctica diaria.
Y antes de que me lluevan críticas, en mis más de 14 años de conocimiento y trabajo con el marco Scrum puedo asegurar que NO SIEMPRE ES EL MEJOR MARCO DE TRABAJO. De vuelta, sino sería contradecir la idea misma de que la complejidad no admite recetas. ¿Por qué entonces pensar en Scrum como el über-meta-framework, aplicable ad-eternum a cualquier contexto y situación organiacional?. Sigo pensando que, contrario a lo que un Scrum Trainer hace más de una década insisitía al discutir conmigo al respecto, la no aplicabilidad no tiene que ver necesariamente con la falta de conocimiento en el marco en sí, sino que a veces:
- Los requisitos organizacionales para su éxito no se pueden cumplir.
- Hay más valor en aplicar otro marco de trabajo, que también puede ser iterativo-incremental, y que puede utilizar algunos de los elementos de Scrum.
- El producto a desarrollar tiene por sus características, o las del contexto de aplicación, la necesidad de utilizar otro marco (existente o, muy probablemente, algo desarrollado a medida).
Hablando bien de Scrum
No quiero decir con esto que Scrum no funcione o no sirva. Nuevamente, depende. Al contrario creo que sí funciona en muchos casos. Más aún, creo que fundamentalmente Scrum es una buena estructura para pensar el delivery de productos con una cadencia iterativa-incremental.
Algunos elementos interesantes de Scrum:
- Scrum es claro y ordena: hay roles, hay reuniones y hay artefactos. Esto da estructura, y las estructura son buenas y necesarias cuando un equipo empieza a trabajar de otro modo.
- Scrum permite visibilizar problemáticas organizacionales: la dificultad de establecer prioridades, los impedimentos para alcanzar entregables de valor al final de la iteración, la posibilidade del ejercicio de la retrospectiva, son ejemplos de elementos constituyentes del marco que generan mucho valor.
- Scrum alienta el desarroolo de una visión empírica del proceso de desarrollo de producto.
- Scrum alienta el aprendizaje de los equipos de trabajo
- Scrum impulsa el trabajo en equipo, y el poder generar entregas sin necesidad de mecanismos de comando y control, o de seguimiento individual por parte de un líder.
En conclusión
Si un equipo quiere incursionar en la entrega adaptativa de proyectos y productos, puede ser que usar Scrum sirva. En parte el éxito estará en saber acompañar ese proceso de despliegue, pero también en que se cumplan varios requisitos organizacionales que favorezcan el éxito y que el modelo de delivery y de entrega de valor organizacional sea integrable al marco de trabajo. Si pasado un tiempo razonable (¿6 meses, 1 año?) no hay evolución, quizás haya que revisar algunas de las hipótesis que dieron lugar a la existencia del marco. Probablemente haya espacio para trabajar en ellas y lograr que el marco despliegue su valor. O quizás descubramos que es el proceso en sí el que debe ser revisado… En ese caso, si un equipo en su proceso de evolución siente que Scrum lo limita, me parece genial que pueda explorar otros marcos, o adecuar algunas de las prácticas del mismo (y no hace falta que se preocupe demasiado si deja de llamarse “Scrum”; lo importante al final del día es GENERAR VALOR. Scrum no es un absoluto, ni una bala de plata, ni la solución a todos los dolores organizacionales.
También creo que es muy válido encontrar otras formas de construir producto de una manera incremental que respodan mejor a las necesidades organizacionales, y fundamentalmente, a generar valor a clientes. En esa exploración pueden aparecer marcos como ShapeUp, Kanban, u otros.
Lo importante creo es el trabajo A PRIORI de tratar de entender para qué utilizaríamos un marco determinado, qué le aportaría o no a nuestro equipo, organización y clientes, que “costo pagaríamos” por aplicarlo, qué requisitos tendríamos que establecer para qué funcione, y como aseguramos ir pudiendo evaluar el progreso en su utilización. Es decir, el marco no verlo como una “receta” mágica, sino como parte de un proceso entreverado y continuo de exploración de problemas y potenciales soluciones.
