Trece ideas de Scrum que puedes aplicar en tu gestión

Scrum por allí, Scrum por allá… llevo oyendo hablar de Scrum mucho tiempo ya, “una metodología de desarrollo de software”, “tiene que ver con el mundo de agile”, “cosas de techies”. En definitiva, oyendo campanas pero sin haber dedicado nunca tiempo a profundizar lo suficiente.
Bueno, ahora ya sé de dónde vienen las campanas 🙂 He puesto foco durante unas horas a entender mejor que es eso de Scrum (gracias a este curso online, y a leer la guía oficial de Scrum), y cómo funciona. Efectivamente, Scrum es una metodología de desarrollo de producto (normalmente vinculado al mundo del software) que se enmarca dentro de la filosofía Agile. Diría (y aquí si algún experto me tiene que corregir que lo haga) que es una forma (¿la que más éxito ha tenido?) de “aterrizar” la filosofía del manifiesto ágil en algo más concreto y funcional.
Ahora bien, es evidente que Scrum tiene su origen y su “caldo de cultivo” en el mundo del desarrollo del software, y se ve claramente que muchas de las cosa que plantea es ahí donde tienen todo el sentido del mundo, y donde los expertos lo explotan mayoritariamente. Lo que me iba cuestionando a medida que leía era: ¿es aplicable Scrum a otros ámbitos, a la gestión de proyectos menos técnicos? Algo me dice que sí, que la dinámica de trabajo puede ser extrapolada (con más o menos “ajustes”).
(Pulsa aquí si quieres ver una introducción breve a las metodologías ágiles y a Scrum)
Fruto de esa reflexión, y más allá de que se pueda aplicar la metodología de forma más o menos estricta, he extraído estas trece ideas de Scrum que se pueden aplicar a la gestión de cualquier proyecto:

• Ten siempre el valor aportado al cliente como vara de medir: En Scrum, los elementos del product backlog se priorizan en función del valor que van a aportar al cliente. Lo que más valor aporte, se busca hacer cuanto antes mejor. El objetivo que persigue el “producto incremental” siempre es buscar aportar el mayor valor posible, cuanto más tangible mejor. La definición de requerimientos, el feedback en las revisiones… siempre está orientado a lo mismo. Esta “obsesión por el valor” es algo que no debe perderse de vista nunca en el desarrollo de un proyecto. ¿Cuántas veces, en el fragor de la batalla, nos miramos demasiado el ombligo y nos olvidamos de para qué estamos trabajando, nos enredamos en discusiones bizantinas que no llevan a ningún sitio, o nos emocionamos con detalles que apenas le aportan a nadie? Pues eso, no perdamos la brújula de la aportación de valor.
• Organiza tus proyectos como sucesión de miniproyectos cerrados: se definen los “sprints” como periodos de una a cuatro semanas de trabajo sobre una serie de elementos del backlog (elementos que se definen al principio del sprint y que no se tocan) que, al finalizar, dan como resultado una “versión funcional del producto”. Este enfoque elimina la incertidumbre, los cambios de prioridades, el pasarse la vida replanteándose cosas… y permite al equipo centrarse en “producir” sin interferencias del exterior durante el sprint. Nos centramos en lo que hemos definido para el sprint, nos aislamos del exterior (la relación con el exterior es cosa del product owner) y sacamos el producto que nos habíamos propuesto sacar. Lo que haya que cambiar, lo que haya que corregir, las nuevas prioridades… ya se abordarán en el siguiente sprint (que, como llegará pronto, en ningún caso nos va a suponer un gran problema).
• Entrega producto valioso desde el primer momento: además de funcionar como una sucesión de “miniproyectos”, en los sprints el objetivo es que al terminarlo haya un resultado final. Con cada “miniproyecto” el resultado será mejor y mejor (iteraciones), pero desde el primer momento se busca resolución y no hay que esperar a que transcurran n meses para tener algo tangible o darse cuenta de que, oh, no has ido por el buen camino. De hecho, idealmente, podrías abandonar el proyecto al terminar cualquier “sprint” y el resultado sería valioso por sí mismo. De esta forma, todo el trabajo que haces tiene sentido y aporta valor por sí mismo.
• Feedback, feedback y más feedback: igual que en el caso del design thinking, el objetivo es que tras cada “sprint” se produzca una revisión que permita validar que efectivamente el resultado incremental aumenta el valor, ver lo que funciona y lo que no, y a partir de ahí tomar decisiones para la siguiente ronda. Este ciclo permanente de “producto funcional” y “feedback” permite ir avanzando y adaptándose de forma continua. No olvidemos exponernos al veredicto de los usuarios, no tengamos miedo a recibir sus opiniones: es lo único que nos sirve para mantener el rumbo.
• Las prioridades las define uno y nadie más: el product owner es la figura encargada de interactuar con los “usuarios/clientes” (stakeholders en general), de identificar sus necesidades, de llegar a compromisos con ellos respecto a sus prioridades… y una vez filtrado todo ello, de trasladarselo al equipo de forma unívoca. Es el único que lo hace, la bisagra que une y a la vez aísla a los stakeholders y al equipo, el único interlocutor válido. Esta figura recupera el principio clásico de la “unicidad de mando”, y evita que haya más gente “metiendo la cuchara” y mareando al equipo, cambiando prioridades y tratando de arrimar el ascua a su sardina.
• Protege al equipo: el equipo debe centrarse en trabajar, y aislarse en la medida de lo posible de interferencias e incertidumbres. Esto es labor del product owner, que centraliza las relaciones del equipo con los stakeholders (evitando que éstos vuelvan loco al equipo) y cerrando el alcance de los sprints en las reuniones de planificación (proporcionando un escenario de estabilidad al equipo, mientras él absorbe nuevos requisitos, cambios en prioridades, etc… que retendrá hasta llegar al siguiente sprint).
• Comunicación multidireccional constante: Scrum define en la metodología todas las ocasiones en las que se producen interacciones entre los miembros del equipo. Reuniones de planificación, reuniones de refinamiento, reuniones diarias, reuniones de revisión, retrospectivas. En todos los casos el objetivo es “poner encima de la mesa” las distintas visiones que se puedan tener (sobre dificultades, enfoques, cómo se va a trabajar) y llegar a acuerdos. Coordinación sobre la base de la comunicación permanente.
• Deja que los que saben se organicen: el product owner es el que define las prioridades, pero a partir de ahí es el equipo de desarrollo el que determina cómo abordar esas prioridades, qué tareas realizar, cómo repartírselas, cómo coordinar sus distintas habilidades. Son los que mejor saben hacer las cosas, y no tiene sentido que venga nadie de fuera a organizarles el trabajo. La autonomía es una clave de la motivación, y la motivación es una de las claves de un trabajo bien hecho.
• Los equipos necesitan estar equilibrados: el equipo Scrum debe reunir, entre todos sus miembros, todas las capacidades necesarias para resolver las tareas que tiene asignadas. Es decir, no debe depender de nadie externo para avanzar. De esta forma, está 100% en las manos del equipo ejecutar lo que decidan, y no se deben quedar parados esperando a que alguien les resuelva nada. Esta visión suele ser difícil de organizar en los proyectos (y más si pensamos en proyectos transversales, con gente “de distintos departamentos” con “distintos directores”), pero resulta fundamental si queremos que las cosas salgan adelante de forma ágil.
• Presta atención a cómo trabajas, y corrige si es necesario: las reuniones de retrospectiva se centran, al finalizar cada “sprint”, en analizar el funcionamiento del propio equipo, de identificar qué cosas han ido bien y qué cosas tienen que ir mejor. Este foco tendemos a olvidarlo y más si va a ser fuente de conflictos; para darnos palmaditas todos valemos, pero exponer problemas a la cara de forma constructiva y aceptar nuestras equivocaciones ya nos resulta más difícil. Y sin embargo es fundamental si no queremos que los problemas se enquisten.
• Respeta los procesos y las herramientas, aunque parezca aburrido : siguiendo con la idea de la autoconciencia, la figura del Scrum Master se encarga de asegurar que el proceso se siga “a rajatabla”, que se celebren las reuniones que se tienen que celebrar y se hagan de la forma adecuada. En los proyectos todo son buenas intenciones, pero es fácil dejarnos llevar por las urgencias, por la rutina, por el “esto ya nos lo sabemos” y el “bueno, esto me lo salto que tampoco pasa nada” y a la que nos descuidamos hemos descarrilado por completo, hemos dejado de aplicar las rutinas y los hábitos que nos habíamos prometido seguir y acabamos en el batiburrillo habitual.
• No te olvides, trabajas con personas: otra de las labores del Scrum Master es “prestar atención a las personas”. Es decir, vigilar las dinámicas interpersonales dentro del equipo, e intervenir cuando sea necesario para reconducirlo. Esta labor pone de manifiesto algo que ya he comentado en alguna ocasión: somos personas trabajando con personas, es absurdo pretender que nos relacionemos como si fuesen máquinas. Hay filias, hay fobias, hay roces, hay momentos altos y momentos bajos… y tener a una persona cuya responsabilidad es precisamente estar atento a todo eso implica reconocer esa realidad.
• Cuanta más información tenga el equipo, mejores decisiones podrá tomar: todo el proceso de Scrum se basa en la idea de que todo es compartido por todos. Todos ven el product backlog, todos definen el sprint backlog, todos ven el seguimiento diario, todos hacen las reuniones de revisión y de retrospectiva, todos dan su opinión respecto a cómo ejecutar el trabajo… No hay carpetas privadas, no hay “ángulos ciegos”, todo el mundo tiene toda la información necesaria para hacer su trabajo. Y así, normalmente, las cosas salen mejor.