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.

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.

lunes, 3 de septiembre de 2018

¿Hay alguna dinámica que muestre la importancia de la holgura o aire en los sprints?

Vaso al 80%, se transporta bien
Una de las cosas más complicadas de transmitir es la necesidad de holgura o aire en la carga de trabajo, también conocida como slack time, que consiste en no cargar nunca un sprint al 100% y entender que una productividad del 80% es una productividad muy alta.

Cuando hablo del tema salen argumentos como que es mejor que los equipos tengan trabajo a mano por si acaso se quedan sin... trabajo que al final hace ruido y todo el mundo espera que también se entregue. Son argumentos cargados por nuestra cultura tradicional en la que la cantidad de trabajo entregado, y no el valor entregado, importa.

Vaso al 100%, al transportarlo
se derrama el agua y hay que
limpiar (retrabajo)
Recuerdo un candidato a coach ágil que me decía que no "creía" en la iteración IP que marca el marco de SAFe, una iteración cuyo nombre deriva de "Innovation & Planning" que no se planifica y que permite que la cadencia de entrega de valor sea posible... lo gracioso es que cuestionaba las lecciones del marco de SAFe del que pretendía certificarse.

He trabajado con equipos utilizando esa holgura o aire, y otros sin, siempre veo el mismo patrón; los que no tienen holgura no consiguen encontrar un ritmo de entrega sostenible, cada fin de sprint es como una pequeña crisis de fin de proyecto.

Eelco Rustenburg, un gran trainer, hace dinámica muy simple, y que puede entender todo el mundo, con la que muestra la importancia de no cargar al 100% los sprints. Consiste en dos partes:
  1. Transportar un vaso lleno de agua al 80% de un extremo de la clase al otro extremo
  2. Y después transportar un vaso completamente lleno
Hasta podríamos experimentar la dinámica de forma mental, todos hemos transportado con nuestras manos vasos con agua u otra bebida. Un vaso al 80% se transporta rápido y sin derramar, un vaso al 100% se transporta lento y con mucho cuidado, y siempre hay un accidente en el camino y se produce un derrame. Desde el punto de vista del flujo es mucho mejor llenar vasos (sprints) al 80% y que haya un buen ritmo, que avanzar tortuosamente con vasos (sprints) completamente llenos. Con un vaso al 100% además se produce retrabajo; hay que sacar la bayeta y limpiar las gotas de agua derramada... quizá así podamos entender lo caro que sale ese 20%. Los tiempos medios que hemos experimentado son 36 segundos con un vaso al 100% versus 8 segundos con un vaso al 80%!!!

sábado, 25 de agosto de 2018

¿Qué hacer para tener reuniones de valor?

Reuniones de valor - Cortesía de Pixabay
Una de las cosas que más me sorprende es el mar de reuniones que suele haber en algunas empresas. Reuniones que muchas veces se solapan y que carecen de la facilitación adecuada. Suele ocurrir entonces una escasa asistencia y cancelaciones de las mismas media hora antes. A mi me ha pasado recibir una cancelación estando de camino, y a Jaume le ha pasado viniendo de Barcelona, recién llegado la noche anterior al hotel en Madrid.

Alexandre me comentaba que en Brasil pasa tres cuartos de lo mismo y lo que hizo fue crear un sistema en que hay que ganárselo para poder ir a una reunión, y que se resume en los siguientes puntos:
  • Si alguien quiere tratar un tema lo propone y ha de encontrar a dos personas que le respalden.
  • Conseguidos dos respaldadores se comunica la reunión y los interesados deben pedir apuntarse.
  • El proponedor acepta y declina a los peticionarios, con lo que ir a una reunión es algo que se vuelve de valor. De esta manera el proponedor hace que las personas adecuadas estén dentro y las no adecuadas queden fuera.
Cuando tenga oportunidad de probar este sistema contaré mi experiencia... aunque intuyo que voy a tardar un poco.

viernes, 17 de agosto de 2018

¿Se puede hacer una retrospectiva con un tablero virtual?

Las personas no dejan de sorprenderme... aunque todo lo que ocurre sea naturaleza humana, y sabiendo que cuando permites que florezcan aparecen los comportamientos humanos más espectaculares, como la colaboración, no deja de sorprenderme como evolucionan los equipos a través de las retrospectivas... y eso hace que me sienta muy bien :-D
Tablero Trello de retrospectiva
6 de 8 equipos de una tribu con la que trabajo han optado por hacer sus retrospectivas con Trello. Algunos de los miembros están localizados en otras ciudades de España, y todos, incluidos los que están en Madrid, hacen sus retrospectivas con Trello.

Los que están colocalizados se reúnen en una sala y participan con los que están en remoto por videoconferencia. En las salas se proyecta a las personas en videoconferencia, así que se ven todos y pueden leer sus expresiones y gestos, a la vez que todos comparten un tablero Trello que trabaja cada uno en su portátil. Trello se sincroniza al momento en los diferentes dispositivos de los miembros con lo que todos participan del mismo punto de referencia. El tablero suele tener las siguientes columnas:
  • :-) ¿Qué ha funcionado bien?
  • :-( ¿Qué no ha funcionado?
  • Las ideas para mejorar
  • Agradecimientos
  • Acciones exitosas
Las retrospectiva comienza con un vaciado de la columna de "Agradecimientos", seguido de un repaso de la/s acción/es votadas en la retrospectiva anterior, de la que se mueven las que han funcionado a la columna "Acciones exitosas", las que no han funcionado se descartan. Así tenemos la evolución de las mejoras a lo largo del tiempo.

Luego todo el mundo añade post-its virtuales a las primeras cuatro columnas, en individual y a la vez. Lo interesante es que post-its de veces anteriores siguen ahí, con lo que la adición es incremental y se focaliza en mejoras nuevas.

Una vez acabado, cada uno lee sus post-its, en algunas ocasiones un miembro del equipo lo hace para todos, y finalmente se vota a viva voz. En un pequeño brainstorming se añaden ideas al/los post-it/s votados y se le/s señala con un sticker como mejora para el sprint entrante.

De esta manera equipos maduros en Scrum han creado su propia práctica de retrospectiva evolutiva que además ocurre en una media hora escasa. ¡Espectacular!

lunes, 6 de agosto de 2018

¿Un poco de historia de Scrum y Scrum Manager?

Póster del cuadro com las reglas de Scrum
Uno de lo cuadros sinópicos de Scrum que más comprensibles y claros son es el de Juan Palacio de Scrum Manager. Yo utilizo su póster impreso en un hule para explicar el ciclo de Scrum en mis clases.

Recientemente vi una noticia en LinkedIn que mostraba la versión 0.4 del cuadro, lo que me hizo mucha ilusión porque representaba un poquito de historia de Scrum Manager. Escarbé un poco en google, escribí a Juan y recopilé unas pocas versiones del cuadro, así que este post nació de la idea mostrar esas pequeñas obras de arte ágiles.

Marco en su primera concepción y presentación en sociedad por
Ken Schwaber en OOPSLA (1995) - SCRUM Development Process
1990: A principios de la década Ken Schwaber empleaba una primera aproximación a Scrum en su compañía, Advanced Development Methods, a la vez que Jeff Sutherland desarrollaba una aproximación similar en Easel Corporation y fue quien le diera el nombre de Scrum.

1995: Ken Schwaber y Jeff Sutherland presentaron una serie de artículos que describian Scrum en la OOPSLA (1995). Ken Schwaber lo hizo en su artículo SCRUM Development Process donde describió la implementación de Scrum para software que él empleaba en el desarrollo de Delphi. A partir de ese momento Schwaber y Sutherland colaboraron para consolidar las mejores prácticas de la industria en lo que hoy se conoce como el marco de Scrum.

Figure 1.1: Scrum Summary de Schwaber y Beedle
2001: Ken Schwaber y Mike Beedle describieron el marco en su libro "Agile Software Development with Scrum".

"Las implementaciones de Scrum para desarrollo de software se vienen enriquecendo desde entonces, y poco tienen que ver las implementaciones actuales con la original de Ken Schwaber. Ahora es muy raro que alguien configure un campo de Scrum con los controles originales (paquetes, cambios, riesgos, soluciones…), la pila única ha evolucionado a pila de producto y pila de sprint." nos cuenta Juan Palacio en  "Así era la primera implementación de Scrum para Software".

Scrum: Ficha Sinóptica Rev.0.3 - 2005
2005: Juan Palacio funda Scrum Manager que es el resultado de una iniciativa personal de un gestor de proyectos que decide ofrecer altruistamente una alternativa de formación de Scrum libre y gratuita a través de su plataforma on-line.

Una de las primeras versiones del cuadro que vió la luz fue la revisión 0.3. El facilitador y gestor de la ejecución del proceso recibe el nombre de Scrum Manager, sus responsabilidades no son del proyecto sino del grupo de procesos y métodos de la organización. Con el criterio de Scrum Management, es recomendable que las responsabilidades que cubre este rol, estén identificadas en una única persona, sobre todo cuando se comienzan a aplicar prácticas de Scrum en la organización.
Scrum: Ficha Sinóptica Rev.0.4 - 2006
Modelo Académicio de Scrum Rev.0.6 - 2008

2008: El rol del facilitador / coach / gestor del marco toma el nombre del Scrum Master.

Desde la concepción inicial el marco de conocimiento se viene definiendo "de abajo arriba", el crecimiento y evolución son resultado de aportaciones de la comunidad profesional sobre la semilla de OOPSLA. En esta evolución de Scrum se fue añadiendo la reunión de revisión de sprint, la de planificación de sprint, y más tarde, sobre 2010, otra de retrospectiva.

En abril de 2014 Juan creó la versión del cuadro actual con el titulo Las Reglas de Scrum que corresponde a la revisión 1.1.
Las reglas de Scrum Rev.1.1 - 2014

Rev.1.1 con el Propietario del Producto en la retrospectiva
Y por último la revisión 1.1 tal como la utilizo yo con mis equipos.

En esta versión el Propietario del Producto asiste y es parte activa en las retrospectivas. Al fin y al cabo un Propietario del Producto está íntimamente ligado a un equipo de desarrollo, por tanto su asistencia a las retrospectivas puede aportar mucho a la mejora continua del proceso.

Descargas / Downloads
Mis agradecimientos a Juan Palacio por compartir sin pedir y haber hecho posible Scrum Manager :-)

sábado, 4 de agosto de 2018

¿Cómo ha de ser la estrategia en una compañía ágil?

Estrategia deliberada o intencional - cortesía de Pixabay
Entre mediados de los años 50 a mediados de los 70, en un mundo relativamente predecible, la estrategia de una compañía se hacía exclusivamente en la planificación estratégica.

Esta planificación es una responsabilidad y actividad del equipo ejecutivo, donde en base al contexto actual, este establece un objetivo final e identifica los pasos a seguir y que suele materializarse en un plan anual. Por lo general el equipo ejecutivo contribuye a la estrategia y el siguiente nivel de gerentes desarrolla partes locales que son integradas en este plan anual.

Una vez obtenido el plan anual la compañía se centra en seguir la estrategia definida, con una clara separación entre quién ha planificado y quién la ejecuta. Una evaluación anual de la organización, sus fortalezas, debilidades, oportunidades y amenazas llevan al desarrollo de nuevas estrategias y un nuevo plan anual. A este enfoque clásico se le conoce como estrategia deliberada o intencional.

Hoy en día la planificación estratégica es un oxímoron ya que asume que al definirla  disponemos de toda la información y tenemos el control de nuestro mercado y producto. En los años 80 entramos de pleno en el mundo VUCA, un entorno de mercado muy volátil en el que los cambios ocurren a mucha velocidad y el medio y largo plazo a veces son impredecibles. En esta nueva realidad la planificación estratégica corre el riesgo de ser víctima de su rigidez y minimizar la competitividad de la compañía. ¿Qué empresa es hoy en día dueña de su producto?
Henry Mitzberg acuñó el termino de estrategia emergente
Henry Mintzberg, experto en management, sostiene que la planificación estratégica ciega a la dirección de las empresas, esta inhibe el pensamiento y el análisis de las condiciones cambiantes en las que se desenvuelve la compañía. Es necesario ser consciente de esta turbulencia del cambio y tener la flexibilidad de una planificación emergente para poder hacerle frente y adaptarse. Muchas de las estrategias emergen cuando las personas y los equipos experimentan y resuelven pequeños problemas de los que aprenden y generan nuevas oportunidades.

La estrategia emergente es el resultado de un proceso discontinuo, irregular, no sistemático y espontáneo de la ejecución estratégica, y que obedece al comportamiento y a las acciones que realizan las personas que intervienen en el proceso. Es un enfoque estratégico, aunque no deliberado, que consiste en aprender y sentir el camino a seguir y ajustar continuamente la visión a la realidad. Es un proceso de inspección y adaptación en el que descubrimos de forma continua las necesidades de nuestros clientes, sus propuestas e intenciones.

Como podemos imaginarnos Scrum es un marco de estrategia emergente, con cada revisión de sprint obtenemos feedback de aquellos que van a consumir el producto, por tanto cada sprint es un ciclo de aprendizaje para que negocio y Propietario del Producto puedan incluir información fresca en la estrategia del producto. La estrategia deliberada o intencional viene marcada por la visión inicial de producto, que primero se materializa en la pila de producto y luego evoluciona con la misma de forma emergente con cada sprint.

Los marcos de escalado también se basan en la estrategia emergente. Veamos donde esta está presente y como forma parte natural del marco de SAFe .
Puntos del big picture de SAFe donde se recoge la estrategia emergente
SAFe incorpora una capa de gestión de la demanda (portfolio) que es el punto donde la compañía inyecta temas estratégicos y que representa la estrategia deliberada o intencional. En este nivel el LPM (Lean Portfolio Management) identifica iniciativas estratégicas en forma de epics, todas ellas con un business case asociado. La estrategia emergente comienza cuando cada epic ha de consistir en un MPV (Mínimo Producto Viable), y por tanto sus hipótesis se han de validar mediante el ciclo Lean-Startup antes de enviarlo a desarrollar a los trenes.

El noveno principio de SAFe habla de descentralizar las decisiones; otorga poder de decisión a aquellos que están donde la información, por tanto Product y Solution Management tienen toda la autoridad para incluir decisiones estratégicas procedentes de las realidades a su nivel (programa y large solution). A nivel de tren SAFe prescribe la Exploración Continua, un proceso de exploración continua del mercado y las necesidades de los usuarios que redefine y ajusta mediante el ciclo Lean-UX la visión, la hoja de ruta y la pila de programa. Cada PO-Sync es un evento donde se trata información fresca proveniente de la exploración continua y por tanto es donde se produce gran parte de la estrategia emergente.

Otra fuente de estrategia emergente está en el evento core de SAFe, la PI Planning. Ocurre cuando los equipos "cocinan" las funcionalidades de la pila de programa, que representan la intención, y obtienen de forma emergente la factibilidad a través de los planes y los objetivos de PI. Recordemos que en la revisión de los planes Business Owners y Product Management aprenden sobre ajustes de visión, alcance y recursos, que no es más que otra manifestación de la estrategia emergente.

Quiero dedicar este post a Dani, quién me descubrió a Mintzberg :-)

lunes, 30 de julio de 2018

¿Cómo mostrar la autoorganización en un ART?

El evento core de SAFe es la PI Planning, el evento presencial en que el estamos todos y que funciona en cadencia a manera de latido para tren (ART). De manera autoorganizada ocurre el alineamiento y compromiso de todos los equipos del ART y bajo misión y una visión compartidas.

No hay magia en SAFe... excepto quizá en la PI Planning
Historias de Usuario del módulo #3: PI Planning
Desde Estratecno quisimos montar un meetup para probar la autoorganización en un tren en toda su dimensión. Miguel encontró la SAFe City Simulation de Mark Richards y del equipo de CoActivation, que se basa en una metáfora no técnica, como es la construcción de ciudades, para llegar a audiencias que no sean de tecnología, así que Ángel y yo nos lanzamos y preparamos el meetup con la Simulación SAFe City :-)

Las tarjetas con las historias de usuario, las dispositivas de la introducción y el manual para el facilitador están disponibles en la página de los autores: SAFe City Simulation.

Tras una breve introducción y repaso de los conceptos de una PI Planning, iniciamos esta simulación de planificación cruzada que hace hincapié en el poder de la planificación colaborativa y la capacidad del enfoque de PI Planning de SAFe para permitir a los equipos optimizar de forma autoorganizada y colaborativa las dependencias internas en un ART y resaltar los cuellos de botella del flujo.
PlanificaciónTablero de dependencias


Agile Kids, un equipo de constructores y su tablero :-)
El tren estuvo formado por una combinación de equipos constructores (funcionales) y uno de especialistas (de componentes), a los que les entregamos un conjunto de funcionalidades (features) e historias de usuario con numerosas dependencias entre equipos constructores y especialista para que de forma autoorganizada construyan un plan durante el breakout. Los outputs fueron los siguientes:
Los tres outputs son producto de la autoorganización a nivel del tren; los objetivos de equipo individuales están alineados con los objetivos del tren, el entramado de dependencias es resultado directo de acuerdos entre equipos y los riesgos y su posible mitigación es consenso de todo el tren.

El tiempo de juego fue de aproximadamente 1 hora 45 minutos, se repartió de la siguiente manera:
  • Introducción y configuración (30 minutos)
  • Planificación (1 hora minutos)
  • Conclusiones (15 minutos)
Equipo de especialistas, fontaneros y electricistas en las Termópilas. ¡Parecían 300!Tablero de los especialistas 
Al acabar la simulación solo hicimos un par de preguntas: ¿Habéis sentido la autoorganización a nivel del tren? ¿Habéis sentido como planificamos los 7 equipos de forma colaborativa? Las respuestas fueron entre otras:
Un feedback que me ha emocionado fue el siguiente:
  • SAFeCity: SAFe no es una estructura que soporta el negocio tradicional. Las herramientas y los procesos pueden ser o no ágiles, el que lo ve Agile eres tú.
The making of :-)
Para quién quiera probar la simulación le recomiendo hacerlo en una mañana y hacer los 3 módulos que propone Mark Richards seguidos. Nosotros nos focalizamos en el tercer módulo, con lo que la visión y el establecimiento de objetivos comunes fue poco potente y resultó en el punto de mejora propuesto por la mayoría de asistentes.

Lo que hagas, hazlo con pasión
Steve Jobs

Quiero dar mis agradecimientos a Miguel y a Estratecno por creer en nosotros, en SAFe e impulsarnos a hacer estos meetups, a David por apoyarnos y a gestionar con RyanAir Labs el aportar el local, cervezas y tortillas :-), a Bria y a Ryan por el apoyo de Scaled Agilea Ángel con el que formo equipo de primera y a todos los asistentes por su colaboración e ilusión

sábado, 28 de julio de 2018

¿Cuál es una buena técnica para construir una hoja de ruta?

Tablero con una hoja de ruta
cortesía de Alexandre Magno
Imaginemos que tenemos nuestra visión del producto y estamos listos para obtener la hoja de ruta. Una de las mejores técnicas es la denominada "recuerda el futuro" o "remember the future", la que voy a presentar en este post.

Si construimos la hoja de ruta partiendo de la fecha actual hacia adelante, lo que ocurre es que pensamos en pasos pequeños y de lo que el producto debería hacer después de cada uno de ellos, como extrapolación razonable de lo que ha hecho anteriormente. Así pensamos en pequeñas mejoras, y dado que somos pesimistas, llenaremos el camino de buffers y pasos a menudo triviales.

Si recordamos el futuro empezamos por proyectarnos en el futuro, a un estado de éxito al que queramos llegar, y luego vamos dando pasos hacia atrás. "Recuerda el futuro" es una dinámica colaborativa, por tanto deben de estar presentes todos los interesados de negocio, los Propietarios del Producto y el cliente si fuera posible.

Dibujamos una línea de tiempo y empezamos por el final, por cuando tengamos pensado lanzar el productoEl marcado de ese final generará mucha conversación alrededor de para cuando tiene sentido lanzar el producto. Esa conversación generará informaciones cruzadas que son la clave para una buena estrategia, por ejemplo marketing podría revelar que la competencia lanzará un producto similar en noviembre, entonces podríamos decidir marcar octubre para el lanzamiento. Si creáramos una hoja de ruta basada en un plan detallado de ventas podríamos acabar lanzando nuestro producto después de la competencia y no darnos cuenta.

Para proyectar el estado de éxito pedimos a los asistentes que imaginen que están más allá de esa fecha de lanzamiento, que el producto ha sido un éxito y que han estado utilizándolo de forma casi continuada. De esta manera estamos respondiendo a la pregunta "¿qué habremos hecho?", pensar en un éxito futuro como ya completado nos permite tomar decisiones más efectivas al reducir el conjunto total de resultados posibles. Entonces podremos responder a la pregunta "¿cómo lo hicimos?", y ya podemos imaginar una secuencia de beneficios u outcomes obtenidos hacia atrás, generando descripciones creativas y ricamente detalladas de los mismos.

Si fuéramos hacia adelante en el tiempo nos haríamos la pregunta "¿qué deberíamos de hacer?" con lo que no tendríamos un marco de referencia para comparar, no asumiríamos el éxito y posiblemente nos perderíamos pensando en si es posible conseguir el siguiente beneficio u outcome.

Para construir la hoja de ruta:
  • Paso 1: Pedimos a los participantes que imaginen que están en el futuro y que han logrado el éxito.
  • Paso 2: Pedimos que vayan más allá: un día, semana o mes...
  • Paso 3: Pedimos a los participantes que anoten con el mayor detalle posible, qué aspecto tiene el éxito, qué beneficios u outcomes han obtenido.
  • Paso 4: Retrocedemos en el tiempo al siguiente punto de éxito y les pedimos que respondan a la pregunta "¿qué habrá pasado para que ese estado de éxito sea cierto?"
  • Paso 5: Iteramos "¿y justo antes de eso?"... ¿y antes de eso?... y así crearán la linea del tiempo a la inversa recordando el futuro.
El resultado será una hoja de ruta con los beneficios u outcomes sobre la línea de tiempo. Esta es la linea de tiempo principal, podemos hacer otras líneas opcionales paralelas con historias de usuarios (outputs) o riesgos por ejemplo. Si hiciéramos más de una linea de tiempo es importante resaltar que debemos de trabajar en una sola a la vez, nunca en paralelo, perderíamos el foco.