sábado, 16 de noviembre de 2019

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

miércoles, 6 de noviembre de 2019

¿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ñen de factibilidad y llevan 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 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.

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.

martes, 22 de octubre de 2019

¿Qué dinámica utilizar para establecer los valores de un equipo o tribu?

Para que un árbol florezca
necesita buenas raíces (valores)
Cortesía de Pixabay
Aunque los equipos ágiles tengan interiorizados los valores de Scrum y las tribus o ARTs los valores de escalado o SAFe®, es importante ser conscientes de los valores que el grupo considera importantes y crear alineamiento entre y con ellos. No olvidemos que los valores son los fundamentos que guían la conducta para llevar a equipos y empresas a nuevas formas de trabajar con mejores resultados de negocio, entre ellas a la Agilidad.

En este post quiero presentar la dinámica de los valores guía que lleva a obtener acuerdos que los miembros de los equipos consideren necesarios para trabajar en equipo y fortalecer la cohesión, consensuando los valores principales y su significado.

La dinámica la ha de facilitar un Scrum Master, un coach ágil o una persona con habilidades de facilitador. En un primer paso se obtienen los valores individuales miembro a miembro, un valor por post-it, para luego consolidarlos todos en un único tablero. Para inspirarnos podemos mostrar valores principales como los de la lista que sigue:
  • Alegría: ilusión, jovialidad, buen humor
  • Alineamiento: para mantener el ritmo y un objetivo único del equipo o de la tribu
  • Ambición: trabajar fuerte, aspiraciones
  • Autonomía: libertad, autogestión, autoorganización, autodisciplina, independencia
  • Calidad: excelencia en el trabajo
  • Colaboración: creamos estructuras y utilizamos métricas para que los personas tengan interés individual en colaborar
  • Compromiso: sentirnos comprometidos con el trabajo
  • Confianza: crear un ambiente de confianza y creer que las personas hacen lo mejor que pueden dadas sus circunstancias
  • Coraje: aceptar retos juntos, defender ideas, decir que "no"
  • Cortesía: ser atentos, educados
  • Foco: trabajar en el mínimo número de cosas posible a la vez
  • Franqueza: manifestamos preocupaciones, expresamos lo que pensamos o sentimos con sinceridad y claridad
  • Honestidad: decente, decoroso, razonable, justo, probo, recto, honrado
  • Humildad: tenemos conocimiento de las propias limitaciones y debilidades, mostramos vulnerabilidad
  • Inspiración: sugerir ideas creadoras, suscitar sentimientos
  • Limpieza: ser cuidadoso, ordenado
  • Obediencia: ser sumiso, respetuoso
  • Perdonar: dispuesto a perdonar y a reconocer errores
  • Prestigio: reputación, fama o logros
  • Propósito: el sentido que se otorga al equipotribu
  • Reflexión: pensar 2 veces antes de actuar
  • Respeto: respetar a cada uno como es y el trabajo de los demás
  • Responsabilidad: seriedad, ser fidedigno
  • Servicial: preocuparse por el bienestar de otros
  • Tolerancia: apertura de mente
  • Transparencia: visibilidad, honestidad, sinceridad, veracidad
Obtenida la lista de valores consolidados, cada miembro del equipo o tribu la ordena según la importancia que le otorga como guía principal en sus vidas, de mayor a menor. El orden ha de ser estricto, no puede haber dos valores en la misma posición.

Se forman grupos de cuatro o cinco personas para que debatan y discutan el orden de los valores y para que reordenen la lista de forma consensuada. Finalmente el equipo o la tribu al completo reordena de nuevo la lista, el resultado es el orden final de los valores guías según lo que piensa y siente el grupo.

Se cierra la dinámica con una reflexión discutiendo y acordando lo que cada valor significa en la práctica diaria, ejemplificando cómo se debe de actuar. Todo ello se plasma en post-its y un tablero, con la idea de revisar y acuatizar los valores periódicamente.
Tablero con el resultado de la dinámica en el que el foco está en los tres primeros valores

lunes, 7 de octubre de 2019

¿Existe algún juego para hacer team-building en silencio?

Caja juego "The Mind"
Uno de los juegos cooperativos que me encanta y podría jugar día tras día es "The Mind" de Wolfgang Warsch. Se trata de un juego de cartas en el que hay que colaborar para poder ganar, o ganamos todos o perdemos todos. Es una excelente actividad de team-building. Está compuesto por 120 cartas:
  • 100 cartas numeradas del 1 y el 100.
  • 12 cartas de Nivel: para visualizar el nivel del juego donde 12 es el más avanzado.
  • 5 cartas de Vida.
  • 3 cartas de Shuriken.
Las reglas del juego son muy sencillas; la idea es que el equipo ponga las cartas en orden ascendente en el centro de la mesa sin turnos ni orden de juego y en silencio absoluto.

Se empieza por el nivel 1 colocando la carta correspondiente en la mesa. Repartidas las cartas quien crea que tiene la carta más baja la coloca bocarriba en el centro de la mesa, de manera que se vea el número. El siguiente jugador que crea que tiene la siguiente carta más baja, la coloca encima y bocarriba.

Jugando "The Mind" en el AOC 2019
Dado que está prohibido hablar, gesticular o comunicarse de cualquier forma, los jugadores han de aprender a utilizar la mente colectiva para decidir si su carta es la siguiente más baja.

Si el equipo consigue colocar todas sus cartas en orden ascendente en el centro de la mesa ha superado el nivel. Pasan a la carta del siguiente nivel y hacen las rondas necesarias para superarlo.

Si el equipo coloca una carta en el orden incorrecto pierden una vida y vuelven a seguir jugando en el nivel actual. Las cartas de Vida permiten seguir jugando pese a haber cometido un error en el orden de las cartas.

En cualquier momento durante el juego un jugador puede levantar la mano para sugerir que se juegue una carta Shuriken. Si todos los jugadores aceptan jugar un Shuriken cada jugador descarta su carta más baja y el juego se reanuda.

El juego se basa en la mente colectiva
Los jugadores han de intuir en absoluto silencio el tiempo de los demás, y lo hacen a través del lenguaje corporal plasmado en ligeros movimientos, agitación física, relajación en señal de espera, etc. Este juego tan sencillo es una excelente actividad de team-buidling, aunque no podamos hablar, ni debatir ni ponernos de acuerdo de manera explícita es necesario el trabajo en equipo para conseguir alcanzar el objetivo común.
  • Permite conocer más a los miembros del equipo, las fortalezas y debilidades de cada uno
  • Establece conexiones entre estos, celebran los éxitos y lloran los fracasos juntos
  • Refuerza la empatía por los demás miembros
  • Crea complicidad y sentimiento de pertenencia al equipo
Es reconfortante como Scrum Master ver que con cada nivel superado el equipo se une más y más.

domingo, 6 de octubre de 2019

¿ServiceNow como herramienta para un ART?

Menú SAFe
Recientemente he tenido la oportunidad de poder probar el paquete de soluciones de ServiceNow preparado para SAFe®.

ServiceNow proporciona aplicaciones que admiten dos configuraciones diferentes de SAFe: Essential SAFe y Portfolio SAFe.

Pude probar la configuración de Portfolio que se obtiene instalando "Agile - Scaled Agile Framework - Portfolio SAFe plugin (com.snc.sdlc.portfolio_safe)". Una vez instalado aparece el menú que se puede ver en la imagen de la izquierda.

El plugin considera equipos y cadencia a dos niveles:
  • ART: que ejecuta Program Increments (PI)
  • Equipo: que ejecuta sprints (iterations)
La pila está integrada y preparada a tres niveles, lo que se denomina el unified backlog:
Ejemplos de pantallazos de los tres elementos de la pila
Cada uno de los tres niveles de la pila incluye priorización WSJF. La estructura entre niveles es jerárquica, hay relación de las features con el epic correspondiente por ejemplo, aunque permite features e historias de usuario independientes, huérfanas. Eso está bien ya que en la exploración continua a lo largo de la ejecución de las iteraciones aparecerán tanto historias de usuario como historias técnicas (enablers).

Desde la perspectiva formal de SAFe las pantallas y sus campos son completables, por ejemplo a nivel de epic faltan los leading indicators, los requisitos no funcionales y el patrón de escritura de un epic no se basa en el epic hypothesis statement o elevator pitch.
Pantallazo del tren y sus equipos
El flujo entre niveles de la pila no está automatizado, eso quiere decir que si por ejemplo terminamos todas las historias de usuario de una feature esta no queda terminada automáticamente. Eso está bien así, ambos elementos tiene una definición de hecho (DoD) específica y los grupos de interesados de un y otro elemento son distintos; las historias de usuario las terminan los equipos y las features las acepta Product Management para darlas como terminadas.

El tren se estructura a base de un grupo de equipos, la aplicación recoge toda la información desde las personas a os equipos y a los ARTs.
Ejemplos de tablero de equipo y portfolio
Hay tableros kanban a tres niveles:
Más un tablero específico para la PI Planning localizado en la pestaña "Planificación" que facilita una planificación detallada del próximo incremento del programa. Permite a los miembros del ART discutir las features del incremento del programa, desglosarlas en historias de usuario y planificar los sprints necesarios para completar el incremento del programa.
Tablero para la PI Planning con vista por historia y por feature
Los equipos colocan sus historias en su carril correspondiente y pueden establecer las dependencias resueltas entre historias, así como las dependencias resueltas entre features, y alternar entre la vista por historias o por features.

ServiceNow no está preparado para recoger los objetivos de los equipos ni los objetivos del PI.

En resumen es una aplicación que cubre las necesidades básicas de una implementación SAFe, tanto para una configuración Essential como Portfolio.

Lo que no me gusta:
  • A falta de objetivos del PI el elemento esencial para la flexibilidad no está presente. Recordemos que son los objetivos los que guían la ejecución y se buscan cumplir, no una colección de features o historias de usuario. Los objetivos se cumplen con más o menos, y con cambios en el camino, con mejores historias de usuario o features. La falta de objetivos son la carencia principal de la aplicación ya que sin estos no fomenta la Agilidad.
  • El tablero para la PI Planning es muy correcto desde la perspectiva del diseño y la solución, pero desde la perspectiva de usabilidad en acción, cuando 12 a 15 equipos actúen sobre el mismo a la vez, probablemente convierta en un cuello de botella.
Lo que me gusta:
  • Está basado en los términos y según los conceptos de SAFe.
  • Su usabilidad es intuitiva.

miércoles, 25 de septiembre de 2019

¿Cuáles son los valores de Scrum?

En la versión de 2016 la Scrum Guide incluyó 5 valores, entendemos como tales aquellas cosas en las que creemos y nos guían en nuestra forma de actuar. El propósito de los valores de Scrum es el proporcionar una brújula para la toma de decisiones y la dinámica del equipo. Estos ayudan a los equipos ganadores a adoptar Scrum y a entregar un software que deleite a sus clientes y crear un excelente lugar para trabajar.
Póster de los valores de Scrum de la Scrum.org
  • Foco: Nos centramos en trabajar en el mínimo número de cosas posible y evitamos distracciones de manera que consigamos entregar antes, trabajar mejor juntos y obtener resultados de mayor calidad.
  • Coraje: Dado que el equipo es uno y por tanto no afrontamos los retos y objetivos solos, podemos aceptar retos mayores confiando en poder alcanzarlo todos juntos.
  • Franqueza: Contamos de manera clara cómo avanzamos, los problemas que tenemos y manifestamos nuestras preocupaciones.
  • Compromiso: Nosotros somos los que controlamos la cantidad de trabajo que hacemos y cómo lo hacemos, por tanto nos comprometemos con el resultado esperado.
  • Respeto: Al trabajar juntos, compartiendo éxitos y fracasos, nos iremos conociendo y respetando cada uno como es, asumiendo que todos aportamos lo mejor de nosotros mismos en cada momento.
Scrum tiene unos principios o directrices que nos van a ayudar a interiorizar estos valores:
Ejemplo de como una compañía aplica los valores de Scrum
  • El producto tiene un objetivo definido, conocido y asumido por todos los miembros.
  • El criterio de priorización se realizará basado en las necesidades manifestadas por el cliente e indicará las funcionalidades inmediatas para avanzar hacia el objetivo.
  • No hay información oculta y en las decisiones se tienen en cuenta las consideraciones y aportaciones del todo el equipo.
  • Todos los miembros tienen la competencia profesional necesaria para aportar un trabajo valioso.
  • Todo el equipo tiene confianza real en el desempeño, valor y compromiso de los demás.
  • Cada persona tiene el margen de actuación y decisión necesario para su aportación al proyecto y es responsable de sus decisiones, acciones y omisiones.
  • El desarrollo se realiza con una cadencia de avance objetivo continuo y sostenible.
  • De forma periódica el equipo analiza su forma de trabajo y tomará 1 o 2 acciones de mejora concretas y medibles.
A continuación os presentamos algunas situaciones donde estos valores nos pueden guiar:

Situación Comportamiento siguiendo valores Anti-patrón Valores involucrados
Otros equipos nos piden ayuda frecuentemente Indicar dónde pueden encontrar la solución para que puedan ser autónomos en el futuro asistiéndoles sólo en momentos de especial dificultad.

Si fuera demasiado recurrente facilitarles el contacto de algún arquitecto del área de la compañía y educadamente indicar que necesitas focalizarte en el trabajo de tu equipo.
Ir cada vez a ayudarles dejando nuestro trabajo. Foco y compromiso
El Propietario del Producto quiere introducir nuevas funcionalidades al sprint Si está dentro del objetivo y él ve que es más relevante que lo que estamos haciendo aceptarlo indicando los riesgos posibles y si fuera necesario avisar que algo comprometido puede no acabarse.

Si fuera recurrente sacar el problema en la retrospectiva.
Aceptar siempre lo que el Propietario del Producto nos agregue.Compromiso, coraje y franqueza
El Propietario del Producto pide una funcionalidad que no parece posible realizar Se acepta el reto solicitando una ventana de tiempo para poder experimentar antes de decir que no se puede hacer. Indicar que no es posible hacer lo que pide. Coraje y compromiso
Un miembro del equipo parece distraído Le preguntas si le pasa algo a lo que te da las gracias por preocuparte pero que es algo personal.

Le dejas su espacio, hoy lo necesita.
Le recriminas que qué le pasa hoy y que así no va a salir el trabajo. Respeto

Post escrito conjuntamente con Rubén Álvarez, link al post en su blog "Aprendiendo Agile"

lunes, 23 de septiembre de 2019

¿Cuál es la diferencia entre velocidad, capacidad y carga en Scrum?

En mis clases a veces hay mucha confusión respecto a estos tres términos, especialmente con respecto a la velocidadVeamos qué hay detrás de cada uno de ellos:
Gráfico que muestra los tres términos y como están relacionados: velocidad, capacidad y carga
La velocidad solo debe de usarse para el equipo con fines de planificación, las métricas de éxito del equipo siempre deben de basarse en la entrega de valor, es decir en un incremento de trabajo del producto entregado al cliente. Cuando el sistema, todo lo que rodea al equipo, le permite encontrar la velocidad con la que en cada sprint entrega todo lo planificado (planificar menos pero entregar siempre todo al 100%), entonces cabe esperar que el equipo acelere y aumente su velocidad en aproximadamente un 10% por sprint durante su fase de performing (aproximadamente entre 1 y 2 años).

El Propietario del Producto puede usar la velocidad para proyectar cuántas historias de usuario estimadas en puntos de historia pueden completarse en un punto en el futuro. Así se hace posible la planificación de release, que dependiendo de la longitud del sprint le permite fijar una fecha para la release.