…o Scrum no funciona de la forma en que muchas organizaciones esperan que lo haga?. ¿La causa del fracaso al utilizar un marco de trabajo como Scrum, está realmente en Scrum, o en el modo / expectativa de uso que se le da?
Llevo casi 2 décadas trabajando en proyectos TI, y más de una década trabajando intensamente en distintas temáticas vinculadas a la agilidad. Scrum fue uno de los primeros marcos de trabajo ágiles que conocí y comencé a utilizar. Siempre me gustó la claridad (o aparente claridad) de sus definiciones: Estos son los roles. Estos los artefactos. Estas las reuniones. Scrum es un juego reglado.
Pero como cualquier juego reglado, aún de un número finito de reglas es posible tener infinitas variaciones de jugadas, movimientos y resultados posibles. (bueno, probablemente no infinitas, pero si una diversidad enorme). Como el coaching, Scrum puede resultar engañosamente simple. Vamos, que la guía de Scrum tiene sólo 20 hojas, lo que para alguien con poco tiempo o ganas de leer, parecería hacerlo el marco de trabajo ideal para aprender e intentar aplicar. Y acá tal vez empiezan algunos de los problemas: a pesar de ser corta la guía, muchísima gente que dice aplicar Scrum nunca la leyó. A pesar de ser un marco que alienta la horizontalidad, y fomenta el aprendizaje continuo, la denominación de “master” a veces hace creer a la gente que con un poco de entrenamiento se puede llegar a tener maestría en el marco de trabajo.
Como el coaching, Scrum puede resultar engañosamente simple. Y, para muchas organizaciones, el engañoso puede reemplazarse por tentador.
Cuando una organización evalúa incorporar agilidad, y es algo que viene sucediendo con bastante frecuencia los últimos 5 años, siempre aparece en la mesa la palabrita “Scrum”. Y la idea de su aparente simpleza, más que engañoso, resulta tentador. Sumemosle a eso la enorme cantidad de certificaciones que han ido germinando a la luz de su popularidad (nuevamente, para obtener el título de “master en scrum”, sólo parecería ser necesario un curso que, en promedio lleva 16hs).
Pero nada de esto, de por sí, debería quitarle valor al marco de trabajo. Desde que el tiempo es tiempo, y los negocios son negocios, organizaciones e individuos encuentran la forma de trasnformar buenas ideas en buenos negocios. En mi opinión Scrum es particularmente valioso para equipos pequeños, orientados a producto, autónomos y con poca dependencia entre las actividades que llevan adelante y otros equipos o áreas de la organización.
En mi opinión Scrum es particularmente valioso para equipos pequeños, orientados a producto, autónomos y con poca dependencia entre las actividades que llevan adelante y otros equipos o áreas de la organización.
Cuando uno trabaja en un equipo de estas características, lo reconoce enseguida. Suceden cosas diferentes que en otro tipo de iniciativas no pasan: Hay cierto espíritu de camaradería, entusiasmo, una clara orientación a resultados, y un gran “ethos” que vuelven innecesarios los planes detallados y los compromisos por triplicado y rubricados, lo que terminan ayudando a que las cosas sucedan.
Un ejemplo de un equipo donde algo parecido a Scrum sí funcionaba
Hacia el 2004 estuve involucrado en un proyecto en el que, si bien no implementamos Scrum “by the book” todas esas consideraciones existían: Se trató de la exploración de un módulo de un ERP clase mundial. Una solución para industria liberada un poco a las apuradas, con mala documentación y peor acompañamiento. Tampoco había experiencias previas de implementación (no al menos en la región). En concreto, este proyecto requería muchos desarrollos a medida, mucha interacción con la realidad del negocio (fueron mis primeros acercamientos a varios de los conceptos de Design Thinking en los que profundizaría 4 o 5 años después), muchas experimentación y mucho trabajo en equipo. Sobre esto último, creo que hubieron algunos factores muy importantes puestos en juego. Como equipo, si bien había jerarquías (Gerentes de IT, gerentes de consultoría, algún que otro senior, etc.) en la práctica funcionamos siempre como una célula horizontal, aútonoma y auto-organizada, con altos niveles de apertura para el diálogo y transparencia. Otro factor relevante fue contar con el soporte continuo de representantes del negocio, y una interacción fluida con equipos de sub-sistemas relacionados. El nivel de apertura y colaboración fue tan alto que, dentro de nuestro equipo, participaba activamente el dueño del sistema legacy que este módulo iba a reemplazar (algo que él tenía en claro desde el primer día). En cuanto al funcionamiento más operativo, fue bastante simple y conectado con la esencia de Scrum: Todas las semanas repetíamos una rutina: los lunes planificábamos los objetivos, todos los días repasabamos como veníamos (incluso con mayor frecuencia, ya que estábamos co-localizados), hacia fin de la semana visualizabamos los avances que, entre todos, habíamos logrado. Experimentábamos y aprendíamos todos juntos. Paso a paso. Puede ser que el tiempo me haya hecho olvidar las fricciones o puntos de dolor, que seguramente existieron. Pero más que nada recuerdo lo enfocados que estábamos. La pasión que le poníamos en el día a día. Y la convicción que juntos generábamos algo valioso. Nunca sentí la presión del cronograma, o del resto de la organización para con el resultado. Mucho tuvo que ver con eso el rol del “PO” y del “SM”, que si bien no tenían esos nombres, en la práctica cumplían con el rol.
Pero Scrum parece que no funciona…
Son muchas las organizaciones que, tras intentar utilizar Scrum por un tiempo, terminan abandonándolo. Esto no necesariamente es malo. En cierto punto, es probable que a un equipo Scrum le quede chico. Son muchas las organizaciones que conozco, donde Scrum fue parte de un SHU (ver SHU-HA-RI) en el proceso de aprendizaje y, a partir de su estructura, evolucionaron hacia otras formas de trabajo más efectiva.
Pero cuando las organizaciones insisten con que el problema es el marco de trabajo Scrum , he descubierto que en muchos casos no es así. En una gran cantidad de empresas, la causa principal por la que Scrum “no funciona”, es que no cumplen con los requisitos mínimos para que Scrum despliegue su valor. Como dice un conocido mío “muchas veces el problema es que se le pide a los proyectos que resuelvan las cosas que los proyectos no pueden resolver”. Con Scrum sucede algo parecido.
Para muchas organizaciones, la causa de que Scrum “no funcione”, es que la organización no cumple con los requisitos mínimos para que Scrum despliegue su valor.
¿Y cuales son estos requisitos? Bueno, muchos de ellos están descriptos en el manifiesto y los principios para el desarrollo ágil de software y capturados en los pilares de Scrum: adaptación, inspección y transparencia. La clave es interpretarlos a la luz de la realidad de cada organización
Algunos de los requisitos bajo los cuales Scrum tal vez podría funcionar
A continuación, repaso algunos de los requisitos que considero indispensables para que el marco de trabajo Scrum despliegue su promesa de valor:
- La esencia de Scrum es empirismo: Si la organización necesita responder para cuando, con exactitud, va a tener terminado cada uno de los entregables, probablemente con Scrum no podrá hacerlo. Si ya sabemos de antemano todos los pasos, y todos los tiempos, por qué usar un enfoque adaptativo?
- La esencia de Scrum es la autonomía del equipo: Si dentro del equipo hay una figura de liderazgo tradicional (líder que “lidera” personas), el equipo pierde la independencia y el poder de toma de decisión necesario para cerrar el ciclo de «confianza-compromiso»: mientras menos confianza le damos a las personas, menos auto-confianza las personas tendrán. Y también, menos compromiso con los resultados que ellos no comprometieron, sino el líder). La autoorganización da lugar a elementos emergentes e impredecibles. Si dirigo o condiciono, el diseño emergente “no emerge”. Las personas delegan su poder de decisión en el lider, y su nivel de empoderamiento baja. Como organización, si queremos utilizar Scrum, tenemos que confiar en las personas y los equipos para que funcione Scrum. Y si no podemos confiar en las personas, y por eso tenemos que poner estructuras de control sobre ellas, probablemente la falta de resultados (por la que decidimos intentar con Scrum) este muy directamente vinculada a esa falta de confianza.
- La esencia de Scrum es el foco y la priorización: Si el nivel de contradicción, ambigüedad o “tironeo” organizacional hace que siempre haya “múltiples prioridades” (un oximoron), probablemente Scrum no sea la mejor idea. Tener una lista priorizada por el negocio de funcionalidades está en el ABC de Scrum. El que no haya prioridad indica muchas cosas significativas: ¿puede ser que los propósitos organizacionales no sean claros?¿Puede ser que haya más iniciativas abiertas que capacidad de ejecución?¿Quizás no hay un buen alineamiento entre las áreas, y todas compiten por optimizar su desempeño, en lugar de generar sinergia para mejorar el resultado de toda la organización?. Sin foco y prioridad, se corre un riesgo muy alto de terminan siendo una fábrica de funcionalides que nadie use, o estar interrumpiendo siempre las iteraciones, en la persecución de un objetivo de negocio que siempre se modifica.
¿No sirve entonces intentar aplicar Scrum en organizaciones donde no se cumple estos requisito?
La respuesta, como intuirán a esta altura, no es otra que depende. Intentar aplicar Scrum en organizaciones que no cumplen los requisitos mencionados más arriba, probablemente sí sirva, pero no del modo en que se espera que lo haga. Intentar aplicar Scrum en una organización con cierto nivel de disfuncionalidad (¿acaso no son todas las organizaciones un poco disfuncionales? probablmente ponga de relieve muchísimas problemáticas organizacionales. Es decir, el intento de usar Scrum actuará como un metabolizador de las ineficiencias organizacionales, exponiendolas más antes que después. Resolverlas o no, ya no depende tanto de Scrum, como del deseo / necesidad de la organización por querer cambiar genuinamente.
Al final del día, lograr esos cambios generará un éxito mayor al que se le puede atribuir al marco de trabajo Scrum. Es el ejercicio de trabajar en resolver las problemáticas organizacionales la que terminará posicionándola en otro lugar.
Ese resultado valdrá más que cualquier marco de trabajo, por mejor o peor que sea.