Scrum cuando cada miembro tiene su propio producto

Parece que estás usando algunas características de Scrum pero no el Framework. Hay algunas lagunas en su descripción que me interesan:

• ¿Quién gestiona la acumulación y establece las prioridades?
• ¿Hacéis planificaciones, revisiones y retrospectivas?

Es muy difícil para mí imaginar cómo sería una reunión de planificación para un grupo de personas donde cada persona trabaja en un producto diferente.

Entonces, respondiendo a tus preguntas:

¿suena como si incluso deberíamos estar usando scrum?

no lo hace Podría preguntar a sus gerentes por qué está "usando Scrum", si es solo porque es una tendencia, entonces podría intentar otra cosa. Además, creo que sería más fácil para ustedes filtrar el trabajo pendiente según el producto de cada uno y comenzar a usar un tablero Kanban para hacer un seguimiento del progreso. Es más simple y se adapta a equipos y "solo equipos" :D

¿Hay alguna forma en que podamos hacer que nuestros standups y sprints sean más relevantes para cada miembro?

Puede definir cuadros de tiempo para liberar sus incrementos y llamarlo Sprint, no estará en la perspectiva de Scrum, pero es una forma de organizar las entregas.

Mantendría las reuniones de pie ya que tienen alguna relación entre lo que llaman "diferentes productos", principalmente porque si son pragmáticos, el equipo siempre puede beneficiarse, pero trataría de ver qué productos estarían realmente involucrados en cada uno de los reuniones de pie para evitar que la gente se tome el tiempo de escuchar cosas en las que no están involucradas.

Parece que hay algunas cosas en juego aquí:

Producto vs aplicaciones vs Proyecto

Que muchos productos suenen anormales, ciertamente difíciles de mantener. Por lo general, cuando veo que la gente dice que tiene tantos productos, en realidad se refiere a aplicaciones o proyectos. Hay dos cosas que suelo encontrar útiles cuando hablo de un producto: primero, ¿qué piensa el cliente? ¿Diría su cliente que su producto es análisis de datos o análisis de datos cardiovasculares? Y segundo, su enfoque es similar entre los diferentes tipos de análisis de datos. No tienen que ser exactamente iguales, pero las similitudes en el enfoque significan que las mejoras en un área pueden trasladarse a otras si las trata como 1 (o menos) productos). Piense en Microsoft Office. Word, Excel y Powerpoint funcionan de manera muy diferente, pero hay muchas formas de crear documentos de un tipo u otro y tratarlos como un solo producto tiene enormes ventajas.

El beneficio de los equipos

Lo que describes no suena como un equipo. Suena como un grupo de personas que comparten una oficina. Un equipo adecuado puede beneficiarse de una mayor flexibilidad y una mayor productividad. Por ejemplo, si entra más trabajo para un tipo de trabajo que para otro, un equipo puede centrar su atención en el campo de ese trabajo, pero la configuración que describa debe obligar a esos proyectos a esperar. Además, la mayor parte del trabajo que realiza un equipo tiene algunas formas de trabajo repetido entre tareas. A menudo, los equipos que trabajan juntos pueden manejar este trabajo de manera más eficiente para obtener una mayor productividad.

Donde los equipos no funcionan

Si el trabajo es radicalmente divergente, puede ser que cada tipo de trabajo requiera atención completa y todo el tiempo de una persona para mantenerse al día con los desarrollos en ese tipo de trabajo. Esto es muy raro, por lo general solo afecta la investigación de vanguardia, pero no sé en qué tipo de trabajo está, así que tal vez esto se aplique.

Usando Scrum

Scrum está diseñado para ayudar a los equipos a resolver problemas complejos y desarrollar productos de forma iterativa. No es que Scrum no funcione para otras cosas, pero esto es en lo que realmente sobresale. Si esto no es lo que está haciendo, puede haber mejores enfoques para usted.

Eso no funciona dentro del marco de Scrum , sino Scrum In Name Only ( SINO ).

Scrum es un marco para desarrollar, entregar y mantener productos complejos.

Al elegir compartir personas en múltiples proyectos, esfuerzos, productos y llamarlo equipo , el marco Scrum sería un ajuste forzado inadecuado. Una forma en que se expone la ineficacia y la ineficiencia es lo que usted llama el informe diario, probablemente en realidad un informe de estado tradicional.

Esta mala gestión clásica puede continuar ignorando sus costos. Una mejor alternativa es trabajar para cambiar el enfoque hacia un modelo de personal más dedicado, y el cambio puede ser muy desafiante.

Si los "productos" (puede nombrarlos proyectos o lo que sea adecuado para usted) no están relacionados, entonces no es necesario que se unan porque el estado no es importante para los demás y, en su caso, en realidad lo son. no un equipo. Una reunión de pie distraerá a los que no estén interesados ​​en la información que se comparte en el stand up.

Es mejor ponerse de pie con los miembros del equipo relacionados solo para seguir centrándose en el proyecto y el estado de ese proyecto (hitos, problemas, logros, etc.) en lugar de involucrar a todos.