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

Icono diseñado por Flat Icons de www.flaticon.es

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

¿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 (ARTs) en un Solution Train. La respuesta nos llevó a la zona gris de SAFe, a 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 ±125 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 ±125 individuos.

De ahí viene el concepto de tribu del tren: un grupo de familias que se ayudan unas a otras y siguen a un líder para sobrevivir y se limita a ±125 individuos. Históricamente cuando una tribu crecía mucho aparecía otro líder, se enfrentaban y la tribu se segmentaba en dos tribus. Para sentirse parte de grupos más allá de ±125 individuos la naturaleza humana simplemente no está preparada.

El ser humano ha tratado de inventar conceptos artificiales para crear grupos muy grandes, por ejemplo los conceptos de nación y de religión; son conceptos en los que la autoorganización no funciona. Si fuera así ayudaríamos a un mendigo en la calle si perteneciera a nuestra nación... pero no ocurre así, si le ayudamos lo hacemos por nuestros valores individuales, como el humanitarismo por ejemplo.

SAFe con el Solution Train no trata de crear un concepto que agrupa individuos por encima del tren, es plenamente consciente que el límite de individuos es por trenes y que estos se pueden coordinar como elementos individuales con herramientas y comunicación top-down.

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, probablemente se escale igual de mal aplicando cualquier marco o práctica, 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".

SAFe and Scaled Agile Framework are registered trademarks of Scaled Agile, Inc.

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

• ¿Qué hice ayer que ayudó al equipo de desarrollo a lograr el objetivo del sprint?
• ¿Qué haré hoy para ayudar al equipo de desarrollo a lograr el objetivo del sprint?
• ¿Veo algún impedimento que evite que el equipo de desarrollo o yo logremos el objetivo del sprint?

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.

¿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 proyecto. Trae 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 su 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

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

El nuevo paradigma Teal ya está en gestación, ya podemos encontrar algunas organizaciones en Europa:

• Buurtzorg en Holanda: Atención de enfermería domiciliaria de alta calidad y bajo costo.
• Evangelische Schule Berlin en Alemania: Un Instituto.
• Heiligenfeld en Alemania: Un hospital se salud mental.
• Favi en Francia: una fundición de latón dentro de la industria automotriz