miércoles, 12 de diciembre de 2018

¿Hay alguna dinámica para mostrar la importancia de los ciclos iterativos?

En octubre hubo un evento muy interesante en el grupo de las Agile Women; Agile Kids, en el que exploramos la Agilidad aplicada al entorno familiar con nuestr@s hij@s. Una de las actividades fue el reto del malvavisco, o Marshmallow Challenge, en el que aprendimos sobre la importancia de los ciclos de aprendizaje iterativos.

La dinámica la ideó originalmente Tom Wucej para permitir a los equipos experimentar de forma simple y profunda la naturaleza de la colaboración, la innovación y la creatividad, componentes necesarios para entender la Agilidad. Me he inspirado en su charla TED para escribir este post.

De Why Kindergarteners Consistently Outperform CEOs on this Challenge
Consiste en formar equipos de cuatro personas que tienen que construir en 18 minutos una estructura estable lo más alta posible con 20 espaguetis, un metro de cinta de carrocero, un metro de cuerda y un malvavisco, y este debe de estar colocado en la cúspide de la estructura. Lo interesante de esta dinámica es que fuerza a los participantes a aprender a colaborar muy rápido.

Las instrucciones descritas en la guía del facilitador son:
  • Los equipos compiten para construir la estructura independiente más alta, medida desde la superficie de la mesa hasta la parte superior del malvavisco. La estructura no puede suspenderse de otra estructura (como una silla, la techo, o una lámpara).
  • Todo el malvavisco debe estar en la cúspide de la estructura. Cortar o comer parte del malvavisco descalifica al equipo.
  • Usar el material que el equipo elija, a excepción del malvavisco (que debe colocarse encima de la estructura).
  • Los equipos pueden romper los espaguetis y cortar la cinta de carrocero y la cuerda según crean necesario para crear su estructura.
  • El reto se ha de completar en 18 minutos. Los equipos no pueden tocar la estructura cuando el tiempo se agote, tocar o apoyar la estructura al final de la dinámica descalifica al equipo.
Los participantes suelen empezar orientándose, los miembros del equipo debaten, imaginan como será la estructura, disputan por el poder, luego pasan un tiempo planificando, organizando, dibujan la estructura y finalmente pasan la mayor parte del tiempo construyendo la estructura con los espaguetis. Finalmente, justo cuando se acaba el tiempo, alguien coloca el malvavisco en la cúspide y el peso del mismo suele hacer que toda la estructura colapse.

Equipo en plena construcción
Tradicionalmente los profesionales de TI hemos sido formados y entrenados para encontrar el único plan correcto al principio de nuestros proyectos, justo cuando es el momento de mayor incertidumbre y por tanto mayor ignorancia. Luego ejecutamos ese plan, y cuando la fecha de entrega se nos echa encima, cuando a modo de colocar el malvavisco en la cúspide, hacemos las actividades más críticas como son la integración y las demos a clientes, el proyecto entra en crisis...

El enfoque de los niños en la dinámica es diferente, ellos crean muchas más estructuras exitosas así como las más interesantes e innovadoras. Esto ocurre porque los niños empiezan con el malvavisco y construyen prototipos sucesivos manteniendo siempre el malvavisco en la cúspide, con lo tienen múltiples puntos de aprendizaje para arreglar prototipos fallidos a lo largo del proceso. Los diseñadores consideran este tipo de colaboración como la esencia del proceso iterativo, con cada versión los niños reciben feedback instantáneo de lo que funciona y lo que no.

La dinámica nos muestra que la capacidad de jugar con prototipos y validar es esencial. Pensemos que toda funcionalidad, épic o historia de usuario no deja de ser una hipótesis de solución a necesidades de nuestros clientes, y es esencial validar si nuestras soluciones tienen sentido para aquellos que van consumir nuestro producto. Scrum, como proceso iterativo incremental, aporta ciclos de aprendizaje sobre el producto que ocurren con el feedback de los interesados en cada revisión de sprint.

Una vez que los equipos de la dinámica han comprendido el valor del prototipado consiguen mejores estructuras, pero aún así hay algunos que destacan sobre los demás. En estos equipos emerge un facilitador, alguien con habilidades para entender el proceso y facilitarlo, haciendo que el equipo sea más exitoso todavía. Agilidad trata de equipos hiperproductivos, personas que sumando juntas rinden al máximo, y en estos equipos de la dinámica se ve claramente la importancia de los facilitadores, como ocurre con los Scrum Masters en los equipos de Scrum.

La lección fundamental de la dinámica es que el diseño y la construcción son un deporte de contacto. Exige que tengamos todos nuestros sentidos puestos en la actividad, y que apliquemos nuestras mejores ideas, sentimientos y actos en el reto que nos ocupa. Y, a veces, un pequeño prototipo de esta experiencia, el feedback de nuestro cliente, es todo lo que necesitamos para llevarnos del fracaso al éxito.

Los niños construyen las estructuras más estables e interesantes

miércoles, 7 de noviembre de 2018

¿Cómo energizar a equipos y grupos?

Juagacetamol con Reduestrés, Imaginina, Socialdiverxona y Productivina
Es común iniciar las clases, los meetups y eventos de Agilidad con un rompehielos para que los asistentes se abran y conecten rápidamente al resto de grupo. También ocurre que cuando retomamos las clases después de la comida del mediodía se produce algún bostezo o incluso algún dormisqueo y necesitemos de una actividad energizadora.

Gertrudis me regaló hace poco un frasco de Juegacetamol® con píldoras de diferentes naturalezas para estimular a las personas en diversos aspectos. La web de Juegacetamos.es describe el frasco como:

"Juegacetamol® es un producto diseñado para potenciar y desarrollar la capacidad de jugar en adultos. Son juegos que nos invitan a conectar con lo que hacemos y empatizar con las personas con las que nos relacionamos, entrenando nuevas habilidades y abriendo la mente, a través de micro-momentos que te permiten cambiar tu perspectiva y ver tu próxima acción de manera diferente".

Cada cápsula, que imita a los medicamentos más populares, contiene 1 juego, se abre y contiene un papelito con instrucciones para una microactividad.
  • Reduestrés: "Alivia el estrés y revitaliza la espontaneidad con la terapia definitiva: playfulness!"
  • Imaginina"La creatividad es la inteligencia divirtiéndose, así que liberémosla".
  • Socialdiverxona"Potencia la diversión, inhibe la vergüenza y facilita la diversión conectando con los demás".
  • Productivina: "Juegos energizantes y retos estimulantes para levantar el ánimo, las ventas y lo que haga falta".
Socialdiverxona haciendo la ola al ganador del juego
piedra-papel-tijera en un evento de Scrum Manager
Dos ejemplos de Socialdiverxona que han ido muy bien para energizar la sala son:

Piedra-Papel-Tijera, en el que se forman parejas al azar que juegan a tres puntos, la piedra vence a la tijera rompiéndola, la tijera vence al papel cortándolo y el papel vence a la piedra envolviéndola.

El ganador busca otro ganador en la sala y el perdedor se hace fan incondicional del ganador, juega la pareja de ganadores y los fanes animan a su ganador. El ganador busca otro ganador y el perdedor y su fan se vuelven incondicional del ganador. Esto se repite hasta que quede un único ganador en la sala. A medida que avanza el juego los fanes forman grupos grandes que animan a su ganador y todo ello crea mucha energía en la sala. Finalmente y como premio se le puede hacer la ola al ganador.

Socialdiverxona en forma de juego del teléfono por mímica
como rompehielos en un meetup de SAFe
Teléfono por mímica, en el que todos los asistentes forman un círculo mirando a la pared. La persona de un extremo inventa una secuencia de gestos a modo de mensaje y se lo enseña a la persona siguiente. A modo del juego del teléfono el mensaje mimetizado recorre todo el circulo de personas.

A medida que las personas han participado propagando el mensaje pueden mirar hacia la sala y ver como el mensaje avanza y se desvirtúa, provocando risas y mucha energía en la sala.

Como curiosidad mencionar que los niños ríen de media 300 o 400 veces más que los mayores, y que el adulto más alegre solo ríe de media unas 20 a 30 veces al día... ¡necesitamos Juegacetamol®!

domingo, 4 de noviembre de 2018

¿Cuál es el punto de inflexión para que sea posible la Agilidad en las compañías tradicionales?

Las crisis nos impulsan a cambiar - cortesía de Pixabay
Soy de la opinión que las empresas que pueden ser verdaderamente ágiles ya lo son. Quedan las que intentan serlo y lo serán en una medida no del todo completa; allí estamos los coaches ágiles intentando llevarlas lo más cerca posible a la Agilidad, hasta donde les permitan sus procesos estar por debajo de las personas.

Uno de los mayores problemas existentes en las empresas tradicionales son sus estructuras por áreas verticales, los silos, cada uno con sus objetivos individuales que irremediablemente llevan a la competencia entre áreas, y que hacen que los esfuerzos de unos se anulen por los esfuerzos de los otros, de manera que la empresa siempre sea la gran perdedora. Y por no mencionar los bonos que pueden situar el interés personal por en encima de la empresa. Este tipo de estructuras minimizan la colaboración y por tanto hacen árdua la transformación ágil.

Las consecuencias suelen ser un time-to-market demasiado tardío para llegar a las oportunidades del mercado en un mundo en turbulencia del cambio, y que aquellos que no innoven pierdan aproximadamente un 30% competitividad al año.

Lo que provoca el punto de inflexión en el que las empresas inician su verdadera trayectoria de transformación ágil son las crisis, como por ejemplo la falta de presupuesto y la continua falta de competitividad. Hay mucha resistencia interna, mucho egos que vencer, y en algunos casos el cambio no puede ocurrir hasta que la generación de directivos se jubile... las empresas que respondan rápido a las crisis van a sobrevivir, las que no, a no ser que tengan un producto monopolio, probablemente no lo hagan.

Alcanzar el punto de inflexión a través de la crisis significa llegar al punto en el que el imperativo organizativo principal es lograr el cambio en lugar de resistirse. Es cuando la forma actual de hacer negocios es obviamente inadecuada para lograr nuevas soluciones dentro de una ventana de supervivencia. La resistencia al cambio se diluye cuando los empleos de la gente están en juego. Siempre habrá quienes sean resistentes pero serán superados por la ola de energía que impulsa el cambio obligatorio a través de la empresa.

En ausencia de una crisis, los líderes deben impulsar el cambio de manera proactiva y deben de exhibir lo que Toyota llamaría "una sensación de peligro constante", una sensación de crisis potencial que no tiene fin y que alimenta la mejora continua. En este caso los lideres deben de crear constantemente la necesidad de cambio en todo, dejando claro que mantener el status quo es simplemente inaceptable.

sábado, 3 de noviembre de 2018

¿Cómo se hace un User Story Mapping?

User Story Mapping es una técnica que Jeff Patton describe en 2014 en su libro "User Story Mapping: Discover the Whole Story, Build the Right Product", y es muy útil para construir una pila de producto que vaya más allá de una lista unidimensional de historias de usuario y epics. Esta técnica nos permite obtener los siguientes beneficios: 
  • Visión compartida: a través de la participación en la elaboración del User Story Map todos los involucrados construirán una visión compartida del producto a obtener, lo que facilitará mantener el foco en la solución a lo largo de su construcción.
  • Alineación: los miembros del equipo y negocio (Propietario del Producto e interesados o clientes) podrán estar alineados sobre lo que se va a construir sabiendo el por qué o las razones subyacentes.
  • Mejor entendimiento de lo que quieren los clientes: a través del modelado de los clientes y de lo que van a hacer con el producto, se puede alcanzar un alto nivel de entendimiento de las verdaderas necesidades de los clientes.
  • Mejor entendimiento de los problemas que enfrentan los clientes: aplicando esta técnica se puede lograr un alto nivel de empatía con los clientes, tanto por participar en la dinámica, como también por tener la oportunidad de ponerse en el lugar del cliente a la hora de modelar lo que hará con el producto y cómo lo hará, pudiendo pensar en cuáles son sus problemas y cómo solucionarlos mediante el producto que se va a construir.
  • Un mapa de historias de usuario ordenado por versión: al modelar un backbone del flujo del cliente a través del producto, podemos definir el conjunto de historias que conformarán el Mínimo Producto Viable (MPV) a sacar al mercado, que le permita a los usuarios llevar a cabo todo el flujo de una manera básica (con por lo menos una funcionalidad por cada actividad obligatoria en el flujo), así como una idea inicial de las siguientes versiones que se prevé sacar posteriormente, que puede cambiar en función del feedback y otros elementos del mercado obtenidos cuando salga a producción el MPV y cada una de las versiones siguientes.
Pila de producto plana y pila de producto construida con la técnica del User Story Mapping
Se trata de una técnica colaborativa de construcción de la pila de producto. Para ello se reúnen los involucrados con la definición, uso y construcción del producto, como interesados, clientes o usuarios finales, el Propietario del Producto y el equipo con un moderador, que en la mayoría de los casos es el Scrum Master o el coach ágil. El objetivo es que de manera conjunta se definan, descubran, prioricen y estimen las historias de usuario y/o epics que se prevén como parte del producto a construir.

Para emplear la técnica del User Story Mapping se van definiendo los siguientes elementos:
  1. Backbone del User Story Map: el backbone o espina dorsal del User Story Map captura las actividades de alto nivel que un usuario va a realizar cuando use el producto que se quiere construir. Por ejemplo, el backbone de un proceso de compra de un libro en formato digital en una web de venta de libros on-line sería:
    Ejemplo de Backbone de un User Story Mapping
  2. Historias de usuario asociadas con cada actividad del proceso ordenadas por valor (las más valiosas en la parte superior): para cada actividad que va a realizar el usuario con el producto se definen las historias de usuario que le van a permitir realizar la actividad. Luego ordenarlas de arriba abajo colocando las más valiosas o prioritarias más arriba. Para el ejemplo de la compra de un libro en formato digital en una web de venta de libros, un conjunto de historias de usuario asociado a cada actividad y priorizadas por valor de arriba hacia abajo sería:
    Backbone e historias de usuario de un User Story Mapping
  3. Mínimo Producto Viable (v 1.0) y las siguientes versiones que se prevé liberar del producto: se determinan cuáles son las historias de usuario que compondrán el Mínimo Producto Viable (v 1.0) y las siguientes versiones reflejando esto en el User Story Map, como por ejemplo:
    Backbone, historias de usuario y versiones de un User Story Mapping
Una vez que se ha llegado hasta aquí, el equipo puede hacer una estimación inicial del esfuerzo necesario para realizar cada historia de usuario. De esta manera el Propietario del Producto puede tener una estimación del esfuerzo requerido para desarrollar el MVP y cada una de las versiones definidas en el User Story Map. Si conoce la velocidad del equipo, es decir, cuántos puntos de historia puede hacer el equipo por sprint y la duración de los sprints, puede hacer un gráfico de producto y obtener una estimación inicial de cuándo es probable que se entreguen cada una de las versiones definidas hasta el momento. Esta estimación inicial se irá ajustando y podrá ir cambiando a medida que se tengan estimaciones más precisas y se hagan entregas de software funcionando que proporcionen feedback sobre el producto y sus funcionalidades.
Previsión de lanzamiento de versiones sobre gráfico de producto - cortesía de Scrum Manager
Como se ha visto, la técnica del User Story Mapping es una forma colaborativa poderosa y efectiva para aterrizar la visión de un producto y obtener su pila de historias de usuario y epics, el MVP y las siguientes versiones en una hoja de ruta del producto, y permite que de manera flexible se puedan ir reflejando los cambios que surjan a lo largo del proceso de desarrollo y de entregas.

Un artículo interesante que ha servido como base para el post y donde se explica muy bien lo que es y como se hace un User Story Mapping es "Know thy customer: agile’s essential guide to user story maps" de Heather Krebsbach (2016).

miércoles, 31 de octubre de 2018

¿Cómo explicar lo que es un Mínimo Producto Viable?

No siempre es fácil explicar la naturaleza de un MPV (Mínimo Producto Viable), sobre todo cuando los oyentes vienen de una cultura clásica en la que se piensa en el todo y se pretende que la primera entrega sea la solución completa e ideal. Un MPV se alinea con la frase de Reid Hoffman, cofundador de LinkedIn, que dice:
"Si no te avergüenzas de tu primer producto, es que lo lanzaste muy tarde"

Hablando del tema con Gema me explicó un ejercicio muy simple de lo hace ella para explicar el concepto. Se basa en el ejercicio que Jeff Patton propone en su libro "User Story Mapping: Discover the Whole Story, Build the Right Product" y que menciona en el capítulo 5: ¿Qué hacemos desde que nos despertamos hasta que salimos por la puerta de casa?

El ejercicio consiste en un User Story Mapping en el que los asistentes identifican la secuencia de actividades desde que suena el despertador hasta que salen de casa. Un ejemplo de resultado, que suma 53 minutos, podría ser el siguiente:
  • Apagar alarma
  • 5 minutos de remolonear (5 min)
  • Sacar los pies de la cama
  • Afeitarme (6 min)
  • Ducharme (7 min)
  • Secarme (1 min)
  • Secarme el pelo (4 min)
  • Peinarme estilizado (5 min)
  • Vestirme (5 min)
  • Preparar desayuno (4 min)
  • Tomarme un café con una tostada (10 min)
  • Repasar mensajes móvil (3 min)
  • Repasar actividades del día (2 min)
  • Coger cartera y llaves (1 min)
  • Salir
Obtenida la secuencia y para entender el MPV, se les dice a los asistentes que imaginen que se han dormido y solo disponen de 15 minutos para levantarse y salir de casa, por tanto tienen que identificar las actividades estrictamente imprescindibles. Por ejemplo podría quedar en lo siguiente:
  • Apagar alarma
  • Sacar los pies de la cama
  • Ducharme (7 min)
  • Secarme (1 min)
  • Vestirme (5 min)
  • Coger cartera y llaves (1 min)
  • Salir
Este último conjunto de actividades representa el MPV para levantarse y salir de casa; entendido el concepto los asistentes estarán preparados para identificar MPVs en las iniciativas de negocio de sus áreas de la compañía.
User Story Mapping con dos MPVs, el primero el del ejemplo - del taller de José Manuel Beas :-)

martes, 30 de octubre de 2018

¿SAFe es 100% Agile y Lean?

Hace poco estuvo Celia entre los asistentes de un curso de SAFe, es una coach ágil de nivel que inició un debate muy interesante, preguntó por cómo se resuelven las dependencias entre trenes en un Solution Train. La respuesta nos llevó a la zona gris de SAFe, la capa Large Solution donde Agile y Lean se pueden tambalear.
Big Picture de SAFe con la capa en que Agile y Lean se pueden tambalear
La capa Large Solution es una capa de coordinación de trenes que ocurre a través de un tren virtual. El debate fue alrededor de la palabra "coordinación" que nos indica claramente que si en este nivel hacen falta coordinadores que empujan (pull) hacia los trenes, no es posible la autoorganización. Otra razón fue el número de individuos de un Solution Train, son demasiados para que pueda emerger la autoorganización.

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

Con la resolución de dependencias entre trenes que propone SAFe se hace patente la imposibilidad de autoorganización y la ejecución por empuje (push) en un Solution Train.  Para ello SAFe propone dos puntos de coordinación que recuerdan a una clásica estructura top-down:
  • El primero está en el Solution Train Management Review and Problem-Solving, que ocurre entre el día 1 y el 2 de las PI Planning individuales de los trenes. En este evento se habla de dependencias identificadas en las PI Plannings y se les envía instrucciones especificas a cada tren para el segundo día.
  • Y en la POST PI Planning, donde los RTE después de colocar la información de su tren en el Solution Planning Board, discuten las dependencias con otros trenes o proveedores y sacan ajustes necesarios que después comunican a los trenes.
Otro indicador de la imposibilidad de autoorganización es la imposibilidad de conocimiento tácito colectivo común a todos los trenes. Para ello SAFe nos propone el Solution Intent, una fuente virtual única de conocimiento que recoge todo aquello que forma parte del Solution Train.

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

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

martes, 16 de octubre de 2018

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

Mapa de habilidades del equipo - thanks Alexandre
Originalmente la reunión diaria se basaba en que cada miembro del equipo de desarrollo contestara a las tres preguntas recogidas en la Scrum Guide, produciéndose así la coordinación y autoorganización del equipo:
La revisión de 2017 de la Scrum Guide introduce la siguiente revisión: "El equipo de desarrollo es el encargado de establecer la estructura de la reunión diaria y esta se puede conducir de diferentes maneras si se enfoca en el progreso hacia el objetivo del sprint. Algunos equipos de desarrollo usarán preguntas, algunos se basarán más en discusiones".

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

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

En este punto es donde el equipo entra en conversación y decide de forma colaborativa quien es la personas ideal, o personas ideales, para acometer esa tarea. Es buena idea elaborar y apoyarse en un mapa de habilidades del equipo, como el de la imagen del post.
  • En vertical enumeramos las especialidades existentes en el equipo multifuncional y necesarias para construir historias de usuario de principio a fin.
  • En horizontal enumeramos los miembros del equipo.
  • Finalmente representamos con lineas gordas, finas, discontinuas y ausencia de las mismas la profundidad de la habilidad de cada miembro.
Es recomendable que el Scrum Master impulse a los equipos a cambiar la estructura de la reunión diaria de tanto en tanto, la variedad mantiene a los equipos más motivados y refuerza el compromiso de sus miembros.