Contacto +34 93 737 62 70
           
Contacto +34 93 737 62 70
Como alcanzar business agility enfoque lean

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

¿Podemos ayudar?

 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.:

  • ¿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
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 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.
  • 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?

¡Si has llegado hasta aquí, comparte este artículo!

¿Podemos ofrecerte más información?

Newsletter mensual

Cada mes enviamos una newsletter a más de 1.000 personas con contenido interesante que hemos encontrado en Internet, artículos nuestros y nuestras novedades. Queremos ofrecer contenido de calidad y no saturarte con muchos correos.

Formulario de contacto

Si crees que podemos ayudarte con alguna duda o necesidad de soporte, no dudes en contactar con nosotros. Estaremos encantados de ayudar.

Ir arriba

Newsletter mensual

Un boletín mensual. Respetamos tu privacidad.