¿SAFe® es 100% Agile y Lean?

Hace poco estuvo Celia entre los asistentes de un curso de SAFe®, es una coach ágil de nivel que inició un debate muy interesante, preguntó por cómo se resuelven las dependencias entre trenes (ARTs) en un Solution Train. La respuesta nos llevó a la zona gris de SAFe, a la capa Large Solution donde Agile y Lean se pueden tambalear.

Big Picture de SAFe con la capa en que Agile y Lean se pueden tambalear

La capa Large Solution es una capa de coordinación de trenes que ocurre a través de un tren virtual. El debate fue alrededor de la palabra "coordinación" que nos indica claramente que si en este nivel hacen falta coordinadores que empujan (pull) hacia los trenes, no es posible la autoorganización. Otra razón fue el número de individuos de un Solution Train, son demasiados para que pueda emerger la autoorganización.

Recordemos que un tren está basado en el tamaño de las redes sociales, y que estas están limitadas a ±125 individuos, número que identificó Robin Dunbar y que representa la cantidad máxima de individuos que pueden relacionarse plenamente en un sistema determinado. Por tanto la autoorganización, y con ello la ejecución por arrastre "push" que ocurre en los trenes, solo es posible hasta aproximadamente ±125 individuos.

De ahí viene el concepto de tribu del tren: un grupo de familias que se ayudan unas a otras y siguen a un líder para sobrevivir y se limita a ±125 individuos. Históricamente cuando una tribu crecía mucho aparecía otro líder, se enfrentaban y la tribu se segmentaba en dos tribus. Para sentirse parte de grupos más allá de ±125 individuos la naturaleza humana simplemente no está preparada.

El ser humano ha tratado de inventar conceptos artificiales para crear grupos muy grandes, por ejemplo los conceptos de nación y de religión; son conceptos en los que la autoorganización no funciona. Si fuera así ayudaríamos a un mendigo en la calle si perteneciera a nuestra nación... pero no ocurre así, si le ayudamos lo hacemos por nuestros valores individuales, como el humanitarismo por ejemplo.

SAFe con el Solution Train no trata de crear un concepto que agrupa individuos por encima del tren, es plenamente consciente que el límite de individuos es por trenes y que estos se pueden coordinar como elementos individuales con herramientas y comunicación top-down.

Con la resolución de dependencias entre trenes que propone SAFe se hace patente la imposibilidad de autoorganización y la ejecución por empuje (push) en un Solution Train. Para ello SAFe propone dos puntos de coordinación que recuerdan a una clásica estructura top-down:

• El primero está en el Solution Train Management Review and Problem-Solving, que ocurre entre el día 1 y el 2 de las PI Planning individuales de los trenes. En este evento se habla de dependencias identificadas en las PI Plannings y se les envía instrucciones especificas a cada tren para el segundo día.
• Y en la POST PI Planning, donde los RTE después de colocar la información de su tren en el Solution Planning Board, discuten las dependencias con otros trenes o proveedores y sacan ajustes necesarios que después comunican a los trenes.

Otro indicador de la imposibilidad de autoorganización es la imposibilidad de conocimiento tácito colectivo común a todos los trenes. Para ello SAFe nos propone el Solution Intent, una fuente virtual única de conocimiento que recoge todo aquello que forma parte del Solution Train.

Solution Intent es un repositorio para almacenar, administrar y comunicar el conocimiento del comportamiento actual y previsto de la solución. Cuando sea necesario incluye especificaciones y diseños fijos y variables, referencia a estándares aplicables, modelos de sistemas y pruebas funcionales y no funcionales y trazabilidad e información sobre individuos, equipos y trenes.

Bien, probablemente haya una zona gris en el marco, probablemente se escale igual de mal aplicando cualquier marco o práctica, mi opinión es que de lo que se trata de ayudar compañías a ser más eficientes con personas motivadas desarrollando su trabajo en un entorno adecuado. Ese precisamente es el objetivo de Agile y Lean, y SAFe es un excelente punto de partida para las compañías clásicas que quieran encaminarse en esa dirección. Dependerá de la mentalidad de los coaches ágiles, líderes y agentes del cambio si una implementación de SAFe concreta está más o menos alineada con Agile y Lean, dependerá de si en su ADN fluye "personas sobre procesos".

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

¿Cómo hacer una reunión diaria que no se base en las tres preguntas?

Mapa de habilidades del equipo - thanks Alexandre

Originalmente la reunión diaria se basaba en que cada miembro del equipo de desarrollo contestara a las tres preguntas recogidas en la Scrum Guide, produciéndose así la coordinación y autoorganización del equipo:

• ¿Qué hice ayer que ayudó al equipo de desarrollo a lograr el objetivo del sprint?
• ¿Qué haré hoy para ayudar al equipo de desarrollo a lograr el objetivo del sprint?
• ¿Veo algún impedimento que evite que el equipo de desarrollo o yo logremos el objetivo del sprint?

La revisión de 2017 de la Scrum Guide introduce la siguiente revisión: "El equipo de desarrollo es el encargado de establecer la estructura de la reunión diaria y esta se puede conducir de diferentes maneras si se enfoca en el progreso hacia el objetivo del sprint. Algunos equipos de desarrollo usarán preguntas, algunos se basarán más en discusiones".

Por tanto la reunión diaria ya no está atada a las tres preguntas clásicas, y en este post quiero exponer una variante que da buenos resultados potenciado la autonomía de los equipos.

Primero cada miembro del equipo mueve sus tareas hechas a la columna done y luego comenta los problemas e impedimentos que crea tenga sentido exponer. La variante principal consiste en que después el Scrum Master coge tarea a tarea, guiado por la priorización de las historias de usuario con las que estén relacionadas, y pregunta al equipo: ¿quien es el más adecuado para esta tarea?

En este punto es donde el equipo entra en conversación y decide de forma colaborativa quien es la personas ideal, o personas ideales, para acometer esa tarea. Es buena idea elaborar y apoyarse en un mapa de habilidades del equipo, como el de la imagen del post.

• En vertical enumeramos las especialidades existentes en el equipo multifuncional y necesarias para construir historias de usuario de principio a fin.
• En horizontal enumeramos los miembros del equipo.
• Finalmente representamos con lineas gordas, finas, discontinuas y ausencia de las mismas la profundidad de la habilidad de cada miembro.

Es recomendable que el Scrum Master impulse a los equipos a cambiar la estructura de la reunión diaria de tanto en tanto, la variedad mantiene a los equipos más motivados y refuerza el compromiso de sus miembros.

¿Cómo gestionar una cartera de proyectos de forma Lean-Agile?

La gestión Lean-Agile de proyectos pasa por una pila de producto
única que aúna las todas las funcionalidades por valor de negocio

La Agilidad pone el foco en productos, en flujos de valor, y en las realidades de muchas compañías que están en plena transformación siguen inmersas en la gestión de proyectos. Aunque objetivo y ciclo de vida de productos y proyectos son distintos, podemos aplicar Agilidad a menor potencia a nuestros proyectos ágiles. Con ágiles entendemos proyectos guiados por valor de negocio y con incorporación natural de cierto grado de cambios en su evolución.

En un ambiente clásico nos basamos en montar líneas de tiempo (planificaciones) atadas a un alcance inicial para dotar las líneas de tiempo de los recursos para cumplir con cada una de ellas, sin tener en cuenta capacidades ni dependencias subyacentes. Constituimos el equipo del proyecto, eso quiere decir que con cada proyecto buscamos a las personas adecuadas de diferentes especialidades y de diferentes centros de coste, y formamos un solo equipo supuestamente ideal para el proyecto. Trae la gente al trabajo, por lo que la dotación de recursos a la linea de tiempo no deja de ser un deseo. Ni todos están disponibles cuando lo requiera el proyecto, ni sabemos como ese grupo de personas recién formado va a resultar como equipo integrado.

Características no deseadas de la gestión clásica:

• Planificación y ejecución basadas en utilización y disponibilidad de las personas
• Fuerte resistencia a cambios de alcance
• Sobrecarga y fricción: Baja velocidad de construcción
• Equipos sin continuidad
• Mueve la gente al trabajo

Una buena solución para hacer una gestión Lean-Agile de proyectos trata de desacoplar los proyectos de los equipos. La idea es aunar las funcionalidades de todos los proyectos en una única pila de producto, y alimentar las pilas de los equipos concretos desde esta. Esta forma de hacerlo permite tener equipos con continuidad que conserven el conocimiento tácito adquirido a lo largo de los años y la integración en equipo de alto rendimiento de sus miembros.

La idea es tener equipos funcionando con una velocidad conocida e inyectarles trabajo de forma balanceada a su capacidad con funcionalidades de diferentes proyectos, según tenga sentido.

Recordemos que la gestión ágil se basa en medir la capacidad de flujo de los sistemas y sus equipos de personas existentes, ajustar el trabajo a la capacidad y poner el foco en mejorar el flujo de forma continua, alineando, sincronizando y teniendo en cuenta las dependencias. Trae el trabajo a la gente.

Características deseadas que aporta la gestión ágil a través de una pila única:

• Planificación y ejecución basadas en valor de negocio
• Absorción del cambio como ventaja competitiva
• Ajusta el trabajo a la capacidad
• Equipos con continuidad
• Mueve el trabajo a la gente

¿Hay algo más allá de la Agilidad?

Rubén, Scrum Master y amigo, me pasó la imagen de la izquierda que representa un chiste sobre SAFe poniendo en duda de si es Agile. Este me hizo pensar en el futuro; ¿seremos Agile en el futuro?

Ya hoy en día muchas empresas de los países nórdicos de Europa, países como Suecia y Holanda, han integrado Agile en su cultura y forma de trabajar. Algunas ya piensan en evolucionar más allá los valores y principios del Manifiesto Ágil.

En su libro "Reinventar las Organizaciones", Frederic Laloux, nos habla de un nuevo paradigma cultural más allá de Agile, las empresas Teal, que son las mejor adaptadas al nuevo contexto social y económico.

Este paradigma pone el foco en desarrollar al máximo el potencial humano de los empleados de una empresa, entendiendo a la organización empresarial como un organismo viviente que está en continua evolución y desarrollo.

Las organizaciones Teal se constituyen según tres principios esenciales:

Autogestión

La cultura Agile aporta empoderamiento, pero el empoderamiento implica que un gestor de rango superior delega parte de su poder, mientras que para Teal la autoridad no forma parte de un sistema de suma cero. En las estructuras de las organizaciones Teal no hay miembros con poder de decisión y miembros ejecutores. Por naturaleza, y no por delegación, todos tienen poder de decisión y la estructura de la organización incluye procesos holocráticos para la regulación del flujo de información y decisiones.

Plenitud

En las organizaciones las personas se suelen mostrar con una máscara profesional adecuada a las expectativas de su función y lugar de trabajo: abogado, médico, ingeniero, mecánico, oficinista, director, etc. En las organizaciones Teal no hay ascensos por los que pelear, jefes a los que contentar y las personas se muestran de forma plena, siendo ellos mismos. Son organizaciones que invierten mucho tiempo en la selección de personal, informando a los candidatos de los valores y formas de trabajo para que puedan decidir si quieren ser parte de la organización o no.

Propósito evolutivo

Para las organizaciones Teal, el beneficio es un subproducto de un trabajo bien hecho. La finalidad de la organización no es el valor para los accionistas ni maximizar las ganancias, sino su propósito evolutivo: ¿Cuál es la identidad de la organización? ¿Y qué es lo que desea? No para qué queremos usar la organización en tanto que propietarios, sino más bien ¿cuál es el potencial creativo de la empresa vista como un sistema viviente?

Principales características de las organizaciones, según su paradigma cultural - cortesía de Scrum Manager / Scrum Level

Por tanto el futuro probablemente no sea Agile. Podría aventurarme a sugerir que los marcos ágiles, como Scrum y SAFe no son más que sentido común codificado para que empresas tradicionales mejoren sus formas de trabajar y adopten una mentalidad ágil. Tanto Scrum como SAFe podemos verlos como buques rompehielos, que si son bien aplicados, rompen a las culturas tradicionales para darles la oportunidad para que en estas emerja la Agilidad.

El nuevo paradigma Teal ya está en gestación, ya podemos encontrar algunas organizaciones en Europa:

• Buurtzorg en Holanda: Atención de enfermería domiciliaria de alta calidad y bajo costo.
• Evangelische Schule Berlin en Alemania: Un Instituto.
• Heiligenfeld en Alemania: Un hospital se salud mental.
• Favi en Francia: una fundición de latón dentro de la industria automotriz

¿Cual es la transición del comportamiento hacia un coach ágil?

De dirigir... - cortesía de Pixabay

Aquellos que provenientes de cargos tradicionales quieran incorporarse al rol de coach ágil deben de cambiar sus comportamientos de jefes o consultores a comportamientos de coach. En primer lugar han de alinearse con la primera directiva de Kerth y creer firmemente en ella:

Independientemente de lo que sabemos ahora,

creo firmemente que todo el mundo ha hecho el trabajo lo mejor que podía, teniendo en cuenta lo que sabía en ese momento, con sus habilidades y capacidades,

los recursos que tenía disponibles en ese instante

y adaptándose a la situación en cuestión.

... a guiar - cortesía de Pixabay

A partir de ahí los principales cambios de comportamiento necesarios se pueden resumir en la siguiente tabla que nos puede servir de guía:

• De coordinar contribuciones individuales a hacer coaching del equipo completo para potenciar su colaboración.
• De actuar como experto a ser un facilitador.
• De conducir hacía un objetivo específico a estar muy involucrado en el desempeño general del equipo.
• De dirigir a guiar y permitir que el equipo encuentre su propio camino.
• De saber la respuesta a preguntar al equipo por la respuesta.
• De hablar sobre deadlines y opciones técnicas a poner el foco en la entrega de valor de negocio.
• De dirigir en lo correcto a base de decisiones propias a hacer lo correcto para el negocio en ese mismo momento.
• De arreglar problemas antes que ayudar a otros a resolverlos a facilitar talleres de resolución de problemas con los equipos.

¿Cuál es un buen nivel de "cumplimiento" de un sprint?

En Estados Unidos, en Europa en los países nórdicos, en Inglaterra, y en otros países del mundo, las entrevistas de trabajo se focalizan en el mayor fracaso que haya podido tener el candidato. Haber superado un fracaso significa necesariamente haber aprendido y por tanto tener experiencia real; hacer las cosas bien probablemente no signifique más que eso, haberlo hecho bien sin haber arriesgado nada y sin haber hecho nada excepcional.

En España en las empresas tradicionales celebramos el haber llegado al 100% del trabajo marcado; con mentalidad ágil y pensando en resultados y beneficios para nuestros clientes, lo que queremos es ir mucho más allá del 100%, y lo queremos hacer con menor esfuerzo y poniendo toda nuestra energía en lo que tiene valor y a través ciclos de mejora continua.

Antes que nada recordemos que cuando hablamos de nivel de cumplimiento en Agilidad hablamos de cumplir con el objetivo del sprint, no con las historias de usuario de la pila de sprint.

Cuando los equipos en planificación definen su objetivo del sprint generan un sentimiento de compromiso en base a un reto excitante, que les guíe e inspire a llegar mucho allá y les haga hacer cosas excepcionales.

Bajo esta perspectiva un buen nivel de cumplimiento está alrededor de un 60% a un 80% de los objetivos marcados, y esto ocurre con el objetivo del sprint y en los objetivos trimestrales, como son los OKR en un ambiente de escalado.

Si nuestro foco es cumplir al 100% no vemos las grandes ideas

Equipos que llegan a sus objetivos y OKRs al 100% significa que no ven lo que ocurre a su alrededor, están ciegos a las buenas ideas, por tanto sus objetivos son mediocres y no son lo suficientemente retantes!!! Si nos basamos en OKRs retantes que cumplimos al 60-80% ocurrirá que los equipos harán cosas excepcionales y ocurran la innovación y la mejora continua, y recordemos que para ser competitivos hoy en día necesitamos adaptarnos e innovar continuamente.

Esto ocurre en empresas cuya gerencia proporciona un objetivo general y una dirección estratégica a través de una visión sólida, con un mínimo de planes específicos de trabajo o proyecto, con requisitos desafiantes y un alto grado de libertad en cuanto a cómo los equipos cumplen con los requisitos.

Empresas con equipos que cumplen al 100% simplemente hacen cosas mediocres, y equipos que están al 120%, hay jefes que se vanaglorian de ello, significa que esos jefes no saben lo que hace su gente, y que sus equipos simplemente están sumidos en un salto de mata constante.

¿Hay alguna dinámica que muestre la importancia de la holgura o aire en los sprints?

Vaso al 80%, se transporta bien

Una de las cosas más complicadas de transmitir es la necesidad de holgura o aire en la carga de trabajo, también conocida como slack time, que consiste en no cargar nunca un sprint al 100% y entender que una productividad del 80% es una productividad muy alta.

Cuando hablo del tema salen argumentos como que es mejor que los equipos tengan trabajo a mano por si acaso se quedan sin... trabajo que al final hace ruido y todo el mundo espera que también se entregue. Son argumentos cargados por nuestra cultura tradicional en la que la cantidad de trabajo entregado, y no el valor entregado, importa.

Vaso al 100%, al transportarlo
se derrama el agua y hay que
limpiar (retrabajo)

Recuerdo un candidato a coach ágil que me decía que no "creía" en la iteración IP que marca el marco de SAFe, una iteración cuyo nombre deriva de "Innovation & Planning" que no se planifica y que permite que la cadencia de entrega de valor sea posible... lo gracioso es que cuestionaba las lecciones del marco de SAFe del que pretendía certificarse.

He trabajado con equipos utilizando esa holgura o aire, y otros sin, siempre veo el mismo patrón; los que no tienen holgura no consiguen encontrar un ritmo de entrega sostenible, cada fin de sprint es como una pequeña crisis de fin de proyecto.

Eelco Rustenburg, un gran trainer, hace una dinámica muy simple, y que puede entender todo el mundo, con la que muestra la importancia de no cargar al 100% los sprints. Consiste en dos partes:

1. Transportar un vaso lleno de agua al 80% de un extremo de la clase al otro extremo
2. Y después transportar un vaso completamente lleno

Hasta podríamos experimentar la dinámica de forma mental, todos hemos transportado con nuestras manos vasos con agua u otra bebida. Un vaso al 80% se transporta rápido y sin derramar, un vaso al 100% se transporta lento y con mucho cuidado, y siempre hay un accidente en el camino y se produce un derrame. Desde el punto de vista del flujo es mucho mejor llenar vasos (sprints) al 80% y que haya un buen ritmo, que avanzar tortuosamente con vasos (sprints) completamente llenos. Con un vaso al 100% además se produce retrabajo; hay que sacar la bayeta y limpiar las gotas de agua derramada... quizá así podamos entender lo caro que sale ese 20%. Los tiempos medios que hemos experimentado son 36 segundos con un vaso al 100% versus 8 segundos con un vaso al 80%!!!