Cómo gestionamos las dependencias entre los equipos

Entradilla…

Si preguntas a un/a usuario/a qué quiere que haga su producto, lo más probable es que te conteste: “Todo”. Todas las funcionalidades son importantes, prioritarias y necesarias para él/ella. Sin embargo, no vas a poder construir todas las funcionalidades a la vez, por lo que tendrás que conseguir una priorización inicial, sobre todo si para construir el producto necesitas además de la colaboración de varios equipos y/o departamentos.
Esta priorización inicial nos proveerá de un roadmap sobre el que podremos y deberemos hacer ajustes según el feedback que recibamos de los usuarios en cada entrega, sobre todo si utilizas un enfoque iterativo e incremental.

Sin embargo, ocurre que a veces en las empresas los productos se crean sin dedicar tiempo a esa identificación de dependencias inicial y cuando los desarrolladores empiezan a crear el producto, surgen bloqueos que pueden llevar hasta la paralización del desarrollo. Por eso te proponemos que levantes estas conversaciones lo antes posible.

Para identificar las dependencias del resto de equipos puedes reunirte por separado con cada uno de ellos e identificar las necesidades y cómo se van a resolver. Pero, desde nuestra experiencia, esta solución consume mucho tiempo y es probable que perdamos información de una conversación a otra o que surjan nuevas dependencias que necesiten de nuevas reuniones. En su lugar te proponemos una solución que hemos aplicado en nuestros clientes y que te ayudará a identificar las dependencias y alinear a todos los participantes.

Reúne a todos los involucrados

Lo primero que necesitas es que todos los involucrados participen en todas las conversaciones con el objetivo de evitar el efecto “teléfono escacharrado” donde el mensaje se desvirtúa según pasa entre los diferentes oyentes. Todas las opiniones son útiles y necesarias. Convócales explicando qué esperas que ocurra en la sesión y cuál es el objetivo a lograr. Es importante que, si las agendas de estas personas suelen estar llenas de otras reuniones o eventos, intentes convocarles con anticipación suficiente para que puedan asistir. Si no pueden asistir, pueden enviar a alguna persona de su equipo.
Estas sesiones pueden llevar varias horas si el nivel de incertidumbre del que partimos es elevado, por lo que es probable que haya que hacer más de una sesión para resolver las dependencias.

Identifica los usuarios

Comienza identificando los usuarios que van a recibir el producto. Parece algo demasiado obvio, pero es necesario que todo el mundo sepa qué tipo de usuario va a recibir el producto. En función del usuario en la mayoría de productos se habilitan diferentes funcionalidades, se muestran datos diferentes, nuevos flujos de navegación, …
Para registrar toda la información te recomendamos que utilices un panel visual, físico o remoto en función de cómo se desarrollen las sesiones. Utiliza un postit diferente para cada usuario, y registra la información más relevante al lado.

Tablero de usuarios

Identifica las funcionalidades

Ahora es el momento de identificar las funcionalidades del producto. Puedes utilizar los documentos que existan hasta ese momento con la definición del producto. Es mejor si todos los participantes ayudan a identificar las funcionalidades. Para reflejarlo en el panel, te recomendamos que sigas estos pasos:

  1. En la parte superior identifica los grandes bloques de funcionalidades del producto. Puedes utilizar postits más grandes, incluso un color diferente para cada bloque. Si puedes, ordénalos de izquierda a derecha según la interacción del usuario. Por ejemplo, para Twitter podría ser: Registro – Inicio sesión – Ver tweets – Escribir tweet – Interacción con tweets – Tendencias – …
  2. A continuación, debajo de cada bloque coloca las funcionalidades que se necesitan para completar cada una de las acciones. Intenta escribirlo en un lenguaje suficientemente claro para que todos los participantes entiendan lo que se espera de cada funcionalidad. Cada una de las funcionalidades irá en un postit separado y del mismo color que el bloque.
  3. Por último, traza una línea horizontal debajo de los elementos necesarios para un primer entregable a los usuarios. En el caso de productos nuevos, estos son los elementos mínimos que se necesitan para tener la primera versión viable del producto, el MVP (Mínimo Producto Viable). Si vamos a tener diferentes entregas después del MVP, puede añadir más líneas horizontales con las funcionalidades que se desean añadir en cada una de ellas.

Guarda una foto o captura de este panel, ya que utilizaremos estos postit en los siguientes pasos.

Customer Journey

Identifica las dependencias

Ahora vamos a construir un nuevo panel para identificar las dependencias de la primera entrega. Para ello será necesario que los participantes ordenen las funcionalidades en una única columna ordenada de mayor a menor aporte de valor. Recupera los postits del panel de funcionalidades o crea una copia de todos ellos para este nuevo panel. Una vez construida la pila, vamos a recorrer una a una cada una de las filas identificando los usuarios que recibirán la funcionalidad y los equipos que tienen alguna dependencia en la funcionalidad. También puedes dejar un espacio en cada fila para registrar alguna información relevante que surja durante la conversación. Aquí es el momento en el que se deben levantar todas las necesidades. Puede ocurrir que en función de las dependencias detectadas la priorización varíe.
Aunque puedes realizar este proceso sobre todas las entregas, nuestra recomendación es que os enfoquéis en la primera entrega. Una vez esté todo listo, incluso con los equipos ya desarrollando, podéis empezar las conversaciones de las siguientes entregas. De esta forma, podéis incorporar el feedback a las sesiones y variar la priorización inicial.

Tablero dependencias

Al finalizar la sesión tenemos una lista de funcionalidades priorizada por aporte de valor al usuario en la que se han identificado los diferentes equipos que intervienen para construirlas. Como ves este proceso llevará algún tiempo a todos los participantes, pero en única conversación con todos ellos involucrados gestionaréis las dependencias antes de que se conviertan en un problema para el producto.

 

Bonus Track:

Cuando queremos conceptualizar un producto, en Agile solemos utilizar métodos como la Agile Inception o Lean Inception. Estos métodos de conceptualización nos permiten realizar un proceso de investigación e indagación para encontrar la mejor solución al problema que necesitamos resolver con nuestro producto. Si hacemos el proceso completo, obtendremos como uno de los resultados, la lista de funcionalidades de nuestro producto incluyendo el trabajo de todos los equipos implicados.

 

También te puede interesar.

Ventajas de aplicar el Lead Time en los Equipos Scrum

En ocasiones, cuando arrancamos con los Equipos Scrum, nos encontramos con un par problemas habituales: el tamaño de los PBIs y que trabajan en paralelo en todas los PBIs del sprint. Hoy te traigo una solución que hemos puesto en marcha en algunos Equipos Scrum de nuestros clientes.

Entender a los Equipos Scrum desde las Métricas

En nuestro trabajo diario con los equipos Scrum, es importante entender qué está ocurriendo sprint a sprint, y en qué lugares debemos poner el foco de las acciones de mejora de los equipos. También es importante disponer de datos objetivos, que en las sesiones de retrospectiva o de revisión del proceso, nos ayuden a tomar decisiones basadas en la realidad, y no en sensaciones u opiniones subjetivas.

Scrum para disipar incertidumbre

Scrum es un marco que te puede servir para hacer lo mismo de siempre a trocitos. Sin embargo, puedes utilizar Scrum de manera inteligente y sacarle toda su potencia. ¿Cómo? Orientándolo a generar certezas sobre tu producto o tu mercado.

Cómo convivir con las incidencias en un Equipo Scrum

En los Equipos Scrum que desarrollan nuevo software y mantienen el ya existente, es muy habitual tener que lidiar con incidencias provocadas por el software en producción. Su gestión es complicada ya que interrumpen directamente nuestro plan para el sprint, y al producto ya priorizado en el Product Backlog.

Como empezar como Scrum Master

Acompañar a equipos es una gran responsabilidad pero es muy gratificante. Cada persona y cada equipo tiene unas necesidades diferentes en función de su realidad. Sin embargo, bajo nuestra experiencia, estos consejos pueden servirte para iniciarte como Scrum Master en un equipo.

Cómo mejorar tu Scrum Daily

En ocasiones nos encontramos con equipos en los que la Scrum Daily se ha convertido en un evento individualista donde cada miembro del equipo de desarrollo comenta las tareas realizadas durante el día anterior, muchas veces con cierto carácter de reporte. Sin embargo, la daily es un evento colectivo donde a través de la inspección y adaptación se traza un plan de trabajo del día para el equipo.

Beneficios de la automatización en los equipo Scrum

La automatización, cada vez más, forma parte del desarrollo del software. ¿Qué beneficios tiene para los equipos Scrum?

Es importante usar Historias de Usuario

Usar Historias de Usuario es importante para los Product Owner, además de la más utilizada a la hora de escribir el Product Backlog.

Apoya a tu equipo entendiendo qué le ocurre

La transparencia es uno de los pilares de Scrum. Con ella conseguimos hacer visible lo que ocurre dentro del producto, equipo, personas, … para hacer inspección y adaptación. ¿Cómo podemos saber qué ocurre en el equipo para poder apoyarle?

Monta equipos Scrum de éxito

Cómo montar equipos Scrum de éxitoYa sabes lo que es un equipo Scrum. Es hora de dar un paso adelante y entender cómo montar un equipo Scrum de éxito. ¿Qué tipo de perfiles incorporas? ¿Cómo se balancean? ¿Cuándo les incorporas? Son preguntas que probablemente te...

0 comentarios

Enviar un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Aceptarás nuestra política de cookies si continúas navegando.

ACEPTAR
Aviso de cookies