Value Stream Management: Midiendo la entrega de valor

Value Stream Management por Gabriel Cassarini y co-autor Alonso Álvarez

El caso de Nokia se presenta habitualmente como uno de esos ejemplos de “no saber adaptarse a los cambios”. Y en ese discurso Nokia tiene como compañeros a Blockbuster (que rechazó la oportunidad de comprar a Netflix) y Kodak (que inventó la fotografía digital pero no la explotó comercialmente).

Todas ellas compañías que no entendieron los cambios de hábitos, de tecnología, de mercado. Y este discurso suele ser el preámbulo para justificar un cambio de mentalidad, estrategia y procesos, normalmente asociado a la necesidad de abordar una transformación ágil. 

Sin embargo, hace una década Nokia era el alumno modelo de la transformación y modernización de grandes organizaciones que abrazaban la agilidad. Por aquella época, el famoso Nokia Test permitía evaluar el grado de madurez de los equipos, medir cómo de ágiles eran y si seguían los principios de Scrum. Pero ya sabemos cómo terminó la historia de Nokia —terriblemente mal.  

¿Qué falló con Nokia?

Cuando Nokia detecto la necesidad de reconvertirse y ser más ágil, se embarcó en un costoso programa de transformación interna que consistía en formar a sus equipos en Scrum y en la adopción de prácticas ágiles y nuevas herramientas. Expertos de todos los rincones fueron contratados para formar a los equipos en la gestión ágil de los proyectos. La dirección de la empresa confiaba en que agilizando la forma de trabajar de los equipos lograría mejorar la situación de toda la organización. El avance se medía por la tasa de adopción de Scrum y por el uso de las nuevas herramientas. 

Pero el problema de Nokia realmente estaba en otro sitio. El lanzamiento del iPhone en 2007 había cambiado el panorama completamente. El software se convertía en la nueva fuente de innovación. Por aquella época, Nokia utilizaba el sistema operativo Symbian y no tenía una arquitectura capaz de integrar una tienda de aplicaciones, por ejemplo. Los equipos técnicos de Nokia veían claramente que el principal obstáculo estaba en la enorme deuda técnica de la plataforma de software. 

Pero sus esfuerzos para lograr el apoyo necesario para resolver ese problema chocaban con la estructura organizativa de la empresa—y la poca comprensión de la situación por parte de la dirección y las áreas de negocio.

La transformación interna

La transformación interna de la organización solo producía optimizaciones locales. Y aunque esto ayudaba a los equipos individuales, no aceleraba la innovación y la entrega de valor a lo largo de toda la cadena. Había una gran desconexión entre los niveles de producción y la dirección. Si los despliegues y pases a producción debían ser aprobados por un grupo que solo se reunía una vez por mes, la velocidad de entrega seguía siendo mensual—aunque los equipos liberan nuevas funcionalidades cada 2 semanas. 

Las métricas de agilidad que se usaban en la transformación de Nokia ponían el foco en los equipos individuales, pero no daban una visión sistémica, de principio a fin, de cómo fluía el trabajo por toda la cadena de valor. No mostraban el impacto negativo de la mala gestión de las dependencias entre los equipos, el problema de la deuda técnica y la falta de alineamiento entre las áreas técnicas y de negocio.  

La falta de visibilidad en el impacto y contribución sobre los resultados de negocio llevaron al fracaso. Los árboles no dejaban ver el bosque—que estaba quemándose. 

A nivel de negocio no podemos gestionar lo que no podemos medir 

Actualmente muchas organizaciones están invirtiendo enormes recursos en procesos de transformación digital y no pueden ver los beneficios ni medir los resultados para saber si los cambios funcionan—o no: “Banks Spend $1 Trillion on Digital, But Few Reap the Rewards”. En estas compañías, la eficiencia y eficacia del desarrollo de software es muy baja si las comparamos con lo que logran los gigantes tecnológicos y las startups. 

¿Sería posible ver cómo fluye el trabajo de los equipos que producen software en tiempo real, de la misma manera que observamos todo el proceso de fabricación de un coche en una línea de ensamblaje? 

Es complicado responder a esto. Buena parte del proceso de producción de software es una actividad creativa, basada en el conocimiento y que ocurre en la cabeza de los desarrolladores. Es imposible pedirles que documenten y registren todo el proceso para hacerlo visible porque durante el desarrollo se utilizan diferentes herramientas y canales de comunicación. No podemos inspeccionar sus cabezas ni leer sus mentes.  

Además, parte del problema vuelve a estar en el liderazgo. Conceptos del desarrollo y despliegue de software que son familiares a las personas del mundillo del software—deuda técnica, puntos de historia, entrega incremental de valor—no significan nada para los líderes que gestionan las iniciativas IT como proyectos independientes y miden todo en término de presupuestos, planificaciones y optimización de coste. 

Aún así, hay empresas que sí logran medir cómo fluye el trabajo y la entrega de valor en términos de negocio. Uber ha demostrado que una aplicación bien diseñada y que corre en un móvil puede alterar una industria completa. 

Estas empresas utilizan métricas y estructuras internas dinámicas para guiar la innovación. No les basta con tener equipos ágiles. Además, es necesario que la estructura de la organización no sea un obstáculo para la colaboración y comunicación transversal de las diferentes áreas. Y en el caso del software, también hace falta tener una arquitectura técnica que sea capaz de evolucionar—y que permita crear soluciones de manera incremental, iterativa e integrando diferentes tecnologías. 

Sus líderes hablan el idioma de los desarrolladores porque muchos lo fueron antes, comprenden la complejidad y la incertidumbre del proceso, y esto les permite definir y ejecutar bien sus estrategias de software. 

Midiendo y optimizando la entrega de valor de principio a fin

Existen muchos marcos de trabajo y prácticas para agilizar, transformar y escalar el desarrollo de software. Todos ellos intentan alinear la organización interna con los flujos de valor (value streams) por los que discurre el trabajo, la creación y entrega de valor. Todos intentan tener una visión amplia del ciclo completo de desarrollo, de principio a fin, y que involucre a todos los actores.  

Algunos, como SAFe, son marcos integrales de gestión que combinan la estructura actual de la organización con nuevas redes dinámicas por las que fluye la innovación. Otros, como las prácticas de DevOps, se enfocan en los aspectos más técnicos, la automatización, los bloqueos y cuellos de botella durante las fases de construcción y despliegue. Otras propuestas, como Flight Levels, buscan visualizar y optimizar el flujo de valor aplicando los principios y prácticas de Kanban. Y finalmente, otros como Flow Framework, utilizan métricas para cerrar el abismo entre la estrategia de negocio y el proceso de desarrollo. Hay variedad opciones para todos los gustos. 

En próximos artículos analizaremos en detalle la propuesta de Flow Framework para interconectar las actividades de desarrollan software, de extremo a extremo, y medir su impacto en las áreas de negocio.   

Parte 2: ¿Qué es Flow Framework?