Value Stream Management: ¿Qué es Flow Framework?

En el artículo anterior analizamos el problema de la transformación digital de Nokia. Comentamos que las optimizaciones y métricas locales, a nivel de los equipos, estaban desconectadas del resto de estrategias y de toda la cadena de entrega de valor. El foco estaba puesto en medir la ejecución de actividades en lugar de tomar distancia y medir el impacto de la transformación en los resultados de negocio. Nuestro objetivo en este artículo es empezar a analizar la propuesta de Flow Framework para interconectar las actividades de desarrollo de software y medir su impacto en las áreas de negocio. Necesitamos tener trazabilidad, gestionar el flujo del trabajo de los equipos y tomar mejores decisiones en base a datos y resultados. Un enfoque sistémico y empírico. 

Umm… dicho así suena un poco abstracto. Vayamos por partes. 

¿Qué es un Value Stream?

El concepto de value stream proviene de los procesos de fabricación industrial y se refiere a todo el flujo o cadena de valor, de principio a fin, desde que llega una solicitud hasta que ponemos el resultado en manos del usuario final. Aquí lo utilizamos para referirnos a toda la secuencia de actividades, personas y herramientas que intervienen en la producción de software. Según SAFe y Flow Framework, la producción de software a gran escala requiere que haya una relación 1-a-1 entre la dedicación de los equipos de desarrollo y los value streams. Es decir, que cada equipo participe en un único value stream. Foco y dedicación. Aplicar esta estrategia en la creación de los equipos aumenta la eficacia, la calidad del trabajo—y también mejora el compromiso, aumenta el conocimiento compartido y la salud de los equipos. 

Cuando hablamos de value streams es especialmente importante incluir a todos los stakeholders y actores. Si excluimos, por ejemplo, a los equipos de soporte o a las áreas de negocio, el resultado no es un value stream, sino segmentos de un flujo. En ese sentido, los equipos ágiles y DevOps son segmentos. Los segmentos son importantes pero nuestro objetivo ahora es tener una visión sistémica, de extremo a extremo de todo el value stream, y ver de qué forma podemos medir cómo discurre la entrega de valor. 

Una taxonomía para los ítems

El primer paso para poder medir es identificar claramente los ítems que viajan por el flujo de valor. Estas unidades de trabajo, que en Flow Framework se denominan Flow Items, de alguna manera representan el valor que se entrega a los clientes y usuarios. Los equipos ágiles utilizan un backlog para gestionar el trabajo y las prioridades. Flow Framework propone la siguiente taxonomía para clasificar los ítems del backlog: 

• Feature: es un requisito funcional con valor de negocio (historia de usuario, épica). Las features representan necesidades de los usuarios y suelen ser recogidas por Product Owners, stakeholders y las áreas de negocio 
• Defect: es la corrección de un defecto (bug, errores, incidencias). Los defectos suelen ser reportados por el equipo de calidad, los usuarios o el propio equipo técnico 
• Debt: se refiere al pago de la deuda técnica del software. Por ejemplo: acometer mejoras en la arquitectura para facilitar el mantenimiento, automatizar tareas, adoptar nuevas herramientas. Estas necesidades suelen ser detectadas por los equipos técnicos—los arquitectos y desarrolladores 
• Risk: son requerimientos no funcionales como la seguridad, cumplimiento de estándares y normativas (GDPR), privacidad de datos. En muchos casos, estos requerimientos actúan como restricciones sobre el diseño de la solución técnica 

Tener visibilidad y cierto grado de abstracción sobre el flujo de los ítems a través de los procesos y herramientas de la organización nos permitiría identificar cuántos diseñadores, desarrolladores, Product Owners, managers, testers y otros perfiles estuvieron involucrados en crear, desplegar y dar soporte a una feature concreto.

Balancear la distribución

Es importante que los equipos trabajen sobre una distribución equilibrada de los diferentes tipos de ítems. La distribución puede ir variando con el tiempo para maximizar el valor de negocio—principal responsabilidad de los Product Owners. Si llegan demasiadas incidencias, algunas features tendrán que ser quitadas de las prioridades del backlog. Si la presión por entregar nueva funcionalidad a la par que corregir errores no se estabiliza, al cabo de varios trimestres la deuda técnica interferirá con la capacidad de avanzar en el desarrollo. De la misma forma, si los riesgos no son explícitamente priorizados en el backlog, nunca serán implementados.  

Es necesario que esta información, que es de naturaleza técnica, pueda ser comunicada a las áreas de negocio. La siguiente imagen muestra lo que ocurre cuando el equipo invierte todo su esfuerzo en desarrollar nuevas funcionalidades (features) y descuida la calidad y la corrección de defectos. Con el tiempo, la deuda llega a ser tan grande que es imposible continuar desarrollando nuevas funcionalidades y el equipo se ve obligado a parar completamente para pagar la deuda. Si no reducimos esta deuda de forma regular, el software se vuelve prohibitivamente caro y difícil de mantener y actualizar. 

En muchas organizaciones, las áreas de negocio no ven este problema y continúan empujando a los equipos a implementar nuevas features a costa de aumentar la deuda técnica. En las grandes tecnológicas suele haber más conciencia de este problema porque los directivos, en general, suelen tener experiencia en el desarrollo de software. Necesitamos herramientas para que los líderes y perfiles menos técnicos vean claramente este problema. Los Product Owners no solo deben optimizar la entrega de valor a corto plazo; también deben tener en cuenta el impacto de una mala distribución de las prioridades de los ítems del backlog. ¿Qué hubiera pasado si la dirección de Nokia hubiera podido visualizar el impacto de la deuda técnica?  

En el próximo artículo analizaremos en detalle las métricas que propone Flow Framework para medir el trabajo que fluye por un value stream de desarrollo de software.