miércoles, 12 de junio de 2019

¿Cómo gestiona SAFe las dependencias de los equipos con otros equipos internos y externos?

Siempre que formo a los alumnos sobre la PI Planning y hablamos del Program Board de SAFe® hay cierta curiosidad y desacuerdo. Recordemos el Program Board; es uno de los tableros output de la PI Planning que muestra en qué sprint (iteración) una determinada feature está prevista que esté terminada, así como las dependencias significativas de esa feature, si las hubiera, sea una historia de usuario, una tarea o una actividad:
Program Board con la visión a nivel de tren - imagen del tema PI Planning cortesía de © Scaled Agile, Inc.
El desacuerdo suele producirse porque en las realidades de la mayoría de mis alumnos lo que ponen en el Program Board son todas aquellas historias de usuario que tienen dependencias entre si, la historia dependiente unida a la historia de la que depende. De hecho en algún tren donde he actuado de coach ágil hemos utilizado tableros de estas características, con dependencias entre historias de usuario, útil pero menos potente que un auténtico Program Board.

La disfunción en estos casos resulta en tableros con dependencias entre historias de usuario que acaban siendo muy poblados en post-its y con una intrincada maraña de hilos, útil sin duda pero ilegibles desde el punto de vista holístico del tren (ART). El Program Board, tal como lo describe SAFe, muestra todas las dependencias desde la perspectiva del nivel de tren, las features. Cuando se celebran los Scrum de Scrums y las PO-Sync ante el Program Board lo que interesa es la lectura del progreso del tren versus las features, no versus las historias de usuario que a priori solo son de interés a nivel de equipos.

En la propuesta de SAFe la gestión de dependencias no se limita al Program Board, en los tableros donde se refleja la pila (de producto) del equipo, un tablero output de la PI Planning donde el equipo ha distribuido de froma preliminar las historias en los sprints del PI, se reflejan las dependencias en las propias historias de usuario afectadas. Concretamente si una historia tiene una dependencia, SAFe sugiere poner un post-it rojo que describa la dependencia y cuando la dependencia se ha tratado y resuelto con el equipo correspondiente se le añade una marca de verificación.
Gestión de las dependencias a nivel de equipo
De esta manera tenemos la gestión de dependencias agregada a nivel de tren y la gestión de las mismas en cada uno de los equipos en la parte que le pertoca y con toda la información local que precisan.

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

lunes, 3 de junio de 2019

¿Cómo potenciar las PI Plannings de un Solution Train?

Distribución salas PI Planning y espacio comun
Una de las zonas más grises del marco de SAFe® es la capa Large Solution, ya que en ella hay escasas posibilidades reales de conseguir una autoorganización como ocurre en los ARTs y en los equipos. Tal como nos explica Dunbar, para que haya autoorganización a nivel de tribu o red social, no podemos superar los 125+ individuos en el tren y por ende en la PI Planning.

Recordemos que la PI Planning es el heartbeat de SAFe, el latido del corazón del marco. Si nos situamos en un excelente punto de partida, alineados entre equipos de desarrollo y negocio y con las dependencias significativas resueltas, todos los demás eventos son de menor importancia. Con un buen punto de partida solo es necesario reaccionar y ajustar en menor medida para mantener al tren en la dirección de máximo valor de negocio.

Si hubiera forma de introducir mínimos niveles de autoorganización en PI Plannings paralelas obtendríamos un mejor punto de partida que maximizaría la entrega de valor del Solution Train y por ende los beneficios económicos de la compañía.

Los RTEs tenemos nuestros foros en los que compartimos muchas experiencias de todos tipos, y hay una expuesta por Matt que me llamó mucho la atención. Él es RTE en un tren que junto con otros 3 forma parte de un Solution Train. Haciendo homenaje al sexto principio del Manifiesto Ágil que dice que la mejor comunicación ocurre cara a cara, su compañía reúne a todos los integrantes de sus trenes para las PI Plannings en una sola localización (hotel o centro de negocios).

Las cuatro PI Plannings individuales ocurren en 4 grandes salas individuales que están unidas por un pasillo o hall que permite ser punto de encuentro para representantes de los 4 trenes. En este espacio están el STE, Solution Arquitect y Solution Managers, y es donde se colocan los program boards de los trenes individuales junto al solution board del Solution Train. Cada dependencia individual se lleva a este espacio de manera que es visible para todos los trenes. RTEs, System Arquitects y Product Managers así como Business Owners y miembros de los equipos tienen aquí un punto de convergencia con otros trenes. Esta configuración potencia enormemente la comunicación y coordinación entre trenes, muy en dirección autoorganización y que probablemente sea una ventaja competitiva diferencial para la compañía. 

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