¿Cómo tiñe la PI Planning la intención de realidad?

PI Planning en el Big Picture de SAFe®

Una de las frases de SAFe® y que se refiere a la PI Planning dice así:

No hay magia en SAFe...

excepto quizá en la PI Planning

Veamos pues cual es la magia de este evento core del marco.

Recordando los inputs y outputs de la PI Planning tenemos entre otros como input el program backlog, la pila de features que Product Management ha preparado, y como outputs los objetivos del equipo, las pilas iniciales de los equipos y el program board con las features colocadas en la iteración en la que el equipo estima terminarlas y las interdependencias detectadas resueltas.

La primera clave está en comprender que el program backlog representa la intención de Product Management y negocio, representa aquellas cosas que desde el punto de vista de negocio son las que aportan el máximo valor y están limitadas en tamaño a la capacidad del tren, por tanto representan las features deseables para construir y obtener al final de PI.

Cuando en PI Planning los equipos toman esas features, las desglosan en historias de usuario, resuelven dependencias que emerjen entre si y con equipos externos, estos están "cocinando" la intención para obtener factibilidad. Esa es la magia de la PI Planning, utiliza la complejidad del pensamiento focalizado de todos los individuos del tren como inteligencia colectiva para obtener un plan factible tiñendo así la intención, representada en el program backlog, de realidad.

Finalizada la PI Planning las pilas iniciales de los equipos y sus objetivos del PI no van a cuadrar al 100% con la intención, con las features del backlog, quizá un 80%... Habrá cosas que no es posible construir, puede que por razones tecnológicas o por capacidad para absorber dependencias, para otras habrán surgido ideas y soluciones mejores... lo importante es entender que la PI Planning hace que los equipos crean un plan de partida en el que crea cada individuo, un plan que sea factible y por tanto garantice el éxito.

Program backlog y program board y su maraña de dependencias

En la imagen de la derecha podemos ver un program backlog, el rotafolios a la izquierda, mostrando en azul las features que ha sido posible planificar; las verdes son aquellas que no se han podido incluir por alguna razón. En el tablero de la derecha se puede ver el program board con todas las dependencias identificadas y resueltas, están representadas por las cuerdas rojas. ¿Qué precio tiene un plan trimestral para 8 equipos que tiene todos los números de ser exitoso? ¿Que precio tiene el program board en el que se nos muestra las dependencias resueltas para ese trimestre? No habrá retrasos ni bloqueos, porque el plan lo han cocinado, cada uno desde su perspectiva, todos aquellos individuos que lo van a ejecutar.

Resaltar que el compromiso se establece con los objetivos que los propios equipos han establecido, y un objetivo es una cosa flexible. Un objetivo se puede alcanzar con un grupo de historias de usuario u con otro, con más o con menos, lo importante es que al final de PI el cliente reciba la mejor solución posible a su necesidad. El compromiso por objetivos nos hace ágiles, hace que las pilas de los equipos sean flexibles al igual que una pila de producto de un equipo de Scrum.

Con la PI Planning los equipos son dueños de sus planes y esa responsabilidad es uno de los beneficios más significativos del evento, cada individuo siente su responsabilidad en el resultado del tren, creándose así un ambiente de trabajo mejor en el que se impulsa la colaboración. Durante la PI Planning ocurre otro beneficio casi mágico, todos hacen hincapié en el equilibrio entre el trabajo y la vida, asegurándose de no planificar excediendo la capacidad y obtener un plan de partida excepcional.

Aunque no haya sido posible incluir todas las features el voto de confianza muestra a Business Owners entusiasmados

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

¿Cuáles son las novedades de la versión 5.0 de SAFe®?

En octubre Scaled Agile anunció y puso a disposición del público su actualización a la versión 5.0. Se trata de una actualización significativa del marco que proporciona orientación sobre las siete competencias básicas que ayudan a una organización a convertirse en una empresa Lean y alcanzar la Agilidad Empresarial (Business Agility), el paradigma empresarial para las compañías que van a florecer en el despliegue de la quinta revolución tecnológica.

La novedades que nos trae esta nueva versión se pueden ver resaltadas en la imagen al final post y son las siguientes:

• Business Agility: Agilidad Empresarial, el nuevo marco incluye la capacidad para poder competir y prosperar en la era digital respondiendo rápidamente a los cambios del mercado y a las oportunidades emergentes con soluciones empresariales innovadoras.
• Measure and Grow: se focaliza en cómo medir el estado de Business Agility y cómo acelerar el crecimiento para mejorar los resultados económicos generales.
• Organizational Agility: esta nueva competencia de Agilidad organizacional describe cómo los líderes Lean thinkers y los equipos ágiles optimizan sus procesos de negocio, desarrollan estrategias con compromisos claros y adaptan rápidamente la organización para capitalizar nuevas oportunidades.
• Enterprise Solution Delivery: antes Business Solutions and Lean Systems Engineering; esta competencia describe cómo aplicar los principios y prácticas Lean-Agile a la especificación, desarrollo, implementación, operación y evolución de las aplicaciones de software, redes y sistemas ciberfísicos más grandes y sofisticados del mundo.
• Agile Product Delivery: antes DevOps and Release on Demand; se ha convertido en la competencia Agile Product Delivery, que es un enfoque centrado en el cliente para definir, construir y liberar en un flujo continuo productos y servicios de valor para clientes y usuarios.
• Continuous Learning Culture: esta nueva competencia de cultura de aprendizaje continuo describe un conjunto de valores y prácticas que alientan a las personas, y a la empresa en su conjunto, a aumentar continuamente el conocimiento, la competencia, el rendimiento y la innovación.
• Agile Teams beyond Technology: se ha reestructurado esta competencia de Team and Technical Agility que describe las habilidades críticas, los principios y prácticas Lean-Agile que los equipos ágiles y los equipos de equipos ágiles (ARTs) utilizan para crear soluciones de alta calidad para sus clientes.
• Portfolio Vision: la competencia de Lean Portfolio Management se ha reescrito como una capacidad organizada para alinear la estrategia con la ejecución, cumplir con los compromisos existentes de manera confiable y permitir una mejor innovación.
• Customer Centricity: el nuevo marco incluye Design Thinking para centrarse en sus herramientas y prácticas para poner al cliente en el centro.
• Essential Level: los niveles de equipo y programa (ART) se han unido en uno sólo que corresponde a la configuración essential.
• Continuous Delivery Clarity: se muestra más claridad en el flujo de exploración continua, integración continua y despliegue continuo en la ejecución de las iteraciones.

Las novedades de la versión 5.0 sobre el Big Picture de SAFe®

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

¿Dónde inspirarse para encontrar Leading Indicators?

Los Leading Indicators ayudan a los Propietarios del Producto
a tomar las decisiones acertadas - cortesía de Pixabay

Los Leading Indicator están tomando mucha importancia en el desarrollo ágil de software; este implica construir los mejores productos posibles de forma iterativa y con feedback frecuente, y los Leading Indicators son indicadores de feedback predictivo clave para el desarrollo ágil con una entrega máxima de valor.

Los Leading Indicators son cualquier indicador predictivo que cambia antes de que el resto de los indicadores económicos comiencen a ir en una dirección particular, nos sirven para detectar señales de advertencia tempranas y a tomar medidas decisivas mientras todavía estemos tiempo. No son indicadors precisos, pero ayudan a los observadores del producto en el mercado a tomar decisiones rápidas y acertadas, a Propietarios del Producto y Product Managers a decidir lo que construir y lo que no.

En entornos tradicionales estamos rodeados de Lagging Indicators, indicadores que miden el resultado final de nuestra estrategia y esfuerzos. Son fáciles de medir y nos dicen cómo nos está yendo como organización, pero en la mayoría de los casos son difíciles de influir o de mejorar directamente.

Veamos un ejemplo ilustrativo: Imaginemos que quiero adelgazar. Una medición clásica sería el peso, quizá al final del día o al final de la semana. El peso es un Lagging Indicator, la medición es a posteriori, a lo mejor me he esforzado mucho y he ido al gimnasio toda la semana, y resulta que no he perdido nada de peso, me he dado cuenta demasiado tarde. Un Leading Indicator sería medir las kcal que tomo durante el día, si me quedo un poco por debajo de las aproximadamente las 1800 kcal que necesita mi organismo al día, tengo todos los números de haber adelgazado al final de la semana.

Veamos un ejemplo de TI: imaginemos que queremos sustituir los diferentes logins de los sistemas de nuestra organización por un single-sign-on. Un Leading Indicator sería medir el aumento de single-sign-ons versus el descenso de logins individuales, esa tendencia nos muestra si nuestra idea de single-sign-on tiene o no éxito entre los empleados de la organización.

Leading indicators sobre el uso de historias de usuario, sobre la sustitución de funcionalidades como en el ejemplo del single-sign-on, sobre tests A/B en los que medimos que solución prefiere nuestro usuario o cliente, son una herramienta clave para que Propietarios del Producto y Product Managers tomen las decisiones adecuadas para construir el mejor producto posible, maximizando así el retorno de la inversión hecha en el mismo.

Podemos inspirarnos en el marco de Google HEART para encontrar Leading Indicators:

Google HEART Framework

y también en las Pirate Metrics de Dave McClure:

Dave McClure's Pirate Metrics

¿Todos los equipos de un área o una compañía han de tener el mismo tablero?

Introduciendo límites WIP: Los tableros
deben de estar en continua evolución

Hoyendía la mayoría de compañías ya tienen varios equipos ágiles trabajando; llegado un momento de mínima madurez la inercia tradicional lleva a estas a querer estandarizar las prácticas y procesos ágiles.

Nuestra mentalidad tradicional viene de la producción en masa, de la estandarización y de los productos commodity; la cuestión es que eso ya no funciona en nuestro mundo actual donde los proyectos y productos son de muy distintas naturalezas, de modelos de negocio dispares y de una hipersegmentación del mercado.

Para afrontar esa realidad necesitamos de la Agilidad y de equipos autoorganizados que hagan frente de forma adaptativa y flexible a esa realidad de proyectos y productos siempre cambiante. Visto esto podemos imaginarnos que los tableros de los equipos deben de ser únicos y haber evolucionado hacía aquella configuración que aporte más al equipo para que sean realmente una herramienta que les permita maximizar el valor entregado.

Tablero de un equipo de Kanban con multitud de estados

Una de las mejores formas para evolucionar hacia tableros útiles es mediante tableros físicos y post-its. Son una forma muy flexible de visualizar y ajustar continuamente el flujo de trabajo, permitiendo que cada equipo descubra su propio mejor proceso. Herramientas como JIRA llevan a que las personas se focalicen en aprender el proceso de la herramienta y limitan el descubrimiento del proceso propio y la mejora continua del mismo.

Como podemos ver los tableros que potencian al máximo a los equipos deben de ser únicos, lo que no significa que no pueda haber un patrón en común. Probablemente los flujos de trabajo y valor, y las políticas de la compañía lleven a un diseño con partes comunes.

Los tableros de equipos Kanban son los que más diferentes suelen ser. La metáfora para los equipos Kanban es la carrera de relevos; donde un especialista pasa el testigo al especialista del siguiente estado, donde los estados representan un flujo de trabajo o de valor muy específico. Cada equipo Kanban puede estar gestionando cosas muy distintas a los demás, por ejemplo el mantenimiento de un software, la venta y seguimiento de un producto, la planificación de un evento...

Tablero de Scrum o scrumboard (TODO, DOING, DONE)

En cambio los tableros de los equipos de Scrum suelen ser más homogéneos. Son equipos donde el enfoque es el holístico y su metáfora es el equipo de rugby, donde un equipo al completo, como un ente de nivel superior, intenta recorrer el campo como una unidad, pasando la pelota de un lado a otro.

Los tableros de equipos de Scrum suelen ser mucho más parecidos, aunque casi nunca iguales. Puede haber áreas específicas del equipo, convenciones de colores o de elementos del equipo que los hacen diferir de los demás.

Los Scrum Masters y coaches ágiles aprendemos a leer los tableros de los equipos, y percibimos que la madurez en Agilidad se puede leer en la diversidad de tableros de los distintos equipos de una compañía.

¿Cómo de importante es dar permiso para fallar?

Permitido fallar, para aprender...
Cortesía de Pixabay

Uno de los beneficios que nos traen los marcos ágiles como Scrum son entornos de confianza donde los individuos pueden exponer su opinión sincera, un entorno donde el coraje es un valor, donde se puede disentir y decir que "no" sin temor a consecuencias y donde el conflicto es sano y representa diversidad. Solo así conseguimos entornos en los que las planificaciones de sprint y las PI Plannings se tiñan de factibilidad y lleven al éxito, ya que los que van a hacer el trabajo crean esos planes y tienen toda la libertad para hacer planes en los que crean de verdad.

Para que todo esto ocurra es necesario aprender, y para aprender es necesario fallar. Quizá algunos conozcáis el vídeo de la bicicleta invertida; en ese vídeo Destin de Smarter Every Day nos muestra entre otros aprendizajes que para aprender a ir en bicicleta invertida hay que desaprender primero el ir en bicicleta normal. El mensaje de fondo es que para cualquier cambio, como lo es una transformación ágil, se requiere de un aprendizaje, y para aprender hay que caerse unas cuantas veces de la bicicleta y levantarse para intentarlo de nuevo.

Por tanto en una transformación ágil es necesario que la compañía como sistema falle rápido para aprender rápido, y para ello es necesario desbloquear el posible miedo al fallo de los individuos. Como coaches ágiles debemos de sugerir al CEO o a los altos directivos y líderes dar un mensaje muy explícito, como por ejemplo: "Tenéis permiso para fallar, fallad rápido, aprended rápido y haced grandes cosas".

No podemos esperar que los equipos lean un libro sobre bicicletas, o un marco ágil, y después ya sepan montar en bicicleta; hay que empezar a caminar, a caerse y a levantarse. Es esencial que los directivos lo entiendan y den mensajes que desbloqueen ese miedo a caerse.

Lo que importa es un ritmo de mejora continua sostenible
Cortesía de Pixabay

Cuando los equipos sienten que pueden fallar, son más valientes y se retan a ir un poco más allá de lo que creen que son capaces. Un equipo que se rete quizá solo llegue al 80% de lo que se ha propuesto, pero su coraje, su proactividad y su energía les habrá llevado a hacer mucho más de lo que hubieran hecho pensando en cumplir al 100% sus objetivos. Equipos que entregan el 100% de lo planificado son equipos que probablemente solo hagan lo de siempre, sin retarse ni evolucionar y sin mejorar de forma continua.

Uno de los mensajes más potentes que he oído fue de un directivo que dijo a todo el ART (Agile Release Train) de 80 personas, un equipo de equipos, que en el primer PI, ciclo de incrementos en entorno trimestral, el resultado podía ser un "piece of shit" que nadie quiera, y que eso no le importaba... lo que le importa es que el ART aprenda a colaborar y coja ritmo, ¡un ritmo sostenible de mejora continua! Les dio permiso a fallar, a rechazar, a decir que "no", y además les animó a planificar tiempo para aprender y explorar en sus sprints.

El fracaso no es fallar, el fracaso es no aprender

y fallar a ayudar y a pedir ayuda

En nuestra cultura es esencial este tipo de mensaje. Venimos de una cultura del pecado original, del juicio ajeno y del "no" como primera opción. Para que nuestros equipos hagan grandes cosas solo los líderes pueden desbloquear esos comportamientos que tanto tiempo nos han impregnado.