Me mola Scrum, pero que lo haga otro.

¿Cuántas veces en nuestro trabajo hemos mirado a nuestro alrededor y hemos visto que algo no encaja? Por alguna extraña razón pensamos: “Siempre lo hemos hecho así”. Todos sabemos que es una respuesta absurda, sin embargo nadie quiere cambiar nada. Esta reflexión nos la hace Jeff Sutherland en su libro “Scrum: The Art of Doing Twice the Work in Half the Time”.

Y así es, en muchos lugares de trabajo encontramos a personas con ansias de mejora, ya que los procesos improductivos que existen en las empresas son muy visibles a bajo nivel. El problema es que muchas personas creen que la mejora es tan difícil que no se va a producir, y acaban por mirar hacia otro lado. A Scrum le ocurre algo parecido. En este post vamos a terminar con ese mito.

Como sabemos, la misión de Scrum consiste en ayudar a los equipos a explotar al máximo su potencial y su productividad. Aplicar Scrum puede parecer difícil, pero esa afirmación sólo proviene de quien ni siquiera está dispuesto a intentarlo. No hay excusa válida que nos impida hacer Scrum. El gran problema a la hora de ponerlo en práctica es la disciplina. En muchos casos termina surgiendo el caos y buscamos excusas para no cambiar nada.

Después de varios años trabajando con equipos en cliente, me he encontrado con diferentes excusas a las que se agarran los equipos para renunciar a Scrum sin ni siquiera haberlo intentado. A continuación analizaremos algunas de las más comunes.

Excusa 1: “No estamos tan mal”

La primera excusa tras la que muchos se escudan es la de “no estamos tan mal”. Se trata de equipos que se han acostumbrado al statu quo, que saben que las cosas no son perfectas pero que piensan que nada se puede cambiar. Tenemos que demostrar a estos equipos que existen formas mejores de hacer las cosas. Generalmente se les acaba convenciendo por ósmosis: si ven a equipos cercanos que progresan, muchos acabarán por querer probar “eso que hace el vecino”.

Excusa 2: “Sabemos hacer Scrum (pero en realidad no)”

También están los equipos que creen saber lo que significa hacer Scrum. El problema es que alrededor de Scrum se han creado muchas organizaciones y guías diferentes que explican qué es Scrum porque piensan que al ser ágil, se puede modificar a tu gusto. Hace poco un compañero me dijo lo siguiente: “He hecho muchos cursos de Scrum en diferentes empresas y todos decían que el suyo era el bueno”.

Pero Scrum sólo hay uno, el creado por Jeff Sutherland y Ken Schwaber, y podemos estudiarlo a través de la Scrum Guide. En este grupo se incluyen a las personas que defienden que "lo importante de Scrum no es seguir las normas, sino mantener el espíritu". El problema es que si entendieran el espíritu, entenderían para qué están las normas, así como todo lo que se pierde cuando estas no se respetan.

El espíritu real de Scrum consiste en entregas tempranas para poder inspeccionar, aprender y adaptarnos en el siguiente Sprint. Sin entregas, Scrum no funciona. Un cliente puede aceptar que no se cumpla una fecha si se le va entregando valor, pero no aceptará que no se llegue, si no ha podido ver nada.

Excusa 3: “Con una fecha fijada, no podemos hacer Scrum”

También hay equipos que desconocen Scrum y afirman que “si hay una fecha, no puede haber Scrum”. De nuevo discrepamos ante esta excusa. Si la fecha es una restricción del proyecto, entonces será el alcance el que variará. Eso sí, poner fijos en la ecuación fecha y alcance acaba por ahogar los proyectos.

Al final, algo tiene que ser variable, y si tenemos en la ecuación ambos valores fijos, la calidad entregada será “la-que-nos-dé-tiempo”. Es importante comunicar a los equipos que tienen esta forma de pensar que un proyecto con baja calidad genera mucha frustración. Para un desarrollador, por ejemplo, el código es algo más que su trabajo.

El hecho de que un código esté bien construido será algo que lo motive, y asimismo se sentirá frustrado si tiene que renunciar a la calidad para llegar a una fecha concreta. Además, para nuestros clientes, una baja calidad en un proyecto generará descontento entre los usuarios. Podemos ejemplificar esta sensación muy claramente si nos trasladamos por un momento al taller de nuestro mecánico.

Cuando llevamos el coche al taller solemos toparnos con la siguiente estimación: “Arreglarlo nos llevará 3 días, tenemos muchos coches pendientes”. La verdad es que no nos importan los demás coches; nosotros queremos nuestro coche ya, a poder ser en una hora, y si son veinte minutos, mejor.

Sin embargo, hay una cosa que queremos por encima de todo: que cuando saquemos el coche del taller no tengamos que volver a llevarlo porque falle algo. Eso sí que nos cabrearía y nos generaría desconfianza en ese taller. Preferimos los tres días a la opción de menos tiempo pero asumiendo riesgos.

Excusa 4: “En la vida real es muy difícil hacer Scrum”

Pasamos ahora a los equipos que nos dicen: “la vida real, ya sabes cómo es”. A estos equipos generalmente hay que mostrarle justamente cómo es la vida real. En la vida real hay muchas horas extras, sobreesfuerzos, cambios continuos de prioridades, personas descontentas, mucha frustración, clientes insatisfechos, proyectos fracasados y personas con depresión o ataques de ansiedad.

Si no cambiamos nada, seguiremos obteniendo los mismos resultados que actualmente tenemos en la supuesta “vida real”. ¿Describe Scrum un mundo ideal que no existe? ¿Debemos rendirnos a la realidad? ¿Es Scrum tan irreal que más vale que lo hagan otros? Después de trabajar con muchos equipos, he descubierto que generalmente hay dos salidas: seguir como estamos o cambiar, la archiconocida expresión “salir de la zona de confort”.

Recordemos que Scrum nace de personas que, viendo todas estas situaciones, deciden crear un modelo de trabajo diferente, más cercano a cómo funciona el desarrollo de Software.

No obstante, hay una buena noticia: la ley de Pareto 80-20 aplicada al software nos dice que “en el 20% de las funcionalidades está el 80% del uso que le van a dar los usuarios a la aplicación”. Por tanto, la clave es encontrar ese 20%, y es precisamente ahí donde Scrum nos puede ayudar.

Para que funcione, la priorización es clave, y esta se podrá extraer de la claridad que nos aporta un Sprint Review. Muchas personas piensan que el famoso Product Backlog es la alternativa en Scrum al Plan de Proyecto en un proyecto tradicional. ¡Nada más lejos de la realidad!

Cuando se creó Scrum, Jeff Sutherland tuvo una conversación con su responsable en la que le hizo ver que construir un Plan de Proyecto era autoengañarse y que no serviría para nada. Su responsable le respondió: “De acuerdo. ¿Y qué me piensa entregar a cambio del plan?”. A lo que Jeff contestó: “Pues al final de cada mes (Sprint) le voy a entregar cosas terminadas, cosas que poder vender si se quiere y sobre las que poder opinar”. Este es el motivo por el que el Sprint Review es uno de los pasos más importantes de Scrum.

Muchos equipos llaman a este paso la “Demo”, lo cual es un gran síntoma de haber malentendido Scrum. En una “Demo”, el Equipo de Desarrollo enseña al Product Owner y a los diferentes Stakeholders que haya invitado cuál es el estado del proyecto. Si dejamos que la reunión se desarrolle así, nos encontraremos con que realmente se trata de una reunión de informe que sólo sirve para estudiar el porcentaje de avance, lo cual no es donde Scrum quiere poner el foco.

El Sprint Review, como todo en Scrum, está basado en la Inspección-Adaptación. Es una parte del proceso donde el Product Owner, junto con el resto del equipo, va a inspeccionar con los Stakeholders el producto que estamos construyendo para adaptar el siguiente Sprint a lo que está pasando.

Este evento es responsabilidad del Product Owner y por tanto será él quien lo conduzca y quien vele porque salga bien. Recordemos que el resultado de un Sprint es la suma del incremento que ha desarrollado el Equipo de Desarrollo junto a las decisiones que el Product Owner ha tomado, por tanto todos deben poder responder de ellas e inspeccionarlas en común.

En un Sprint Review no sólo se inspecciona el incremento, también se inspecciona el mercado: ¿Lo que estamos haciendo le sirve a alguien? ¿Estamos acertando? ¿Alguien pagaría por lo que hemos hecho? Si la respuesta es negativa, es preciso cambiar el plan. Otra cosa habitual en la “Demo” es encontrarnos a un Stakeholder con mucho poder en la organización reprender al equipo porque “va mal”.

Este tipo de actitudes no harán que el equipo trabaje mejor, es más, posiblemente haga que vayan peor porque estarán varios días comentando lo sucedido en vez de centrarse en el producto. Ante estas situaciones hay que tenerlo muy claro: “No me eches una bronca. En vez de eso, ¿cómo me vas a ayudar para que lleguemos?”.

Excusa 5: “Este proyecto es especial, no podemos hacer Scrum”

La última excusa que nos podemos encontrar es la que dice: “Scrum está muy bien, pero es que este proyecto es especial”. Yo tuve la experiencia hace tiempo de escuchar esa frase de dos Scrum Masters el mismo día. Me hizo gracia, ya que según el PMI todos los proyectos son únicos e irrepetibles, y por tanto, especiales. ¡Abracemos el cambio! Busquemos caminos para mejorar.

La buena noticia es que ya hay equipos que alcanzan la excelencia, equipos con muchas ganas de mejorar que se superan día a día por hacerlo mejor. Equipos que no se rinden y que no tienen miedo a probar hasta encontrar lo que funciona.

En Paradigma, uno de los equipos que hace Scrum de libro, había mejorado tanto que se tuvo que hacer la siguiente pregunta: ¿Qué podemos mejorar ahora? Se atrevieron a probar con Kanban. No sabían de antemano si este era el mejor método, pero quisieron probar. Habían ido dando pasos hacia la excelencia y no se conformaban sólo con eso. ¡Querían seguir superándose!

Finalmente, es necesario entender que el cambio de una organización es un proceso lento y que requiere esfuerzo. Muchas personas que tratamos de llevar Scrum a los equipos vemos que es una cuestión de esfuerzo y de querer llevar a cabo el cambio.

Scrum no es algo imposible o difícil de hacer. Cuando se trabaja con un equipo que de verdad quiere mejorar, se acaba viendo que es posible y que, poco a poco, ese equipo va a encontrar caminos que lo lleven a la excelencia.