Contacto 

+34 93 737 62 70

¿Cómo alcanzar Business Agility con un enfoque Lean?

scrum-master / Por Alex Ballarin / 18 enero, 2020

Hay modelos o infografías que no añaden conocimientos estrictamente nuevos, pero que aportan
un gran valor al hacer más entendibles los conocimientos existentes. Esta infografía de John Cutler
[1] me ha parecido uno de estos. Representa diferentes niveles de un equipo «cross-functional» y
el alcance de los «feedback loops» que les permiten tomar decisiones. He pensado en escribir
sobre él porque me parece una muy buena herramienta para explicarle a un directivo que no sabe
nada de agilidad de negocio de que va esto, y que no piensen muchos que «hacen Agile» cuando
simplemente están comenzando su camino.

Cursos relacionados

Fecha Curso

 29/03 Professional Scrum Master (PSM) – Virtual

¿Podemos ayudar?

Contenidos del artículo [Ocultar]

1  Lean: romper silos para mejorar el flujo

2  Mapa de adopción de agilidad de negocio
3  Nivel 2: Agile subcontratado
4  Nivel 4: Agile comienza aquí, pero no Scrum
5  Nivel 7: Agile con un Product Owner de verdad
6  Nivel 8: Agilidad de negocio
7  Conclusiones

 Lean: romper silos para mejorar el flujo

Una de los principios de la filosofía Lean [2] es maximizar el flujo de valor al cliente a lo largo de la
organización, o de varias organizaciones que trabajan de manera integrada. Para ello hay
que romper los silos, que son unidades organizativas a las que se les asignan objetivos sobre un
tipo de trabajo concreto y que frecuentemente optimizan su trabajo a costa de crear barreras a la
colaboración con el resto de actividades de la cadena de valor. Esta infografía puede ayudar
a reflexionar a los directivos respecto el enorme desperdicio de tiempo, esfuerzo y dinero que
puede ahorrarse. Si utilizamos el modelo de las 7 fuentes de desperdicio de Mary y
Tom Poppendieck [3], podemos lanzar algunas preguntas como p.e.:
Privacy - Terms
 ¿Cuánto tiempo se pierde esperando la aprobación de unos requisitos? ¿Merece la pena
apretar al equipo de desarrollo a riesgo de perder calidad?
¿Cuántos requisitos se han de rediseñar por no haber buena comunicación entre los
desarrolladores y los usuarios?
¿Cuánto podemos aprovechar el feedback real del uso de la aplicación si tenemos un
roadmap fijo?

¡Entre otras muchas que podríamos hacer!

 Mapa de adopción de agilidad de negocio

Este modelo ofrece una visión de extremo a extremo sobre como se genera el valor y por
ello puede ser una herramienta útil para planificar «top-down» de manera efectiva como adoptar
la agilidad a nivel organizativo, por encima de los nichos que suelen darse cuando la agilidad
comienza de manera aislada a nivel de proyecto.

Aunque es diferente, me recuerda a la técnica del «Feature Team Adoption Map» [4] de Large-
Scale Scrum (LeSS).

Niveles de Agilidad de Negocio (John Cutlefish)

Vamos a revisar algunas de las conversaciones más interesantes que podríamos tener con la
dirección de organizaciones que quieren adoptar agilidad de negocio, o que están en el proceso y
no obtienen los resultados esperados.

 Nivel 2: Agile subcontratado

Una visión tradicional y con perspectiva financiera del desarrollo de software es que es una
actividad externalizable. Según esta visión, el desarrollo no «aporta valor» realizarla de manera
interna en la organización, aunque las actividades anterior (analistas) y posterior (gestión de
sistemas) sí lo hacen. Además como se ve en la infografía, el «test» se hace por parte del equipo
pero requirere la colaboración de roles internos de la organización, como los analistas, testers o
los usuarios finales. Algunas preguntas que pueden evidenciar el desperdicio son:

¿Qué posibilidad tienen los desarrolladores de mejorar los requisitos y el diseño si éstos ya Privacy - Terms

tá d ? Có f t t ti ió ?
 están cerrados? ¿Cómo afecta esto a su motivación?
¿Cómo se pueden anticipar errores en el entorno de producción si los equipos no pueden
acceder autónomamente siquiera a un entorno de preproducción?

En definitiva, este nivel de «Agile» no mejora casi nada respecto a los proyectos «waterfall»
subcontratados, ni respecto a desarrollar un producto más adecuado a las necesidades del
usuario ni tampoco de detectar posibles problemas técnicos.

 Nivel 4: Agile comienza aquí, pero no Scrum

Aunque el alcance de un equipo Agile a este nivel pueda parecer ambicioso, si analizamos los
niveles anteriores NO llegan a los mínimos de Scrum, p.e.:

Los requisitos vienen definidos desde fuera del equipo, que básicamente se dedica a la
construcción del software.
No hay un feedback real de los despliegues a entornos realistas (como preproducción).

Aún así, Scrum pide más capacidad de acción para un Equipo Scrum:

El Product Owner, con poder real de decisión sobre los requisitos, está fuera del equipo
hasta el nivel 6.
Aunque los niveles 5 y 6 otorgan al equipo la capacidad (deseable) de desplegar a
producción, Scrum solo pide que el incremento sea «potencialmente desplegable» (ya en
nivel 4).

En definitiva, este nivel permitirá al equipo desarrollar un software de mayor valor para el usuario,

pero probablemente sigamos con una mentalidad de despliegues infrecuentes, hecho que
provocará que tardemos más en entregar el valor y que perdamos oportunidades de feedback
para llegar antes a mejorar la solución.

 Nivel 7: Agile con un Product Owner de verdad

Aunque para el desarrollo de un producto interno (B2B) de una organización posiblemente el nivel
6 pueda ser suficiente, para un producto que se desarrolla para el mercado (B2C) se necesita
mayor agilidad aún en la toma de decisiones.

En el nivel 7, el Product Owner tiene la capacidad de tomar decisiones de inversión

autónomas en función del feedback que da el desarrollo de producto con métricas de
usuario.
Posiblemente el tamaño de funcionalidades aún sea grande, p.e. definiciones de producto
trimestrales como las que hace SAFe, pero su ejecución se intenta planificar y optimizar
según las métricas.

Como resumen, estamos delante de equipos plenamente empoderados para tomar decisiones de
inversión y como llevarlas a cabo, de manera que pueden ser plenamente responsables de los
resultados. En nivel de autonomía, el empoderamiento y agilidad en la toma de decisiones de los
equipos debería facilitar una alta efectividad y agilidad de negocio.

 Nivel 8: Agilidad de negocio

En este nivel, la propia selección de oportunidades de inversión se hace según el feedback de los
resultados del producto. Esto requiere:

Un uso intensivo de las métricas de producto para la toma de decisiones. Privacy - Terms

Mi i i lt ñ d l t d t b j l i i t t t
 Minimizar el tamaño de los paquetes de trabajo en los que se invierte para tener antes
feedback que justifique la evolución del Backlog de inversiones.
Intentar anticipar, de la manera más barata posible, si una funcionalidad merece continuar el
proceso de desarrollo. Esto suele requerir de la adopción del enfoque y técnicas de Product
Discovery [5] durante las actividades de selección de oportunidades y planificación de
requisitos.

 Conclusiones
En este artículo he intentado presenta el mapa de adopción de agilidad de negocio como una
herramienta para ayudar a los responsables de la transformación ágil a entender y planificar el
alcance de la transformación. Esto se basa fundamentalmente en dos ideas:

Los enormes costes de oportunidad que se producen cuando solo se realiza de manera ágil
una parte de la entrega de valor al usuario.
Alcanzar una verdadera agilidad de negocio, aunque puede variar en escenarios B2B y B2C,
requiere una transformación realmente produnda de las prácticas habituales de gestión e
ingeniería en las organizaciones.

 Referencias

1. Journey to Product Teams (Infographic)

2. Wikipedia – Lean Software Development
3. Poppiendick – The Seven Wastes of Software Development
4. LeSS – Feature Team Adoption Map
5. Mixpanel – What is Product Discovery?
6. The Product Manager – A guide to product analytics

¿Quieres recibir más información y recursos de

calidad?

¡Sigue a Alex en las redes sociales!

Alex Ballarin es Professional Scrum Master y Business Agility Coach. Además de este blog,

publica contenido frecuentemente en las redes sociales. 

  

Privacy - Terms
 ¡Suscríbete a nuestra newsletter mensual!

Cada mes enviamos una newsletter a más de 1.200 personas con contenidos,
recursos y ofertas especiales de nuestros cursos. Queremos ofrecer contenido de
calidad y sin spam.

Nombre *

Apellido *

Teléfono

Empresa

Email *

Mensaje *
Explícanos como podemos ayudarte

Al hacer click sobre el botón enviar estás confirmando que has leido y aceptado nuestra
Política de privacidad.*

Enviar

Contacta con nosotros

ITNOVE. BUSINESS AGILITY EXPERTS. Cursos Scrum y Kanban en Barcelona.

Cursos Scrum y Kanban en Barcelona

Carrer de Valencia 63 local Agora

08015 Barcelona
+34 93 737 62 70

Política de privacidad Política de cookies

Conoce a ITNOVE

Privacy - Terms