Aprendiendo sobre Flow Efficiency con Tina Dankwart

Contenidos

Flow Efficiency con Tina Dankwart

https://www.youtube.com/watch?v=J5S1MuKQre4&t

¿Qué hace un Value Stream Architect?

Tina Dankwart es Senior Value Stream Architect en Tasktop, una plataforma de gestión del flujo de valor, donde trabaja con empresas tradicionales ayudándolas a realizar cambios reales en la forma en que entregan tecnología a través de la implementación de técnicas de flow efficiency.

Para empezar, nos gustaría pedirte que te presentaras un poco y nos hablaras de tu trayectoria. Y las cosas que estás haciendo con la gestión del flujo y la optimización del trabajo de los equipos.

Actualmente trabajo para Tasktop, y ayudo a empresas a realizar algunos cambios en la forma de lanzar sus productos tecnológicos.

Sobre todo, empresas de software, aunque también tenemos hardware. Trabajamos con bancos y empresas automovilísticas también. Ayudamos a las empresas a realizar optimizar su forma de trabajar.

Me apasiona especialmente alinear todo con los resultados. Hay mucho debate sobre que métricas utilizar, en base a actividades, o a resultados. Todo eso es importante, por supuesto, pero lo que más me gusta es hacer que la gente piense que es para ellos el éxito. ¿Cuál es el resultado al que aspiran? Y eso es lo que se refleja en gran parte del trabajo que hago a diario.

Tina, ¿cómo has llegado hasta este puesto?

Antes trabajaba para una empresa de software muy grande, de software y hardware, Hewlett-Packard. Construía soluciones para clientes de SaaS en diferentes proyectos. Me pasé 10 años construyendo data lakes y luego tratando de extraer información. Así que se de primera mano lo que es ser esa pobre persona que tiene que intentar sacar parte de la información.

Después, en algún momento, empecé a utilizar integraciones para resolver esos problemas, que es un poco la base de Tasktop. Se trata de integrar y conectar esos silos que tenemos en las empresas, y me encanta la visión del CEO.

De hecho, empecé a trabajar allí antes de que el CEO escribiera su exitoso libro (Project to Product). Pero me encanta la visión, y me encanta el ambiente de trabajo. Así es como he terminado aquí.

Solemos empezar con una pregunta sobre tu primer contacto con las metodologías agiles. ¿Cuáles fueron tus sensaciones al respecto? Tu primera impresión.

En realidad, vengo de un entorno waterfall. Como todos, en cierto modo. Fui a la universidad cuando esa era todavía la metodología que se enseñaba. Todo giraba en torno a la definición de los requisitos, lo importante que era que entendiésemos eso y luego ir de un paso al siguiente.

Estuve trabajando en una empresa en la que di apoyo y más tarde fui consultora de soluciones para uno de sus principales productos de ALM, que se basa en gran medida en waterfall. Entonces se empezó a hablar de que había una manera diferente de trabajar, y me generó curiosidad.

Empecé a entender cuáles eran nuestros problemas dentro de la empresa para la que trabajaba, sobre los silos y la falta de agilidad que teníamos, y que nada estaba alineado con el producto.

En ese momento, pensé que era muy extraño que nadie parecía ser el hacerse responsable del todo. Cada uno estábamos en nuestra pequeña burbuja tomando decisiones. Pero voy a ser sincera, mi primer pensamiento fue, «Oh no, aquí es cuando se marchan nuestros clientes.»

Esto va a tomar fuerza y no encaja con lo que nosotros hacemos. Así que, o cambiamos y hacemos algo diferente…o no va a ser bueno.

Y vimos que sí que erosionó la base de clientes que teníamos. La gente estaba cambiándose al Atlassian Stack. Obviamente, se llevaron muchos clientes. Empezaron a ganar cuota de mercado, ya que estaban mucho más alineados con esta nueva forma de trabajo.

Mientras que los productos tradicionales de ALM, definitivamente no tanto. Se basaba todo en el paso a paso, a través de ese waterfall. Así que, la respuesta sincera es que pensé, «Oh, esto no va a traer nada bueno», pero sentí curiosidad por ello, sin duda.

¿Ha evolucionado tu metodología de la misma manera que ha cambiado la forma en la que gestionas esto?

Definitivamente sí. Por un lado, ahora lo veo como algo absolutamente necesario (Agile y DevOps). Y también creo que no es suficiente.

No vale sólo con las transformaciones ágiles. No es suficiente con eso. Tenemos que empezar a prestar atención a los flujos de trabajo. Necesitamos medir las cosas correctas. Y aquí vuelvo al tema de los resultados.

Tenemos que medir para optimizar, entregar más rápido y mejor software y tecnología. Tenemos que saber si la transformación ágil ha sido exitosa. Vemos mucho este rebranding. La gente coge un equipo y dice: «Ahora sois un flujo de valor», pero no están cambiando absolutamente nada.

Esto también ocurre con la agilidad. Piensan: “Vamos a convertirnos en un equipo ágil y celebramos que ahora todo el mundo trabaja en JIRA”. Pero lo más común que vemos es que la gente piensa que son ágiles y realmente no lo son. Acabas con este pequeño sándwich de scrum, que es como me gusta llamarlo.

Así que tienes el equipo de desarrollo y son realmente ágiles, pero que se basa en un modelo de financiación de 18 meses, donde se decide ahora lo que vamos a construir en 18 meses. Lo que no es para nada ágil. Y hay empresas que saben que no son ágiles, y lo admiten, y piensan: «Oh, estamos tan atrasados».

Pero luego están las que realmente piensan que son ágiles y se dan una palmadita en la espalda. Y cuando miras en profundidad, es una sandía: por fuera parece verde, y por dentro es completamente roja. No son ágiles.

Por un lado, tienes el modelo de financiación, y por el otro, la gestión del release. Es algo bastante común que, debido al modelo de financiación, tienes enormes cargas de trabajo que tienen que ser completadas antes de que el cliente pueda tenerlo en sus manos.

Así que se optimiza la construcción, y tal vez las pruebas, pero luego hay que esperar a que se terminen las otras cosas antes de ponerlo en marcha. Y esta es una parte realmente importante de la medición de extremo a extremo. Si sólo optimizamos el trozo en el medio no logramos nada en absoluto. Y luego, por supuesto, esta todo el asunto de cómo se ve el éxito.

Hay que asegurarse de que nos alineamos con ello, y esa es la parte que tenemos que añadir a la transformación ágil. La alineación con los resultados.

De lo contrario, nos encontramos con que ni siquiera sabemos si estamos llegando a alguna parte. Estamos haciendo las rutinas, las ceremonias. Estamos llamando a todos Scrum Masters, pero en realidad, ¿hemos cambiado algo?

Y si es así, ¿cómo lo sabemos? ¿A qué aspiramos y cómo sabemos que lo estamos consiguiendo?

Optimización del flujo de trabajo

En nuestro caso, solemos hablar con bancos o compañías de seguros, como clientes aquí en Netmind, y todavía vemos a los gerentes tratando de optimizar la utilización de los recursos, y asegurarse de que todo el mundo está muy ocupado. ¿Cuál es tu consejo a la hora de orientar el debate hacia la optimización del flujo de trabajo?

Yo diría que las dos cosas están completamente vinculadas. ¿Cómo voy a optimizar y utilizar perfectamente los recursos si no mido de extremo a extremo?

Un ejemplo: nosotros trabajamos con una gran compañía de seguros americana. Sabían que tardaban 120 días de principio a fin en entregar algo, pero no sabían exactamente dónde estaba el trabajo en ningún momento. Y lo que hacían era lanzar desarrolladores al problema: «Seguramente, si ponemos muchos desarrolladores y contratamos montones de ellos, se resolverá nuestro problema».

Cuando investigamos dónde se atascaba el trabajo, se dieron cuenta de que este problema solo consumía dos días y medio de los 120.

Puedes optimizar eso en tu flujo de valor, y no habrás logrado ninguna diferencia en absoluto.

Es importante que cuando queramos optimizar nuestros recursos empecemos a preocuparnos por el flujo, para así poner a las personas adecuadas en el lugar adecuado y alinearlo con lo que queremos conseguir. Queremos ser más rápidos, queremos asegurarnos de que todo el mundo está ocupado y trabajando en las cosas correctas.

Eso es en lo que tenemos que centrarnos. Y si eso es lo que queremos, tenemos que saber dónde está el cuello de botella y poner a las personas adecuadas a solucionarlo.

Hablas mucho de la Aprendiendo sobre Flow Efficiency. ¿Cuál es tu definición de flujo? Y lo más importante, ¿cómo podemos medirlo? Porque medir la eficiencia no es tan fácil.

En primer lugar, tenemos que pensar en la variable del tiempo de flujo. Y como los dos están vinculados.

Cuando hablamos de end-to-end, tenemos que entender que se refiere a cuánto tiempo tarda algo en pasar por mi flujo de valor.

El comienzo es cuando el cliente pregunta. El reloj empieza a correr cuando el cliente lo pide. No es cuando llega al backlog. No es cuando los desarrolladores lo han terminado y el trabajo está hecho. Y el final es cuando el cliente lo tiene en sus manos.

Así que tenemos que pensar en esto realmente de un extremo al otro. La eficiencia es, de ese tiempo, cuánto es de espera y cuánto es de trabajo activo.

Toda espera es desperdicio, sin excepción. Si queremos ser más baratos, reducir los costes, optimizar los recursos, ser más rápidos, etc., tenemos que eliminar ese waste.

Así que primero tenemos que medirlo, pero no es tan sencillo. Normalmente, lo que la gente piensa al hablar de eficiencia es: «Sí, tengo un estado de ‘bloqueo’ en JIRA. Así, puedo decir exactamente cuánto tiempo está bloqueado».

Por desgracia, el estado de bloqueo tiene dos problemas importantes.

El primero es que no es muy granular. En realidad, no dice dónde se están atascando las cosas. Puede ser que esté esperando a las pruebas, esperando a los desarrolladores o esperando algún tipo de aprobación. Lo ideal sería tener estados mucho más granulares.

Pero la cuestión más importante es que cuando se miran los estados, hecho o ‘done’ es mi estado favorito porque ‘done’ puede ser cualquier cosa. ‘Done’ es el estado de espera más común que encontramos y el que más se pasa por alto.

Lo realmente importante es que tenemos que hacer que estas cosas sean visibles. Y no es fácil, pero es muy importante tenerlo en cuenta. Además, no es igual para todos los equipos. No es que una única solución valga para todos.

Así que, yo, que he estado ahí tratando de sacar información de data lakes sé que es algo realmente difícil de hacer. Tienes que ser capaz de modelarlo, dependiendo de cómo trabaje cada equipo.

Así que ‘done’ para un equipo puede significar que el cliente lo tenga en su mano, que está realmente hecho. Pero sigo escuchando a la gente referirse a que está hecho, que está hecho-hecho, y que está realmente hecho.

Por supuesto, no podemos ir y alinear todo en JIRA o cualquier herramienta que estemos utilizando, porque cada equipo trabaja de manera diferente. Y eso es lo realmente importante, ser ágil y dar el poder a los equipos. Tenemos que encontrar la manera de hacer visible lo que está pasando, en vez de lo que pensamos que está pasando.

El otro estado que casi nunca es preciso es el ‘trabajo en curso’. ¿Estamos trabajando en ello, o estamos esperando a algo? ¿Hay otras formas de visualizarlo y que podamos decir: «El trabajo en curso es trabajo asignado al equipo de pruebas»? ¿Puede ser que realmente se esté esperando al equipo de pruebas? ¿Es decir, se está trabajando activamente en ello?

Tenemos que desgranar esto cada vez más para obtener una imagen más clara. Al principio, tienes una imagen borrosa de lo que está sucediendo y cuanto más se profundice, mejor será la visión.

Y desde ahí podemos empezar a optimizar y ver la mejora de reducir waste. Y se aumenta la velocidad, así como se disminuye el tiempo hacia el valor.

En estos casos, para rastrear todos esos estados que mencionas, necesitas información. Supongo que los testers o los desarrolladores necesitan registrar los cambios en algún lugar. ¿Cuánta información deben proporcionar sin sobrecargarlos con trabajo extra?

Hay dos respuestas a eso. La cosa es que cualquier mejora requiere cierto esfuerzo, ¿no? Y los beneficios en este caso son muy grandes. La parte importante es que tenemos que considerar por qué. ¿Por qué lo hacemos?

A la gente no le gusta meter información en JIRA porque no ven ningún retorno en ello. «Es sólo una cosa estúpida de administración».

Todos hemos estado allí. Empezar a hacer un seguimiento de las horas es una pesadilla. Así que, tenemos que crear un por qué realmente convincente ya que, al final, el cambio se produce en los equipos, y si quieren que algo cambie, si ven que pueden realmente hacer cambios para solucionar sus problemas, lo harán.

Por ejemplo, «estoy constantemente esperando a las pruebas, o estoy sobrecargado todo el tiempo, o simplemente no puedo hacer las cosas que quiero porque estoy constantemente distraído por todas estas otras cosas de última hora».

Una vez que se obtiene el verdadero por qué y hay una respuesta, dirán: «Bien, ahora le veo sentido a poner esa información ahí porque puedo usar esos datos para defender que algo tiene que cambiar».

La otra opción, por supuesto, es que hay herramientas disponibles en el mercado que pueden ayudar con esto. Lo que hay que hacer es moldearlo, pero lo más importante, y creo que es muy importante, es establecer las expectativas adecuadas para este tipo de transformaciones.

Esto significa trabajo, incluso con las herramientas, hay que moldearlas porque, obviamente, cada equipo trabaja de forma diferente.

Si quieres tener una imagen clara de lo que está pasando, necesitas ese esfuerzo. Y por eso, realmente depende de los coach y del resto crear el entorno para motivar a la gente y ayudar a entender por qué estamos haciendo esto, que es lo que ganan con ello. Y eso es lo realmente crítico.

Los obstáculos de implementar “Flow Efficiency”

Queríamos preguntarte sobre los principales impedimentos que has encontrado con los flujos de trabajo. ¿Cómo podemos identificar y tratar de mitigar estos impedimentos en una empresa?

Por desgracia, no hay una respuesta única. Hay muchas cosas diferentes.

Cuando empezamos a medir, nos encontramos con muchas cosas diferentes y la más común es el ‘trabajo en curso’. Hay demasiado trabajo en curso. Ese es el gran problema que se ve en todas partes.

¿Por qué el trabajo en curso es un problema? En primer lugar, en los equipos sobrecargados, la felicidad de los empleados cae en picado.

Es el mayor enemigo de la felicidad de los empleados y el mayor impulsor de la rotación laboral, al igual que los empleados se den de baja por enfermedad, que, por cierto, es un gran indicador.

Hay empresas lo utilizan como indicador los días de baja, porque si sobrecargas al equipo y están descontentos, la gente coge bajas más a menudo. Pero también cambian de trabajo.

Así que la felicidad de los empleados es muy importante. La gente infeliz no es tan eficiente.

Segundo punto. Cuando se sobrecarga a los equipos, la velocidad decaerá.

Esto lo puedes aplicar a otros contextos. Se puede ver muy claramente en una autopista. Cuantos más coches haya en la autopista, menos avanzarán.

Nosotros hicimos un experimento, quitamos el 10% de la carga de trabajo de un equipo, y obtuvimos un aumento del 600% en su productividad. Es increíble la diferencia que eso supone. Así que es realmente importante.

Y, por último, contar con un sistema inestable es un impedimento. Pensando en esa autopista, no puedes predecir cuánto va a tardar un coche en atravesar el sistema. Así que no puedes saber lo que está pasando en términos de tiempo medio.

Y si no puedes hacer eso, no puedes predecir cuándo se trata de la asignación de recursos. Cuando se trata de predecir cuando algo va a entrar en funcionamiento, no voy a ser capaz de hacerlo.

O peor aún, puedo estar felicitándome porque las cosas van rápido. Pero solo estoy teniendo en cuenta “las ambulancias” que pueden sí avanzan, mientras que el 80% de mis “coches” siguen en la carretera.

¿Qué hacemos con esto? La gente no se da cuenta del problema que supone la sobrecarga de trabajo en un equipo. Es vital sacar algunos de estos “coches” de la carretera.

Aquí es donde entran los coaches. Hay que vigilar esto y poner en marcha una estrategia de retirada de tareas. Hay que darse cuenta de que los equipos son sus propios enemigos porque siempre se les elogia por estar ocupados.

Hay que darse cuenta de si el equipo sigue trabajando, incluso cuando se manda parar. Seguro que dicen algo como: «Pero entonces estaré sin hacer nada, ¿qué voy a hacer?».

Esto es especialmente visible cuando se trabaja con contratistas. Todos piensas que tienen que estar ocupados todo el tiempo.

El Manifiesto Ágil nos da un montón de consejos sobre esto y lo que se puede hacer en estos casos.

Mucho de esto está relacionado con los resultados, con lo que estamos tratando de conseguir. Hay que eliminar todas las cosas que no son urgentes. Hay que decir NO más a menudo a las cosas que no son críticas. Hay que tener muy claros los resultados que queremos conseguir y dejar de lado las cosas que no importan, las que no son relevantes.

Estos son algunos consejos, pero, por desgracia, no es una solución universal, porque depende en gran medida de cada equipo. Si encontramos un cuello de botella y queremos optimizar el flujo, depende del cuello de botella que nos encontremos.

Pero lo primero es siempre iniciar la conversación. ¿Por qué está ahí ese cuello de botella? ¿Cuál es el problema? Muchas veces, los equipos conocen muy bien cuál es el problema. ¿Qué podemos hacer? Hay muchas optimizaciones diferentes que se pueden hacer.

Aquí es donde entra un buen coach para ayudarles. Porque a menudo ellos mismos no saben cómo solucionarlo. Es mucho más fácil facilitar el cambio. Es más sencillo conseguir que la gente desde fuera pueda

identificar problemas y hacer cambios. Un factor realmente importante para crear el cambio es crear el ambiente adecuado para que el cambio ocurra. Crear un espacio seguro.

A menudo nos encontramos con que tenemos todos estos datos y queremos hacer algo con ellos. Y debemos tener mucho cuidado, y saber separar entre que hay un problema, y tener claro que tú no eres el problema. Es una parte muy importante del coaching.

Ahora que mencionas esta metáfora del tráfico, hay una simulación sobre la creación de cuellos de botella del Deutsche Bank, del gobierno alemán que es fantástica y muy gráfica. Se ve de forma muy gráfica que no ocurre nada cuando se intentan añadir líneas adicionales, sólo cuando se reduce el WIP.

Creo que la estabilidad de un sistema es una pieza esencial. Porque en el momento en que tenemos demasiado WIP, todo se vuelve imprevisible. No podemos ver cuándo va a estar terminado, cambiamos las prioridades. Y esa es la otra gran cosa que suele ocurrir, las prioridades cambian todo el tiempo, pero es muy difícil.

Y, tienes razón, detener el flujo de nuevos coches que entran en ese sistema al que te refieres en esa es la simulación, es la única manera de mejorar y entonces empezar a medir.

Obviamente tenemos que eliminar los cuellos de botella o las obras en el camino. Pero, lo primero en lo que tenemos que centrarnos es en si tenemos un sistema estable. Y solo cuando lo tengamos podremos cambiar realmente, y esto tiene muchos otros efectos secundarios positivos.

¿Sigue recibiendo opiniones que no están de acuerdo en esta fiebre por la optimización del flujo? ¿Qué opiniones opuestas o contradictorias está recibiendo en relación con estas métricas de flujo has encontrado? Porque no es tan fácil implementar estos cambios en organizaciones grandes.

Creo que lo que más escucho es: «Oh, no. Otra vez más. Otra métrica con la que me van a fustigar». Me encuentro gente que no está muy de acuerdo con las métricas y se preguntan que qué sentido tienen si no van a cambiar nada. Esa es la resistencia más grande, que pensamos que estamos demasiado ocupados para hacer nada.

Creo que es muy importante que tengamos en cuenta que existe el nivel ejecutivo y que ahí están entusiasmados con las métricas, pero el cambio se produce a nivel del equipo, y por lo tanto debemos tener muy claro que, si no se actúa, no tiene sentido. Si no hacemos nada con los datos es una completa pérdida de tiempo.

Pero lo que es más importante, volviendo a la seguridad psicológica, tenemos que llegar al punto en que la gente no tema a las métricas, sino que las utilicen para argumentar las cosas que quieren cambiar.

Al final, todo el mundo suele ir a trabajar porque quiere hacer un buen trabajo. Así que es muy importante determinar qué es lo que la gente espera conseguir. ¿Cuáles son los cambios y por qué? Y lo que vemos, es que, una vez que se aplican los cambios a pequeña escala, otras personas quieren sumarse porque las cosas están mejorando.

Es decir, nadie odia que le quites el 50% de la carga de trabajo. Por fin entienden: «Existe esta gran visión a nivel ejecutivo. ¿Cómo se traduce eso a lo que estoy haciendo? Si no me interesa y se me va a medir por los puntos de historia y por el número de épicas, pero no tengo ni idea de lo que quiero hacer…no me sirve de nada.”

Y cuando cambias eso y se entiende qué es lo que se quiere hacer, es cuando empezamos a pensar en optimizar, en cómo vamos a hacer que sea mejor.

Se crea esa atmósfera de: «Vale, queremos pasar a la acción de verdad, y tenemos que crear la seguridad para pasar a la acción porque esto son experimentos». Al final, es bastante difícil jugársela y decir: «Vamos a hacer cambios entre testing y desarrolladores, vamos a probar esto y veremos cómo funciona» Porque podría fallar.

Por eso es importante que tengamos datos que lo respalden. Si hemos identificado un cuello de botella aquí, vamos a proponer algunas ideas y ver cómo podemos arreglar eso.

Y luego midamos si ha cambiado algo. Y a medida que se avanza, se pueden empezar a abordar algunas de las cosas más importantes. No vas a empezar cambiando el modelo de financiación. Nadie va a arriesgarse y decir: «Sí, vamos a cambiar el modelo de financiación ahora mismo». Pero cuando haces pequeños experimentos y luego los vas ampliando, consigues la aceptación de los otros equipos. Consigues la aceptación para hacer cambios más grandes porque puedes demostrar el impacto que tienen.

Esas son las resistencias más comunes con las que me encuentro, que mucha gente decide no hacer nada, básicamente seguir con el statu quo.

Tina, has mencionado antes que es muy difícil implementar estos cambios. Según tu experiencia, ¿cuáles crees que son los impedimentos más evidentes que ves cuando las empresas tienen que cambiar e implementar esta otra mentalidad.

Está claro que es necesario el compromiso de los ejecutivos, sin duda. Sin la aprobación de estos, no vas a llegar a ninguna parte porque no vas a poder eliminar obstáculos.

Si pensamos en el propio equipo, solo pueden hacer cambios a su nivel. Si estamos pensando en esa pequeña porción de mi flujo de valor, si realmente quiero tener un impacto, será necesario eliminar impedimentos más grandes para mostrar el éxito y crear la seguridad de la que hablamos antes.

Necesitamos la participación de los ejecutivos. Y realmente necesitamos que ellos también animen. Queremos hacer cambios, identificar los problemas, crear esa atmósfera y definitivamente les necesitamos para eso.

Pero también, es un gran problema. El mayor problema es el análisis-parálisis. Todos piensan, «Sí, genial. Estamos viendo todas estas cosas. Ahora tenemos que hacer un cambio».

El cambio es difícil. Seamos claros. Y ese es probablemente uno de los mayores impedimentos para la implementación. Mostrar las métricas está genial pero no es fácil.

La realidad es que hacer cambios requiere que todo el mundo esté alineado y piense en por qué estamos haciendo esto. Tenemos que aportar ideas creativas sobre cómo vamos a mejorar el flujo y no tomar acción es el mayor de los impedimentos que veo.

Sacar las métricas es fácil, podemos conectar las herramientas. Hay muchas formas de obtener esos datos, pero una vez que los tenemos, ¿qué vamos a hacer con ellos? A menudo te encuentras con gente que se resigna totalmente al statu quo, sobre todo en las grandes empresas, ya que piensan que nada va a cambiar.

«Ahora tenemos los datos que respaldan lo que ya sabíamos, pero no creo que nada cambie».

Este pensamiento puede ser abordado en todos los niveles. Así que, a nivel de equipo, creando un argumento convincente. En el nivel ejecutivo, necesitamos la participación de todos. Y los del medio, por supuesto, que también.

Cómo implementar una transformación

Antes, hablabas de implementar la transformación a través de un pequeño experimento. Una especie de forma incremental de abordar el cambio, pero ¿cuánto tiempo se tarda en ver los beneficios?

Realmente depende de lo pequeño o grande que quieras comenzar. El enfoque más común es empezar a pequeña escala en un par de flujos de valor que tengan grandes problemas. No queremos uno con problemas fáciles.

Queremos un problema grande y tangible, que sea lo suficientemente visible para la empresa, para convertirse en un faro y demostrar que se pueden hacer cambios.

Hemos visto en el pasado que se quieren utilizar equipos que ya son ágiles, pero no vamos a ser capaces de demostrar mucho en ese caso.

Si queremos efectuar el cambio, lo ideal es empezar con equipos con una mente abierta, una mentalidad de crecimiento.

Pero el tiempo que se necesita para ver resultados puede variar. Ver cambios reales dentro de esos flujos de valor puede lograrse en unos cuatro o cinco meses.

Reunir los datos iniciales es bastante rápido. Entonces es cuando se plantea la hipótesis, pero es la parte del cambio lo que lleva más tiempo.

Los datos y la comprensión de los mismos y la obtención de conocimientos deberían durar de cuatro a seis semanas. Lo realmente importante es hacer un cambio a nivel de equipo. Algunos cambios pueden aplicarse rápidamente; otros requieren mucho más tiempo.

Y entonces se entra en esta región de dependencias con otros equipos. Y lo que sucede muy a menudo es que nos encontramos con tres interdependencias, pero en realidad, nos damos cuenta de que hay dependencias con muchos más.

Así que los incorporamos también. Porque al final, los flujos de valor no son lineales. A menudo existe este concepto de flujo de valor en cascada, y lamentablemente no es cómo funcionan los valores.

Es posible hacerlo a gran escala, hacer todo visible y optimizarlo. Pero la recomendación es empezar con algo pequeño, hacer que sea un éxito, y luego ampliarlo y extenderlo más.

Además, hacer visible todo un flujo de valor no siempre es fácil, y a veces ni siquiera es posible. A medida que avanzas hacia el lado izquierdo del flujo de valor, hay veces que utilizan PowerPoint.

Buena suerte con eso porque en realidad no se puede hacer nada con eso. No hay estados en PowerPoint. No hay nada que me diga cuánto tiempo ha permanecido en un estado concreto.

El cambio es un proceso continuo. Tampoco hay un punto en el que podamos decir que ya está todo terminado. Porque, por supuesto, una vez que muevo un cuello de botella, se va a trasladar a otro lugar.

Si puedo optimizarlo, se hará cada vez más pequeño, pero el cuello de botella va a empezar a desplazarse. Prestar atención al flujo es un proceso continuo. Pero realmente, podríamos empezar a ver cambios reales medibles en unos pocos meses.

Y alguien como tú, como arquitecta de flujos, tu idea es probablemente contar con un coach para el equipo y ayudarles a identificar correctamente los flujos de valor. ¿Es necesario estar ahí todo el tiempo con ellos, o tu intervención es algo concreto para después dejar que el equipo sea autónomo?

Sin duda, la segunda opción. Lo que sabemos es que en las etapas iniciales se necesita mucho coaching. Es muy importante porque, a menudo, se trata de realizar un cambio de mentalidad completo y necesitamos ayuda para crear esa atmósfera para que la gente realmente piense y se anime. Y también para todas estas cosas de las que hemos hablado antes. «¿Y ahora qué? ¿Tengo los datos, pero como cambio?»

Así que necesitas gente que tenga experiencia con los flujos y experiencia con la agilidad para ayudar a poner las cosas en su sitio. Al final, la idea es enseñar a la gente a pescar para que se incorpore a las rutinas y que las métricas se conviertan en parte del día a día. Optimizamos las cosas, las medimos y conocemos nuestros OKR. Conocemos los resultados empresariales deseados y seguimos optimizándolos y asegurándonos de que no perdemos el rumbo.

También lo hacemos en Tasktop. Nos aseguramos de seguir midiéndonos porque aprendemos mucho sobre la marcha. Nunca terminas de aprender sobre las diferentes cosas que puedes hacer para optimizar las cosas y lo que tiene impacto en cosas como la felicidad de los empleados.

Existe esta idea de topologías temáticas en la ley de Conway. Para recordar, la ley de Conway, dice que la estructura de tu empresa se refleja en la estructura de tus productos. Y en las topologías temáticas se dice que tienes que cambiar la estructura de tus equipos para reflejar la arquitectura más adecuada para los productos. ¿Crees que hay algo similar que podamos hacer para mejorar el flujo? ¿Hay alguna manera de organizar las diferentes capas de la organización para mejorar el flujo?

Sí, alinear virtualmente los equipos por el flujo de trabajo es la base. Creo que lo interesante es que la pregunta que me hacen a menudo es: «¿Tengo que diseñar flujos de valor para toda la empresa? ¿Todo para poder alinear los equipos?»

Lo más importante es darse cuenta de que los flujos de valor ya existen. No es necesario diseñarlos. Están ahí porque el valor fluye a través de tu empresa. Si no fuera así, habrías quebrado hace tiempo.

Se trata de descubrir esos flujos de valor y de alinearlos. De nuevo, lo importante es empezar midiendo lo que existe ahora y alinear y optimizar según lo que encontremos en las mediciones.

En nuestros cuellos de botella, ¿dónde se atasca el trabajo? ¿Vemos interdependencias entre los equipos? Alinear los equipos de acuerdo con todo esto para mejorar el flujo de trabajo.

No hay un diseño real que podamos dar. Al fin y al cabo, cambia porque también depende de lo que se está construyendo. Es muy importante que midamos y luego optimicemos.

Tener product owners para la toma de decisiones es algo importante. Pero es muy importante que miremos esos flujos de valor y los descubramos. Están ahí. No son lo que un consultor dice que son.

En realidad, no los estamos diseñando. Simplemente te ayudamos a descubrir lo que son y cómo son interdependientes entre sí. Los productos están interconectados. Así que un flujo de valor es tan corto o largo como tú quieres que sea. Porque puedes mirar partes pequeñas o grandes.

Pensemos en un coche. Un coche en sí mismo es un flujo de valor. Pero se compone de un millón de otros flujos de valor. Está el navegador por satélite, y eso es un flujo de valor. Dentro de eso, están los mapas, y son un flujo de valor también.

Así que es importante que veamos todos los flujos de valor y sus interdependencias. Podemos hacer eso con los estados de los que hablamos antes, viendo que estamos esperando esta parte, y que estos equipos están conectados. A veces, podemos fusionar esos flujos de valor, pero son mucho menos fijos de lo que la gente piensa que son.

Por eso digo que deben de estar prácticamente alineados en torno al flujo de valor, porque no son tan fijos como podríamos pensar.

El futuro de VSM y últimas reflexiones

¿Cómo imaginas el futuro de la agilidad? ¿Hacia dónde vamos? Esta idea de los flujos de valor, hace cinco años, todavía no existía. Al menos no con la potencia que se habla hoy en día, pero ¿ves algún cambio, o algo que está llegando?

Bueno, creo que lo más importante es el Business Agility. Alinear el negocio y la tecnología. Y asegurarnos de que todos estamos tirando en la misma dirección. Eso es lo más importante. La gestión del flujo de valor se ha sumado a la agilidad y a los DevOps y a todo eso. Se complementan entre sí.

Alinear a todo el mundo, asegurarse de que todos hablamos el mismo idioma, saber a qué nos referimos. Podemos hablar de compensaciones, podemos hablar de impacto, y estar alineados con el valor del negocio.

Esto ocurre muy a menudo en la parte tecnológica, se habla de puntos de historias, de épicas y los de negocios se preguntan que de que están hablando, que no les interesa, que prefieren hablar de resultados.

Es importante que empecemos a hacerlo bien, que tengamos a todos en la misma mesa. Y saber que todos estamos tirando al mismo tiempo, alejarse la centralidad de costes y una creación de valor que este alineada con el negocio.

¿Tienes algunas palabras finales o algo que quieras compartir con la audiencia, incluso algún consejo o recomendación?

Para mí, una de las claves es empezar a medir, y pensar en lo que es realmente el éxito. ¿Cuál es el resultado que estamos buscando? Ese es el verdadero destino final.

Eso es lo que debemos tener claro.

Tenemos que dejar de medir nuestro éxito en función de las actividades porque eso falla. Si nos paramos ahí, no lograremos ningún cambio. Hay que ser valientes y hacer cambios de verdad, porque eso es lo que creo que falta. Que empezamos a medir las cosas y la gente se entusiasma mucho y luego no hace nada al respecto.

Y en ese momento, todo se convierte en una pérdida de tiempo. Así que creo que lo importante es empezar a medir. Asegurémonos de que todos estamos alineados y luego seamos valientes para pasar a la acción y cambiar para mejor.