Contextless Scrum: ¿marco orientado a principios o a reglas?

¿Tenemos que ver Scrum como un proceso lleno de reglas? ¿Puede obtenerse un uso más flexible del marco de trabajo, aunque sin deformarlo, entendiendo bien sus principios? Este artículo intenta dar una respuesta.

Leer artículos y debates de las redes, así como dar clase, me generan muchas ideas para escribir aunque últimamente tengo poco tiempo para hacerlo. En la última clase del postgrado Agile, Lean IT y DevOps de la UPC School, trataba de resaltar lo importante que es entender Scrum como lo que es, un marco de trabajo para abordar proyectos y problemas complejos. Durante esta explicación me vino a la cabeza el termino “contextless” (que suena parecido a las tarjetas “contactless”) para nombrar la aplicación mecánica, férrea y simple de Scrum sin tener en cuenta el contexto del equipo u organización.

En este artículo profundizaré en la importancia de entender el contexto como estrategia para tratar de conseguir una aplicación evolutiva y profunda de Scrum, nunca deformada o fláccida, evitando la ortodoxias y el simplismo que frecuentemente que dejan descolocados a los equipos al intentar imponer una aplicación inflexible y única de Scrum que no les es viable ni al principio, y en ocasiones nunca.

Vuelta a lo básico: Scrum y la complejidad

Scrum funciona especialmente bien en entornos complejos donde obtener un análisis correcto y preciso del problema es realmente difícil. El modelo de Stacey, ver el diagrama a continuación, resume los tres principales factores de complejidad: requisitos a realizar, tecnología a utilizar y las personas (tanto las que intervienen en el proyecto como los clientes o usuarios).

¿Por qué Scrum es superior a los enfoques tradicionales para proyectos o problemas complejos? Porqué implementa el control de procesos empírico, basado en descomponer un problema grande en partes más pequeñas y tratar de aprender continuamente sobre el trabajo a realizar aplicando los principios de transparencia, inspección y adaptación, además de la adherencia de los 5 valores de Scrum (coraje, foco, compromiso, respeto y apertura) al equipo Scrum. Esto es aplicable al concepto de Sprint y a todos los eventos que lo forman. El aprendizaje continuo permite a Scrum adaptarse continuamente y optimizar el trabajo hecho, llegando antes o de manera más barata a la mejor solución posible que puede dar el equipo dentro de su contexto al desafío planteado.

Adaptando Scrum al contexto de la organización

Cada organización y cada equipo tienen un contexto diferente. La Scrum Guide (recomiendo leerla en inglés) define Scrum de una manera deliberadamente vaga, con las mínimas reglas posibles, y orientada a principios y valores, para que cada equipo utilice Scrum como un marco de reflexión y aprendizaje, por contra de un modelo de procesos rígido que se sigue sin entender el porqué y sin generar aprendizaje compartido en el equipo. En los siguientes apartados daré ejemplos, basados en mi experiencia trabajando con diferentes equipos, de como Scrum puede adaptarse al contexto del equipo y de la organización en el que éste opera.

Adaptando Scrum según la complejidad de los requisitos

¿Cómo pueden ser los requisitos más o menos complejos? Los requisitos pueden hacerse complejos de obtener y entender por varias razones:

• Los requisitos son complejos en sí, en casos como un algoritmo complicado de implementar o por tener muchas reglas y condicionantes del dominio difíciles de entender.
• Los requisitos corresponden a un problema que ni los usuarios ni el equipo Scrum han visto antes, por tanto les falta experiencia y deben aprender para reducir su complejidad relativa.

Si se dan los dos casos iniciales, se hace muy difícil en la práctica estimar una hoja de ruta. Una opción es partir el problema en partes (p.e. casos del algoritmo o del problema novedoso) e ir abordando algún Sprint para obtener más información y poder comenzar a estimar parte del desarrollo. Por contra, si es asequible obtener los requisitos, se puede estimar una hoja de ruta de Sprints sin la necesidad de hacer un análisis ni planificación exhaustivas.

Por tanto, Scrum puede usarse en contextos donde tener una planificación inicial sea asequible o imposible, sin dejar de ser Scrum.

Adaptando Scrum según la complejidad del cliente

¿Es difícil captar las necesidades de los usuarios, ya porque sean internos y no puedan tener la dedicación suficiente para transmitir sus necesidades reales al equipo de trabajo, o bien por ser usuarios externos que no conocemos?

En el caso de usuarios internos con poca disponibilidad puede parecer una odisea conseguir que colaboren con el equipo de desarrollo validando requisitos durante el Sprint y que aquello que se presente en la Sprint Review ya esté “aceptado”. El primer paso debería ser intentar eliminar este impedimento, ya sea consiguiendo más tiempo para dichos usuarios, o cambiando de interlocutores. Pero si no se puede conseguir dicha participación, aunque  detallar los ítems a trabajar durante el Sprint no sea la opción más ágil, tal vez vez ayude definir un “Ready” exigente con criterios de aceptación claros para conseguir que el máximo del alcance del Sprint pueda ser aceptado y no presentar ítems al Sprint Review para su validación.

Por contra, si no conocemos directamente a nuestros usuarios, puede que sea útil definir la técnica de “Personas” para empatizar mejor con los usuarios, y usar sistemáticamente mecanismos que nos ayuden a entender mejor la aceptación de los usuarios via experimentos (p.e. analítica de web, encuestas online, test A/B). En este caso, probablemente sea contraproducente definir requisitos antes de su desarrollo y convenga definir Sprints cortos y con metas orientadas al aprendizaje sobre los aspectos que desconocemos de la conducta del usuario.

Adaptando Scrum según la complejidad de la tecnología

La tecnología añade una tercera dimensión de complejidad al desarrollo de productos. Preguntas como estas pueden hacer un desarrollo viable o no, y suelen ser desconocidas al inicio de éste cuando estamos tratando de productos altamente innovadores:

• ¿Será posible que una tecnología soporte el rendimiento o los requisitos del usuario?
• ¿Está la tecnología suficientemente madura para hacer productos de mercado?
• ¿Podremos conseguir un diseño implementable con el tiempo y dinero disponibles?

Por otro lado, cuando tratamos de productos con hardware, habitualmente no es posible poder tener un producto “potencialmente entregable” cada Sprint, tanto por la velocidad de la realización de las tareas en este dominio, como con que la propia naturaleza del hardware suele hacer que incluso añadir cambios a productos “sencillos” no pueda ser hecho en plazos de pocas semanas. ¿Tenemos que renunciar a usar Scrum entonces? En estas situaciones es necesario adaptar Scrum de maneras como:

• Si no se puede desarrollar un incremento del producto potencialmente desplegable cada pocas semanas, definir Sprints un poco más largo del máximo teórico de 4 semanas.
• Los objetivos del Sprint pueden ser eliminar un riesgo técnico severo, por ejemplo: probar que se puede realizar una pieza de este material que tenga la resistencia adecuada para el uso.

Ambos ejemplos se apartan de la visión del Framework Scrum como un proceso orientado a reglas, pero hacen posible usarlo con el objetivo de aprender en desarrollos complejos usando los principios del empirismo (transparencia, inspección y adaptación).

Orientando Scrum a principios y no reglas

Es necesario entender profundamente los elementos y reglas del framework Scrum para defender su uso correcto, evitando deformarlo gratuitamente el contexto de organizaciones que comienzan a usarlo y tienen “vicios”. Pero mejor aún de entender profundamente sus principios y como adaptarlo a contextos que no son los ideales, para poder usarlo en más situaciones y evitar que la ortodoxia cierre el paso a su uso. Como dice el principio “Shu-Ha-Ri” de las artes marciales, el estadio superior “Ri” de aprendizaje puede implicar “romper la regla” cuando se tiene el conocimiento suficiente y se quieren obtener objetivos más difíciles.