Quienes pensamos que la adopción de Scrum puede suponer un paso adelante en la consolidación del proyecto empresarial, somos conscientes de la dificultad del proceso. O deberíamos serlo.
Aún sin ser innecesariamente dogmáticos, adoptar Scrum como marco para la aplicación real y medible del concepto Agile, orientada al desarrollo del negocio a través de nuestros equipos, supondrá afrontar una revisión del modelo de relación personas-empresa existente en la organización, de nuestra cultura corporativa.
Para ello, deberemos trabajar, conjuntamente, desde un conocimiento del marco Scrum y desde un reconocimiento de nuestra propia realidad, un enfoque que nos permitirá afrontar el proceso de manera tan rigurosa como integradora, sin dogmas, pero con firmeza.
Así, haciendo nuestro el dicho de “Nunca desaproveches una buena crisis”, respondemos a la pregunta que encabeza este artículo con un ¿por qué no?
¿Por qué no aprovechar el momento, justo ahora, para hacer de nuestra estrategia RESTART mucho más que una vuelta a la actividad?
¿Por qué no aprovechar el momento para encontrar nuevas formas de hacer lo que hacemos, más eficientes, más inclusivas, más creativas y libres de las limitaciones que nos imponen las creencias, las nuestras y las de nuestros equipos, sobre las capacidades reales de lo que podemos ser como organización?
Si hacer siempre lo mismo no nos llevará a nada nuevo, hacer algo nuevo, y hacerlo mal, no nos llevará a nada mejor.
El concepto japonés SHU-HA-RI, propio de las artes marciales, describe el camino del aprendizaje hacia la maestría a través de tres etapas:
Sigue la regla (SHU) – Rompe la regla (HA) – Sé la regla (RI)
Comenzar por la primera fase, la de aprender a hacer Scrum, nos permitirá entender qué es, cómo se hace -bien- y, quizás lo más importante, para qué queremos utilizar Scrum en nuestra organización.
A partir de este punto, podremos identificar qué aspectos de nuestra realidad deberemos considerar especialmente, y en qué orden, para acometer esta tarea.
Uno de los puntos críticos que encontraremos, foco de resistencias, no obstante, razonables y, por ello, posibles de anticipar y de gestionar a favor del proceso, será el definido por el enfrentamiento entre dos visiones que parecen polarizar el debate sobre el modo en el que las empresas tratan de conseguir sus objetivos: el enfoque de proyecto y el enfoque de producto.
A pesar del consenso existente sobre sus diferencias, ya que nos acercamos a Scrum y, a través de éste, a Agile, deberíamos convenir una definición del concepto de proyecto, una que, para ser útil, deberá ser rigurosa, adaptada a nuestra realidad y libre de prejuicios, es decir, una “Working Definition”.
Una primera definición de proyecto incluiría, junto a los términos de alcance, plazo y presupuesto, un relato que, como resumen, desprestigiaría el alcance, al condicionar el resultado del proyecto a los otros dos factores y que, como conclusión, aseguraría que un proyecto, por lo general, no acaba nunca.
Las descripciones más académicas, como la del PMI[1], dejan claro, sin embargo, que un proyecto es “una misión temporal, emprendida para crear un producto, servicio o resultado, únicos”.
Parece que esta y no otra es la acepción de proyecto que los creadores de Scrum tienen en mente cuando escriben en su guía[2]:
“cada Sprint puede ser considerado un proyecto con un horizonte no superior a un mes. Como los proyectos, los Sprints tienen por objetivo construir algo”
Es decir, a través de Scrum no vamos a dejar de hacer lo que hacíamos, simplemente (!), creemos con firmeza en que lo vamos a hacer mejor, en que vamos a construir un producto de más valora través de la participación, comprometida y responsable, de nuestros equipos, limitando el riesgo asumido y reduciendo el time to market al construir el incremento en sucesivas entregas, sometidas a inspección y a adaptación, siempre, con foco en construir soluciones en funcionamiento.
Y, ¿en qué nos basamos para creer algo así?
Como hemos visto, la diferencia entre construir un producto y trabajar en un proyecto únicamente es relevante si atendemos a cómo realizamos el trabajo.
Scrum no es un modelo, ni una práctica ni, tampoco, una metodología.
Scrum se define como un marco ligero, sencillo de comprender y difícil de dominar[3]. Sus fundamentos, teoría, roles, eventos, artefactos y reglas son claros e inmutables de forma que, si bien es posible implementar únicamente parte de todo ello, el resultado obtenido no será Scrum.
El marco teórico de Scrum está basado en el Empirismo, y es aquí donde encontraremos un aspecto crítico para su integración en una organización que esté orientada a la creación de valor a través de proyectos, cuyo enfoque tradicional, basado en el Racionalismo, difiere notablemente en aspectos tan prácticos y relevantes como la gestión del riesgo y la de los equipos.
Scrum se orienta a la creación continuada, sostenida e incremental de valor, donde resulta fundamental la inspección, entendida como oportunidad para obtener el feedback de los usuarios, clientes o stakeholders, sobre el incremento, esto es, sobre la suma de todo el producto construido a lo largo de los diferentes Sprints, desde el primer Sprint.
De esta manera, Scrum consigue limitar el riesgo, algo que puede observarse objetivamente por comparación con la experiencia en la gestión tradicional de proyectos, en los que el producto, descrito al inicio de la planificación a través del alcance tiene, básicamente, una única fecha de entrega.
En Scrum, gracias al Empirismo, el cambio es bienvenido, en la medida en que incrementa las posibilidades de construir el producto de más alto valor posible limitando el desperdicio y, como hemos visto, el riesgo.
A la vista de lo anterior, resulta evidente que, en términos generales, una compañía alejada formalmente del marco Agile, en general, y de Scrum, en particular, deberá poner atención a la necesidad de acercar a los stakeholders al proceso de construcción del producto, y hacerlo de modo que su feedback pueda ser no ya considerado, sino auténticamente incorporado a lo largo del mismo.
Ya hemos visto cómo el valor, en forma de “workingsolutions”[4], resulta fundamental en Agile y, como marco capaz de hacer realidad los principios del Manifiesto Ágil, en Scrum.
Otro elemento crítico, “el otro”, deberíamos decir, son los equipos.
Las personas que componen el Equipo Scrum son conscientes de su capacidad y de su responsabilidad, a nivel individual y compartido, para construir el incremento esperado y, al mismo tiempo, gozan de la confianza de la organización en que, efectivamente, lo son.
Equipos auto organizados y multifuncionales, formados por personas capaces y responsables a quienes une una alianza en valores.
Siempre han existido organizaciones que han confiado en las personas que las integran. Esto no es algo exclusivo de Scrum, como tampoco loes de Agile.
Aunque, en la actualidad, Scrum es utilizado en la práctica totalidad de sectores y, dentro de éstos, en la mayoría de las funciones, tuvo su origen en el mundo de la tecnología.
Nacido en los años 80, Scrum adquiere su forma de marco de trabajo, integral y coherente, en los años 90, y es a partir de 2001 cuando, con la aparición del Manifiesto Ágil, pone de manifiesto su capacidad para hacer realidad sus principios, entre los que figuran los relativos a personas y a la colaboración.
Tal y como narran los propios firmantes del manifiesto original, este es el resultado de la identificación de los puntos comunes entre los diferentes modelos que cada uno expuso ante los demás, todos los cuales giraban, entre otros aspectos, sobre la imposibilidad de continuar aumentando el control sobre el trabajo de los equipos cuando, como se hacía evidente, el incremento sostenido de la supervisión no había logrado una mejora de las ratios de éxito en la industria.
La existencia de estructuras y posiciones orientadas a la planificación de los proyectos, y a la supervisión del trabajo y de los trabajadores, es un hecho más que probable en una organización orientada hacia la gestión tradicional de proyectos.
Así, otro aspecto crítico en la adecuación de la organización al marco Scrum será afrontar el reto de alinear su estructura y, muy particularmente, el de integrar a la figura de Project Manager en el Equipo Scrum, algo que, además, debe hacerse con transparencia e integridad y no a través de una acción de “camuflaje”, iniciada por un cambio vacío, desconcertante y desmotivador para todos sus miembros, en la denominación de las funciones.
Sin duda, la compañía deberá afrontar otros muchos retos en su camino para encontrar su nueva forma de trabajar.
Unos retos, no obstante, a la altura del impuesto por la realidad de la crisis que vivimos, y por la necesidad de que nuestras empresas sean, como siempre han sido, la garantía del futuro de nuestro país.
En su empeño por conseguirlo, los empresarios tienen ante sí una nueva oportunidad de poner de relieve suya demostrado liderazgo, una tarea para la que deberán ayudarse del estudio y de la experimentación de nuevas formas de trabajar, en un proceso dirigido a hacer de la nueva realidad de su empresa, una realidad mejor para todos.
[1]Project Management Institute
[2]The Scrum GuideÔ. The Rules of the Game. Ken Schwaber and Jeff Sutherland (Documento disponible libremente en www.scrum.org)
[3]Lightweight, Simple to understand and Difficult to master. The Scrum GuideTM
[4]Adaptación libre del autor del término Working Software, uno de los elementos que definen el Manifiesto Ágil, publicado en 2001. La licencia busca hacer extensivo el concepto, asociado con el compromiso de producción de software operativo, funcionando, a la totalidad de productos y servicios que pueden ser construidos como resultado del trabajo en colaboración de un grupo de personas.
