Soy miembro de un equipo Scrum. Esta mañana tuve una discusión con mi Scrum Master donde dije que necesitaba dos personas de otro equipo para ser parte de mi equipo. Dije que me gustaría discutir esto con el propietario del producto y luego con el gerente. El Scrum Master básicamente cambió la discusión, diciendo que la responsabilidad de eso no era mía ni del Product Owner, sino del Scrum Master.
¿Quién es responsable de cambiar la composición del equipo Scrum?
Esta es una pregunta interesante porque aborda algunas de las sutilezas de la autoorganización con marcos ágiles. En particular, destaca las diferencias entre autoridad e influencia .
Los miembros del equipo Scrum son responsables de identificar los impedimentos (p. ej., el equipo no tiene suficiente experiencia en el diseño de bases de datos) y recomendar mejoras adaptativas (p. ej., sugerir que John Doe, el DBA, podría proporcionar la experiencia que le falta al equipo). Los miembros del equipo también son responsables de ejercer influencia en la composición del equipo al hacer recomendaciones sobre cómo agregar o quitar personas del equipo.
Los Product Owners son (a menudo) responsables del presupuesto de recursos. En tales casos, el Dueño del Producto sería responsable de aprobar o declinar los recursos que serían cargados a su presupuesto. Esto cae directamente en la responsabilidad central del propietario del producto de establecer las prioridades del proyecto.
Los Scrum Masters son responsables de facilitar las discusiones sobre los recursos del proyecto (incluidas las limitaciones de recursos), los impedimentos del proceso y las recomendaciones para la mejora del proceso. Sin embargo, los Scrum Masters generalmente carecen de autoridad para implementar cambios organizacionales directamente. Cuando el equipo Scrum acuerda un enfoque, el Scrum Master es responsable de garantizar que las recomendaciones del equipo lleguen a los tomadores de decisiones apropiados y de promover los intereses del equipo dentro de la organización más grande a través de la influencia .
A menos que al Scrum Master se le haya asignado autoridad adicional más allá del alcance típico del rol, no debe tomar decisiones de contratación o asignación de recursos de manera unilateral. Hacerlo no es una práctica de Scrum generalmente aceptada, y ciertamente no es de interés para la formación de equipos; sin embargo, ocasionalmente ocurre en cierto tipo de organizaciones.
Tiene toda la razón al plantear sus inquietudes y recomendaciones dentro del equipo, pero es responsabilidad conjunta del Equipo Scrum acordar una solución y un vocero . Sin embargo, decidir qué personas o recursos necesita el equipo, y cómo el equipo podría ayudar mejor al Scrum Master a representar los intereses del equipo ante el resto de la organización, definitivamente no está dentro de su autoridad para manejarlo solo.
La autoridad organizativa, ya sea en nombre de la empresa o del equipo Scrum, siempre debe delegarse. El Scrum Master tendría toda la razón al señalar a un miembro del equipo que adopta un enfoque unilateral de este problema como fuera de las prácticas generalmente aceptadas del marco.
El primero de Agile Manifesto es: "Individuos e interacciones sobre procesos y herramientas", lo que significa que nadie debe desanimarse de eliminar los impedimentos diciendo que no es su función . Especialmente si hay un impulso viable para hacer las cosas.
Si desea analizar más de cerca las "reglas", cada uno de los miembros del equipo debe poder plantear riesgos e impedimentos y proponer soluciones y planes de mitigación. Si un equipo carece de habilidades o conocimientos, también afectaría la capacidad del equipo para alcanzar los objetivos. Suena como el impedimento de un PO también.
Eliminar impedimentos es responsabilidad de un Scrum Master porque los miembros del equipo y el PO a menudo se enfocan fuertemente en obtener los resultados, por lo que también debe haber alguien que se preocupe por el desempeño del otro equipo , ya que sus recursos (en realidad) serán robados. Sin embargo, difícilmente imagino a un SM que lograría cambiar el tamaño de un equipo sin el apoyo activo de un equipo.
Si entendí su pregunta correctamente, ya que su equipo está tratando de agregar recursos, entonces está haciendo lo correcto; sin embargo, si solo usted se ha asegurado de hacer ese ajuste, me temo que no es su decisión, es la decisión del equipo. En los equipos de scrum, estas decisiones se toman en colaboración, por lo tanto, si cree que necesita dos recursos, es mejor que presente esto como un impedimento en el scrum diario y justifique después del scrum al equipo y al SM las razones por las que tiene la intención de hacerlo. En Scrum, el equipo está facultado para realizar ajustes en la configuración del equipo; sin embargo, un Scrum Master podría supervisar si está haciendo lo correcto o no. Por ejemplo, el tamaño de su equipo es de 6-7 y está agregando un par de recursos más, arriesga el aspecto de la comunicación, el flujo, etc. El PO al final del día es responsable ante el negocio sobre el ROI al final del sprint. Podría estar financiando el proyecto si es así, ya que Adrian sugiere que es su última llamada para agregar recursos, ya que podría haber un impacto en los costos. Si estos dos recursos son recursos compartidos entre otros equipos, entonces no debería involucrar la aprobación del PO, posiblemente involucraría al PO ejecutivo para toda la plataforma. Cuando tiene recursos compartidos, es mejor llevar a cabo reuniones de planificación de sprints de clúster en las que se involucren recursos compartidos.
Racionalicemos un poco: - Definitivamente no es la llamada del PO, él es responsable de administrar el producto y no el equipo (eso es autogestionado), pero por supuesto tiene el presupuesto, por lo que hay una llamada indirecta en la estructura del equipo. - El Scrum Master necesita mantener al equipo en modo de alto rendimiento, por lo que su enfoque debería ser: Veo que le falta algo de fuerza, veamos la posibilidad de agregar X miembros más a nuestro scrum.
Pero debe ser decisión del equipo agregar otro miembro del equipo y quiénes deben ser esos miembros del equipo, ya que el equipo necesita sentirse cómodo con la adición.
Ahora sobre el tiempo: la retrospectiva es un buen momento para decir "En este sprint notamos la falta de habilidades X o Y" o durante la planificación "Para hacer esos EE. UU. necesitamos X e Y que no tenemos en el equipo".
Eso es hablar de teoría... En la práctica, quien tiene el presupuesto suele hacer la llamada.
En un mundo Scrum ideal, no necesitas personas, necesitas equipos. Por supuesto, la realidad es diferente. Su Scrum Master tiene razón, no es su responsabilidad, pero debe ser parte de la discusión. Tu Product Owner también tiene razón, porque tampoco es su responsabilidad. Su responsabilidad es entregar y cuando este acto está en riesgo, debe hacer algo al respecto. Hasta que el cambio en la configuración del equipo no afecte esto, debería aceptar el cambio. Parece que no es responsabilidad de nadie. Este es uno de los defectos de Scrum. La brecha creada entre el desarrollo y la gestión dejó estos temas abiertos.
Sin embargo, tiendo a ver una solución bastante buena para este problema: el gerente de línea, el gerente de proyecto, el propietario del producto y el scrum master se sientan juntos y analizan la situación. Cuando tienen un entendimiento, piden la propuesta del equipo y toman una decisión juntos .
¿Quién es responsable de cambiar la composición del equipo Scrum?
Convocaría una reunión e invitaría
Dado que este cambio podría afectar a otros proyectos, estas personas deberían tener la oportunidad de participar en la discusión.
El gerente, el propietario del producto y el maestro de scrum deben sentarse juntos y discutir esto con usted como un comienzo para comprender de dónde viene.
El propietario del producto debe tener a mano su cartera de pedidos, el maestro de scrum debe tener a mano las tareas pendientes y el gerente debe tener una comprensión del presupuesto, etc.
Todos discuten para comprender los diferentes puntos de vista y luego, lo más probable es que el gerente necesite ver si es financieramente factible.
Luego lo llevas al equipo y dejas que ellos decidan.
Cazador de ciervos
pvblivs