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.

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

viernes, 5 de octubre de 2018

¿Hay algo más allá de la Agilidad?

Rubén, Scrum Master y amigo, me pasó la imagen de la izquierda que representa un chiste sobre SAFe poniendo en duda de si es Agile. Este me hizo pensar en el futuro; ¿seremos Agile en el futuro?

Ya hoy en día muchas empresas de los países nórdicos de Europa, países como Suecia y Holanda, han integrado Agile en su cultura y forma de trabajar. Algunas ya piensan en evolucionar más allá los valores y principios del Manifiesto Ágil.

En su libro "Reinventar las Organizaciones", Frederic Laloux, nos habla de un nuevo paradigma cultural más allá de Agile, las empresas Teal, que son las mejor adaptadas al nuevo contexto social y económico.

Este paradigma pone el foco en desarrollar al máximo el potencial humano de los empleados de una empresa, entendiendo a la organización empresarial como un organismo viviente que está en continua evolución y desarrollo. 

Las organizaciones Teal se constituyen según tres principios esenciales:

Autogestión

La cultura Agile aporta empoderamiento, pero el empoderamiento implica que un gestor de rango superior delega parte de su poder, mientras que para Teal la autoridad no forma parte de un sistema de suma cero. En las estructuras de las organizaciones Teal no hay miembros con poder de decisión y miembros ejecutores. Por naturaleza, y no por delegación, todos tienen poder de decisión y la estructura de la organización incluye procesos holocráticos para la regulación del flujo de información y decisiones.

Plenitud

En las organizaciones las personas se suelen mostrar con una máscara profesional adecuada a las expectativas de su función y lugar de trabajo: abogado, médico, ingeniero, mecánico, oficinista, director, etc. En las organizaciones Teal no hay ascensos por los que pelear, jefes a los que contentar y las personas se muestran de forma plena, siendo ellos mismos. Son organizaciones que invierten mucho tiempo en la selección de personal, informando a los candidatos de los valores y formas de trabajo para que puedan decidir si quieren ser parte de la organización o no.

Propósito evolutivo

Para las organizaciones Teal, el beneficio es un subproducto de un trabajo bien hecho. La finalidad de la organización no es el valor para los accionistas ni maximizar las ganancias, sino su propósito evolutivo: ¿Cuál es la identidad de la organización? ¿Y qué es lo que desea? No para qué queremos usar la organización en tanto que propietarios, sino más bien ¿cuál es el potencial creativo de la empresa vista como un sistema viviente?
Principales características de las organizaciones, según su paradigma cultural - cortesía de Scrum Manager / Scrum Level
Por tanto el futuro probablemente no sea Agile. Podría aventurarme a sugerir que los marcos ágiles, como Scrum y SAFe no son más que sentido común codificado para que empresas tradicionales mejoren sus formas de trabajar y adopten una mentalidad ágil. Tanto Scrum como SAFe podemos verlos como buques rompehielos, que si son bien aplicados, rompen a las culturas tradicionales para darles la oportunidad para que en estas emerja la Agilidad.

viernes, 14 de septiembre de 2018

¿Cual es la transición del comportamiento hacia un coach ágil?

De dirigir... - cortesía de Pixabay
Aquellos que provenientes de cargos tradicionales quieran incorporarse al rol de coach ágil deben de cambiar sus comportamientos de jefes o consultores a comportamientos de coach. En primer lugar han de alinearse con la primera directiva de Kerth y creer firmemente en ella:

Independientemente de lo que sabemos ahora,
creo firmemente que todo el mundo ha hecho el trabajo lo mejor que podía, teniendo en cuenta lo que sabía en ese momento, con sus habilidades y capacidades,
los recursos que tenía disponibles en ese instante
y adaptándose a la situación en cuestión.

... a guiar - cortesía de Pixabay
A partir de ahí los principales cambios de comportamiento necesarios se pueden resumir en la siguiente tabla que nos puede servir de guía:
  • De coordinar contribuciones individuales a hacer coaching del equipo completo para potenciar su colaboración.
  • De actuar como experto a ser un facilitador.
  • De conducir hacía un objetivo específico a estar muy involucrado en el desempeño general del equipo.
  • De dirigir a guiar y permitir que el equipo encuentre su propio camino.
  • De saber la respuesta a preguntar al equipo por la respuesta.
  • De hablar sobre deadlines y opciones técnicas a poner el foco en la entrega de valor de negocio.
  • De dirigir en lo correcto a base de decisiones propias a hacer lo correcto para el negocio en ese mismo momento.
  • De arreglar problemas antes que ayudar a otros a resolverlos a facilitar talleres de resolución de problemas con los equipos.

miércoles, 12 de septiembre de 2018

¿Cuál es un buen nivel de "cumplimiento" de un sprint?

En Estados Unidos, en Europa en los países nórdicos, en Inglaterra, y en otros países del mundo, las entrevistas de trabajo se focalizan en el mayor fracaso que haya podido tener el candidato. Haber superado un fracaso significa necesariamente haber aprendido y por tanto tener experiencia real; hacer las cosas bien probablemente no signifique más que eso, haberlo hecho bien sin haber arriesgado nada y sin haber hecho nada excepcional.

En España en las empresas tradicionales celebramos el haber llegado al 100% del trabajo marcado; con mentalidad ágil y pensando en resultados y beneficios para nuestros clientes, lo que queremos es ir mucho más allá del 100%, y lo queremos hacer con menor esfuerzo y poniendo toda nuestra energía en lo que tiene valor y a través ciclos de mejora continua.

Antes que nada recordemos que cuando hablamos de nivel de cumplimiento en Agilidad hablamos de cumplir con el objetivo del sprint, no con las historias de usuario de la pila de sprint.

Cuando los equipos en planificación definen su objetivo del sprint generan un sentimiento de compromiso en base a un reto excitante, que les guíe e inspire a llegar mucho allá y les haga hacer cosas excepcionales.

Bajo esta perspectiva un buen nivel de cumplimiento está alrededor de un 70% o un 80% de los objetivos marcados, y esto ocurre con el objetivo del sprint y en los objetivos trimestrales, como son los OKR en un ambiente de escalado.
Si nuestro foco es cumplir al 100% no vemos las grandes ideas

Equipos que llegan a sus objetivos y OKRs al 100% significa que no ven lo que ocurre a su alrededor, están ciegos a las buenas ideas, por tanto sus objetivos son mediocres y no son lo suficientemente retantes!!! Si nos basamos en OKRs retantes que cumplimos al 70-80% ocurrirá que los equipos harán cosas excepcionales y ocurran la innovación y la mejora continua, y recordemos que para ser competitivos hoy en día necesitamos adaptarnos e innovar continuamente.

Esto ocurre en empresas cuya gerencia proporciona un objetivo general y una dirección estratégica a través de una visión sólida, con un mínimo de planes específicos de trabajo o proyecto, con requisitos desafiantes y un alto grado de libertad en cuanto a cómo los equipos cumplen con los requisitos.

Empresas con equipos que cumplen al 100% simplemente hacen cosas mediocres, y equipos que están al 120%, hay jefes que se vanaglorian de ello, significa que esos jefes no saben lo que hace su gente, y que sus equipos simplemente están sumidos en un salto de mata constante.