Tenemos una organización en la que estamos pasando a dos equipos de scrum que trabajan en diferentes partes de nuestra cartera de pedidos . Entiendo la idea de que cada equipo debe ser una unidad multifuncional completa y no debe tener otras distracciones. Eso parece un ideal perfecto.
En nuestro caso, tenemos un miembro del equipo cuyas habilidades podrían ser útiles para ambos equipos, pero que por lo general no tienen trabajo de tiempo completo para ambos equipos. Para concretar esto, ella es diseñadora web (y la web no es nuestro producto principal), pero lo mismo podría aplicarse a cualquier persona con un conjunto de habilidades especializadas. Y es muy buena en lo que hace, por lo que decir "bueno, trabaje en este equipo y encuentre otras formas de ayudar: escriba algunos documentos o algo así" es subóptimo e insatisfactorio para ella.
¿Existe una buena manera de que ella contribuya a ambos equipos sin sentir que tiene el doble de metatrabajo y prioridades conflictivas?
Si es así, ¿cuál es la mejor manera de manejar esto? ¿Qué pasa si hay cuatro personas que se sienten así en lugar de solo una?
Si no, ¿qué hacer en su lugar? El enfoque por el que me inclino es asegurarme de que todas las historias de los usuarios estén divididas de manera que todo lo que requiera algo de diseño web pueda ser manejado por completo por su equipo, pero no sé qué tan bien escalará eso.
Veo que esto sucede todo el tiempo con System Architects. Varios equipos necesitan sus habilidades especializadas, pero ningún equipo individual consume todo su tiempo durante el sprint.
La mejor solución que he visto para este tipo de situaciones es que el grupo de personas especializadas (arquitectos, diseñadores, lo que sea) opere como su propio equipo scrum y se comprometa en función de su capacidad para satisfacer las necesidades de los otros equipos.
Al hacerlo, se asegura de que el grupo/individuo especializado pueda hacer un compromiso honesto y expone los problemas de hacer que los equipos dependan de un recurso especializado que le permita inspeccionar/adaptarse para resolver o mitigar esos problemas.
Según Scrum, no es posible, pero en la vida real sucede de vez en cuando, y es algo bueno y está funcionando. Asegúrese de que ella pueda asistir tanto a las reuniones de pie como a las de planificación para que pueda organizar su trabajo, saber lo que vendrá y los equipos sepan qué esperar de ella. No veo otra buena solución.
Scrum según el libro, establece que los miembros del equipo no deben estar en diferentes equipos ni en diferentes proyectos. Esta es una situación ideal, pero si una empresa está haciendo la transición a scrum/agile, puede llevar un tiempo poder estructurar los recursos del proyecto de manera scrum.
Comenzaría por tenerlos en múltiples equipos y proyectos, incluso si esto no es lo ideal, pero reduciría las divisiones simultáneas tanto como sea posible. Luego, en los retro, debes estar atento a cómo está funcionando el equipo y el proyecto. Si todo el mundo está feliz, genial. Si no, trabaje con la administración para proporcionar una mejor situación. Esto podría ser tener un arquitecto junior en su equipo todo el tiempo, o incluso hacer la idea de "arquitecto como equipo scrum" de Clayton.
Entregue primero, si la gerencia ve buenos resultados, es más fácil convencerlos de los cambios necesarios para obtener resultados aún mejores.
No tenga miedo de "hacer un comienzo de mierda", scrum se trata de mejorar su proceso, no de hacerlo bien desde el principio.
Pídale que contribuya a cada equipo secuencialmente. No es ideal. Pero, es mejor que tenerla multitarea.
jmort253
Zsolt
Clayton