A mediados de mayo de 2020 una investigación encontró que el 55% de las empresas planeaba incrementar el uso de agile en los siguientes 12 a 14 meses, lo cual implicó un aumento del 13% respecto a la encuesta original que se había completado 5 meses antes. El 43% dijo que su impulso para adoptar metodologías ágiles había crecido en los últimos 90 días, y el 15% que había aumentado de manera notable. El 33% señaló que había expandido la adopción de agile en los últimos 90 días para ayudar a administrar el trabajo en equipo en contexto remoto y distribuido.
Ahora bien: como se detalla en este artículo, una de las prácticas que se están extendiendo es descomponer los trabajos de los equipos ágiles en una jerarquía que incluye estos rangos: épica, característica, historia de usuario y tarea. Esta jerarquía se popularizó en virtud del uso del marco de escalado Scaled Agile Framework (SAFe), que según un estudio de la consultora KPMG realizado el año pasado, estaba siendo aplicado en el 19% de las organizaciones encuestadas. Pero también otros equipos que nunca usaron SAFe están empleando la misma estructura, tanto para ofrecer servicios tecnológicos como para otro tipo de trabajos.
Los trabajos incluidos en el rango de la épica producen grandes productos valiosos o grandes cambios valiosos en los productos. Los descompone en trozos más pequeños de valor para que pueda ofrecer soluciones a sus clientes antes de esperar una gran solución al final.
Por su parte las características se descomponen en historias de alto valor que, según la definición, también deberían proporcionar valor en la producción, algo que también ocurre más velozmente que construir una característica completa.
No obstante, el autor de esta nota alerta que en la forma en que los equipos agile descomponen el trabajo en una jerarquía de épicas, características e historias existe un anti-patrón oculto que es preciso revertir: “Los equipos utilizan herramientas ágiles para gestionar épicas, características, historias y tareas. Pero con demasiada frecuencia los utilizan para articular una estructura de desglose del trabajo (WBS), en lugar de una estructura de desglose de valores (VBS)”, apunta. WBS se refiere a la práctica común y tradicional de gestión de proyectos de dividir las tareas en partes más pequeñas, lo que permite a los equipos estimar el tiempo y los costos para su finalización. VBS, en cambio, se centra en la entrega de productos y subproductos, no en tareas y subtareas. Dado que el pensamiento de WBS da como resultado “historias de usuarios deficientes”, el autor destaca la necesidad de hacer un cambio crítico de pensamiento que en esencia debe pasarde gestionar proyectos a entregar productos.
Cambiar el chip
En la nota que recomendamos el autor explica cómo realizar este cambio. Y propone una serie de ejercicios para “modificar el chip”. ¿Por qué razón? “Porque muchos equipos utilizan los tres rangos –épicas, características, e historias- como contenedores para tareas grandes, tareas medianas y tareas más pequeñas, lo que lleva a historias de usuarios mal escritas”, dice. Y si bien esto responde a varias razones, en el contexto que estamos revisando la clave estaría en que se los trata como elementos de trabajo, y no como elementos de valor: “WBS se ha utilizado para planificar el trabajo de desarrollo de soluciones de software durante mucho tiempo, por lo que está profundamente arraigado en nuestra `memoria muscular´. Y cuando estábamos impulsados por proyectos, esta era una gran técnica”, dice el autor. Y añade: “Pero con el movimiento de la cultura del proyecto hacia la cultura del producto, esta técnica ya no funciona bien. Hoy hay que pensar en términos de entrega de productos”.
Entregar valor
En un VBS, las épicas, las características y las historias son lo mismo: entrega de valor. Es solo que cada uno tiene distintas reglas y sintaxis debido a que cada uno tiene un nivel de riesgo diferente.
Las épicas son de mayor riesgo, las características son menos riesgosas y las historias conllevan menos riesgo aún. Además, cada épica, característica e historia crea o modifica un producto: las épicas son valores que se entregarán o estarán listos para producción en más de tres meses; las características se pueden entregar en menos de tres meses; y las historias se pueden entregar en menos tiempo que un sprint.
La conclusión es que la épica versus la característica versus la historia es simplemente una suposición de primer nivel sobre el tamaño del esfuerzo para ofrecer valor. De esta manera, una vez que se pasa de una WBS a una VBS real, los equipos agile pueden informar fácilmente sobre la entrega de valor.
En suma, la nota destaca que mucha gente ve sus herramientas ágiles de gestión del trabajo como una jerarquía de épica, característica e historia. Y la memoria muscular de un WBS es tan fuerte que superponen esta estructura de desglose de trabajo en los contenedores de épica, característica e historia. La propuesta, en cambio, es centrarse en productos, subproductos y entrega de valor. Refactorizar los atrasos existentes separando las tareas del valor. Y pensar en la jerarquía de épicas, características e historias como nada más que una primera estimación del tiempo.
Para profundizar en esta perspectiva, invitamos a leer este artículo.
¿En tu organización están trabajando con esta práctica agile de descomposición en jerarquías? ¡Sería genial que cuentes el caso!