SAFe

Como ayuda SAFe a las organizaciones

Como ayuda SAFe a las organizaciones. SAFe combinado con Lean, permite a las organizaciones escalar los beneficios de Lean y Agile en todos los niveles de la organización, creando eficiencias y vinculando la estrategia a la ejecución.

Artículo escrito por: Victor Fairén

Algunas estadísticas (anecdóticas)

En la página oficial podemos encontrar algunos resultados del impacto de SAFe en las organizaciones que lo usan. Estas métricas se centran en 4 aspectos fundamentales del negocio y los equipos: tiempo de puesta en el mercado, Calidad, Productividad y compromiso.

Los resultados típicos que se reportan a Scaled Agile Framework (SAFe) incluyen:

20 – 50% incremento de la productividad
25 – 75% mejora en la calidad
30 – 75% menor tiempo de salida al mercado
10 – 50% incremento en el compromiso de los trabajadores y su satisfacción laboral.

Está demostrado que el uso adecuado de SAFe para escalar las prácticas Lean y Agile, ayuda en los aspectos anteriormente mencionados. Aunque los porcentajes son poco rigurosos de acuerdo con el método científico.

Con SAFe, el trabajo duro vale la pena incluso en las primeras etapas de una implementación. La mayoría de las organizaciones ponen SAFe en práctica de forma incremental, a veces con solo un lanzamiento de un Tren ágil (ART) y algunos equipos. Este tipo de implementación ha demostrado una y otra vez que conduce a ganancias tempranas y, sobre todo, ganancias sostenibles a largo plazo.

¿Por qué los negocios necesitan SAFe?

Las empresas deben aprender a adaptarse rápidamente a los cambios tecnológicos y las condiciones económicas o se extinguirán, sin importar su tamaño, inteligencia o fortaleza. Esto es válido incluso para empresas que no se consideran empresas de tecnología de la información (TI) o software. Los servicios profesionales, los servicios financieros, las instituciones de atención médica y las entidades gubernamentales dependen en gran medida de su capacidad para producir nuevos productos y servicios basados en tecnología.

Las empresas que entienden la urgencia de moverse y adaptarse más rápido, y cambiar sus formas de trabajo, tendrán éxito. Los que no lo entienden, luchan, o simplemente se desvanecen. El mundo de los negocios está plagado de ejemplos: Blockbuster, Kodak, Palm Computing y Compaq fueron líderes icónicos del mercado que no pudieron adaptarse a los nuevos modelos comerciales e innovaciones tecnológicas por delante de sus competidores.

Scaled Agile Framework (SAFe) ayuda a las empresas a abordar los grandes desafíos de desarrollar y entregar software y sistemas en el menor tiempo de entrega sostenible. Es como una base de conocimiento en línea, libre, con patrones de éxito comprobados para implementar escalación de Lean-Agile a nivel compañía. SAFe combina el poder de Agile con pensamiento sistémico y desarrollo de productos Lean. Sincroniza la alineación, la colaboración y la entrega para múltiples equipos ágiles. Como resultado, SAFe proporciona grandes mejoras a la agilidad del negocio, incluida la productividad, el tiempo de comercialización, la calidad y el compromiso de los empleados, y más.

¿Por qué las empresas utilizan SAFe?

Aquí listaremos una serie de razones por la cuales las que SAFe es esencial para los equipos Agile y porqué deberían incorporarse para ayudar a alcanzar tus objetivos de negocio.

Fomenta la rápida adaptabilidad a los cambios tecnológicos y las condiciones económicas.
Promueve la colaboración y la transparencia entre el desarrollo y la alta dirección.

Asegura la obtención de valor de negocio en el menor tiempo sostenible.
Asegura un enfoque consistente hacia la planificación, ejecución y entrega.
Independientemente del tamaño de la empresa, SAFe permite la escalabilidad y la configuración que se adaptan a las necesidades de su negocio.
Los equipos ágiles multifuncionales entregan software de trabajo cada dos semanas.
La piedra angular de SAFe es la cadencia de la sesión de Planificación de Incremento de Programa (PI) donde los equipos ágiles se unen para definir los objetivos que desean alcanzar en un período de tiempo fijo. Esto da como resultado sesiones presenciales, colaborativas, interactivas e innovadoras que crean espíritu de equipo y sinergia.
Promueve la alineación de estrategia, visión y arquitectura entre el desarrollo y los equipos gerenciales.
La integración y validación continua entre los equipos ayudan a reducir los riesgos.
Proporciona una mejora significativa en la productividad del negocio, la calidad, el compromiso de los empleados y el tiempo de comercialización.
El uso de Scrum-of-Scrum en Agile Release Team mantiene al equipo sincronizado entre sí.
Promueve la innovación.

Artículo escrito por: Victor Fairén

SAFe versión 5.0, todas sus novedades

En enero del 2020, la gente de scaledagile framework lanza una nueva versión del “marco de trabajo” para ayudar a llevar Lean y Agile a todos los niveles que se desee en las organizaciones. Hablemos de SAFe 5.0.

Este es la nueva imagen de la “big picture” de SAFe:

2 Nuevas competencias

En un artículo anterior contábamos las novedades de la versión 4.5 a la 4.6:

https://jeronimopalacios.com/2019/10/novedades-en-las-nuevas-versiones-de-safe-4-6-y-5-0/

En la 4.6 se añadía una nueva dimensión con la introducción de las competencias. Éstas nos dan una estructura para poder llevar a cabo una clasificación sobre los comportamientos y herramientas deseables.

Siguiendo esta línea, se identifican 2 nuevas competencias:

Agilidad de la organización.

Cultura de aprendizaje continuo.

Business Agility

En esta nueva versión irrumpe uno de los tópicos de moda en el mercado Agile desde hace unos años: Business Agility.

Entendemos como Business Agility, la capacidad de competir y prosperar en la era digital respondiendo rápidamente a los cambios del mercado y las oportunidades emergentes con soluciones comerciales innovadoras.

Business Agility requiere que todos los involucrados en la entrega de soluciones (líderes empresariales y tecnológicos, desarrollo, operaciones de TI, legal, marketing, finanzas, soporte, cumplimiento, seguridad y otros) utilicen prácticas Lean y Agile para entregar continuamente productos innovadores y de alta calidad y Servicios más rápidos que la competencia.

A Business Agility se la relaciona con la quinta revolución tecnológica. Para sostener esta capacidad se basa en las siete competencias centrales que propone el modelo.

SAFe 5.0 – Your Operating System for Business Agility

La adopción de Business Agility aporta una nueva visión más amplia del marco de trabajo. Ofrece una visión del objetivo que se quiere alcanzar mediante el uso de SAFe.

Esta visión afecta a los principios de SAFe, ahora hay 10 principios, frente a los 9 anteriores:

#10 – Organízate alrededor del valor

Para llevar a cabo la adopción a nivel de empresa de Lean y Agile, no se puede dejar de lado el modo en como se estructura los distintos equipos. No se trata de romper los departamentos existentes ni mucho menos, ya que esto sería una disrupción demasiado grande para algunas empresas.

Se trata de identificar todo el camino que recorre una petición de un cliente hasta que éste puede disfrutar del producto o servicio solicitado. Las cadenas de valor deberían estar por encima de las estructuras organizacionales pues el primer valor de Lean es la entrega de valor al cliente, y esta debe ser la máxima que persigan las organizaciones.

Obviamente lograr esta situación no suele ser sencillo. Normalmente requiere del uso de herramientas, roles y comportamientos que nos acerquen al objetivo. SAFe nos puede servir como referencia para poder avanzar hacía este objetivo.

Si quieres conocer todos los cambios al detalle, consulta nuestras próximas formaciones de SAFe: https://jeronimopalacios.com/training/leading-safe/

Novedades en las nuevas versiones de SAFe

SAFe v4.6

AUTOR: Victor Fairén

Como viene siendo habitual la gente de Scaled Agile Framework, van sacando nuevas versiones de SAFe cada cierto tiempo. Fue en noviembre de 2018 cuando lanzaron la nueva versión del framework 4.6: SAFe 4.6 para compañías Lean.

La versión 4.6 no incluye muchas novedades a nivel conocimientos, pero si introduce un nuevo enfoque. En esta versión cabe destacar que se crean 5 competencias a distintos niveles que serían el objetivo principal para poder comprender y adoptar SAFe. Las competencias son un conjunto de conocimientos, habilidades y comportamientos relacionados que permiten a las compañías mejorar la calidad y entrega de valor en el menor tiempo de ejecución sostenible.

La versión 4.6 de SAFe se centra en las siguientes 5 competencias:

A pesar de venderse como un marco de trabajo “out-of-the box” en esta versión se intuye que para poder desplegar SAFe es necesario el desarrollo de unas capacidades, conocimiento y habilidades previas.

Mi opinión sobre SAFe no es exactamente la oficial. Para mi, SAFe es una librería de recursos que deben ser usados según las necesidades de la organización. Este planteamiento ha sido muy beneficioso en el uso de SAFe a las empresas y alumnos que he apoyado. La novedad de la “capacitación previa” va muy alineado a esta postura: ¡”SAFe no es un marco de trabajo plug-and-play”!

Competencias v4.6

Las 5 competencias básicas que se introducen en esta nueva versión son:

Liderazgo Lean Agile: no podemos pretender una evolución Agile si los líderes de la organización o del cambio no tienen realmente una mentalidad Lean-Agile. Sin unas personas que puedan guiar y apoyar a la organización con el mindset adecuado no es factible.

Agile a nivel equipo y técnico: Los equipos son la base del cambio. No sólo se debe adoptar Agile como mentalidad de trabajo sino también a nivel técnico, con el uso de técnicas y herramientas que nos permitan estar alineados con el propósito que perseguimos.

DevOps y Entrega bajo demanda: la idea de en cualquier momento seremos capaces de entregar la solución funcionando, es la base de esta competencia.

Soluciones de negocio e Ingeniería de sistemas Lean: Agrupa todas aquellas prácticas, conocimientos, habilidades y comportamientos que ayudan a la gestión de grandes soluciones.

Gestión de Porfolio Lean: aplicación del enfoque lea en la gestión de carteras así como los presupuestos para las cadenas de valor.

Beneficios de la versión 4.6

Desde el punto de vista de formador-consultor, así como el feedback recibido por los alumnos podemos enumerar una serie de beneficios o ventajas que aporta esta nueva versión respecto a las anteriores

Mayor claridad sobre los ámbitos donde Agile puede (y debe) adoptarse para ayudar a la compañía en una evolución.
Simplicidad: ofrece una visión general más esquemática.
Mayor entendimiento de las necesidades mediante la agrupación de competencias.

SAFe v5

Lo han vuelto a hacer. En el afán de adaptarse a los tiempos cambiantes, el equipo de SAFe ha presentado una nueva versión del marco de trabajo. Esta versión no está madura todavía, de hecho, su lanzamiento oficial no será hasta el 2020, sin embargo, ya se han dado a conocer algunas novedades.

Novedades de la versión SAFe v5

Siguiendo la línea de la versión 4.6, en esta nueva versión aparecen 2 nuevas competencias para dar respuesta a dos elementos claves en una organización:

Gestión del conocimiento y aprendizaje continuo
Agilidad Organizacional

7 competencias básicas

A parte de las 5 ya conocidas:

Liderazgo Lean Agile
Agile a nivel equipo y técnico
Entrega de producto Agile
Entrega de Soluciones de negocio
Gestión Lean de Porfolio

Se crean dos competencias más:

Agilidad de la organización: describe cómo las personas con pensamiento Lean y los equipos Ágiles optimizan sus procesos de negocio, evolucionan la estrategia con nuevos compromisos claros y decisivos, y adaptan rápidamente la organización según sea necesario para capitalizar las nuevas oportunidades.
Cultura de aprendizaje continuo: describe un conjunto de valores y prácticas que alientan a las personas, y a la empresa en su conjunto, a aumentar continuamente el conocimiento, la competencia, el rendimiento y la innovación. Esto se logra convirtiéndose en una organización de aprendizaje, comprometiéndose con la mejora incesante y promoviendo una cultura de innovación.

Esta nueva versión incluye una autoevaluación sobre la agilidad de la organización, para poder detectar de los distintos ámbitos nuestro nivel y así poder trazar un plan de mejora continua.

AUTOR: Victor Fairén

Estimaciones conjuntas en SAFe

Idea inicial que plantea SAFe en la formación

Durante las formaciones de SAFe hay un momento en el cual los equipos deben calcular su capacidad para poderse planificar su carga durante la siguiente iteración.

En la simulación se considera que “Cada miembro del equipo de Desarrollo aporta 8 puntos al equipo por sprint de 2 semanas”. Esto resulta una sorpresa, negativa, para la gente habituada a trabajar con metodologías Agiles y utilizar la herramienta de las estimaciones relativas.

¿8 puntos por persona es poco? ¿o mucho?

Lo importante de este punto no es la cantidad de puntos que aporta cada miembro del equipo, sino una idea mucho más poderosa: las velocidades de los distintos equipos deben tener una referencia común.

El hecho de que todos los equipos que participan en la elaboración de una solución tengan velocidades comparables nos sirve para tener una predictibilidad de una manera sencilla. Ésta es la clave: predictibilidad poder saber si llegamos a la fecha comprometida o cuando habrá nuestro producto MMF (Minimum Marketable Features) estará listo para salir al mercado.

Cuando los equipos están empezando en la adopción Agile, esta propuesta de capacidad para el equipo es adoptada sin ningún problema. Pero ¿qué pasa con los equipos que ya tienen su propia definición de capacidad? ¿Qué sucede con la predictibilidad cuando necesitamos conocer las estimaciones de muchos elementos donde participan varios equipos en su elaboración? Y donde cada uno tienen sus criterios tanto de capacidad como de estimación relativa definidos.

Entender la adopción de SAFe

Aunque pueda ser presentado como un marco de trabajo, SAFe no es exactamente eso. SAFe es una base de conocimiento probado e integrado para el escalado de las prácticas Agile en las empresas. Me gusta presentar SAFe, sobre todo, como una biblioteca de herramientas para escalar la agilidad.

El símil de la biblioteca es muy válido, pues si no tenemos asimilada la mentalidad Agile el uso que le demos a las herramientas quizás no sea el mejor ni nos aporte ningún beneficio. Es como ir a una biblioteca de Francia sin saber francés, no podremos obtener todo el beneficio de aprender todo lo que los libros en francés nos quieren transmitir.

Las estimaciones relativas son una herramienta más de esta biblioteca, para equipos con poca experiencia en las metodologías ágiles, la propuesta de SAFe es aceptada como válida.

¿Y qué sucede con equipos más experimentados?

En una ocasión nos encontramos con que la empresa tenia ya una cultura Agile y existían varios equipos ya trabajando cada uno en sus productos que luego se integraban en la solución final.

Cada equipo hacía un producto, y algunos productos los podían hacer entre varios equipos. Las velocidades y estimaciones eran totalmente independientes entre ellos: había equipos que completaban 400 SP (story points o puntos de historia) en un sprint de 2 semanas y otros que hacían 20 SP. Los había cuya capacidad era 100sp, 150, 80, etc.. cada equipo había definido su manera de estimar y esto era perfecto a nivel de equipo. Y no era más eficiente el equipo de velocidad 80 que el de 20, ni que el de 400, era un tema de distintos criterios de valoración.

El reto se planteaba cuando necesitábamos saber si llegábamos a tiempo para entregar el proyecto incluyendo a todos productos. Poder estimar con cierta fiabilidad requería:

Descomponer las épicas de programa para identificar los productos relacionados
Cada equipo indagaba sobre las historias de usuario que les afectaba de la épica
Se estimaban todas las historias de usuario.
La estimación por equipo de las historias se agrupaba de manera que teníamos la estimación total de la épica para ese equipo
Las estimaciones parciales de las épicas se agregaban para obtener una estimación a nivel programa.

¿Qué sucede si cada equipo tiene su propio criterio?

Como cada equipo tenia su propio criterio se nos plantean varios retos:

Necesidad de saber exactamente quien hará cada épica. Había épicas que las podría hacer cualquier equipo y era muy poco flexible definir el responsable al inicio del proyecto. ¿y si luego ese equipo no la implementa? Esto era un gasto de tiempo en la estimación inicial que no servía.
Necesidad de ponderar cada una de las estimaciones para cada equipo para poder tener una velocidad combinada que nos permitiera tener predictibilidad. El esfuerzo era grande y resultaba que un equipo en un momento dado decidía cambiar sus referencias y las estimaciones ya no eran válidas, y se tenía que recalcular todas las estimaciones donde participaba ese equipo.
La cantidad de tiempo dedicado a las tareas anteriores era muy elevada.

Esta era la situación a la que nos enfrentábamos, necesitábamos tener predictibilidad a un coste inferior.

Se les planteó a los equipos nuestra necesidad y se decidió crear una Task Force con miembros de todos los equipos para definir un criterio de estimación común.

Primera iteración: Definir 1 SP para el tren

Los equipos en SAFe se agrupan por trenes, un tren es un equipo de los equipos que trabajan para un mismo programa. Lo lógico parecía que era probar esta idea en un tren antes de extenderla a toda la organización.

De esta manera nos fuimos reuniendo semanalmente 2 horas para compartir visiones de lo que suponía 1 Story Point para cada equipo.

Finalmente, conseguimos establecer un criterio común para todos de unas historias de usuario tipo que representaban la complejidad de 1SP.

Nos llevó nuestro tiempo, pero ya teníamos una referencia.

Segunda iteración: Definir algunos valores más de referencia (2SP, 5SP y 10SP)

Una vez teníamos definida las características de la Historia de Usuario tipo para todos los equipos del tren, el siguiente reto era definir alguna otra historia de usuario referencia mayor que 1 SP.

Los equipos empezaron a trabajar en la Historia de Usuario tipo para 2sp y empezaron otra vez las dificultades para alcanzar un acuerdo y la cosa se complicó más cuando trataron de definir una historia de 5 sp. En ese momento, la propuesta pasó a ser redefinir la historia de usuario inicial de 1 sp… Volvíamos a estar en el mismo punto que 2 meses antes.

Era momento de pivotar y buscar otro tipo de soluciones.

Tercera iteración: introducción de #NoEstimates

El siguiente experimento era probar de adoptar la idea de #NoEstimates, ya que usaba un elemento de referencia común e indiscutible para todos los equipos: la duración del sprint.

La idea de #NoEstimates se basa en el hecho de que, para tener predictibilidad en la consecución de un objetivo de negocio, no es necesario dedicar una cantidad ingente de tiempo a estimar todos y cada uno de los elementos.

#NoEstimates propone tener como referencia una duración, y que la “estimación” sea comparada sobre si es menor o mayor que el tamaño referencia.

Escogimos como referencia medio sprint, es decir 1 semana. Los equipos solo necesitaban analizar si la historia de usuario se podía hacer en una semana o menos. En caso afirmativo, pasaban al siguiente elemento. En caso negativo, se descomponía el elemento en otros más pequeños y nos repetíamos la pregunta sobre si cabía en medio sprint.

La predictibilidad se obtendría del numero de elementos que se finalizaban por equipo durante un sprint.

De esta manera obtuvimos beneficios casi inmediatos:

Los equipos dedicaban menos tiempo al proceso de estimación.
Los equipos estaban motivados a estimar, ya no era una tarea tediosa.
No hacía falta ponderar las velocidades pues contábamos elementos finalizados.
No era necesaria saber de antemano que equipo haría que épica pues al final la diferencia en el desarrollo de los equipos no era significativa.
Cambió el ambiente hacía una colaboración mayor entre equipos

No podía existir falta de acuerdo entre los equipos pues medio sprint era lo mismo para todos.

Cuarta iteración: #NoEstimates a nivel de programa

Viendo el éxito de la adopción de esta práctica a nivel de equipo, nos planteamos los beneficios de escalarla a nivel de programa. Sonaba razonable, si al cliente le entregamos épicas pues porque no estimar directamente a este nivel.

El resultado fue muy satisfactorio, ahora miembros de los diferentes equipos del tren (Dev team y Product Owners) estimaban si las épicas podían hacerse en la mitad de una iteración de PI (program increment o Incremento de Programa). Es decir, la referencia para las épicas era si podían completarse en 6 semanas de trabajo (1 PI = 6 sprints, 1 sprint = 2 semanas).

Llevó un tiempo acostumbrarse a esta nueva escala de comparación, y aun así funcionó muy bien. Los equipos ya no necesitaban dedicar tanto tiempo a estimar, descomponer detalladamente las historias de usuario, sino que había una estimación a más alto nivel.

Como es normal, a este nivel la desviación podría ser mayor, pero al ser el margen (6 semanas) también muy grande quedaba bastante compensado. No hubo apenas épicas con grandes desviaciones de las estimaciones iniciales.

Take aways

De esta experiencia nos podemos llevar varios puntos interesantes:

Nueva herramienta para estimar: #NoEstimates
Idea clave sobre el aprendizaje: Aprender es un proceso iterativo experimental.
Lo importante no son las herramientas, sino el propósito que buscamos alcanzar con ellas.

Descentralizar las decisiones

SAFe está basado en una serie de principios Lean y Agile. Estos principios son fundamentales para la creación de un flujo eficiente de los procesos de desarrollo de productos, y todas las decisiones que se tomen deben estar basadas en estos principios:

Tomar una visión económica
Aplicar el pensamiento sistémico
Asumir variabilidad; preservar opciones
Construir incrementalmente con ciclos de aprendizaje rápidos e integrados.
Basar los hitos en la evaluación de objetivos sobre sistemas funcionando
Visualizar y limitar el WIP, reducir el tamaño de los lotes, y gestionar los tamaños de colas
Aplicar cadencia y sincronismo mediante la planificación conjunta de varias áreas
Desbloquea la motivación intrínseca de los trabajadores del conocimiento
Descentraliza la toma de decisiones

Es muy importante tener presentes estos principios cuando se trabaja acorde con SAFe, al ser este un marco de trabajo, no todas las situaciones posibles estarán descritas, solo “las reglas del juego”.

Los principios de SAFe incluyen, entre otros, el pensamiento Lean y Sistémico, los principios y métodos agiles, el flujo de desarrollo de producto.

Muchos grandes pensadores han seguido este camino antes que SAFe, dejando centenares de libros y estudios a partir de los cuales destilar lo necesario para adaptar un marco de trabajo a las necesidades actuales de las empresas. El objetivo es sintetizar todo el conocimiento y las lecciones aprendidas de centenares de entregas en un solo marco de trabajo.

Varios de estos principios están basados en la obra de Donald Reinertsen (The Principles of Product Development Flow – Second Generation Lean Product Development) y en el libro de Daniel Pink (Drive).

Dichos principios no se limitan solo al ámbito del departamento de IT, de hecho hay un movimiento importante por parte de departamentos de HR (también conocidos como departamentos de gestión del talento) en la adopción de SAFe, sobretodo basado en los principios #8 y #9.

Cuando formamos a managers para liderar la transformación mediante la adaptación de SAFe, hay uno de los principios que suele generar controversia entre los asistentes: “Descentralizar la toma de decisiones”:

¿voy a dejar que la gente de mi departamento decida la dirección de la empresa?
¿van los equipos de desarrollo a gestionar la demanda del hardware?
¿los equipos pueden decidir que tecnología usan? ¿Qué hay de la arquitectura de la solución?
este principio no se va a aplicar ¿podemos quitarlo de la formación para los equipos?

Gente llevándose las manos a la cabeza, indignación en la sala…

Obviamente SAFe no dice que todas las decisiones de la empresa deben ser tomadas por los equipos de desarrollo. SAFe sugiere que deberíamos tener un marco de toma de decisiones para decidir qué tipo de decisiones las toman los CEOs, o los arquitectos de la solución, y cuáles pueden ser delegadas a los equipos.

Este marco de toma de decisiones debe considerar una serie de variables, como por ejemplo:

Escala económica: ¿es una decisión que potencialmente implique la inversión de mucho dinero por parte de la empresa? Es conveniente fijar un rango para que la decisión según este valor sea centralizada o descentralizada.
Criticidad temporal: ¿es una decisión que debe ser tomada ahora mismo? ¿no tomarla ahora tiene repercusiones negativas?
Frecuencia de la decisión: ¿Cuán frecuente es esta decisión? ¿es algo que se decide periódicamente o es una decisión puntual o única?
Dependencias con otros equipos/departamentos: ¿esta decisión impactará en el trabajo de otros equipos o departamentos?
Estos son algunos de los parámetros a considerar en la descentralización de decisiones, puede haber muchos otros dependiendo de la empresa o del mercado. La experiencia dice que el factor económico suele prevalecer sobre el resto.
Los objetivos de descentralizar las decisiones es conseguir realmente un movimiento de transformación hacia una empresa ágil.

Las razones/beneficios para implementar un marco para descentralizar las decisiones son varias:

Minimizar los cuellos de botella: no hagamos decidir al CEO sobre algo que no impacta económicamente, no afecta a nadie más y necesitamos tomar la decisión hoy.
Apoderar a los equipos en su ámbito de dominio: quien mejor que el equipo de desarrollo de una aplicación para tomar decisiones de bajo impacto económico pero frecuentes sobre el futuro del producto.
Mejorar el “time to market”: cuando no se toma decisiones conlleva retrasos. Las decisiones facilitan el flujo
Este principio es fundamental si realmente queremos transformar la empresa hacia una empresa basada en el Management 3.0 (Jurgen Appelo) y sobretodo hacia una empresa agil!