Hace más de una semana publiqué en Twitter un hilo sin mucha repercusión sobre los PI Planning de SAFe y el mal uso que se hace de esta práctica en muchos sitios. Voy a tratar de desarrollarlo un poco mejor en este artículo.
Para empezar, SAFe es un marco de trabajo diseñado para tratar de llevar Agile a grandes organizaciones. Es lo que conocemos como un framework de escalado Agile (que es justamente lo que significa SAFe: Scaled Agile Framework). Creado por Dean Leffingwell, ya va por la versión 4.6, lo cuál indica que ha ido cambiando a medida que los consultores que lo trataban de desplegar en diferentes clientes se iban encontrando con impedimentos y desarrollaban soluciones para los mismos. No es raro, pues, que la imagen con la que se le representa ahora mismo sea así de elaborada.
SAFe es, básicamente, un conjunto de buenas prácticas, empaquetadas para que puedan ser utilizadas directamente en la mayoría de grandes organizaciones. No es necesariamente una mala solución a los problemas que identifican la mayoría de los CTOs, CIOs y similares: baja velocidad de desarrollo de las funcionalidades que deben recibir los clientes, descoordinación en la planificación de los proyectos, etc. Muchos hacen algún proyecto piloto aplicando Scrum o cualquier otro método Agile, y se convencen de que ése es el camino para toda la organización; pero no saben por dónde empezar. SAFe trata de responder a esa pregunta.
El PI Planning
El PI Planning es una de las prácticas más significativas de SAFe, y una de las que provoca más quebraderos de cabeza a las organizaciones pues, en mi opinión, no se entiende del todo bien en qué ámbito debe aplicarse (que no es toda la organización, ni mucho menos).
La definición oficial de PI Planning dice esto:
«Es un evento cara a cara, basado en una cadencia, que actúa como el latido del Tren de Entregas Agile (Agile Release Train o ART), alineando a todos los equipos de ese ART hacia una misión y una visión compartidas.»
El Tren de Entregas
De nuevo, de la definición oficial de SAFe:
«Es un equipo duradero de equipos Agile, el cuál, junto con otros interesados (stakeholders), desarrolla incrementalmente, entrega, y donde es posible también opera, una o más soluciones en un flujo de valor (value stream).»
Y sigue:
«Los trenes de entregas Agile (ART) alinean a los equipos hacia una misión de negocio y tecnología común. Cada uno es una organización virtual (típicamente entre 50 y 125 personas) que planea, se compromete, desarrolla y despliega junta. Los ARTs se organizan alrededor de los flujos de valor (value streams) significativos de la empresa, y solamente existen para hacer realidad la promesa de ese valor mediante la construcción de soluciones que lleven algún beneficio al usuario final.»
N equipos no son un equipo de equipos sólo porque alguien decida que tienen la obligación de trabajar juntos, sino porque tienen la necesidad de trabajar juntos para aportar valor a los clientes (a los de verdad, no a los «clientes internos»). A eso es a lo que llamamos «value stream». Parece obvio, ¿verdad? Sin embargo, es curioso la poca atención que se presta a esto.
Las dependencias
Sospecho que PI Planning tiene mucho éxito en las grandes organizaciones porque parece una buena idea para coordinar las planificaciones de los muchísimos equipos involucrados en el desarrollo de sus proyectos. Seguramente por eso muchos dicen estar haciendo «una adaptación propia de SAFe» y en realidad lo único que hacen de SAFe es una mala interpretación del PI Planning. Me recuerda a esos equipos que dicen estar haciendo Scrum porque se reúnen de pié todas las mañanas.
Las dependencias identificadas durante un PI Planning nos indican que hay equipos que dependen unos de otros. Hay muchas razones para que esto suceda. Lo malo no es que suceda sino que no hagamos nada para modificar el sistema: para transformarlo.
Puede que los backlogs contengan funcionalidades mal «cortadas», que los equipos no tengan todas las disciplinas para ser autónomos, que los sistemas sólo puedan ser «tocados» por algunos especialistas… todo eso se puede (y debe) cambiar si queremos ser ágiles.
Puede incluso que haya equipos «artificialmente» presentes en ese evento del PI Planning. ¿Cómo distinguirlos de los que forman parte del mismo Value Stream? Fácil: los que dicen que no saben qué pintan en el PI Planning. El problema es saber a qué Value Stream pertenece cada equipo. Sin embargo, no deberíamos conformarnos tampoco con la opción: «Yo es que no pertenezco a ningún Value Stream». Porque entonces, ¿a qué clientes aporta valor? ¿por qué es tan específica esa aportación de valor? Mmmmm….
La clave de todo este embrollo está en una palabra presente en la definición de PI Planning, al principio de este artículo:
«…alineando a todos los equipos de ese ART hacia una misión y una visión compartidas.»
La Visión
Sí, efectivamente, la Visión. Sin un propósito común no hay equipo y, por tanto, tampoco un equipo de equipos (llámale tribu).
La definición oficial de SAFe:
«Es la descripción del estado futuro de la solución en desarrollo. Refleja las necesidades del cliente y el resto de interesados, además de las características (features) y capacidades (capabilities) propuestas para satisfacer esas necesidades.»
Yo le pongo bastantes peros a esta definición porque es fácil entender que una Visión es apenas una especie de Épica, es decir, un proyecto con una gran incertidumbre. Más que nada porque si esto fuera así, el equipo de equipos tendería a ser menos duradero de lo que, al menos a mí, me gusta. Seguramente porque yo prefiero verdaderas tribus (equipos de equipos, con una identidad cultural fuerte, para los que tener una visión estable y fuertemente aspiracional es importantísimo).
En cualquier caso, incluso que la Visión fuera uno de estos ambiciosos proyectos, ya me valdría para sustentar mi opinión de que muchos de los PI Planning que vemos frecuentemente no convocan a ningún ART pues ponen el foco sólo en la planificación (que es artificial y decidida por quien haya diseñado la organización) y no tanto sobre el flujo de valor («value stream»).
Conclusiones
En resumen, creo que el PI Planning es una gran oportunidad para transformar a una organización, pero para ello debemos estar dispuestos a no conformarnos con gestionar las dependencias, sino que debemos aprovecharlas como señales para guiar la transformación.
Algo de esto ya conté sobre mi experiencia en BBVA el año pasado.
Sólo añadir dos cosas:
1) #SAFe no es más que un paso intermedio para desbloquear los primeros pasos hacia una verdadera agilidad empresarial. Un conjunto de prácticas que pueden ayudar a responder a preguntas como «¿y esto cómo lo hacemos?», pero rápidamente habría que aprender a cambiar solos.
Ese concepto de «estado intermedio» lo traté de explicar hace tiempo:
y 2) Es conveniente entender las fuerzas que intervienen sobre los equipos ágiles cuando tratamos de escalar. Tengo una presentación aquí que igual ayuda a entenderlo mejor.
Si hay presión social, prometo escribir sobre ello. De momento, nada más. Si te apetece, continuemos la conversación en los comentarios más abajo.
DISCLAIMER: Siento si alguna traducción ha ofendido a alguien. Fue sin intención. 🙂