SCRUM EN EMPRESAS DE TRADICIÓN NO AGILE: ¿CASOS DE ÉXITO O FRACASOS ESTREPITOSOS?
Seguro que todo el mundo ya ha oído hablar de los proyectos agile, algunos incluso hemos trabajado en varios proyectos basados en esta cultura.
Creo que, en la mayoría de los casos, la pregunta que más me hacen -quienes no han trabajado nunca así- es ¿de verdad funciona?
La respuesta casi siempre es un Sí aunque con la boca pequeña o poniendo algún que otro pero… Incluso hemos podido escuchar sobre algún proyecto donde no haya ido del todo bien.
Como todo en la vida, si algo se toma en serio, se pone empeño en ello y se ejecuta de manera correcta, el éxito está casi asegurado y esto es precisamente lo que necesita un proyecto de estas características.
En compañías donde ha habido un cambio de cultura a fondo, este tipo de proyectos suelen funcionar y el valor que se les da a los usuarios es muy grande.
En cambio, en aquellas compañías donde se “impone” este tipo de proyectos porque “están de moda”, donde la cultura en muchos casos suele ser la del “tiene que estar para ayer”… no suele funcionar tan bien.
En un proyecto bien ejecutado, las ventajas suelen ser muchas, pero no las vamos a enumerar aquí, ya que son numerosos los artículos que hablan sobre ellas. Sin embargo, no siempre encontramos las desventajas de intentar ejecutar proyectos en agile en empresas donde no se ha dado el cambio del todo.
La palabra clave es: CULTURA. Tiene que acometerse un cambio profundo para adecuarnos a esta cultura, cosa que en la mayoría de los casos no pasa.
Nos saltamos las bases de la metodología
¿Qué suele pasar?
Si nos centramos ya en metodología Scrum, existen una serie de ceremonias importantes (Daily, Sprint Review, Sprint Planning, Retrospectiva…) que son las primeras sacrificadas o transformadas.
Bien, ese es el primer error, saltarnos alguna de estas ceremonias o adaptarlas de tal forma que nada tienen que ver con la premisa original.
Si tomamos como ejemplo la Daily, estas son algunas de las premisas:
- Una Daily debe ser una reunión de no más de 15 minutos.
- De sólo los miembros del equipo, donde a veces se puede invitar al Product Owner.
- Donde se está de pie en una sala y donde hablamos de lo realizado el día anterior, lo que realizaremos en el día de hoy y donde también indicaremos los bloqueos que tenemos pero no se tratará de solucionarlos.
Eso es el mundo ideal y aunque no parece muy difícil de cumplir, ¿qué suele pasar en realidad en muchos casos?
- La Daily se hace por teléfono, puede tener lógica ya que hay gente que no puede trabajar en el mismo sitio, pese a que es lo que se recomienda, pero ni las personas que están en el mismo edificio se reúnen en una sala.
- Suele usarse para comentar todo tipo de errores, comentados al detalle e incluso intentando dar solución al mismo.
- El Product Owner está presente haciendo preguntas, dando requerimientos y parando el ritmo de dicha reunión (a veces el Scrum Master pinta poco), con lo cual en algunos casos llega a durar 30 minutos y se desvirtúa del todo, ya que se convierte en una reunión de seguimiento tradicional.
Otro ejemplo claro suele estar en otra de las ceremonias, la retrospectiva.
Esta ceremonia, donde el equipo se reúne al final de cada sprint y donde se podría dar solución a muchos de los problemas ocurridos durante el mismo, es la ceremonia que más se suele obviar y provoca que en muchas ocasiones no se puedan resolver temas importantes del proyecto.
¿Esto por qué ocurre?
El problema casi siempre es el mismo: se va aplicando más o menos de manera correcta, hasta que en algún momento comienzan las prisas, las crisis y el pánico cuando se entiende -por fin- que Agile no significa que vayamos a desarrollar en la mitad de tiempo.
Si un desarrollo se tarda en hacer un mes, se tardará un mes siempre, de la manera que sea. Otra cosa es que con metodologías como Scrum seamos capaces de hacer entregas parciales, siempre llenas de valor para el usuario, donde podrá ir viendo su producto poco a poco y no al final después de un mes.
Poca implicación
Para que un proyecto Scrum tenga éxito, se tienen que definir perfectamente las User Stories donde el producto Owner en la mayoría de los casos debe describir lo que espera recibir al final del sprint (Definition of Done).
¿Qué suele pasar?
Se tiende a debatir en el Sprint Planning lo que se va a hacer y definir una User Story con un título más o menos descriptivo y, en muchas ocasiones, ninguna descripción o algo muy escueto.
Cuando la persona destinataria de la User Story la lee, tiene que hacer un ejercicio de memoria de lo que se habló en el Sprint Planning, lo que conlleva errores, errores y más errores.
Cuesta mucho en compañías de este tipo hacer entender que el email está muy bien, pero que ahora se va a redactar todo (o lo más posible) en una herramienta, Jira por ejemplo, donde se hará un seguimiento de la User Story, etc, etc. ¿Qué acaba pasando? Que adjuntamos el hilo de correos a la historia porque se hace imposible redactar todo en la Story.
¿Esto por qué ocurre?
En algunos casos ocurre que el Product Owner que se ocupa del proyecto tiene varios más y no puede acometer todo lo que requiere el proyecto. Las tareas del Product Owner no son sólo de gestión, como podían serlo en otro tipo de proyectos, sino que necesitan implicación máxima.
Derivado de esto, aparecen los errores de definición en las User Stories, ya que se necesita mucha implicación para redactar todo meticulosamente y dejar para el email dudas muy puntuales y, si son dudas que redefinen la User Story o son cambios significativos, deberían ser expuestos en comentarios dentro de la misma.
Ataques al Backlog y al sprint
Una vez empieza un sprint, las tareas son las que son y en todo caso, si hay alguna tarea que se deba subir del Backlog, será aquella cuya prioridad esté como alta y el destinatario conozca el detalle de la misma.
¿Qué suele pasar?
Durante el sprint, como hay tareas que no están ni bien definidas ni bien analizadas, se da el caso que no se pueden abordar y se empiezan a subir tareas del Backlog indiscriminadamente sin la estimación precisa y desvirtuando el sprint en cuanto a tiempo y esfuerzo.
¿Esto por qué ocurre?
La mayoría de las veces, por lo dicho anteriormente: la prisa de dar resultados inmediatos. Esto hace que se incluyan tareas sin definir y luego hay cierto caos al incluir tareas del Backlog, ya que no suele estar priorizado, derivado muchas veces de obviar otra de las ceremonias importantes: la de Refinamiento.
Subidas parciales aportando valor
Cuando a un usuario le explicas que vas a desarrollar el producto y, pese a que no esté terminado 100%, se va a ir mostrando en un entorno productivo lo que vaya terminándose, para seguidamente ir mejorándolo y evolucionándolo poco a poco con subidas parciales en cada sprint, el usuario suele decir “¡Qué maravilla!”.
¿Qué suele pasar?
Cuando de verdad estamos en proyecto y le dices a un usuario que va a ver su SW con 5 campos en la tabla en lugar de con los 10 que ha pedido, pese a que le expliques que los siguientes 5 campos los verá en la próxima evolución, el usuario dice “¡No, lo quiero todo, esto así no me vale!”. Con lo cual, te ves siempre obligado a terminarlo todo para hacer la subida y esto choca un poco con lo visto anteriormente. Volvemos sin querer a un waterfall encubierto.
¿Esto por qué ocurre?
Pues normalmente por la presión externa de quien está pidiendo resultados, quien quizá no ha entendido o no ha visto con buenos ojos este método de trabajo.
Con todo lo expuesto hasta el momento se puede entender por qué muchas veces no tienen éxito proyectos de este estilo en este tipo de compañías.
La conclusión es que para abordar proyectos de este tipo hay que diferenciar entre cultura ymetodología. La metodología puede ser Scrum, Kanban, Lean, XP… y se puede aplicar en cualquier proyecto. Ahora bien, para que tengan éxito, las empresas deben haber sufrido una transformación más de fondo en su cultura y es en este punto donde todavía, a pesar del gran avance, aún estamos muy verdes.