¿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.

¿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 :-)

¿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.

¿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.

¿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:

• ¿Qué hizo mi equipo de desarrollo desde la última reunión para lograr su objetivo del sprint?
• ¿Qué hará mi equipo de desarrollo antes de la siguiente reunión para lograr su objetivo del sprint?
• ¿Hay algún impedimento que esté afectando negativamente a mi equipo de desarrollo y que impacte en el objetivo del sprint?
• ¿Hay algo de mi equipo de desarrollo que se pueda interponer o afectar al objetivo del sprint de los demás equipos?

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.

¿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

¿Cuál es el talón de Aquiles de SAFe®?

Tuve una conversación con Marcos Garrido que no me dejó impasible. Ya sabéis que creo en SAFe® y me gusta, creo que es un marco Agile y Lean hasta la médula, pero Marcos fue capaz de arrojar una nueva luz a mis principios.

Si lo miramos con detenimiento Scrum trata de simplificar la complejidad, una empresa es Agile cuando ha simplificado sus estructuras organizativas y funciona de forma plana y fractal.

En cambio SAFe es un marco complejo que trae complejidad, por tanto no pone el foco en la simplicidad como lo hace Scrum. Recordemos el décimo principio del Manifiesto Ágil:

La simplicidad, o el arte de maximizar la cantidad de trabajo no realizado, es esencial.

SAFe sustituye la complejidad organizacional y jerárquica de una compañía por una complejidad Agile y Lean, pero no simplifica, y si no simplifica ¿no va a atar a la empresa a SAFe y a su complejidad? Esto hace cuestionarnos si la empresa que implante este marco pueda tener la oportunidad de ser Agile puro, y si esta va a tener la oportunidad en el futuro de ir más allá de SAFe. Con SAFe lo que puede ocurrir es que se mantenga atascada en un nivel de complejidad similar al de antes de la transformación...

En mi realidad las empresas que pueden ser Agile ya lo son, ahora estamos lidiando con empresas que nunca serán Agile de verdad, grandes compañías y consultoras con cientos de empleados que difícilmente pueden apostar por la persona y empoderarla en su talento. Vender Agile puro a estas empresas es difícil, SAFe tiene un big picture suficientemente complejo o "feo" para que estas empresas se interesen y haya posibilidades de implantarlo. SAFe es un punto de partida que puede funcionar para acercar la compañía a Agile, ¿pero permitirá a la empresa ser Agile de verdad?

Probablemente si, pienso que SAFe ayudará a muchas empresas, pero también alargará la letanía de aquellas empresas que no son conscientes de la nueva realidad del mundo VUCA, un mundo inmerso en la turbulencia del cambio. Las que sobrevivan serán Agile de verdad, e incluso Teal, pero las que no están condenadas a desaparecer sin compasión.

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

¿Hay algún ejercicio que haga vivir a los asistentes como funciona la mejora continua?

Este es un ejercicio del curso CSM de

Marcos facilitando el ejercicio

Estuve de co-trainer con Marcos Garrido en uno de sus cursos de Scrum, dónde para mostrar la potencia de la mejora continua facilitó un ejercicio de construcción de aviones de papel con tres sprints.

Instrucciones de como doblar una
hoja A4 para construir aviones
Cortesía de Ysangkok

Con tres sprints hay suficientes oportunidades de mejora significativas que los asistentes puedan vivir de primera mano, especialmente porque a lo largo de las iteraciones las personas se van conociendo en su manera de trabajar y convergen para formar equipo.

El objetivo trata en primer término de construir aviones de papel que tengan suficiente calidad para volar durante 2 segundos en linea recta, y en segundo término construir tantos aviones como sea posible.

La regla más importante es que una persona solo puede hacer un doblamiento, y después de hacerlo debe de pasar el avión a otra persona.

Los tiempos del juego son:

Tres minutos de sprint para la construcción de aviones

• 2 minutos para la planificación de sprint en la que el equipo debe de determinar la carga en número de aviones que cree que puede construir.
• 3 minutos de sprint para construir los aviones, el sprint incluye al tester que probará los aviones y los clasificará como OK si vuelan en linea recta durante 2 segundos, y como KO si no lo hacen.
• Durante la revisión de sprint el trainer recoge los resultados de los aviones OK y KO en un tablero.
• Antes del siguiente sprint el equipo dedica 3 minutos a una retrospectiva durante los que el equipo busca posibles mejoras para el siguiente sprint, con el objetivo primario de reducir a 0 los aviones KO.

Equipo en pleno doblaje de aviones

Marcos hizo la primera retrospectiva con el equipo y luego inició la planificación del segundo sprint. La segunda retrospectiva la hizo seguida de un Scrum de Scrums con un representante de cada equipo para así compartir experiencias entre equipos.

Tablero con los resultados

Como podemos observar en los resultados por equipos del tablero a la derecha, la mejoras obtenidas a lo largo de los sprints se hacen muy visibles. No es tan relevante como se ha ido incrementado el número de aviones OK, sino como han decrementado los aviones KO.

Todos los equipos excepto el B han incrementado los aviones OK, pero cabe destacar que ese equipo ha conseguido cero aviones KO en el tercer sprint, lo que constituye un éxito de la mejora continua.

Resaltar que el equipo A introdujo un cambio de diseño del avión en el tercer sprint y eso ha redundado en un mayor número de aviones KO, hubieron de aprender de nuevo.

Un mejora que nos llamó la atención fue la del equipo C, ellos se dieron cuenta que la regla de pasar a otra persona permite hacer pairing contruyendo los aviones entre dos, pasándoselo de uno a otro. La idea genial fue que hicieron pares juntando personas con la misma velocidad.

Mis agradecimientos a todos los alumnos que participaron en el ejercicio, se puede ver como quedó la clase :-D

¿Cómo compartir conocimiento y experiencia a lo largo de toda la compañía?

Es deseable que en grandes compañía se compartan dentro de una misma disciplina formas de trabajar, técnicas y herramientas a lo largo de toda la organización. El modelo Spotify le pone el nombre de guild, o gremio, a grupos de personas de toda la organización que desean compartir conocimientos, herramientas, códigos y prácticas y se juntan para tratar sobre ello.

Gremios (guilds) como comunidades de práctica que cruzan las tribus de la organización - Henrik Kniberg & Anders Ivarsson

Un gremio es una comunidad de práctica, semejante a los chapters, pero a diferencia de estos últimos que son locales dentro de una tribu, los gremios son transversales a toda la organización.

La comunidad de práctica es una estructura social dentro de la propia organización que está formada por profesionales de la propia compañía que comparten un interés específico. Su objetivos son:

• Explicitar la transferencia de conocimiento permitiendo que la organización adquiera y refine el conocimiento a través de experiencias y problemas dentro del mismo grupo.
• Ampliar conocimientos mediante un proceso continuo y voluntario a través de estrategias de colaboración, liderazgo, captura y aprovechamiento del conocimiento en la disciplina.

Cada gremio tiene un coordinador del gremio que organiza y facilita los eventos, espacios y necesidades. Aunque los gremios son especializados, cualquier miembro de cualquier squad de cualquier tribu puede unirse a cualquier gremio en que esté interesado.

El autor con el tablero del gremio de Scrum Masters y
coaches ágiles que ha adoptado el nombre de AgileGo

Un gremio a menudo incluye todos los chapters y sus miembros que trabajan en esa disciplina, por ejemplo, el gremio de testing incluye a todos los testers de todos los chapters de testing.

Otro ejemplo es el gremio de coaches ágiles. Los coaches ágiles están repartidos por toda la organización, pero a través del gremio comparten conocimiento de forma continua y se reúnen regularmente para alinearse y colaborar en la mejora organizativa a alto nivel.

Los gremios no son fáciles de implementar, requieren un espacio físico que ha de proporcionar la compañía, algo de tiempo y motivación del grupo, y también requieren cierto grado de coordinación. Más de una vez he observado mucho empuje en la inciativa inicial al establecerse un gremio, empuje que al poco se desvanece por falta de motivación y sentido de utilidad. Aconsejaría comenzar en pequeño, identificar un problema o algo que pueda mejorarse y reunir a un pequeño grupo para tratarlo. En cualquier grupo suele haber un líder natural que le guste meterse en este tipo de berenjenales, dejar que emerja y darle empoderamiento para ser el coordinador del gremio. A que no adivináis quien va a ser el líder para la próxima sesión de AgileGo, jajajaja :-P