El estado de Scrum en 2018

En 1991, Geoffrey A. Moore publicó un libro llamado “Crossing the Chasm” (En Español: Cruzando el Abismo). Es un libro que en su primera edición llegó sólamente a las 5.000 copias vendidas, y que en posteriores revisiones en 1999 y 2014 llegó a alcanzar las 300.000 copias. Este éxito se produjo principalmente a través del boca a boca. Si inicialmente el libro apeló a directivos de empresas tecnológicas, posteriormente lo hizo a ingenieros y por último ha terminado siendo referencia en las escuelas de negocio.

El libro, en resumen, es una descripción de las etapas que tienen que pasar los productos tecnológicos para llegar a la población y cuales son sus características de adaptación en el mercado. Desde los innovadores hasta los rezagados, los productos van evolucionando a través de su adopción en el mercado de esta forma.

La hora de los talibanes y de los agilistas malos

Hace tiempo tuvimos un amplio debate en twitter sobre el Sprint 0. El resumen es que hay quien apoya que Scrum y otros métodos deberían ser flexibles y los que opinan lo contrario.

Éste argumento: “Los agilistas sois talibanes y tenéis que madurar” es un argumento muy común, especialmente entre aquellos que no se sienten cómodos en el lenguaje de todo lo que hacemos. Más sobre este argumento en el blog de Café Ágil.

Lo curioso es que para rebatir, el argumento principal es: “Hay que estar más cerca del negocio”. Como si los que trabajamos en esto no lo estuviéramos. El problema es el mismo que planteaba Moore en “Cruzando el Abismo” y que se ve divertidamente reflejado en la viñeta que preside este artículo.

Las organizaciones se dan cuenta de que cada vez están más rezagadas en la competencia por un mercado -los millenials- que las ve cada vez más anticuadas, y han encontrado en todo lo que se llame digital una salida para intentar recuperar su posición en el mercado.

Como la transformación digital es para cada uno lo que quiere, han ido bajando hasta buscar métodos que les permitan competir en ese mercado, eso si, sin cambiar un ápice sus procesos internos. Así que demandan Scrum y Kanban para el desarrollo de sus productos y esto ha dado pie a un mercado en el que Scrum y Kanban son lo que a cada uno le viene bien. En esta línea iba mi artículo sobre el mercado de limones.

Y en ese lienzo, estamos algunos diciendo: Si no haces Scrum, no lo llames Scrum. Y aquellos que aprovechan esta situación -económicamente- te dicen que eres un talibán.

¿Innovators, Early Adopters, Early Majority o Laggards?

En ocasiones me pregunto, ¿En qué fase estamos con esto de la agilidad? Y creo que ya hemos cruzado definitivamente el abismo. Palabras como Scrum o Kanban, Sprint, Iteración o Scrum Master ya son parte del vocabulario normal de muchas compañías.

Es más, hemos invertido, tal y como describe Moore en su modelo, el proceso en el cual en lugar de vender innovaciones son los clientes los que las exigen. A su manera, pero lo hacen. Eso también abre la oportunidad a vender lo que consideramos oportuno cuando nos piden agilidad.

Cada vez más surgen voces que dicen “Yo no hago agilidad, yo hago [_____]”, lo cual me parece totalmente lícito. Sin embargo, creo que es deshonesto que te compren agilidad y venderle [_____], que es en definitiva lo que vamos viendo en muchos clientes que vienen rebotados y con malas experiencias.

En Scrum, no hay Sprint 0

Si vamos a la guía de Scrum, no encontraremos mención a ninguna de estas dos técnicas. La gestión de proyectos en Scrum se produce en un sólo Sprint y abarca todo el ciclo de vida del software: planificación, diseño, desarrollo, testeo y entrega en un sólo Sprint.

Tener un Sprint 0 es solo una manera de intentar hacer Scrum en fases o lo que es lo mismo, waterfall en Sprints. En Scrum siempre se comienza por el primer Sprint y al final del mismo se entrega una funcionalidad de negocio terminada. Eso permite enfocarse en lo que es realmente fundamental para entregar esa pieza de Software.

Existe una manera de tener el tiempo necesario para montar todo el despliegue usando Scrum, y esto es simplemente ajustando la longitud del Sprint. Esta depende de dos factores:

1. El tiempo mínimo que el equipo de desarrollo necesita para producir valor: Si el equipo no es capaz de producir software terminado en dos semanas, ¿Para que poner Sprints de dos semanas? Si el equipo no es capaz de entregar software en 30 días o menos, hay que ver los impedimentos y eliminarlos.
2. Un horizonte aceptable de riesgo para el Product Owner: El Product Owner, como responsable de gestionar la inversión del desarrollo, tiene que sentirse cómodo con el horizonte de planeamiento planteado por el equipo de desarrollo.

Si el equipo no puede entregar software en dos semanas, pueden tener Sprints de 3 o de 4 semanas. Scrum no dice: “Sprints de dos semanas”, sino “Software en 30 días o menos”.

¿Que sentido tiene hacer un Sprint 0 si las necesidades del proyecto pueden cambiar en dos, tres o cuatro Sprints? Scrum es desarrollo de Software iterativo e incremental, donde cada Sprint tiene varias oportunidades de inspeccionar y adaptar. Un Sprint es un proyecto completo.

Si tomamos todas las decisiones en el Sprint 0, no estamos haciendo mucho más que una fase de “preparación al desarrollo”, donde estaremos tomando muchas decisiones que luego pueden ser erróneas conforme vayamos descubriendo nuevas necesidades que antes no estaban claras. No es muy distinto de PMP o Prince2 y nos llevará al mismo problema.

Si soy completamente incapaz de entregar Software funcionando en 30 días o menos, igual Scrum no es para mi. Y eso está bien.

Tampoco inception

 

Un inception es una técnica que permite descubrir que se quiere hacer para poder llenar un Product Backlog. Es una reunión ligera, que puede durar unas pocas horas, y su lugar ideal de realización es durante el Sprint Planning del primer Sprint.

Sin embargo, muchas organizaciones intentan hacer inceptions que duran varios días y luego necesitan una o varias semanas para poder analizar con detalle cada uno de los Product Backlog Items para poder ordenar el Product Backlog.

Esto tiene otro nombre: Toma de requisitos. Da igual que ahora se haga con Post-its® y en una reunión facilitada, sigue siendo lo mismo que se lleva haciendo muchos años.

Los inceptions no forman parte de Scrum, son técnicas que no deben de interferir en el framework. Por lo que nos cuentas, querido lector, los coaches de tu organización, están adaptando el marco de trabajo Scrum a las técnicas que ellos conocen.

Todas estas técnicas funcionan muy bien con Scrum siempre y cuando asumamos que hay que entregar Software terminado en 30 días o menos. No Story Points. Software terminado.

Esto en realidad esto está inventado, y se llama Waterfall (o desarrollo por fases)

El problema es que en organizaciones en las que se dan estas situaciones, la inversión en agilidad está directamente desperdiciada. Es solamente ponerle distintos nombres a lo que se ha hecho siempre. Un proyecto se convierte en las siguiente fases:

1. Inception: Conocido como la fase de toma de requisitos
2. Sprint 0: Conocido como la fase de preparación de arquitectura/inraestructura. Algunos meten el Inception aquí
3. Desarrollo
4. Testeo
5. Hardening o estabilización
6. Despliegue: Conocida como fase de igual nos hemos equivocado en cosas y tenemos que volver a empezar

Asumiendo que cada una de esas fases dura 1 o 2 sprints, estamos poniendo Software enfrente del cliente cada 3 o 6 meses. Eso en el mejor de los casos. En el peor de los casos desarrollaremos durante un año sin que el cliente haya visto nada ¿En qué es distinto esto de los métodos tradicionales como PMP o Prince2? En nada.

La premisa de Scrum es: “Software terminado en 30 días o menos”, de forma iterativa e incremental. Todo lo que sea salirse de eso, llámese Sprint 0 o Inception no es Scrum y es una señal de organizaciones y equipos inmaduros.

Si no son capaces de hacer esto, es mejor empezar con otra técnica, como el Método Kanban, que permite una mejora evolutiva partiendo de un proceso ya existente. Seguir con Scrum es abocarse al fracaso en esta situación.

Por último y para cerrar las newsletters hasta Septiembre, recomiendo la lectura del libro de Ken Schwaber y Jeff Sutherland, creadores de Scrum: Software en 30 días o menos. En el mismo se explican las mecánicas básicas de como funciona Scrum y de cual es el ciclo de vida de desarrollo de software cuando se utilizan métodos ágiles.