¿Scrum se presta a entornos de proyectos múltiples?

Me mudaré a un lugar de trabajo en el futuro cercano y creo que estarán muy interesados ​​en mi experiencia con Scrum y en cómo se relaciona con su negocio. Estoy tratando de entender si funcionará en su entorno.

En mi lugar de trabajo actual tenemos 2 productos / 2 pedidos pendientes / 2 equipos separados. Obviamente, estos retrasos se priorizan en función de lo que la empresa cree que más necesita para una plataforma que desarrollamos. Sin embargo, el lugar al que me mudaré tiene muchos proyectos en marcha, todos al mismo tiempo con (2/3 personas trabajando en cada uno), pequeños trozos de trabajo entran y se arreglan a diario e imagino todas las entregas del cliente son aproximadamente igual de importantes.

Entonces, me pregunto si alguien tiene experiencia con Scrum en un entorno similar, ¿qué ejemplos reales tiene de cosas que funcionaron? ¿Qué no funcionó? ¿Qué consideraciones hay para que Scrum funcione en esta situación?

Hay algunos aspectos que no estoy seguro de cómo funcionaría bien:

1. Creo que las personas en equipos trabajarán en todos los proyectos y, por lo tanto, potencialmente en equipos scrum si se desglosan.
2. ¿Cómo maneja la prioridad de manejo en tantas partes móviles que probablemente cambian con frecuencia y tienen sus propias escalas de tiempo?
3. Si tienes un equipo de scrum que trabaja en varios proyectos (algunos de ellos solo requieren 1 Dev), ¿cómo entiendes el contexto del stand-up?

Trabajo como Gerente de Desarrollo en exactamente este entorno, y he implementado Scrum extremadamente exitosamente con un equipo de 4 durante el año pasado, de lo que fue un desastre horrible. Tomó un poco de tiempo llegar a donde estamos ahora, pero funciona muy bien. Intentaré resumir las acciones más importantes, pero no dude en preguntar más.

1. Actué como Propietario del producto y Scrum Master. Trabajé para crear una cartera de pedidos para cada producto, con la parte interesada asociada.

2. Luego prioricé TODOS los trabajos pendientes, por lo que efectivamente tuve mis propios proyectos pendientes que abarcaban. Esto estaba usando Fogbugz, por lo que pude filtrar a cada uno por proyecto para que la parte interesada trabaje conmigo y baraje elementos.

3. Planifique sprints a partir de esto, encapsulando todos los proyectos y todos los miembros del equipo, por lo que algunos miembros del equipo trabajarán en sus propias tareas específicas, pero alentarán el trabajo y el aprendizaje interfuncionales. Todas las discusiones de pie son útiles, porque si alguien está hablando de algo que nadie más sabe, tuvieron que elaborar lo suficiente para que lo entendamos. Esto ayudó al aprendizaje.

   • En este punto, el equipo carecía de cohesión, pero al menos estábamos haciendo cosas en todos los proyectos, manteniendo contento al negocio y mejorando la calidad al agregar control de fuente / pruebas automatizadas. Fue una GRAN mejora del desorden que era antes, pero también fue difícil mantener el enfoque, sin otro objetivo que completar el sprint. Tampoco teníamos demostraciones, ya que no serían particularmente relevantes para ninguna de las partes interesadas. Debido a que era tanto PO como SM, fui relativamente gentil al comprometer demasiado al equipo. Vale la pena señalar que todavía estábamos entregando MUCHO más que antes de mi llegada.

4. Luego traté de cambiar lentamente el enfoque de los sprints más a un solo producto, por lo que tendríamos un sprint del 60% en un producto, pero aún con otras tareas. Finalmente, los sprints se centraron en un 90% en una tarea, y las partes interesadas aprendieron a 'esperar su turno'; después de todo, todavía estábamos logrando mucho más de lo que nunca antes habían logrado. Esto hizo posible la demostración de un producto a la vez.

5. Una vez que los sprints se enfocaron, comencé a capacitar a los interesados ​​en Scrum y convertir a algunos de ellos en propietarios de productos. Esta es la etapa en la que me encuentro ahora, trabajo con 3 propietarios de productos y todavía tengo 2 productos que realmente poseo. Los Sprints pueden tener 1 o 2 tareas para 'otros' proyectos, pero tenemos un enfoque suficiente para una demostración de Sprint con los principales interesados ​​del Sprint demostrando solo las nuevas características de sus productos.

Espero que esto ayude, este es el viaje en el que he estado con mi empleador actual, y hasta ahora el equipo de desarrollo, las unidades de negocios y (lo más importante) mi jefe están muy contentos.

Actualmente estoy trabajando como parte de un equipo scrum de 4 personas que es responsable, en un grado u otro, de todos los productos de nuestra compañía. Con un total de aproximadamente 16 productos, más un desastre de productos semi-conectados, puedo decirle por experiencia que scrum no se hace amigo de un entorno de proyectos múltiples. Como se indicó anteriormente, es difícil construir una sinergia de equipo cuando trabajas constantemente individualmente en diferentes cosas. Además, es difícil relacionarse con los detalles de trabajo de las tareas de sus compañeros de equipo, ya que su enfoque está en una tarea completamente diferente, en un proyecto completamente diferente.

Además, el "enamoramiento" o incluso el análisis no asignado con un producto en particular es casi imposible debido a la tasa de rotación de tareas, que puede conducir a la descomposición del código, entre otras cosas.

Si te encuentras en una posición en la que no puedes escapar de múltiples proyectos asignados a tu equipo, no recomendaría SCRUM.

La respuesta aceptada responde bastante a la pregunta, pero me permite compartir mis experiencias. He estado en dos situaciones diferentes en las que los miembros de un equipo SCRUM tuvieron que manejar múltiples proyectos. Un equipo SCRUM puede manejar múltiples proyectos, pero solo bajo ciertas condiciones.

En el primer caso, los múltiples proyectos presentaron un desafío significativo. Mi empleador aún tenía que adoptar las metodologías ágiles en su conjunto. Fui parte de un piloto donde usamos SCRUM para un solo proyecto.

El problema es que el equipo de gestión de proyectos favoreció tener muchos proyectos concurrentes y de larga duración en lugar de proyectos cortos y enfocados. Como resultado, a mi equipo se le asignaron constantemente más proyectos de los que teníamos desarrolladores; ¡Era típico que el equipo de cuatro hiciera malabares entre seis y diez proyectos! Esto se vio exacerbado por el hecho de que también teníamos que manejar una cantidad considerable de responsabilidades operativas y de soporte.

Lo que encontramos fue que debido a que el equipo solo tenía una pequeña fracción de su tiempo dedicado al equipo SCRUM, no pudimos establecer una velocidad confiable y estábamos limitando la cantidad de trabajo para cada Sprint por temor a no cumplir con nuestros compromisos de Sprint. La incorporación de todo el trabajo de otros proyectos en nuestra planificación puede haber ayudado, pero esos proyectos tenían fechas y alcances fijos, lo que hace improbable que pudiéramos haber realizado SCRUM correctamente.

En el segundo caso, toda la compañía había abrazado a Agile desde hacía mucho tiempo y había desarrollado un medio por el cual un equipo SCRUM podría abordar múltiples proyectos. Fue tan efectivo que, como ingeniero, ¡ni siquiera sabía qué eran la mitad de los proyectos! Los propietarios de productos trabajarían con los gerentes de proyecto para identificar el trabajo necesario; Utilizando las estimaciones proporcionadas por nosotros los ingenieros y la velocidad establecida por el equipo, los propietarios del producto pueden hacer predicciones razonables sobre cuándo se completará un artículo en particular. Mientras el equipo cumpla constantemente con sus compromisos, no necesitamos preocuparnos por las fechas de vencimiento de los productos más entregables.

Sin embargo, ayudó que todos estuviéramos trabajando en el mismo pequeño conjunto de aplicaciones. Los equipos se alinearon con los productos, lo que hizo que fuera más fácil saber en qué trabajaban sus colegas y también fue más fácil cambiar el enfoque de un proyecto al siguiente según sea necesario.

En resumen, SCRUM puede adaptarse fácilmente para manejar múltiples procesos concurrentes, si se realiza la planificación y organización adecuadas.

No estoy seguro de entender, si tienes "2/3 personas trabajando en cada uno", entonces no es lo mismo que tener varios equipos, cada uno trabajando en un proyecto.

Pueden cambiar proyectos regularmente, en lugar de tener un 'producto' en el que trabajan continuamente, pero eso no es una gran diferencia. Algunos lugares incluso esperan que los equipos trabajen en diferentes partes de un producto y cambien para trabajar en otra cosa después de completar cada proyecto, principalmente para garantizar una buena difusión del conocimiento.