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/

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 de 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 ScrumsNo 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

domingo, 10 de diciembre de 2017

¿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 no, pienso que SAFe alargará la letanía de las 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.

sábado, 9 de diciembre de 2017

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

viernes, 8 de diciembre de 2017

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

miércoles, 6 de diciembre de 2017

¿Cómo hacer una retrospectiva distribuida con equipos deslocalizados?


Una retrospectiva distribuida es una retrospectiva en la que los miembros de los equipos están en más de una localización, por ejemplo, desde diferentes ciudades en España a diferentes países de todo el mundo. Hoy en día ocurre en muchas empresas: trabajan en un mismo producto con equipos en países tan diversos como Estados Unidos, Inglaterra, India, China… y en este post pretendemos dar algunas herramientas de cómo poder realizar este tipo de retrospectiva.

Como caso práctico para experimentar una retrospectiva distribuida Gema Ruíz-Díaz Mariblanca y João Barreiro organizaron el #Bye2BAOS, un taller práctico de retrospectiva distribuida como cierre del conjunto de eventos organizados en el #ROAD2BAOS con un doble propósito: aprender sobre retrospectivas distribuidas a través de la experimentación directa y hacer la retrospectiva del BAOS 2017.

El lugar

Para simular equipos deslocalizados fue necesario un espacio grande donde los equipos no pudieran ni verse ni escucharse. El sitio elegido fue el Matadero de Madrid, específicamente el Café Teatro, un lugar superculturoso con un entorno propicio para el arte, la inspiración, la innovación y la creatividad.
El Matadero Madrid y el Café Teatro
Los equipos

Después de una breve introducción al taller y a las retrospectivas distribuidas, nos dividimos en tres equipos, cada uno de ellos con un facilitador: el equipo Glaciar con Gema de facilitadora, el equipo CoraBAOS con João de facilitador y el equipo CoffeePanda con Elvira de facilitadora. Cada equipo se ubicó en espacios distintos en la cafetería del Matadero. Originalmente la idea era que estuviéramos distribuidos en distintas salas, pero por problemas de conectividad no se pudo.
Equipo "CoraBAOS" Equipo "Glaciar" Equipo "CoffeePanda"
Las herramientas

Para hacer una retrospectiva distribuida se necesitan dos clases de herramientas, una de videoconferencia que permita vernos las caras y escuchar nuestras palabras entre todos los equipos y un tablero virtual compartido donde reflejar los post-its de la retrospectiva.

Para el taller usamos las siguientes herramientas libres:






appear.in es una herramienta de colaboración por vídeo que permite tener conversaciones de vídeo sin esfuerzo con hasta 8 personas/equipos simultáneamente.

La versión premium admite hasta 12 personas/equipos. Se puede crear una sala sin necesidad de registrarse y también permite registrarse para comprar y personalizar enlaces propios de sala de vídeo.

appear.in funciona en casi cualquier dispositivo e incluso le permite compartir la pantalla para mostrar presentaciones, fotos u hojas de cálculo.



Fun Retro proporciona de un tablero virtual para recopilar datos, hablar sobre las cosas positivas, reconocer a las personas y buscar mejoras. Permite hacer visible la retrospectiva para todos los participantes, seleccionar una actividad y crear y personalizar el tablero. ¡A por ello!

El taller

El objetivo principal de la retrospectiva distribuida fue obtener feedback sobre el BAOS 2017 y generar ideas para hacer un gran BAOS 2018, en particular:
  • Definir cuál es la identidad percibida del BAOS
  • Saber si el BAOS 2017 fue un éxito, un fracaso o un evento más, y por qué
  • Conocer cuáles fueron las cosas buenas y las cosas a mejorar del BAOS 2017 y
  • Generar ideas para construir una gran BAOS 2018
Una vez que nos distribuimos en equipos, comenzamos el taller con una actividad para romper el hielo dentro de cada equipo y luego entre los equipos. Esta actividad es fundamental en cualquier retrospectiva distribuida, ya que fomenta la confianza y la participación de todos. En este caso, y para romper el hielo, cada persona dijo su nombre y cuál era el libro que estaba leyendo actualmente. 

En esta actividad pudimos vivir una de las cosas que pueden pasar en las retrospectivas distribuidas: los fallos tecnológicos y de comunicación, aprendimos que siempre hay que tener un plan B y hasta un plan C para aumentar al máximo las probabilidades de poder seguir adelante con la retrospectiva hasta el final. En el taller tuvimos problemas técnicos, la herramienta de videoconferencia no funcionó en todos los equipos, así que optamos por el plan B de hacer partícipe al equipo afectado por teléfono :). La llamada telefónica tiene sus limitaciones, no ver con quien conversas y el ruido ambiental exterior dificultó oír y entender lo que decían los demás equipos

Luego cada equipo eligió un nombre. Primero generamos palabras por parejas y luego las combinamos creando una nueva a partir de la asociación de las palabras raíz. De aquí surgieron los equipos Glaciar, CoreBAOS y CoffeePanda. Luego estos nombres de equipo se usaron para poder identificar los post-its de cada equipo en el tablero de la retrospectiva.

Finalmente pasamos a hacer la retrospectiva en individual por equipo, generando ideas para cada una de las preguntas a responder. Cada equipo iba poniendo las ideas en el tablero virtual creado en Fun Retro, todas ellas estuvieron identificadas por el nombre del equipo. El tablero virtual fue poblándose dinámicamente a medida que avanzábamos en la retrospectiva, así pudimos ir viendo en tiempo real las aportaciones de todos, con posibilidad de complementarlas y/o unir propuestas similares.
Tablero virtual Fun Retro de la retrospectiva poblándose a medida que avanza el taller
Una vez que cada equipo terminó de generar ideas y dar feedback a las preguntas, procedimos a votar distribuyendo 3 puntos por persona por cada columna de la retrospectiva.
Pantallazo del tablero virtual Fun Retro una vez finalizada la retrospectiva distribuida
Actividad final de conclusiones

Para finalizar el taller hicimos algo muy enriquecedor: nos reunimos todos los equipos y compartimos lo que nos había parecido la experiencia, los aprendizajes alcanzados, los consejos y anécdotas de retrospectivas distribuidas vividas por varios participantes, incluyendo cuando participan equipos deslocalizados en varios países y João hizo una síntesis de lo que hay que tener en cuenta para hacer retrospectivas distribuidas. De esta actividad final los aspectos y/o conclusiones más importantes que surgieron fueron:
  • Por lo general, en las retrospectivas distribuidas lograr una comunicación efectiva y de calidad es muy difícil. Quizás es porque nos estamos basando en cómo se hacen las presenciales. Sería bueno pensar en cómo hacer retrospectivas distribuidas sin tener como base las presenciales, sino definir un diseño propio tomando en cuenta las particularidades y las dificultades que poseen.
  • Es muy importante hacer actividades de engagement antes de comenzar las retrospectivas distribuidas, para aumentar el conocimiento personal de los miembros de los equipos y de sus particularidades culturales.
  • Es bueno que los miembros del equipo se conozcan presencialmente en algún momento, y si es posible compartan tanto dentro como fuera del ámbito laboral, para crear conexiones personales más fuertes y un mayor nivel de confianza.
  • Es muy importante tener un facilitador de la retrospectiva en cada uno de los sitios que intervengan, y que estén coordinados entre sí.
  • Es importante tratar de unificar los comportamientos de los equipos en cada uno de los sitios.
  • Muchas veces hay problemas de horarios, sobre todo cuando hay equipos en distintos países. Hay que llegar a acuerdos, porque por lo general algún equipo se ha de sacrificar ya que tendrá que participar fuera de su horario laboral. Una idea es que se rote este "sacrificio" para que no sea siempre el mismo equipo el afectado.
  • Otro problema al trabajar con equipos de varios países, es que al hablar en un idioma que no es el nativo, se limita la capacidad de expresión, así como el uso de expresiones locales o modismos que no son entendidos por todos los miembros del equipo amplio. Por eso es bueno hacer una labor de concienciación con respecto a la manera de comunicarnos en las retrospectivas distribuidas.
  • Un tema de vital importancia son las diferencias culturales entre equipos de distintos países y culturas, diferencias que pueden llevar a problemas y malentendidos. Una buena práctica para mejorar este aspecto es la realización de actividades de engagement cultural, donde se tenga un tiempo para compartir aspectos específicos de cada uno de los países que participan y de su cultura. 
  • Para realizar retrospectivas distribuidas hay que tener infraestructura tecnológica, necesaria para que funcionen.
  • La tecnología puede fallar por lo que siempre hay que tener un plan B y hasta un plan C.
  • Tener una agenda definida previamente y compartida antes de hacer la retrospectiva.
  • Tener el objetivo de cada dinámica visible en todo momento.
  • Usar cámaras permanentes.
  • Se tarda más en prepararlas y son mucho más complicadas que las retrospectivas presenciales, por lo que es bueno tener un coordinador/facilitador en cada sitio y trabajar de manera conjunta.
  • Hay que manejar el solapamiento de conversaciones, los ruidos ambientales y la concentración y la participación en la retrospectiva. Por esto también es bueno tener un facilitador local.
  • Otras herramientas que se pueden usar en retrospectivas distribuidas:
Y como conclusión general podemos decir que fue una experiencia inmensamente enriquecedora al poder vivenciar lo que es una retrospectiva distribuida, las cosas que pueden pasar, cómo solucionarlas y el poder compartir nuestras experiencias y aprendizajes. Muchas gracias a los organizadores, facilitadores y a todos los que participamos :)
Nuestros agradecimientos a todos los participantes del taller
Post escrito conjuntamente con Gertrudis López, link al post en su blog "Agile: lo bueno, lo feo y lo malo