¿Cómo desde el liderazgo podemos ayudar a un equipo a ser de alto rendimiento?

Patrick Leoncioni en su libro "Las cinco disfunciones de un equipo" nos muestra los puntos críticos que un equipo ha de superar para convertirse en un equipo de alto rendimiento. En el artículo "¿Qué impide a un equipo ser de alto rendimiento?" de Aprendiendo Agile lo resumí.

Desde el punto de vista del liderazgo ¿cómo podemos ayudar a un equipo a superar estas disfunciones?

En primer lugar, el comportamiento del líder tiene que ser acorde al comportamiento que se espera del equipo, ha de liderar desde el ejemplo. A medida que los lideres escalan en la jerarquía, los empleados suelen cambiar su comportamiento hacía ellos, dejan de ser auténticos y de expresar el mejor pensamiento. Para no quedar aislados, los líderes deben de crear un entorno de confianza para que sus empleados y equipos puedan equivocarse, crecer y mejorar.

Las cinco disfunciones de
un equipo de Leoncioni

En segundo lugar, se pueden realizar actividades que ayuden a acelerar el cambio. Casi toda la información que muestro a continuación está extraída del libro de Patrick.

La primera de las disfunciones era la falta de confianza. Aquí lo que un líder puede hacer para empezar a crear un ambiente de confianza, y tal y como la entiende Patrick consiste en mostrar sus vulnerabilidades de manera genuina. Es muy importante que las vulnerabilidades que se enseñen sean reales ya que, de lo contrario, si el equipo entiende que se le ha engañado, habremos perdido su confianza como líderes.

Por otro lado, si algún miembro del equipo muestra alguna vulnerabilidad es imprescindible arroparle con su vulnerabilidad y mostrar que ésta no penaliza a quien la mostró, sino que ayuda a las interacciones que podamos tener.

Las herramientas que nos pueden ayudar en esta disfunción son aquellas que consigan que las personas se conozcan más, se sientan más cercanas unas a otras o se sientan valoradas. Algunas de las dinámicas que se podrían utilizar:

• Historias personales (recomendadas por Patrick): Cada persona contestará a un conjunto de preguntas personales poco delicadas, por ejemplo: ¿Cuántos hijos tienes?, ¿cuáles son tus aficiones?, etc.
• Mapas personales: Cada persona dibuja su mapa personal. Después en parejas se muestran los mapas personales y se hacen preguntas hasta entenderlos. Por último, cada persona presenta a su compañero partiendo del mapa personal, pero contando una historia.
• Eficacia de equipo (recomendada por Patrick): Cada persona del equipo indica cuál es el mayor aporte de cada uno de sus compañeros al equipo.

La segunda disfunción es el temor al conflicto. El líder debe permitir que exista un conflicto sano entre los miembros del equipo. No debe interrumpir los debates por miedo a perjudicar el ambiente. Los líderes deben transmitir tranquilidad cuando aflora un conflicto y permitir que la solución ocurra naturalmente.

El objetivo es conseguir un conflicto sano donde cada miembro pueda expresar lo que considere necesario sin que por ello nadie se vaya con sentimientos desagradables. Así es posible realizar diferentes acciones dependiendo de la naturaleza del conflicto:

• Los conflictos suelen tener una causa raíz, así, uno de los miembros del equipo o el líder puede utilizar la herramienta de coaching de los 5 porqués. Esto hará pensar al equipo en los motivos detonantes del conflicto y les permitirá tomar la mejor acción posible para resolverlo..
• Comunicación asertiva, esta otra herramienta conseguirá que nos comuniquemos en base a datos objetivos y sentimientos que afecte exclusivamente a la persona que transmite la preocupación o el problema y se evitan ataques personales

La tercera disfunción es la falta de compromiso. El consenso y la necesidad de tener mucha información para la toma de decisiones son el mayor de los obstáculos para que un equipo pueda llegar a compromisos en tiempos razonables. El líder debe forzar al equipo a tomar decisiones tratando de evitar estas dos situaciones.

Algunas de las herramientas que tenemos a nuestro alcance para evitar estos problemas pueden ser:

• Toma de decisiones por consentimiento. Esta técnica se utiliza en Sociocracia y consiste, brevemente, en presentar el problema y la solución que está encima de la mesa. Después el equipo vota si consiente o no esta solución. Si algún miembro no consiente debe expresar su preocupación y cómo se podría modificar la solución para que se sintiera cómodo. Una vez incluida la modificación se vuelve a votar. El proceso se repite hasta que se encuentre una solución suficientemente buena para que todos los miembros consientan.
• Fechas límite (recomendado por Patrick). Los equipos deben poner fechas límite a las acciones. Si hubiera acciones intermedias, éstas también deben tener fechas límite. Con esta herramienta se busca tener un seguimiento de los resultados de las acciones y así poder realizar correcciones si fuera necesario.
• Terapia de exposición a bajo riesgo (recomendado por Patrick). Un equipo debe poder tomar decisiones con falta de información. Esto puede hacerles sentir inseguros. Por ello, una manera de que vayan viendo que no son malos tomando este tipo de decisiones es hacerlo con situaciones donde en caso de fallar el impacto sea mínimo.

La cuarta disfunción es la evitación de responsabilidades. El líder debe favorecer que unos pidan responsabilidad a otros y evitar ser él la única fuente de responsabilidad. Si se convierte en la única fuente de responsabilidad las personas no dicen nada a los compañeros, porque para eso está el líder.

Las herramientas que nos presenta Patrick seguramente nos suenen a aquellos líderes que conozcamos Scrum:

• Publicación de metas y estándares: recomienda que se muestre públicamente lo que el equipo necesita conseguir (en Scrum sería el objetivo del sprint) y cómo ha de comportarse cada uno para tener éxito (esto se puede asemejar a la asignación que el propio equipo hace de tareas)
• Revisiones sencillas y regulares del avance: Los miembros del equipo deben comunicar regularmente entre sí sobre cómo están trabajando con sus compañeros hacia las metas establecidas (esto podría ser una variación de la daily en busca de un equipo de alto rendimiento).
• Recompensas de equipo: creo que esto no requiere mucha explicación. Si las recompensas son individuales cada persona va a trabajar de manera individual y no le va a suponer ningún problema que otro compañero no trabaje adecuadamente. Sin embargo, si las recompensas son al equipo, no sólo vas a trabajar de manera más colaborativa, sino esto resalta que el mal trabajo de un compañero te afecta directamente y por tanto es posible que acabes exigiéndole responsabilidades. Otra cuestión aparte es si las recompensas son una herramienta adecuada o no, pueden ser un arma de doble filo.

La última disfunción es la falta de atención a resultados. A mi personalmente la actitud que ha de tener un líder para superar esta disfunción me resulta especialmente complicada. Según Patrick el líder debe valorar únicamente los resultados, de lo contrario da permisos a los miembros del equipo a hacer lo mismo.

Sin embargo, personalmente, entendiendo que los resultados son básicos y ese debe ser el objetivo del equipo, valoro mucho la mejora del equipo en busca de ese objetivo. Creo más en una cultura de mejora continua que de marcar el éxito únicamente por los resultados.

Patrick recomienda hacer públicos los resultados para tratar de que el equipo empuje en dicha dirección.

Desde la Agilidad y con nuestra cultura de transparencia entiendo que esto está resuelto. Sin embargo, si podemos ayudar no siendo flexibles en la consecución o no de los objetivos. Por ejemplo, en Scrum tenemos un conjunto de elementos que se deben obtener al final del sprint. Para considerar que esos elementos están conseguidos disponemos de una herramienta denominada "Definición de hecho" compuesta por un conjunto de condiciones objetivas. Por tanto, si somos rigurosos y poco flexibles a la hora de determinar si se cumple la "Definición de hecho" podremos ayudar al equipo a enfocarse a los resultados.

Un saludo, Alexander y Rubén :-)

¿Cómo escribir historias técnicas de deuda técnica?

La deuda técnica ralentiza la productividad y genera
productos de escasa calidad - cortesía de Pixabay

Un producto no es un producto de calidad si no da solución a las necesidades del usuario o cliente, eso representa su valor, y tampoco es de calidad si la infraestructura tecnológica que lo soporta no es excelente, eso lo representa su integridad tecnológica.

Centrarse únicamente en construir funcionalidades de negocio, como las historias de usuario, puede funcionar a corto plazo, e incluso proporcionar una gratificación inmediata al mercado, pero a medio plazo la velocidad de entrega se ralentizará irremediablemente por una carga aplastante de la deuda técnica que se va adquiriendo.

Es por ello que para garantizar que se realicen las inversiones adecuadas dentro del presupuesto para el producto o proyecto, es necesario incluir historias técnicas de resolución de deuda técnica en la pila del producto.

A menudo el Propietario de Producto no comprende la necesidad y los beneficios de reducir la deuda técnica y no considera historias técnicas para ello en la pila del producto. Recordemos que el Propietario del Producto es parte del equipo ágil y este debe de asumir la responsabilidad de reducir la deuda técnica y analizar esta con los miembros del equipo de desarrollo y trabajar juntos para darle la prioridad adecuada en la pila del producto: su dolor es el dolor del equipo y viceversa.

Los desarrolladores conocen la deuda técnica y son conscientes de la importancia de resolver este problema desde el punto de vista técnico. Hay un técnica provocativa que ideó un equipo de desarrollo para ayudar al Propietario del Producto a tener en cuenta la deuda técnica; utiliza el siguiente el patrón para escribir historias técnicas de esta índole:

If we don't do this [action required]

It will cause this impact [loss of service]

And that will result in [reputational damage] and/or [monetary impact]

Si no hacemos [acción requerida]

Causará el impacto [pérdida de servicio]

Lo que resultará en [daño a la reputación] y/o [impacto monetario]

un ejemplo podría ser:

Si no hacemos por resolver la cobertura de pruebas

Causará el impacto de un incremento mensual del 10% en el número de incidencias

Lo que resultará en una reducción de productividad mensual acumulada de aproximadamente 5 horas

Los equipos viven la realidad tecnológica (herramientas, hardware, entornos, etc.) día a día, ellos saben qué les cuesta en esfuerzo o en tiempo cada vez que se encuentran con un elemento con deuda técnica. Es su responsabilidad analizarla, estimarla y hacerla visible de forma argumentada al Propietario del Producto y a otros interesados.

Hacer partícipe al cliente e interesados tiene dos beneficios; hacer que estos entiendan los problemas del software, y que participen en la solución apoyando la resolución de deuda técnica o proporcionando una perspectiva de negocio que puede cambiar las prioridades.

Gracias Sara por compartir este patrón :-)

¿Cómo tiñe la PI Planning la intención de realidad?

PI Planning en el Big Picture de SAFe®

Una de las frases de SAFe® y que se refiere a la PI Planning dice así:

No hay magia en SAFe...

excepto quizá en la PI Planning

Veamos pues cual es la magia de este evento core del marco.

Recordando los inputs y outputs de la PI Planning tenemos entre otros como input el program backlog, la pila de features que Product Management ha preparado, y como outputs los objetivos del equipo, las pilas iniciales de los equipos y el program board con las features colocadas en la iteración en la que el equipo estima terminarlas y las interdependencias detectadas resueltas.

La primera clave está en comprender que el program backlog representa la intención de Product Management y negocio, representa aquellas cosas que desde el punto de vista de negocio son las que aportan el máximo valor y están limitadas en tamaño a la capacidad del tren, por tanto representan las features deseables para construir y obtener al final de PI.

Cuando en PI Planning los equipos toman esas features, las desglosan en historias de usuario, resuelven dependencias que emerjen entre si y con equipos externos, estos están "cocinando" la intención para obtener factibilidad. Esa es la magia de la PI Planning, utiliza la complejidad del pensamiento focalizado de todos los individuos del tren como inteligencia colectiva para obtener un plan factible tiñendo así la intención, representada en el program backlog, de realidad.

Finalizada la PI Planning las pilas iniciales de los equipos y sus objetivos del PI no van a cuadrar al 100% con la intención, con las features del backlog, quizá un 80%... Habrá cosas que no es posible construir, puede que por razones tecnológicas o por capacidad para absorber dependencias, para otras habrán surgido ideas y soluciones mejores... lo importante es entender que la PI Planning hace que los equipos crean un plan de partida en el que crea cada individuo, un plan que sea factible y por tanto garantice el éxito.

Program backlog y program board y su maraña de dependencias

En la imagen de la derecha podemos ver un program backlog, el rotafolios a la izquierda, mostrando en azul las features que ha sido posible planificar; las verdes son aquellas que no se han podido incluir por alguna razón. En el tablero de la derecha se puede ver el program board con todas las dependencias identificadas y resueltas, están representadas por las cuerdas rojas. ¿Qué precio tiene un plan trimestral para 8 equipos que tiene todos los números de ser exitoso? ¿Que precio tiene el program board en el que se nos muestra las dependencias resueltas para ese trimestre? No habrá retrasos ni bloqueos, porque el plan lo han cocinado, cada uno desde su perspectiva, todos aquellos individuos que lo van a ejecutar.

Resaltar que el compromiso se establece con los objetivos que los propios equipos han establecido, y un objetivo es una cosa flexible. Un objetivo se puede alcanzar con un grupo de historias de usuario u con otro, con más o con menos, lo importante es que al final de PI el cliente reciba la mejor solución posible a su necesidad. El compromiso por objetivos nos hace ágiles, hace que las pilas de los equipos sean flexibles al igual que una pila de producto de un equipo de Scrum.

Con la PI Planning los equipos son dueños de sus planes y esa responsabilidad es uno de los beneficios más significativos del evento, cada individuo siente su responsabilidad en el resultado del tren, creándose así un ambiente de trabajo mejor en el que se impulsa la colaboración. Durante la PI Planning ocurre otro beneficio casi mágico, todos hacen hincapié en el equilibrio entre el trabajo y la vida, asegurándose de no planificar excediendo la capacidad y obtener un plan de partida excepcional.

Aunque no haya sido posible incluir todas las features el voto de confianza muestra a Business Owners entusiasmados

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

¿Cuáles son las novedades de la versión 5.0 de SAFe®?

En octubre Scaled Agile anunció y puso a disposición del público su actualización a la versión 5.0. Se trata de una actualización significativa del marco que proporciona orientación sobre las siete competencias básicas que ayudan a una organización a convertirse en una empresa Lean y alcanzar la Agilidad Empresarial (Business Agility), el paradigma empresarial para las compañías que van a florecer en el despliegue de la quinta revolución tecnológica.

La novedades que nos trae esta nueva versión se pueden ver resaltadas en la imagen al final post y son las siguientes:

• Business Agility: Agilidad Empresarial, el nuevo marco incluye la capacidad para poder competir y prosperar en la era digital respondiendo rápidamente a los cambios del mercado y a las oportunidades emergentes con soluciones empresariales innovadoras.
• Measure and Grow: se focaliza en cómo medir el estado de Business Agility y cómo acelerar el crecimiento para mejorar los resultados económicos generales.
• Organizational Agility: esta nueva competencia de Agilidad organizacional describe cómo los líderes Lean thinkers y los equipos ágiles optimizan sus procesos de negocio, desarrollan estrategias con compromisos claros y adaptan rápidamente la organización para capitalizar nuevas oportunidades.
• Enterprise Solution Delivery: antes Business Solutions and Lean Systems Engineering; esta competencia describe cómo aplicar los principios y prácticas Lean-Agile a la especificación, desarrollo, implementación, operación y evolución de las aplicaciones de software, redes y sistemas ciberfísicos más grandes y sofisticados del mundo.
• Agile Product Delivery: antes DevOps and Release on Demand; se ha convertido en la competencia Agile Product Delivery, que es un enfoque centrado en el cliente para definir, construir y liberar en un flujo continuo productos y servicios de valor para clientes y usuarios.
• Continuous Learning Culture: esta nueva competencia de 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.
• Agile Teams beyond Technology: se ha reestructurado esta competencia de Team and Technical Agility que describe las habilidades críticas, los principios y prácticas Lean-Agile que los equipos ágiles y los equipos de equipos ágiles (ARTs) utilizan para crear soluciones de alta calidad para sus clientes.
• Portfolio Vision: la competencia de Lean Portfolio Management se ha reescrito como una capacidad organizada para alinear la estrategia con la ejecución, cumplir con los compromisos existentes de manera confiable y permitir una mejor innovación.
• Customer Centricity: el nuevo marco incluye Design Thinking para centrarse en sus herramientas y prácticas para poner al cliente en el centro.
• Essential Level: los niveles de equipo y programa (ART) se han unido en uno sólo que corresponde a la configuración essential.
• Continuous Delivery Clarity: se muestra más claridad en el flujo de exploración continua, integración continua y despliegue continuo en la ejecución de las iteraciones.

Las novedades de la versión 5.0 sobre el Big Picture de SAFe®

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

¿Dónde inspirarse para encontrar Leading Indicators?

Los Leading Indicators ayudan a los Propietarios del Producto
a tomar las decisiones acertadas - cortesía de Pixabay

Los Leading Indicator están tomando mucha importancia en el desarrollo ágil de software; este implica construir los mejores productos posibles de forma iterativa y con feedback frecuente, y los Leading Indicators son indicadores de feedback predictivo clave para el desarrollo ágil con una entrega máxima de valor.

Los Leading Indicators son cualquier indicador predictivo que cambia antes de que el resto de los indicadores económicos comiencen a ir en una dirección particular, nos sirven para detectar señales de advertencia tempranas y a tomar medidas decisivas mientras todavía estemos tiempo. No son indicadors precisos, pero ayudan a los observadores del producto en el mercado a tomar decisiones rápidas y acertadas, a Propietarios del Producto y Product Managers a decidir lo que construir y lo que no.

En entornos tradicionales estamos rodeados de Lagging Indicators, indicadores que miden el resultado final de nuestra estrategia y esfuerzos. Son fáciles de medir y nos dicen cómo nos está yendo como organización, pero en la mayoría de los casos son difíciles de influir o de mejorar directamente.

Veamos un ejemplo ilustrativo: Imaginemos que quiero adelgazar. Una medición clásica sería el peso, quizá al final del día o al final de la semana. El peso es un Lagging Indicator, la medición es a posteriori, a lo mejor me he esforzado mucho y he ido al gimnasio toda la semana, y resulta que no he perdido nada de peso, me he dado cuenta demasiado tarde. Un Leading Indicator sería medir las kcal que tomo durante el día, si me quedo un poco por debajo de las aproximadamente las 1800 kcal que necesita mi organismo al día, tengo todos los números de haber adelgazado al final de la semana.

Veamos un ejemplo de TI: imaginemos que queremos sustituir los diferentes logins de los sistemas de nuestra organización por un single-sign-on. Un Leading Indicator sería medir el aumento de single-sign-ons versus el descenso de logins individuales, esa tendencia nos muestra si nuestra idea de single-sign-on tiene o no éxito entre los empleados de la organización.

Leading indicators sobre el uso de historias de usuario, sobre la sustitución de funcionalidades como en el ejemplo del single-sign-on, sobre tests A/B en los que medimos que solución prefiere nuestro usuario o cliente, son una herramienta clave para que Propietarios del Producto y Product Managers tomen las decisiones adecuadas para construir el mejor producto posible, maximizando así el retorno de la inversión hecha en el mismo.

Podemos inspirarnos en el marco de Google HEART para encontrar Leading Indicators:

Google HEART Framework

y también en las Pirate Metrics de Dave McClure:

Dave McClure's Pirate Metrics

¿Todos los equipos de un área o una compañía han de tener el mismo tablero?

Introduciendo límites WIP: Los tableros
deben de estar en continua evolución

Hoyendía la mayoría de compañías ya tienen varios equipos ágiles trabajando; llegado un momento de mínima madurez la inercia tradicional lleva a estas a querer estandarizar las prácticas y procesos ágiles.

Nuestra mentalidad tradicional viene de la producción en masa, de la estandarización y de los productos commodity; la cuestión es que eso ya no funciona en nuestro mundo actual donde los proyectos y productos son de muy distintas naturalezas, de modelos de negocio dispares y de una hipersegmentación del mercado.

Para afrontar esa realidad necesitamos de la Agilidad y de equipos autoorganizados que hagan frente de forma adaptativa y flexible a esa realidad de proyectos y productos siempre cambiante. Visto esto podemos imaginarnos que los tableros de los equipos deben de ser únicos y haber evolucionado hacía aquella configuración que aporte más al equipo para que sean realmente una herramienta que les permita maximizar el valor entregado.

Tablero de un equipo de Kanban con multitud de estados

Una de las mejores formas para evolucionar hacia tableros útiles es mediante tableros físicos y post-its. Son una forma muy flexible de visualizar y ajustar continuamente el flujo de trabajo, permitiendo que cada equipo descubra su propio mejor proceso. Herramientas como JIRA llevan a que las personas se focalicen en aprender el proceso de la herramienta y limitan el descubrimiento del proceso propio y la mejora continua del mismo.

Como podemos ver los tableros que potencian al máximo a los equipos deben de ser únicos, lo que no significa que no pueda haber un patrón en común. Probablemente los flujos de trabajo y valor, y las políticas de la compañía lleven a un diseño con partes comunes.

Los tableros de equipos Kanban son los que más diferentes suelen ser. La metáfora para los equipos Kanban es la carrera de relevos; donde un especialista pasa el testigo al especialista del siguiente estado, donde los estados representan un flujo de trabajo o de valor muy específico. Cada equipo Kanban puede estar gestionando cosas muy distintas a los demás, por ejemplo el mantenimiento de un software, la venta y seguimiento de un producto, la planificación de un evento...

Tablero de Scrum o scrumboard (TODO, DOING, DONE)

En cambio los tableros de los equipos de Scrum suelen ser más homogéneos. Son equipos donde el enfoque es el holístico y su metáfora es el equipo de rugby, donde un equipo al completo, como un ente de nivel superior, intenta recorrer el campo como una unidad, pasando la pelota de un lado a otro.

Los tableros de equipos de Scrum suelen ser mucho más parecidos, aunque casi nunca iguales. Puede haber áreas específicas del equipo, convenciones de colores o de elementos del equipo que los hacen diferir de los demás.

Los Scrum Masters y coaches ágiles aprendemos a leer los tableros de los equipos, y percibimos que la madurez en Agilidad se puede leer en la diversidad de tableros de los distintos equipos de una compañía.

¿Cómo de importante es dar permiso para fallar?

Permitido fallar, para aprender...
Cortesía de Pixabay

Uno de los beneficios que nos traen los marcos ágiles como Scrum son entornos de confianza donde los individuos pueden exponer su opinión sincera, un entorno donde el coraje es un valor, donde se puede disentir y decir que "no" sin temor a consecuencias y donde el conflicto es sano y representa diversidad. Solo así conseguimos entornos en los que las planificaciones de sprint y las PI Plannings se tiñan de factibilidad y lleven al éxito, ya que los que van a hacer el trabajo crean esos planes y tienen toda la libertad para hacer planes en los que crean de verdad.

Para que todo esto ocurra es necesario aprender, y para aprender es necesario fallar. Quizá algunos conozcáis el vídeo de la bicicleta invertida; en ese vídeo Destin de Smarter Every Day nos muestra entre otros aprendizajes que para aprender a ir en bicicleta invertida hay que desaprender primero el ir en bicicleta normal. El mensaje de fondo es que para cualquier cambio, como lo es una transformación ágil, se requiere de un aprendizaje, y para aprender hay que caerse unas cuantas veces de la bicicleta y levantarse para intentarlo de nuevo.

Por tanto en una transformación ágil es necesario que la compañía como sistema falle rápido para aprender rápido, y para ello es necesario desbloquear el posible miedo al fallo de los individuos. Como coaches ágiles debemos de sugerir al CEO o a los altos directivos y líderes dar un mensaje muy explícito, como por ejemplo: "Tenéis permiso para fallar, fallad rápido, aprended rápido y haced grandes cosas".

No podemos esperar que los equipos lean un libro sobre bicicletas, o un marco ágil, y después ya sepan montar en bicicleta; hay que empezar a caminar, a caerse y a levantarse. Es esencial que los directivos lo entiendan y den mensajes que desbloqueen ese miedo a caerse.

Lo que importa es un ritmo de mejora continua sostenible
Cortesía de Pixabay

Cuando los equipos sienten que pueden fallar, son más valientes y se retan a ir un poco más allá de lo que creen que son capaces. Un equipo que se rete quizá solo llegue al 80% de lo que se ha propuesto, pero su coraje, su proactividad y su energía les habrá llevado a hacer mucho más de lo que hubieran hecho pensando en cumplir al 100% sus objetivos. Equipos que entregan el 100% de lo planificado son equipos que probablemente solo hagan lo de siempre, sin retarse ni evolucionar y sin mejorar de forma continua.

Uno de los mensajes más potentes que he oído fue de un directivo que dijo a todo el ART (Agile Release Train) de 80 personas, un equipo de equipos, que en el primer PI, ciclo de incrementos en entorno trimestral, el resultado podía ser un "piece of shit" que nadie quiera, y que eso no le importaba... lo que le importa es que el ART aprenda a colaborar y coja ritmo, ¡un ritmo sostenible de mejora continua! Les dio permiso a fallar, a rechazar, a decir que "no", y además les animó a planificar tiempo para aprender y explorar en sus sprints.

El fracaso no es fallar, el fracaso es no aprender

y fallar a ayudar y a pedir ayuda

En nuestra cultura es esencial este tipo de mensaje. Venimos de una cultura del pecado original, del juicio ajeno y del "no" como primera opción. Para que nuestros equipos hagan grandes cosas solo los líderes pueden desbloquear esos comportamientos que tanto tiempo nos han impregnado.