Nuestra empresa está migrando a Scrum. Me metieron en el rol de Scrum Master (sin capacitación formal, pero estoy trabajando en eso). Nuestro equipo no tiene un propietario del producto debido a la estructura de nuestra empresa y porque damos servicio a todos los demás equipos de la empresa. En cambio, los líderes del equipo dentro de nuestro departamento se relacionan con los otros propietarios de productos.
Hasta ahora, he centralizado toda la gestión de la cartera de pedidos para mí. Creo los elementos de la cartera de productos (PBI) y las tareas, con aportes del equipo y los líderes del equipo, en un esfuerzo por limpiar sus platos de las minucias de la gestión de tickets.
Sin embargo, leí esto en The Scrum Guide hoy:
A medida que se requiere trabajo nuevo, el Equipo de Desarrollo lo agrega al Sprint Backlog. A medida que se realiza o completa el trabajo, se actualiza el trabajo restante estimado. Cuando los elementos del plan se consideran innecesarios, se eliminan. Solo el Equipo de Desarrollo puede cambiar su Sprint Backlog durante un Sprint. El Sprint Backlog es una imagen altamente visible y en tiempo real del trabajo que el Equipo de Desarrollo planea realizar durante el Sprint, y pertenece únicamente al Equipo de Desarrollo.
No tengo del todo claro, de The Scrum Guide , si el Scrum Master se considera o no parte del Equipo de Desarrollo. En otros cursos, creo que el término Scrum Team se refiere al Scrum Master, Product Owner y Development Team, y el término Development Team se refiere simplemente al personal de desarrollo de productos (desarrolladores, evaluadores, diseñadores, etc.).
Mi pregunta es, ¿debería no intervenir cuando se trata del Sprint Backlog? ¿Deberían los desarrolladores crear tareas en el Sprint Backlog según sea necesario?
Tengo la ligera sospecha de que estoy haciendo todo mal.
El Scrum Master no forma parte del Equipo de Desarrollo. Su evaluación es correcta: el término "Equipo Scrum" se refiere al Scrum Master, al propietario del producto y al equipo de desarrollo. El Equipo de Desarrollo incluye a todas las personas que están haciendo el trabajo para transformar los Elementos de la Lista de Producto en un Incremento potencialmente liberable al menos al final de un Sprint.
Si el Scrum Master está trabajando hacia el Incremento potencialmente liberable, entonces el Scrum Master también está en el Equipo de Desarrollo. La persona con el rol de Scrum Master también tiene el rol de miembro del Equipo de Desarrollo.
Parece que parte de la confusión es entre el Product Backlog y el Sprint Backlog.
Product Backlog es una lista de "todas las características, funciones, requisitos, mejoras y correcciones que constituyen los cambios que se realizarán en el producto en versiones futuras" (de la Guía Scrum). Cada uno de estos elementos individuales de la lista son elementos de la cartera de productos. El propietario del producto es responsable de la cartera de productos.
Los elementos de la cartera de productos son refinados por el equipo Scrum. El propietario del producto y el equipo de desarrollo colaboran en el proceso de perfeccionamiento. El equipo de desarrollo se asegura de que cada elemento de la cartera de productos tenga suficiente información para implementar y se aborde cualquier detalle o pregunta. El equipo de desarrollo también proporciona una estimación para ayudar al propietario del producto a ordenar la cartera de pedidos del producto y comprender cuándo se puede completar el trabajo.
En Sprint Planning, una de las salidas es el Sprint Backlog. El Sprint Backlog comienza como un conjunto de elementos del Product Backlog que se planificaron para el Sprint. Sin embargo, puede haber elementos discretos de trabajo que el Equipo de Desarrollo identifique en la planificación. El Equipo de Desarrollo también agrega estos elementos al Sprint Backlog. A lo largo del Sprint, el Equipo de Desarrollo es responsable de mantener el Sprint Backlog.
Estos elementos de Sprint Backlog (mi término, no es algo que se encuentre en la Guía de Scrum) no se estiman. Son simplemente cosas para apoyar la transparencia. Al dividir el trabajo en elementos más detallados, el equipo de desarrollo brinda al propietario del producto y a ellos mismos una mayor visibilidad del trabajo que se realiza en el Sprint. La idea de colocar estos elementos de trabajo en Sprint Backlog es garantizar que el equipo sepa qué trabajo se requiere, ayudar a las personas a concentrarse en el trabajo que debe realizarse e identificar si existen amenazas para lograr el Sprint Goal.
El Equipo de Desarrollo debe ser el que cree los Elementos del Backlog del Sprint, al menos a nivel conceptual. Sin embargo, eso no significa necesariamente que el Equipo de Desarrollo creará los Elementos del Backlog del Sprint en una herramienta de seguimiento de tickets. Quizás el Scrum Master lo haga. Así como el propietario del producto puede delegar parte del trabajo, el equipo de desarrollo también puede hacerlo. Tal vez tenga sentido que, si se usa una herramienta de seguimiento de tickets, se le puede pedir al Scrum Master que ingrese el trabajo allí. Una de las responsabilidades del Scrum Master es facilitar los eventos de Scrum, y garantizar que el trabajo se ingrese correctamente en la herramienta de seguimiento de tickets facilita el refinamiento de los elementos de la cartera de productos, así como la planificación de Sprint y quizás también la revisión y retrospectiva del Sprint.
Una pregunta para usted: Como Scrum Master, ¿está facilitando al equipo eliminando la preocupación de ingresar el trabajo en una herramienta de seguimiento? ¿O está ingresando al trabajo con la intención de instruir al equipo sobre cómo convertir los elementos de la cartera de productos en un incremento potencialmente liberable? Uno es consistente con los principios de Scrum. El otro no lo es.
Si bien tiene buenas intenciones, lo que está haciendo actualmente no es muy ágil y es probable que sea contraproducente para adoptar Scrum adecuadamente a largo plazo. Su proceso actual no se adhiere al marco Scrum , los valores o principios del "Manifiesto para el desarrollo ágil de software", ni empodera ni entrena al Equipo Scrum y al resto de la organización para que sean más ágiles.
Parte de esto ciertamente se debe a una mala comprensión de los roles y responsabilidades del marco, pero algunos de los problemas son probablemente desafíos organizacionales que es poco probable que un Scrum Master recién nombrado tenga el ojo experimentado para identificar fácilmente. Si toda la organización es nueva en Scrum, generalmente es insuficiente adoptar el marco sin asegurarse de que todos en la organización entiendan los cambios de proceso necesarios para beneficiarse verdaderamente del cambio de mentalidad necesario para implementar adecuadamente la agilidad.
Probablemente se requiera capacitación organizacional, en lugar de solo capacitación para una o dos personas en un Equipo Scrum determinado. Si estuviera en su lugar, sin duda lo recomendaría a la alta dirección.
Debe tener un Product Owner singular para Scrum. Si no tiene uno, es posible que esté haciendo algo similar a Scrum, pero en realidad no está siguiendo el marco de Scrum .
Además, aunque técnicamente no hay nada que impida que una persona desempeñe múltiples funciones, como Product Owner y Scrum Master, eso suele ser un antipatrón y, con frecuencia, un conflicto de intereses. Aún así, mientras que otras personas del producto y partes interesadas en la empresa pueden tener aportes, el Equipo Scrum debe tener una persona singular en el rol de Propietario del Producto para Scrum.
El Product Owner es una persona, no un comité. El Product Owner puede representar las necesidades de muchas partes interesadas en el Product Backlog. Aquellos que deseen cambiar el Product Backlog pueden hacerlo tratando de convencer al Product Owner.
Además, el Scrum Master no gestiona el Product Backlog ni el Sprint Backlog, ni el Scrum Master encarga a los Desarrolladores. El rol de Scrum Master tiene responsabilidades claramente definidas , y esas no están entre ellas.
Los tres artefactos clave en Scrum son los siguientes:
El Equipo Scrum como un todo es responsable de entregar el Incremento, pero los dos trabajos pendientes tienen propiedad formal. En particular:
El propietario del producto es el único responsable de la cartera de productos.
El propietario del producto también es responsable de la gestión eficaz de la cartera de productos, que incluye:
- Desarrollar y comunicar explícitamente el Objetivo del Producto;
- Crear y comunicar claramente los elementos del Product Backlog;
- Ordenar elementos de la Lista de Producto; y,
- Asegurar que el Product Backlog sea transparente, visible y comprensible.
El propietario del producto puede realizar el trabajo anterior o puede delegar la responsabilidad a otros. Independientemente, el Product Owner sigue siendo responsable.
El Sprint Backlog es un plan para el Sprint únicamente por y para los Desarrolladores. Incluye varias cosas, pero los desarrolladores son los únicos que deberían administrarlo.
El Sprint Backlog se compone del Sprint Goal (por qué), el conjunto de elementos del Product Backlog seleccionados para el Sprint (qué), así como un plan procesable para entregar el Incremento (cómo).
En la práctica, lo que esto significa es que lo que está haciendo actualmente no solo no es ágil, sino que impide que el Equipo Scrum se empodere y se autogestione. La agilidad requiere adaptación , y la Teoría Scrum tiene claro que:
La adaptación se vuelve más difícil cuando las personas involucradas no están empoderadas o son autogestionarias.
Si bien su intención es ser útil, permitir que un sistema de tickets dirija su proceso es un antipatrón. Además, al definir las tareas para los desarrolladores en lugar de permitirles determinar cómo se realizará el trabajo elegido durante la planificación de Sprint , está usurpando el rol de los desarrolladores dentro del equipo Scrum y evitando que creen diseños emergentes basados en objetivos y resultados. y procesos de entrega justo a tiempo optimizados para sus habilidades individuales y colectivas. Básicamente, se trata de una gestión de proyectos tradicional de mando y control con un envoltorio sucedáneo de Scrum, y es poco probable que obtenga los beneficios reales de un equipo maduro y autogestionado que practica la mejora continua.
Su comprensión es correcta, el Scrum Master no forma parte del equipo de desarrollo, pero tanto el Scrum Master como el equipo de desarrollo, junto con el Product Owner, se conocen colectivamente como Scrum Team.
WRT la pregunta de '¿ Puede Scrum Mast ser parte del equipo de desarrollo ?'
Me he encontrado con situaciones en las que el Scrum Master formaba parte del equipo de desarrollo, es decir, tenía una doble función . Esto fue en una empresa más pequeña que no tenía la capacidad de personal completo. Funcionó, sin embargo planteó la cuestión de un posible conflicto de intereses .
Como prescribe la Guía Scrum, el Scrum Master ' Entrenará a los miembros del equipo en la autogestión' . Entonces, si también fueran parte del equipo de desarrollo, podrían surgir varios problemas posibles:
Habiendo dicho eso, como el Scrum Master es un facilitador , existe la posibilidad de que esto funcione, y en situaciones en las que he visto esto, el Scrum Master trabajará la mayor parte del tiempo en el rol de desarrollador. Entonces, realmente depende de la situación y de la persona, ¿tiene la persona las habilidades y la madurez para usar múltiples sombreros?
Algo que trato de tener en cuenta es nunca pedirle a la gente que haga algo que yo no estoy dispuesto a hacer , así que desde ese punto de vista, podría ser beneficioso.
WRT el backlog del sprint, los desarrolladores siempre son responsables de crearlo , y durante el scrum diario esto puede ajustarse según sea necesario. También vale la pena señalar que la guía de Scrum también establece que " si el propietario del producto o el Scrum Master están trabajando activamente en los elementos del Sprint Backlog, participan como desarrolladores " .
Esencialmente, esta regla está tratando de equilibrar dos cosas.
Evite la adición o los cambios en el trabajo del alcance del sprint.
Impedir que no se registren cambios adicionales o cambios en el trabajo que suceden de todos modos
Si el equipo de desarrollo pudiera, literalmente, solo hacer exactamente lo que estaba en el backlog del sprint, cualquier error en la planificación o la pérdida de detalles sería un gran problema.
Deben poder modificar el plan y esos ajustes deben registrarse y mostrarse en el trabajo pendiente, etc.
Pero, por otro lado, los cambios en el trabajo acordado socavan el sentido de tener sprints. Debe presionar a las OP para que se esfuercen en la etapa de planificación y no confíen en poder cambiar de opinión a medida que el trabajo está en progreso.
Creo que la frase clave de la Guía Scrum que se aplica aquí es esta:
Al final de la Planificación del Sprint, el Equipo de Desarrollo debería poder explicar al Dueño del Producto y al Scrum Master cómo pretende trabajar como un equipo autoorganizado para lograr el Objetivo del Sprint y crear el Incremento anticipado.
Tenga en cuenta que es el Equipo de desarrollo quien explica al SM (y al PO). Un Sprint Backlog de elementos (tareas, artefactos, resultados, lo que sea necesario) que se centre en los elementos del Product Backlog y el Sprint Goal es una excelente manera para que el Equipo de Desarrollo explique cómo pronostican que se creará el Incremento.
Considere también la redacción del Daily Scrum que (no sin coincidencia) usa gran parte del mismo lenguaje:
Todos los días, el Equipo de Desarrollo debe comprender cómo pretende trabajar en conjunto como un equipo autoorganizado para lograr el Objetivo del Sprint y crear el Incremento anticipado al final del Sprint... el Equipo de Desarrollo es responsable de realizar el Daily Scrum.
El Daily Scrum es uno de los eventos de inspección y adaptación durante el Sprint. Se inspecciona el Sprint Backlog: ¿vamos por buen camino para completar el incremento? ¿Se alcanzará el Sprint Goal? De lo contrario, entonces el Sprint Backlog debe adaptarse para garantizar mejor un Sprint exitoso.
Si bien lo anterior se refiere al Equipo de desarrollo, usted, como Scrum Master, aún tiene un papel que desempeñar. Tienes que ayudar al equipo a hacer lo que se necesita sin hacerlo por ellos.
Si cree que el equipo de desarrollo no ha explicado suficientemente cómo pretende entregar el incremento, entonces debe decidir si interviene directamente. Si bien está bien facilitar experimentos para que los desarrolladores aprendan incluso cuando fallan, probablemente no esté bien permitir que la planificación del Sprint finalice cuando es casi seguro que se producirá un Sprint fallido. ¡Y sea consciente de que la caja de tiempo expira!
Del mismo modo, debe observar Scrums diarios y decidir intervenir lo suficientemente temprano en el Sprint para garantizar mejor el éxito.
un día cuando
Todd A. Jacobs