Recientemente participe en el seminario Web que impartieron el Dr. Jeff Sutherland y Ken Schwaber y que organizó scruminc.com,  con motivo de la actualización de la guía de Scrum Noviembre de 2017. Puedes ver la entrevista original en inglés https://vimeo.com/241757318.

En resumen, los presentadores hablan de 5 cambios a la guía que vale enfatizar:

• Usos de Scrum
• Refinamiento del rol del Scrum Master:
• Daily Scrum (Scrum Diaria)
• Time Boxing
• Retroalimentación de la retrospectiva en el Sprint Backlog

Cambios desde la perspectiva de Inteligencia de Negocios Ágil

Estas son mis consideraciones desde el punto de vista de inteligencia de negocios ágil:

Scrum e Inteligencia de Negocios

Si acaso no quedo claro: se puede usar Scrum u otros métodos agiles para soluciones de inteligencia de negocios; se puede usar para proyectos de Bodegas de Datos o de Integración de Datos; se puede usar para proyectos de reportes, de análisis de datos, de minería, de manejo del desempeño organizaciones, de ciencia de datos de análisis predictivo y prescriptivo, etc. En resumen, SI SE PUEDE.

El cambio de la guía es importante para inteligencia de negocios, ya que todavía en la industria hay mucha resistencia a adoptar metodologías agiles o incluso marcos de referencia como Scrum o Kanban. Me acuerdo que hace unos 3 o 4 años, un cliente me refirió a una artículo del Enterprise Information Management Institute que se llamaba “Beware of Scrum Fanatics On DW/BI Projects” donde se “demostraba” que la metodología ágil, en particular Scrum, no era apropiado para proyectos de integración.  Si lees el articulo ves que la autora se presenta como una “fanática” de metodología agiles y tiene su propia metodología: Extreme Scoping™. Aunque es cierto que la autora Larissa Moss hace críticas razonadas, dista mucho de demostrar que Scrum no es aplicable a inteligencia de negocios, y hay amplia evidencia de proyectos exitosos demuestran que si se puede usar Scrum en BI.

Scrum Master y la cultura

Para el segundo punto, vale la pena comparar las redacciones de las dos versiones de la guía, antes y después del cambio. Antes del cambio la guía decía:

“The Scrum Master is responsible for ensuring Scrum is understood and enacted. Scrum Masters do this by ensuring that the Scrum Team adheres to Scrum theory, practices, and rules.”

Después, del cambio en la versión de noviembre del 2017:

“The Scrum Master is responsible for promoting and supporting Scrum as defined in the Scrum Guide. Scrum Masters do this by helping everyone understand Scrum theory, practices, rules, and values.”

La redacción cambia la percepción del rol del Scrum Master, e incluso de Scrum, ya que para nadie es un secreto que este marco de referencia es simple, pero no es fácil. La nueva versión rescata la idea que la cultura de Scrum es algo que siempre está en proceso de mejoramiento y la responsabilidad del Scrum master es promover la cultura por medio de la teoría, las practicas, las regulas y los valores.

Scrum Diaria y su propósito

El tercer cambio relevante tiene que ver con el establecimiento de un propósito claro de la reunión diaria de Scrum: Inspección y Adaptación. Yo creo que la versión anterior era bastante clara, pero algunas personas no lo veían así. Por eso, pero la nueva versión cambia la redacción y el estilo.

Yo por mi parte quiero agregar que desde mi perspectiva Scrum empieza con hacer bien estos dos procesos: Inspección y Adaptación. Si se hacen estos dos procesos bien, es fácil mejorar cualquier otra cosa, y las mejores oportunidades para despuntar son la reunión diaria y en la retrospectiva del sprint. Por eso me quedo grabado una imagen que hace algún tiempo alguien me compartió y que clasificaba en cuatro cuadrantes las reuniones diarias de Scrum de acuerdo a su eficiencia y efectividad. En resumen, las reuniones diarias pueden ser:

Inefectiva – Ineficiente: Empieza tarde, gente ausente, discusiones frecuentes, el Scrum Master dirige la reunión, los impedimentos se discuten después de ocurrieron no antes y los participantes ven la reunión como pérdida de tiempo

Inefectiva – Eficiente: Empieza a tiempo y termina en 15 minutos, sin importar nada; se apresura la agenda; algunos miembros se distraen (correo, depuración de código, navegación de web, etc.) para ser más “eficientes’; los miembros no obtienen nada o casi nada de la reunión por lo que algunos llegan a la conclusión de que es todavía mejor si le enviamos por correo al Scrum Master nuestro reporte y así no nos reunimos!

Efectiva – Ineficiente: Cada miembro reporta lo que hizo, lo que planea hacer hoy y los impedimentos que podría enfrentar; se traen los impedimentos a tiempo, antes de que ocurran; los miembros no suelen preparar la sesión por lo que piensan sobre sus temas durante la reunión; las reuniones suelen tardar demasiado tiempo; en general se valora la reunión, pero el costo en tiempo requerido es alto.

Efectiva – Eficiente: Las reuniones empiezan a tiempo y terminan a tiempo, los participantes vienen preparados y comprometidos, las reuniones tarde 2n+5 (n la cantidad de miembros), los miembros solo reportan cambios al plan de ayer y sus razones, el plan de hoy impedimentos en el horizonte sus necesidades/compromisos para otro y el Scrum Master enseña los gráficos de Burn Down (Trabajo pendiente), trabajo acumulado y captura los temas mas importantes.

Time Boxing

Se agregó, como máximo (at most) a los conceptos relacionados con Time-Boxes (cajas de tiempo o bloques de tiempo) y se establece claramente que todos los eventos de Scrum son time-boxed (empacados-tiempo). Este para mí es un cambio menor, porque esa era la interpretación tradicional, y más bien me hubiera gustado que la guía estableciera una sección dedicada solo al concepto de time-boxing. Esto porque Time boxing es un concepto fundamental no solo de Scrum sino también del manejo del tiempo, y de cierta forma la guía asume que los practicantes conocen el concepto y porque funciona. Time-boxing funciona porque permite atacar problemas abiertos donde no tenemos claro cuál es el alcance de una tarea. Por eso en Scrum todos los eventos son time-boxed.

Time-boxing es una técnica de manejo del tiempo que usa también fuera de Scrum. Por ejemplo, todos mis artículos están escritos usando la Técnica Pomodoro que aprendí en un curso y que me ha servido mucho en los dos últimos años. Básicamente uso un reloj fijado en 25 minutos de trabajo continuo intenso sin distractores (ni mail, ni web, ni redes, etc.) seguidos por 5 minutos de descanso. Si hago 4 pomodoros seguidos entonces el descanso es más largo (15 minutos). Usualmente dedico 2 pomodoros al dia a la escritura y uso https://tomato-timer.com/ como herramienta, pero hay muchos otros equivalentes.

Retroalimentación de la retrospectiva en el Sprint Backlog

Finalmente, el cambio más importante, en mi opinión, es con el objetivo de obtener la mejora continua, el sprint backlog debe incluir por lo menos un ítem de alta prioridad de MEJORA DE PROCESOS, que se haya identificado en la última reunión de retrospectiva. Esto pone de forma absolutamente clara que no solo construyendo código podemos acércanos más a entregar el incremento del producto, y que una parte fundamental del Scrum es la mejora continua.

Otros recursos

La presentación puede bajarse de:  Scrum Guide Revision  La nueva guía en ingles puede bajarse de English Scrum Guide November 2017 y recientemente Lucho Salazar la tradujo Guía Scrum-Noviembre 2017 (Español Suramericano).