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.

lunes, 8 de octubre de 2018

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

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

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

Características no deseadas de la gestión clásica:
  • Planificación y ejecución basadas en utilización y disponibilidad de las personas
  • Fuerte resistencia a cambios de alcance
  • Sobrecarga y fricción: Baja velocidad de construcción
  • Equipos sin continuidad
  • Mueve la gente al trabajo
Una buena solución para hacer una gestión Lean-Agile de proyectos trata de desacoplar los proyectos de los equipos. La idea es aunar las funcionalidades de todos los proyectos en una única pila de producto, y alimentar las pilas de los equipos concretos desde esta. Esta forma de hacerlo permite tener equipos con continuidad que conserven el conocimiento tácito adquirido a lo largo de los años y la integración en equipo de alto rendimiento de sus miembros.

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

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

Características deseadas que aporta la gestión ágil a través de una pila única:
  • Planificación y ejecución basadas en valor de negocio
  • Absorción del cambio como ventaja competitiva
  • Ajusta el trabajo a la capacidad
  • Equipos con continuidad
  • Mueve el trabajo a la gente