Buen enfoque para agrupar diferentes historias de proyectos en los mismos sprints

¿Consideraría que es un buen enfoque agrupar diferentes historias de usuarios de diferentes proyectos en un solo sprint? ¿Alguna vez has detectado pros/contras?

Digamos

1. Project A (Start 2017-01-05 Estimate End 2017-05-30)
   US_A1
   US_A2
   US_A3
   US_A4
2. Project B (Start 2017-03-01 Estimate End 2017-07-30)
   US_B1
   US_B2
   US_B3
   US_B4

Sprint de 2 semanas cuando las fechas de los proyectos se superponen y tiene la misma cantidad de personas para todos sus proyectos, pero tiene múltiples maestros Scrum (uno por proyecto) y un equipo

**Sprint 8 (Prj A & Prj B)**
US_A2
US_A4
US_B2
US_B3

Última actualización 25 de julio de 2019

Olvidé mencionar que la empresa realiza múltiples iteraciones incrementales para mejorar un software/suite. Cada proyecto representa los requisitos de los clientes de diferentes unidades de negocio. Es por eso que solo hay un grupo de desarrolladores para el software, pero muchos gerentes de proyecto con diferentes objetivos, con diferentes historias que pueden superponerse en el tiempo y quizás en los objetivos.

¿Cuántos desarrolladores (personas que producen el incremento de producto en cada Sprint) tiene en un equipo?
@onedaywhen Alrededor de 8 desarrolladores. El software es solo uno con características incrementales por proyecto/cliente.

Respuestas (4)

Habiendo trabajado así, con un solo equipo trabajando en múltiples proyectos al mismo tiempo, en múltiples ocasiones, he identificado numerosas razones para no hacer esto y exactamente ninguna para trabajar así.

En última instancia, pondrá a prueba o fracturará al equipo, drenará la motivación, reducirá la productividad y lo dejará con dos proyectos fallidos.

Varias compañías intentaron hacer esto de varias maneras diferentes, pero ninguna de ellas funcionó al final.

Intentamos abordar los problemas de dos retrasos con todo el equipo. Las principales desventajas eran cambiar constantemente de contexto, lo que generaba una gran sobrecarga, y las peleas inevitables con el PO sobre qué historias del proyecto debían descartarse cuando no lográbamos el sprint. Hacer un proyecto primero y el segundo después hizo que las peleas empeoraran en intensidad; hacer una historia de cada uno a su vez los hizo más comunes a medida que la sobrecarga reducía la velocidad.

También intentamos asignar a algunas personas para que trabajaran principalmente en un proyecto, algunas personas en el otro y algunas compartidas, con la idea de que ambas partes ayudarían si uno u otro proyecto fallaba. Este fracturó a todo el equipo en semanas, con cada lado trabajando en un solo proyecto y sin preocuparse realmente por el otro, perdiendo la noción de la experiencia del dominio y el progreso necesario para el otro proyecto y luego simplemente molesto por tener que unirse. reunión para un proyecto del que no formaban parte. Básicamente, el equipo terminó dividiéndose en dos equipos, uno para cada proyecto, pero eso causó mucho dolor y pérdida de productividad.

Luego también intentamos trabajar en un proyecto para un sprint, luego el otro proyecto para un sprint, etc. Esto funcionó un poco . Tiene menos problemas del primer enfoque porque cada proyecto está en un marco de tiempo claro, pero le costará mucha flexibilidad cuando suceda algo importante en el Proyecto A, pero acaba de comenzar un sprint para el Proyecto B, y luego terminar con la misma pelea prioritaria.

Mi mejor consejo: no lo hagas. Una persona, un equipo, un proyecto, un objetivo. Cualquier otra cosa que no sea eso le costará toneladas de moral y productividad, sin ninguna ganancia. Lectura obligatoria.

Además, como nota final, pregúntate por qué quieres hacer esto. Literalmente, no hay razón para considerar esto; puedes hacer ambos proyectos en serie. Complete el proyecto A y luego complete B una vez que haya terminado A; si pudiera completar con éxito ambos en paralelo, siempre podrá completarlos más rápido en serie. Cualquier razón para comenzar ambos a la vez probablemente se deba a que ya admitió que va a fallar en ambos proyectos de todos modos, y está tratando de mitigar los daños al tener algo que mostrar en la fecha límite para convencer a las personas de que necesita más tiempo. /dinero sin que se retiren. Invierta su tiempo solucionando ese problema y deje que su gente se concentre en una cosa a la vez, así es como trabajarán mejor.

Todo lo que describiste que "discutiste" habría sido trabajo del PO para decidir . No debería haber habido discusiones, al menos no del equipo. He trabajado en equipos de varios productos y, siempre que haya una orden de compra con un conjunto de prioridades, no debería haber discusiones. Puede que no sea el trabajo de PO más agradable con discusiones constantes con las partes interesadas, pero eso no debería preocupar al equipo.
@nvoigt bastante justo. Ampliaré esto con la historia de cómo el PO renunció porque tener que hacer dos proyectos con las partes interesadas que se quejaban lo estresaba, cuando tenga más tiempo. Debería ser el trabajo del PO, pero el PO odiará su trabajo si protege al equipo de desarrollo, y el equipo de desarrollo odiará su trabajo cuando el PO se dé por vencido.
También lo he visto, solo culparía a no empoderar al PO para que realmente haga su trabajo. El problema no son dos (o más) proyectos, porque incluso con un solo proyecto puede haber partes interesadas con diferentes prioridades. El problema es que la OP no cuenta con el respaldo de la alta gerencia para decirles a sus partes interesadas que trabajen juntos de manera constructiva o que se larguen. Si la OP tiene que ceder ante cada demanda que hace una parte interesada... entonces no es una OP tal como se define.

Puedes tener varios proyectos. Puedes tener varios equipos. Pero:

  • Una persona solo puede estar en exactamente un equipo (1)
  • Un maestro Scrum es por equipo, no por proyecto.

Con esas limitaciones, su plan no funcionará de ninguna manera. La mejor opción podría ser formar un equipo, poner ambos proyectos en la cartera de pedidos y trabajar en ellos. Puede arrastrar elementos de trabajo de múltiples proyectos diferentes a un sprint tal como lo dijo. Pero tendrá un maestro Scrum y un propietario del producto.

Alternativamente, si desea dos equipos, forme dos equipos, dos Scrum masters, dos propietarios de productos y dos backlogs.

(1) (mi experiencia me dice que cualquier forma de burlar esta regla fallará gravemente, porque no puede haber ni enfoque ni compromiso , dos de los cinco valores fundamentales, si alguien está en varios equipos).

Gracias por su respuesta. Estamos muy limitados de personas. La plataforma es estándar pero tiene diferentes módulos para diferentes unidades de negocio. El equipo Scrum son los expertos en obtener un consenso para desarrollar las historias de 2 proyectos en un sprint. Estamos haciendo ambos proyectos para diferentes clientes. Tenemos un propietario de producto y 3 gerentes de proyecto que los estamos traduciendo incorrectamente a Scrum master. En este punto deberíamos llegar a los roles 3 PM (2 activos para los prjs), 1 SM, 1 PO y 1 ST? ¿Las 2 PM estarán muy limitadas en su rol de solo negociar con los clientes?
No estoy en posición de decirle cómo hacer uso de su gente. Pero no hay Gerentes de Proyecto en Scrum. Scrum master tiene poco que ver con la gestión de proyectos. El más cercano podría ser PO, pero incluso eso no es un equivalente directo. Puede usar el PM como proxy para el cliente si el cliente no quiere ser ágil también. O podría volver a capacitarlos si así lo desean . O puede decirles que busquen un trabajo de PM en otra empresa. Pero no puede simplemente hacer que continúen enviando mensajes privados. Eso no funcionará. Ágil es o bien. Lo haces o no lo haces. Una combinación fallará peor que permanecer como C&C.
Eso es lo que leí la semana pasada en un libro: PM necesita adoptar un enfoque ágil, si no, no debería estar a cargo de los proyectos. Como dijiste, PM podría funcionar como proxy con el cliente que normalmente no quiere trabajar de forma iterativa. Algunos sí, otros no. Pero supongamos que el equipo de Scrum entrega múltiples entregas rápidas y si el gerente del proyecto las retiene para mostrar todo como un paquete al cliente, esto creará un cuello de botella y podríamos trabajar nuevamente como una cascada rompiendo la filosofía ágil.
@MaximusDecimus En mi opinión, debe convertir sus PM en PO, tal vez con "doble función" como interfaz de PM tradicional para el cliente. SM es un rol muy diferente al que la mayoría de los PM están acostumbrados. Para SM, debe elegir a alguien que sea realmente apasionado y tenga conocimientos sobre Agile y Scrum. Si tiene un cliente que quiere ver todo en una sola versión, corresponde al PO comprender al cliente lo suficientemente bien como para que pueda dirigir las iteraciones sucesivas. Todavía intentaría que el cliente revisara algunas versiones preliminares a partir del medio tiempo.

esa es una idea terrible

  • Solo hay un scrum master por equipo. El scrum master no está vinculado al proyecto porque no es un gerente de proyecto. Su configuración sugiere que su empresa no entiende ni respeta scrum ni a las personas que trabajan para él.
  • No hay ninguna ventaja en mezclar proyectos como este. Claramente, esto es solo una administración que impone plazos arbitrarios sin tener en cuenta la practicidad. No hay ninguna razón por la que alguien sugiera esto en lugar de hacer el proyecto A correctamente y luego hacer el proyecto B correctamente, a menos que estén tratando de engañar a los desarrolladores para que se comprometan a realizar más trabajo del que es factible.
  • Cambiar entre trabajos es ineficaz. Las personas necesitan tiempo para ponerse al día cuando comienzan algo nuevo. Este es aún más el caso cuando se cambia entre proyectos completamente diferentes.
  • Si elude el punto anterior dividiendo el equipo, entonces no estará mejor, ya que perderá muchas de las sinergias del equipo al hacer que trabajen en diferentes proyectos.
  • Es probable que se encuentre con conflictos tan pronto como mezcle los proyectos. ¿Qué es una división "justa" de la capacidad de sprint? ¿Qué tareas tienen prioridad si no puedes terminar todo? El Proyecto A presionará para obtener más atención para lograrlo. El Proyecto B retrocederá. No será más que drama.
  • No tiene garantía de que terminará con el proyecto A en la fecha estimada. ¿Qué vas a hacer entonces? ¿Cortarlo? Si sus gerentes estuvieran dispuestos a hacer eso, también podría adelantar ese plazo un mes y evitar esta mezcla. ¿Vas a seguir corriendo en paralelo? ¿Por cuanto tiempo? Porque eso retrasará el proyecto B y alguien en la escalera no estará contento con eso.

Este es un escenario de doble vínculo de libro de texto.

Muchas gracias por todos los listados del recurso sobre el doble vínculo. ¡¡¡Muy útil!!! La mayoría de las respuestas están alineadas con lo que estamos haciendo mal en este momento, pero estamos progresando para cambiar de tradicional a ágil. En algún momento, las personas que trabajaron de esa manera a lo largo de los años adoptarán finalmente la metodología ágil.
Personalmente, me importa mucho menos "hacer un scrum adecuado" que otros. Pero cuando considera ir en contra del estándar, es importante saber por qué el estándar es como es. La estructura un tanto rígida de Scrum (para un método Agile) es obligar a las partes interesadas a tomar esas decisiones difíciles, inconvenientes pero necesarias sobre qué tiene prioridad, cuánto tiempo está dispuesto a invertir y cuándo reducir sus pérdidas y seguir adelante. Eso es algo que es importante para cualquier proyecto, ágil o no, pero que a menudo se oculta debajo de la alfombra. A menudo con ideas "inteligentes" como en su pregunta.

Ventajas de tener historias de múltiples proyectos en cada sprint:

  • Verás avances en más de un proyecto
  • Los desarrolladores pueden disfrutar de la variedad

Desventajas:

  • El cambio de contexto es costoso y reduce el rendimiento de su equipo
  • Pierde la claridad de tener un solo proyecto en el que concentrarse, lo que también puede reducir la productividad
  • A menudo es más difícil definir las prioridades relativas para tareas de diferentes proyectos.

En mi experiencia, la razón más común para tener múltiples proyectos en cada sprint es que la organización no puede (o no quiere) priorizar y no aprecia la pérdida de productividad que proviene de la multitarea.

pero tienes múltiples maestros Scrum (uno por proyecto) y un equipo

Entonces no estás haciendo Scrum y realmente no deberías llamarlos Scrum Masters. Una de las razones de la existencia de Scrum es que se reconoció que la consistencia de los miembros del equipo realmente ayuda a un equipo a trabajar de manera efectiva. Cuando un equipo trabaja en conjunto, aprenden a adaptarse a las fortalezas y debilidades de los demás. Si está cambiando a los miembros del equipo (especialmente un rol clave como Scrum Master), entonces tendrá una productividad reducida.

Agradezco mucho tu respuesta. Estamos alentando a adoptar un enfoque rápido y ágil ya que trabajamos de manera tradicional durante muchos años y queremos reestructurar todo, pero como un regreso a casa más que una gran revolución. Estamos empezando a descubrir lo que estamos haciendo mal.
Buen enfoque para agrupar diferentes historias de proyectos en los mismos sprints
RespuestasAquíPolítica de privacidad1y, 0v