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. - Gracias a los lectores que le dan sentido a este blog

8 comentarios:

  1. Muy interesante. Nosotros con nuestros equipos nos centramos más en el panel del "road map" o "pi planning" del equipo, pero como digo es para el equipo y es el que más aporta.
    El Program Board me parece muy potente y lo realizábamos en anteriores ocasiones pero detectábamos que teníamos que elegir entre este y el "pi planning" del equipo y acordamos centrarnos en el de equipo porque les aportaba más.
    Aunque como comentas son paneles para diferentes niveles de escalado, equipo y programa.
    Me ha gustado mucho el artículo y me ha aportado, gracias!!!

    ResponderEliminar
    Respuestas
    1. Hola,

      Me alegro mucho que aporte, sé que hay mucha confusión sobre como gestionar las dependencias en un Program Board y por ello escribí el post. Gracias por escribir, aportar a los demás es mi mayor recompensa.

      Saludos,

      Alex

      Eliminar
  2. Hola! Sería posible me compartieras la herramienta con la cual hiciste el tablero, es justo lo que estoy buscando

    ResponderEliminar
    Respuestas
    1. Hola,

      Hasta antes del COVID hacíamos los tableros sobre una gran lámina de foam (papel pluma), post-its y lana roja que sujetábamos con chinchetas. Actualmente utilizamos herramientas digitales como la PIPlanning.App o la plantilla PI Planning de Miro que funcionan muy bien y hasta se pueden vincular a Jira.

      Puedes crearte una cuenta de Miro gratuita y explorar sus posibilidades.

      Espero haberte ayudado, saludos,

      Alex

      Eliminar
  3. Agradecimientos en LinkedIn como el de este link son un reconocimiento que hacen que me sienta recompensado y que con este blog hago una labor que importa. ¡Gracias Alejandro!

    ResponderEliminar
  4. Alexander muchas gracias por tu aporte, pero me surge una duda, si tengo 4 equipos de 8 personas cada una, a esa reunión donde se gestionan los impedimentos debe ir el Scrum Master del equipo como tal? entendiendo que el es el responsable de gestionar los impedimentos, o debería ir todo el equipo? lo que no me queda claro es como se llega a un acuerdo con relación a las dependencias, es una conversación del equipo, es entre SM. quedo atento a tus comentarios. Gracias

    ResponderEliminar
    Respuestas
    1. Hola Alexander,

      La clave no está en gestionar dependencias, sino en identificarlas y resolverlas y comprometerse. Los que deben de hablar son los miembros implicados de ambos equipos, a veces puede ser una persona de cada equipo, a veces varias, a veces los equipos al completo. El Scrum Master solo se asegura de que ocurra y que se haya resuelto, no es parte activa.

      La pregunta que puedes hacerte es la siguiente: ¿las personas que están tratando una dependencia concreta son las que van a hacer el trabajo y tienen todo el poder de decisión para poder comprometerse?

      Espero haberte ayudado,

      Alex

      Eliminar
    2. Excelente Alexander. Muchas gracias por tu ayuda. Saludos.

      Eliminar