Pages Menu
Categories Menu

Posted by on Dic 20, 2017 in General | 3 comments

Se puede ser ágil y no usar Scrum

Mientras escribo este post no dejo de pensar si estoy escribiendo algo demasiado obvio como para poder llegar a darle rango de post. Pero, uf, es que me estoy encontrando mucha gente obcecada en seguir rigurosamente las prácticas de Scrum, o en hacer que otros las sigan, hasta el punto que se les ha olvidado que, quizá, su objetivo era ser ágiles ¿no? y Scrum era… un camino, de muchos posibles.

Hasta el punto de convertir Scrum en un conjunto de reglas que está mal visto cuestionar (recuerda aquello de en vez de reglas y normas por defecto… ausencia de reglas por defecto o más sobre los problemas de tener muchas reglas y Metodologías al detalle) o adaptar, haciendo difícil compatibilizar todo esto con aquello tan ágil como la auto-organización, todo con un fuerte olor a “procesos” por encima de “individuos e interacciones” (y no al contrario). Un caso típico de confundir el fin con uno de los caminos para llegar.

Vamos que parece que el objetivo es poder decir que cumplimos al detalle Scrum, y de ahí inferir que por ello somos ágiles, y de ahí pensar que agilidad es lo mismo que Scrum, y no es así, más bien Scrum es ágil, pero puede haber agilidad sin Scrum, o con parte de él (digo con parte, no sólo con parte de él, lo pillas ¿no?).

Sin ir más lejos, Scrum es uno, de varios, frameworks ágiles, es decir, UNO de los posibles caminos que nos ayudan a poder estar alineados con algo de mayor nivel de abstracción: los valores ágiles. Incluso entre los valores y Scrum están los principios ágiles.

De hecho, esto debiera ser obvio, Scrum es uno más, sin duda el más popular (y también el que más negocio mueve hoy), de muchos otros frameworks ágiles, como eXtreme Programming, FDD, DSDM, Crystal, etc. De todos los anteriores te he hablado en post previos, y en este post de clasificando “métodos” (realmente frameworks) ágiles (y relacionados), que quizá no leíste, porque salió casi en julio, donde te dejé una recopilación de “los otros”.

Es más, hay muchos caminos, recomendables incluso, que te pueden llevar por la vía de la agilidad y a la vez hacerte abandonar el cumplimiento riguroso de Scrum. Puedes empezar usando Scrum e ir mejorándolo para ti, manteniendo la esencia (valores) ágil, hasta el punto de que ya no seas “oficialmente” Scrum… y sigas siendo ágil. De hecho, esta es la base de Shu-Ha-Ri ¿no? aquello de empieza siguiendo las reglas, para romperlas y luego, si puedes, innovar practicas nuevas.

Si bien a mí me parece que Scrum es un buen grupo de prácticas con las que empezar, a repetir con cierto rigor cuando vengo de cero, pero siempre teniendo en la cabeza que eso será una etapa, es temporal, y no un estado final. Y que igualmente podría seguir, para arrancar, otras reglas que no sean las de Scrum o sólo una parte de ellas.

Pero, contrariamente a todo lo anterior, parece haberse interiorizado el mensaje de que si NO seguimos a rajatabla Scrum… lo estamos haciendo mal. Pero no necesariamente es así.

Si metes prácticas que típicamente son malas (o que no son las mejores), las que yo llamo del Lado Oscuro, documentación por encima de hablar, cascadas, etc., probablemente tengas un modelo de trabajo muy mejorable. Pero que te saltes cosas de Scrum no necesariamente implica que lo hagas mal… si has encontrado adaptaciones que son mejores para ti (y que no son Lado Oscuro).

Y complementario a lo anterior, también parece haberse interiorizado el mensaje de que siguiendo al pie de la letra Scrum… ya somos ágiles, y que es eso, sólo eso, lo que hay que hacer para serlo, y ya con ello hemos cumplido. Y no siempre, en muchos contextos, típicamente en desarrollo software, vas a necesitar, además, buenas prácticas técnicas para estar más alineado con los principios ágiles (ya sabes 4 valores, 12 principios), y esas no están en Scrum, y por ello es típico hacer uso de Scrum más otros como eXtreme Programming.

Está claro que si te saltas prácticas de Scrum pues sí, quizá, ya no sigas al 100% y rigurosamente Scrum, pero… ¿y a ti eso qué más te da? ¿tú quieres seguir Scrum o tener un modelo ágil de trabajo? incluso… ¿tú quieres un modelo ágil o trabajar de la mejor manera?

Javier Garzás

Javier Garzás

Ph.D. en informática, Postdoctorado en la Carnegie Mellon (EE.UU) e Ingeniero en Informática.

Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.

También soy profe de la Universidad Rey Juan Carlos.
Javier Garzás

3 Comments

  1. Completamente de acuerdo contigo, justamente de eso trataba un post que publiqué ayer en mi blog: El error de situar los procesos (aunque sean de Scrum) por encima de las personas y lo que es peor, hasta implementar técnicas del Lado Oscuro y hacerlas pasar por prácticas de Scrum. Por ello creo que la figura de Scrum Master o Agile Coach como guía hacia el objetivo de ser ágil es fundamental.

  2. Buen post Javier, y muy útil porque muchos equipos hacen un Scrum “mecánico”, incluso obsesivo con las ceremonias, y no saben responder ¿qué te aporta esta ceremonia?

    Curiosamente, muchos otros “practitioners” no han leido la Scrum Guide, no saben que es el control de procesos empírico y como lo implementa Scrum (inspect and adapt).

    Alex @ http://www.itnove.com

  3. Muy acertado, en cerca de 17 años de carrera profesional y más 8 años en modo “agile”, aun no he visto una implementación que aporte valor y funcione en plan: “vamos a seguir este X a rajatabla”.
    Pon en la X a SCRUM o de cualquier otra cosa, frameworks, libros, metodologías, buenas practicas o lo que quieras.

    Últimamente todo esto me recuerda a CMMI y sus modelos de madurez, a ITIL, COBIT y sus dominios, el PMBOK y sus grupos de procesos, PRINCE2, las ISO como SPICE y tantas otras cosas donde solo valía el “papelito” y el tener un montón de documentos, de ceremonias, artefactos, métricas, kpi, gráficas, procedimientos, etc,etc aunque a a la hora de verdad cuando apretaba el lobo.. saltaba todo por el aire y entraban los “bomberos” y el proyecto salia,, luego venian los lloros, la deuda técnica y todo eso que ya sabemos.

    Para mi la clave (y es lo que aplico) es la flexibilidad y adaptabilidad junto con el mapeo de diversas técnicas, ideas, practicas, etc (desde SCRUM, Lean, XP hasta muchisimas otras cosas que aportan ideas y conceptos interesantes, pero claro sin seguir manuales de libro sino adaptando a las circunstancias y al continuo cambio y movimiento, que es de lo que se trata).

    @tecnoestrategia

Post a Reply

Tu dirección de correo electrónico no será publicada.

Share This