lunes, 1 de enero de 2018

¿Qué hacer si en la organización tenemos equipos ágiles y equipos tradicionales?

En el contexto de la pregunta a la que pretende dar respuesta el post debemos de entender la naturaleza de ambos tipos de equipos.

Equipos ágiles
Equipo ágil con único objetivo común
Cortesía de Pixabay
  • Son multifuncionales, formados por miembros de diferentes especialidades con un objetivo común que les da la capacidad de construir funcionalidades de principio a fin
  • Operan bajo una misma visión que los alinea entre sí y con el proyecto
  • Son autónomos y autoorganizados, están empoderados para hacer la microgestión a nivel de construcción y con el poder de decisión necesario sobre como construir
  • Formados por personas motivadas a base de motivaciones intrínsecas
  • Rodeados de un entorno seguro en el que se fomenta el aprendizaje continuo, el coraje y sin miedo al fallo, donde un fallo es considerado una oportunidad de aprendizaje
  • Trabajan en un entorno de colaboración
Los equipos ágiles operan bajo una cultura y mentalidad de colaboración. Lo hacen cuidando, interesándose y manteniendo sus compañeros como amigos, brindándose apoyo mutuo, que incluye ofrecer bondad y compasión cuando otros están luchando, evitando culpar y perdonar errores, inspirando unos a otros en sus tareas, enfatizando la importancia del trabajo común y tratando a los demás con respeto, gratitud, confianza e integridad.

Equipos tradicionales
Equipo tradicional coordinado por un
jefe de proyecto - Cortesía de Pixabay

  • Están formados por especialistas que se centran en un tipo de tarea determinado, el objetivo de cada miembro es estar enfocado a cumplir con sus tareas
  • Dado que cada miembro tiene una carga de tareas que suele ir más allá de su capacidad, no da tiempo a levantar la cabeza y ver la imagen global del proyecto
  • Tienen un jefe de proyecto que coordina y distribuye el trabajo, el poder de decisión está a nivel de este jefe de proyecto
  • Sus motivaciones suelen ser extrínsecas y suelen materializarse mediante un bonus, una subida de sueldo o un ascenso
  • Trabajan en un entorno de competitividad
Los equipos tradicionales operan bajo la competitividad, a veces entre sus miembros, a veces con otros equipos. Recordemos que cuando hay competitividad siempre hay un ganador y un perdedor... y el gran perdedor siempre es el mismo: la compañía. Más de una vez he visto a equipos situados en una misma sala que no se hablan, a veces tienen el mismo problema técnico, pero por diferentes razones no pueden o no saben colaborar. En ocasiones he juntado a 3 o 4 expertos en el tema de los diferentes equipos y parece que se produce un milagro, encuentran una solución rápidamente. Frente al problema común y durante un momento han colaborado sumando sus perspectivas, esfuerzos y creatividad. Hay un chiste que me recuerda a más de una de estas situaciones: "Jajajaja, ¡¡¡tu lado del barco tiene un agujero!!!"

Trabajar en un entorno ágil resulta en un entorno alineado con la naturaleza humana, bien aplicado crea felicidad, existen ciertas ideas y prácticas de liderazgo que se sabe mejoran la felicidad en el lugar de trabajo. La felicidad no es contraria a la productividad, más bien es al contrario.

¿Y qué ocurre cuando tenemos equipos ágiles y equipos tradicionales trabajando a la vez en una misma ubicación? Uno de los equipos tradicionales se mofaban de forma sana de un equipo que intentaba trabajar con Scrum, les llamaban "Scrumitas Mariquitas" :-P Puede ser gracioso, lo que si hace es evidenciar el trasfondo de una diferencia cultural, y no podemos ignorar las diferencias culturales.

La gestión de personas es una de las áreas donde las compañías tradicionales prestan poca o mínima atención. En cambio compañía ágiles, o en transformación ágil, toman consciencia de la importancia de personas motivadas y sus interacciones, y adquieren Scrum Masters y coaches ágiles empoderados, cuya área primaria de responsabilidad es justamente la gestión de personas y su salud emocional.

En compañías tradicionales que experimentan y dan sus primeros pasos con Scrum mi consejo es separar unos equipos de otros. Todo el sistema tiene una inercia que encorseta y generalmente evita que los equipos ágiles echen sus brotes, ya que los equipos tradicionales también son actores de esa inercia.

Si la compañía está en pleno proceso de transformación, con lideres alineados con los valores de la Agilidad, y se está construyendo un entorno para que la compañía abrace la Agilidad, entonces lo recomendable es que equipos ágiles y tradicionales trabajen juntos, para que los primeros contagien a los segundos y ambos compartan esa transformación de forma colaborativa.

Mis agradecimientos a Cris, una gran profesional con años a la espalda, que me inspiró a escribir este post cuando me preguntó ¿... no queda otra que separar, verdad?

sábado, 30 de diciembre de 2017

¿Qué puede aportar SAFe® a mi empresa?

La Agilidad sin duda está más presente cada vez en las empresas españolas. Las grandes organizaciones se hacen eco de ello mientras su transformación ágil ocurre paso a paso, y las pequeñas y medianas empresas, donde la estructuras son más flexibles, aceleran en su consolidación en Agilidad.

Quien más quien menos ya tiene 6 u 8 equipos ágiles funcionando en Scrum, quienes ya han incorporado ciclos cortos de construcción y entrega, los sprints, en su forma habitual de trabajar, producen resultados medibles con cada ciclo. Los problemas suelen aparecer cuando diferentes equipos trabajan sobre un mismo producto o cuando comparten infraestructuras, frameworks, arquitecturas, etc. En ese caso Scrum no aporta soluciones para resolver las dependencias ni da soluciones para alinear y sincronizar a los equipos, en definitiva no da soluciones para escalar Scrum.

SAFe® nace para dar soluciones a esta necesidad, nace como una base de conocimiento de patrones Agile integrados y probados para aquellas empresas que quieran conseguir algunos beneficios de la Agilidad y/o desarrollar su transformación ágil. Como base de conocimiento SAFe puede ser aplicado a entornos complejos, como las grandes organizaciones, y también de forma más ligera a las PYMES. Ayuda tanto a las que hayan decidido aplicar el marco de escalado, como a las que quieran conocer y explorar el modelo para incorporar e inspirarse en partes de SAFe y dar solución a problemas concretos y a una transformación más progresiva.
La configuración essential SAFe da solución a la coordinación y sincronización de equipos Scrum existentes
SAFe como base de conocimiento aporta todo aquello necesario para una adopción y transformación ágil de las organizaciones, es un medio para llegar a ser ágiles. Aporta principios y prácticas ágiles para un mejor rendimiento operativo, un mejor valor comercial y una adaptación sostenible a las condiciones cambiantes del mercado. A través de sus 4 configuraciones tiene soluciones para PYMES y grandes empresas que cubren desde una sincronización de equipos de Scrum existentes hasta una gestión de la demanda ágil.

La configuración más simple es essential SAFe y es la que puede aportar a todo tipo de empresas y a sus clientes. Os animamos a explorarlo a través de cursos de formación, como Leading SAFe® de Estratecno, y a través de su big picture en https://www.scaledagileframework.com/

SAFe and Scaled Agile Framework are registered trademarks of Scaled Agile, Inc.

miércoles, 27 de diciembre de 2017

¿Cómo suplir la carencia de la cercanía de los usuarios finales?

Delia presentando su taller centrado en Design Thinking
Recientemente asistí al taller "Más allá de Agile, Lean y Design Thinking" presentado por Delia Estebaranz que dio solución parcial a un problema que ocurre en muchas compañías que dan sus primeros pasos en Scrum.

Los que somos Scrum Masters sabemos muy bien que el rol del Propietario del Producto es determinante para que un proyecto con Scrum sea exitoso. De él dependen los ciclos de aprendizaje y la mejora continua del producto, sólo él sabe de prioridades de negocio y sólo él puede guiar al equipo de desarrollo para que en cada sprint este esté construyendo aquello que más valor de negocio aporte.

Para que el desarrollo ágil funcione es necesario que todos tengamos el foco en resolver necesidades de usuarios de negocio finales, y para ello es necesario que estos estén disponibles tanto para el Propietario del Producto como para el equipo. Ya nos los dice el cuarto principio del Manifiesto Ágil que establece:

Las personas del negocio y los desarrolladores
deben trabajar juntos de forma cotidiana a través del proyecto

Ocurre a menudo que las personas de negocio, y a veces incluso el Propietario del Producto, estén muy inmersos en sus tareas cotidianas, tareas provinientes de negocio, y se descuide la atención que los proyectos ágiles requieren de estos. Aquí es donde haciendo una conjunción de Design Thinking, Agilidad y Lean esta puede ayudarnos a construir un mejor producto.

Design Thinking no puede suplir la carencia de la cercanía de los usuarios finales, pero puede acercarnos a ellos a través de los mapas de empatía y del conocimiento del mundo que tenemos todos. Es aplicable a clientes indirectos, como los usuarios de nuestra web por ejemplo, o a situaciones en las que no llegamos a los usuarios finales, algo común a proyectos en que la parte de negocio no está alineada con Agilidad o proyectos como algunos de la Administración Pública en la que es difícil identificar el valor de negocio y hay una gran prescriptividad a los pliegos de licitación.
El mural de Delia que muestra como se complementan Design Thinking (arriba izquierda), Agile (arriba derecha) y Lean (abajo)
El taller de Delia nos llevó a entender a través de dinámicas muy amenas como usando Agilidad, Lean y Design Thinking podemos ir más allá de un buen producto y podemos construir el mejor producto posible para nuestros clientes.

Situémonos en el contexto de muchas compañías actuales que dan sus primeros pasos en Agilidad:


A nivel de equipos de desarrollo empiezan con Scrum, al principio estos se enfocan en entregar software libre de errores de forma incremental con ciclos cortos. Suele haber carencia de una cultura de confianza que hace énfasis en personas empoderadas y equipos autoorganizados. Por otro lado equipos técnicos suelen construir sin un entendimiento claro del problema del usuario y de las necesidades reales del cliente.
El taller
Compañías algo más maduras gestionan las funcionalidades con Lean, en este caso los Propietarios del Producto usan Kanban para gestionar y priorizar las funcionalidades de forma que estén alineadas con la estrategia de negocio. Con un tablero Kanban de esta naturaleza tienen una vista agregada de todo lo que se construye desde la perspectiva de negocio. También a este nivel suele haber carencia en la gestión de personas, su foco está en la eficiencia, la calidad y la reducción de desperdicio.

En el contexto expuesto no se presta atención al cuarto principio del Manifesto Ágil, y aquí es donde podemos aplicar Design Thinking. Con un equipo formado por los diseñadores de los diferentes equipos de desarrollo se puede aplicar esta técnica para incluir al usuario de forma indirecta y validar el encaje problema-solución. La idea es buscar mediante el proceso observar-idear-prototipar de Design Thinking si mediante la solución diseñada se está resolviendo un problema real de un cliente real y de forma significativa.

Mis agradecimientos a Delia por su espectacular taller, y a las Agile Women por la oportunidad de conocer estos talleres :-)

viernes, 22 de diciembre de 2017

¿Un Scrum Master gestiona impedimentos y/o problemas?

Un impedimento en la carretera - cortesía de Pixabay
Como cuando circulamos por una carretera y nos topamos con un rebaño de ovejas que nos impiden el paso, a lo largo del proyecto y los sprints nos podemos encontrar con situaciones imprevistas que nos obligan a cambiar los planes o a buscar soluciones creativas para intentar continuar según lo planificado.

Un impedimento es uno de estos obstáculos o bloqueos que afecta a la realización de tareas del sprint. En Scrum un impedimento es cualquier cosa dentro de un proyecto que interfiera con la productividad o la calidad del mismo.

Por tanto son cosas que impiden a los miembros del equipo de desarrollo a trabajar a la capacidad de sprint estimada, son aquellas cosas que frenan la velocidad. Los impedimentos también son mudas o desperdicios que van en contra del flujo.

Ahora veamos qué es un problema; este se define como un determinado asunto o una cuestión que requiere de una solución. Podemos ver que las tareas son soluciones a los problemas planteados por las historias de usuario, a la vez que las historias de usuario son soluciones a problemas que tienen los usuarios de negocio.
Equipo de desarrollo en reunión diaria
en donde expone los impedimentos

respondiendo a la tercera pregunta
Por tanto los equipos de desarrollo resuelven problemas a través de sus tareas. De la misma manera el Scrum Master se enfrenta a y resuelve problemas derivados de la implantación y uso del marco de Scrum, así como de las interacciones entre las personas.

Pero ¿que ocurre con los impedimentos que sufren los equipos?, ¿los puede resolver el equipo? Desde la perspectiva de los equipos, los impedimentos son obstáculos externos que no siempre pueden sortear, y es en ese caso que van a necesitar la ayuda de un Scrum Master para que los gestione y para que ellos puedan seguir focalizados en las tareas del sprint.

Posiblemente detrás de un impedimento haya una problema, pero no siempre es así, los impedimentos son algo inherente a la realidad, son como los accidentes, son trabas que siempre ocurren. Debemos de comprender que los impedimentos no se pueden erradicar, no se deben de ignorar y en ningún caso aceptar como algo normal, eso sería permitir que los impedimentos pudieran convertirse en problemas sistémicos.

Los equipos deben de ayudar y colaborar en la identificación de los impedimentos. Una buena oportunidad son las reuniones diarias en las que se trata el día a día, el refinamiento en el que se pueden detectar impedimentos que puedan afectar al siguiente sprint y en la planificación de sprint donde se pueden detectar impedimentos al trabajar las dependencias entre historias de usuario o del equipo con otras áreas o equipos. Todo impedimento relevante se acaba identificando en retrospectiva, es el momento en que todo aquello que preocupa al equipo emerge a la superficie.

Identificado un impedimento que el equipo no puede eliminar, cuya responsabilidad de gestión es por tanto del Scrum Master, este se lo lleva bajo el brazo y se debe de centrar en gestionarlo para lograr eliminarlo con la ayuda de quienes puedan resolverlo.

Pantallazo de un scrumboard con un carril para impedimentos
Los impedimentos deben de registrarse en un área del scrumboard, dado que afectan directamente al trabajo del equipo estos han de estar bien visibles para irradiar y poder hacerles un seguimiento intensivo.

Una vez identificados, el Scrum Master será amablemente pesado con aquellos terceros que puedan resolverlos, e informará al equipo durante cada reunión diaria sobre el progreso en los mismos.

Un impedimento que tarde mucho en resolverse, o un sprint con muchos impedimentos, afectará negativamente en la entrega, lo más probable será que el equipo no logre cumplir con el compromiso adquirido en la planificación de sprint.

Respondiendo al post, un Scrum Master gestiona impedimentos que afecten al equipo, y resuelve problemas relacionados con la interacción entre miembros del equipo, la cultura ágil y el marco de Scrum.

Jeff Sutherland, co-creador de Scrum, dice que no eliminar los impedimentos es el principal obstáculo al que se enfrentan las organizaciones de gran tamaño, no suelen faltar razones para no eliminarlos ya que los impedimentos son "la forma en la que siempre hemos hecho las cosas". Cuando alguien argumenta que hay que adaptar Scrum porque "somos como somos" está poniendo sobre la mesa uno de los mayores impedimentos de la compañía.

martes, 19 de diciembre de 2017

¿ScrumFall puede aportar?

ScrumFall en la forma de acometer las tareas del sprint
ScrumFall es un ScrumBut en el que pretendemos trabajar con Scrum pero seguimos impregnados de la mentalidad de construcción de proyectos por fases en cascada.

Una de las formas de ScrumFall se manifiesta en como acometemos las tareas en los sprint, a la izquierda una imagen del post que escribí al respecto el año pasado.

He observado otra forma de ScrumFall en una compañía cuya oficina de proyectos ha diseñado su propia metodología, y que consiste en definir y llenar todos los sprints a partir de la pila de producto inicial a principio del proyecto. La metodología contempla la posibilidad de cambios a lo largo de los sprints, pero esos cambios difícilmente van a prosperar, ya que en el primer momento ya hemos detallado todo el proyecto y nos resistiremos a incorporar cualquier cambio. Al fin y al cabo hemos hecho un esfuerzo para detallar todo, y lo habremos hecho habiendo pensado en el todo, y habremos diseñado y tomado decisiones desde la perspectiva del proyecto en su conjunto.

ScrumFall en la pila de producto
Como podemos ver una pila de producto detalla en el primer momento va a minimizar, y prácticamente evitar, el aprendizaje y la mejora continua sobre el producto, aunque construyamos este de forma incremental e iterativa mediante sprints. Básicamente eso va a provocar que el producto acabe siendo lo que se haya definido a principios del proyecto.

Pero, ¿no hay algún beneficio al aplicar Scrum en estas circunstancias?

Si, lo hay, el hecho de construir de forma iterativa con sprints va a provocar aprendizaje del proceso, el equipo mejorará la forma de trabajar y diseminará el conocimiento a través la mejora continua con cada retrospectiva a final de sprint.

Aunque esta forma de ScrumFall no sea Scrum, puede ser una forma para iniciar Scrum en una compañía tradicional. Si de esta forma se hace patente que el equipo mejora de sprint en sprint, quizá la compañía sienta curiosidad y se plantee aplicar Scrum de verdad.

domingo, 17 de diciembre de 2017

¿Cómo funciona Scrum de Scrums?

Scrum de Scrums está compuesto de representantes de los equipos
Scrum de Scrums es una primera aproximación al escalado presentada por Jeff Sutherland en 2001, un complemento para Scrum no considerado como parte de Scrum y que por tanto no se menciona en la Scrum Guide. Trata de una técnica para usar Scrum de forma escalada cuando varios equipos trabajan en un único producto o una familia de productos única.

Recordemos que los equipos de Scrum no deben de superar los 9 miembros para ser eficientes y para que funcione la autoorganización. Si un producto requiere a más de 9 desarrolladores, en vez de hacer crecer a un equipo existente, el enfoque de Agilidad es crear varios equipos y distribuir el trabajo entre todo ellos. Para ello necesitamos una forma efectiva para la coordinación, el alineamiento y la comunicación entre estos equipos, así como una integración de las entregas a final de sprint.

Scrum de Scrums nos da solución a estas necesidades. Su formato es similar a la reunión diaria, en la que en vez de los equipos, son los miembros los que se sincronizan y alinean dentro de su equipo. Scrum de Scrums se puede celebrar de forma diaria, dos veces a la semana o al menos una vez a la semana. El día que se haga deberá de ser justo después de las reuniones diarias, por tanto será preferible que los equipos celebren sus reuniones diarias en paralelo.

Acabada la reunión diaria un representante de cada equipo acude al Scrum de Scrums, este debe de ser el miembro del equipo que más involucrado esté con el desarrollo del objetivo del sprint, por tanto a sucesivos Scrum de Scrums pueden acudir diferentes representantes. La reunión no debe de superar los 30 minutos, y aunque facilitada por un Scrum Master, los equipos no pueden estar representados por su Scrum Master o su Propietario del Producto. En Scrum de Scrums es necesario que el representante tenga poder de decisión como equipo de desarrollo y que los compromisos adquiridos los adquiera en nombre de su equipo.

Cada representante responde de forma escalada a las tres preguntas estándar de las diarias, más una pregunta extra:
La pregunta añadida es la que coordina y alinea, trata las dependencias y bloqueos que el trabajo de un equipo podría generar para los demás. Para reducir dependencias y bloqueos es una práctica esencial en escalado mantener las historias de usuario de pila de producto lo más independientes posible.

Una vez todos hayan respondido a las cuatro preguntas la reunión pone el foco en tratar una lista de temas pendientes más los detectados en el Scrums de Scrums reciente. Esta lista deberá de estar recogida por ejemplo en una hoja de rotafolios y post-its, un excel, una wiki...

Fijémonos que con equipos no superiores a 9 miembros, y reuniones de Scrum de Scrums con no más de 9 representantes, podemos escalar con esta técnica a 9X9 = 81 personas. Podemos añadir una nueva capa de escalado para el modelo e incluir un Scrum de Scrums de Scrums. No debemos de superar el número de Dunbar de aproximadamente un total de 150 personas. Es el límite que impone nuestro tamaño de la neocorteza cerebral y su capacidad de proceso, según el antropólogo Robin Dunbar no podemos relacionarnos plenamente en una red social (familia, amigos, profesional, virtual...) por encima de esa cantidad de personas.

Otros marcos de escalado incluyen en sus prácticas Scrum de Scrums. En SAFe la reunión ayuda a coordinar las dependencias del ART (Agile Release Train) y proporciona visibilidad de progreso e impedimentos. El RTE (Release Train Engineer) facilita, Scrum Masters y otros (cuando corresponda) se reúnen y revisan el progreso para con los hitos, los objetivos de PI y las dependencias internas entre equipos. La composición de los asistentes es algo distinta al Scrum de Scrums original. En SAFe las dependencias se hacen visibles en el primer momento y se habrán resuelto en la PI Planning, a la vez que existen otros mecanismos de coordinación y alineamiento como son la PO-Sync por ejemplo. Por tanto es suficiente que los Scrum Masters gestionen la coordinación y el alineamiento del tren, en caso de detección de nuevas dependencias o nuevos bloqueos éstos incorporan en la reunión a miembros de los equipos afectados.

martes, 12 de diciembre de 2017

¿Qué ha de ocurrir para que se asiente Agile en un equipo, área u organización?

Hoy en día, obligados por las exigencias del mercado y por ende por los usuarios de móviles que validamos las innovaciones, se están acometiendo transformaciones ágiles en muchas compañías. Desde mi perspectiva la mayoría de los directivos que deciden ir por ese camino desconocen las implicaciones y el alcance de lo que supone. Una transformación ágil debería de ser a nivel holístico: un rediseño organizacional, por medio de un liderazgo al servicio a todos los niveles, un alineamiento de la estrategia a través de priorización de iniciativas por valor con operaciones, presupuestación lean, una transformación de proveedores en partners, gestión de retención y fidelización del talento...

Podríamos comparar la iniciativa de una transformación con la pretensión de conducir en Bangalore, la India, con como lo hemos aprendido en España y tratando de hacerlo como si estuviéramos en nuestra ciudad... probablemente sufriríamos un accidente mortal. No podemos conducir con nuestra mentalidad en una ciudad en la que mentalidad es radicalmente distinta, y dado que somos nosotros los que queremos conducir allí, somos nosotros los que debemos de adaptarnos y adoptar la mentalidad de la conducción india.

En una ocasión les expliqué a dos directivos de qué trata la presupuestación lean, les decía que si estamos construyendo en dos líneas de negocio distintas y una de ellas estaba funcionando y creciendo, y la otra a todas luces estaba en retroceso, habría que plantearse mover presupuesto, recursos y equipos de una a otra con tal de maximizar valor y beneficios. Scrum nos proporciona puntos naturales para ello, el momento entre sprints después de la revisión de sprint. Ambos se rieron de mi, como dice Dean Leffingwell los secretos no se pueden gestionar y en una compañía de silos los intereses entre lineas de producto probablemente sean distintos. Aún así la "transformación" siguió su curso y pusimos en marcha media docena de equipos de Scrum de forma exitosa. Eso si, ¡no sin dolor!

Una vez superados los impedimentos sistémicos bloqueantes y habiendo conseguido en mi labor de Scrum Master establecer un entorno adecuado, iniciamos el primer sprint. Percibimos un punto de inflexión en el sexto sprint, fue un momento en el que las cosas empezaban a funcionar pero no cumplían con las expectativas que tenían del concepto ágil. Recordemos que Scrum impregna de nuevos hábitos a equipos y organizaciones, y resulta que en la sexta iteración de un hábito llegamos a un punto de inflexión donde tendemos a abandonar, pero que si conseguimos superarlo tiene muchas posibilidades de asentarse.

En psicología moderna está comprobado que de promedio todo lo que se repite 21 veces crea un hábito, siempre y cuando estemos motivados a adquirir ese hábito. Una vez adquirido ese hábito ya no se necesita más motivación para mantenerlo. Por ejemplo, si decidimos cambiar el postre calórico diario por una fruta, si lo hacemos alrededor de 21 veces habremos incorporado ese nuevo hábito en nuestra vida cotidiana.

Scrum imprime hábitos nuevos en la forma de trabajar de los que lo adoptan, y de la misma manera que cualquier hábito, Scrum se asienta en las organizaciones alrededor del sprint número 21, siempre y cuando el liderazgo de la transformación ágil está respaldada e impulsada por toda la organización. De ahí un equipo de desarrollo que se inicia en Scrum puede ser un equipo ágil consolidado al cabo de un año, no antes.

Resaltar que en mi experiencia una gran organización tiene un largo recorrido antes de permitir un entorno adecuado para la Agilidad, usualmente son más de 5 años para compañías con cultura empresarial tradicional española. Como podemos ver una transformación ágil es un camino largo que hay que andar paso a paso, con paciencia y constancia. Habrá éxitos seguidos de crisis, cada crisis parecerá un retroceso, que superado significará un paso de gigante hacia adelante.

Como nos cuenta John P.Cotter en su libro "Leading change", las razones principales por las que las transformaciones ágiles pueden no tener éxito son:
  • Permitir demasiada complacencia
  • Fracasar en la creación de una coalición de liderazgo verdaderamente empoderada
  • Subestimar el poder de la visión
  • Permitir impedimentos que bloqueen la nueva visión
  • Fracasar en la creación de triunfos a corto plazo
  • Declarar la victoria demasiado pronto
  • Despreciar la importancia del asentamiento de los cambios
Transformación ágil, primero grandes personas, luego grandes productos - Cortesía de Pixabay