En muchas organizaciones están usando una versión personal de Scrum, con la idea de que Scrum es “solo un marco teórico” y que se puede adaptar. Hemos hablado muchas veces que, Scrum no es modificable, y que en caso de hacerlo, no será Scrum. Esto es lo que conocemos como “scrum-but”.
Soy de la opinión de que, cómo Scrum Master, a la hora de entrenar a la gente en Scrum y desarrollo ágil de software, debemos hacerlo siendo fieles a los orígenes y sus motivaciones. Enseñar un Scrum edulcorado, porque pensamos que Scrum no se puede aplicar, puede generar que unas personas que se acaben sintiendo engañadas cuando descubran lo que no les contaron. Por ejemplo, puede que en tu empresa haya dos Product Owners, sin embargo, un buen trainer enseña que con uno solo, mejoramos la toma de decisión lo que ayuda a la entrega de valor al acelerar el proceso.
Para poder enseñar Scrum bien, siempre he recomendado la Scrum Guide y el Libro Scrum de Jeff Sutherland. Con la guía obtenemos las reglas del juego, es básico dominarlas. El libro de Jeff, nos enseña el porqué y el para qué de cada elemento de Scrum. Nos ayuda a entender la motivación que hay detrás de cada parte de Scrum y cómo se relacionan unos con otros. Esto es básico, no es cuestión de ser “policías del marco” sino de demostrar cómo cada regla o práctica, está enfocada a la entrega continua de valor.
A la hora de decidir cómo usar Scrum en tu empresa u organización, hay tres estrategias que podemos seguir, las repasamos.
Tabla de contenido
Scrum mecánico
La primera estrategia es simple: haz Scrum, ajustándote a sus reglas, prácticas, roles y eventos. Hacerlo es jodido, pero bien entendido, te puede ayudar a gestionar mejor la incertidumbre y entregar valor cuanto antes. Si esta es tu estrategia, ten cuidado, ya que no se pasa de equipos tradicionales a Scrum en un momento, lleva tiempo, mucho entrenamiento, muchas conversaciones y mucha gestión de expectativas. Puedes crear un formulario que mida la calidad de Scrum y así saber en qué punto están tus equipos y cómo avanzan. A esto le puedes agregar métricas de valor cómo EBM o Logic Model y consigues una visualización de cómo Scrum ayuda a tu organización.
Adaptación con cambio de nombre
Otra de las opciones es coger partes de Scrum. Recordemos que, como marco de trabajo, está compuesto de muchas prácticas y reglas, y puede que utilizando partes de Scrum consigas un buen resultado. Si consideras que tu organización no puede implantarlo y que vas a entregar más valor haciéndolo de otro manera, adelante. Si te da un mejor resultado, esto es válido, es más, si inventas una manera mejor de entregar valor, ¡publicalo! Conocerlo puede ayudar a otras personas a tener otros puntos de vista. Ahora bien, esto no es Scrum, y utilizar ese nombre no es válido.
Coger partes de Scrum y usar su nombre
Esto es quizás la actitud menos honesta de las organizaciones. Cogen partes del marco y utilizan el nombre porque “vende”. Frases como “tenemos nuestro Scrum” o “no somos talibanes” pueden llevar a los equipos a un “todo vale”, y cuando “todo vale” los resultados acaban siendo un desastre.
La honestidad empresarial en un mundo tan competitivo es difícil, pero, los equipos y las empresas van aprendiendo y son capaces de reconocer que proveedores entienden el desarrollo ágil y lo que supone hacer Scrum. Estas semanas he podido trabajar evaluando proveedores quién sabía de Scrum y quienes realmente transmitían un fake-Agile.
Os dejamos varias opciones generales que podéis seguir en vuestras organizaciones. Las dos primeras para mí, son válidas, la tercera es quizás la menos honesta y la que demuestra que hay culturas empresariales que están caducas, tiempo al tiempo.
Entradas relacionadas
Comentarios recientes