Comunicación entre equipos de proyectos ágiles y servicios compartidos

Crear comprensión compartida y grandes imágenes visuales

Primero, no entre en pánico, sea ágil o no, este es un problema con cualquier entrega que requiera coordinación.

Lo que desea buscar son herramientas que ayuden a crear un entendimiento compartido y que ayuden a las personas a discutir el panorama general. Si bien las historias de usuarios son útiles, aún pueden ser limitantes. Le sugiero que haga un mapa de su producto utilizando una historia o un mapa de viaje. Estos mapas actúan como una narrativa visual que captura cómo un equipo de producto cree que se desarrollará una experiencia de usuario general y luego se puede explorar con los equipos y desglosar para descubrir cómo los equipos la coordinarán.

Aquí hay un enlace al sitio de Jeff Patton para obtener más información. Recomiendo descargar su presentación de PowerPoint que lo guía a través del proceso para ayudarlo a probarlo. Le ayudará a evitar crear un mapa de características.

https://www.jpattonassociates.com/storymappingslides/

TL;RD

[C]omunicación de los requisitos deja mucho que desear.

Este es tanto el núcleo de su problema como su ruta hacia la mejora del proceso. Parece probable que le falten Product Owners y Product Backlogs para cada equipo, y que no tenga una coordinación adecuada en el nivel de Scrum-of-Scrums.

Además de cubrir los roles faltantes y generar los artefactos Scrum necesarios, su organización puede aprovechar las historias de los usuarios para mejorar la comunicación entre equipos.

Mejorar la comunicación entre equipos con historias de usuarios

Incluso sin los roles y artefactos correctos para coordinar los equipos, puede mejorar sus procesos significativamente asegurándose de no arrojar "requisitos" por encima de la pared entre los equipos. En cambio, los equipos deben intercambiar historias de usuarios que puedan usarse para facilitar las comunicaciones directas entre los miembros de cada equipo.

Por ejemplo, si un equipo de proyecto que construye un nuevo sitio web necesita servicios de base de datos, podría haber una historia de usuario que diga:

Como usuario de un sitio web,
necesito que la base de datos devuelva el tamaño de mi widget ampliado en codos
para poder realizar un pedido de un widget acogedor.

Luego, esta historia se comparte con el equipo de la base de datos, que el propietario del producto de DBA puede colocar en el Product Backlog del equipo de la base de datos y priorizar en coordinación con el propietario del producto del equipo web. Ese es el ideal por el que debes luchar.

De lo contrario, la historia del usuario aún funciona como punto de partida para las conversaciones entre los miembros del equipo web y el equipo de la base de datos. No es una especificación completa, ni pretende serlo. Es un mecanismo para proporcionar contexto entre los equipos, de modo que ambos equipos tengan un marco de referencia común mientras elaboran los detalles de implementación.

En mi trabajo diario, solía tratar el tema de los equipos ágiles distribuidos y la comunicación dentro/entre equipos. Recientemente he representado algunos (en mi opinión) consejos útiles. Los detalles los encuentras en la publicación .

Este artículo resume varias mejoras en la comunicación que se introdujeron en uno de los grandes proyectos en los que he estado trabajando. Para darle un poco de contexto, se trata de la colaboración en el modelo de deslocalización donde los equipos están ubicados en diferentes países europeos.

En la publicación, sugiero introducir las siguientes mejoras:

• no tenga miedo de visitar al cliente y trabajar en tierra
• hacer que todas las partes interesadas se familiaricen con el proceso
• retroalimentación regular sobre los procesos
• ritmo de reuniones diarias y semanales
• roles de comunicación competentes
• directrices claras sobre cómo crear backlog (historias de usuarios, mapas de historias, etc.)
• la institución proxy del propietario del producto: configúrelo internamente de su lado
• robusta herramienta de seguimiento de proyectos utilizada para los intercambios entre los miembros del equipo

Reorganizarse en equipos de características

Puede evitar estos problemas de comunicación reorganizándose en equipos de funciones. Aquí hay dos buenas referencias:

• Alejarse de los equipos de componentes es un paso difícil pero necesario para quienes desean adoptar un enfoque ágil de gestión de proyectos.
• Sin una estructura de equipo de características (sino, en cambio, una organización de equipo de componentes...) es probable que su organización cree numerosos desperdicios y suboptimizaciones que conducen a un ciclo de desarrollo secuencial (en cascada,...).

Si eso no es posible, configure las reuniones de Scrum-of-Scrum como lo sugiere @CodeGnome. Más sobre eso aquí:

• Aunque no es lo único necesario para escalar Scrum, una técnica muy conocida es el uso de una reunión "Scrum de Scrums". Con este enfoque, cada equipo Scrum procede con normalidad, pero cada equipo identifica a una persona que asiste a la reunión Scrum de Scrums para coordinar el trabajo de varios equipos Scrum. Estas reuniones son análogas a la reunión diaria de Scrum, pero no necesariamente suceden todos los días. En muchas organizaciones, tener una reunión de Scrum de Scrums dos o tres veces por semana es suficiente.

Al leer su publicación original, noté que dijo "los equipos de productos crearon bibliotecas que duplicaron... lo que los equipos de servicios compartidos habían hecho hace un año". Es muy importante en el caso de los servicios compartidos que todos puedan ver exactamente qué servicios compartidos están disponibles y exactamente qué proporcionan o proporcionarán.