Una breve introducción a la pregunta: Soy Scrum Master en una pequeña organización de desarrollo web (10 empleados) y hacemos muchos proyectos que durarán 3 o 4 sprints, con una duración promedio de 2 meses en total.
Actualmente me encuentro en una situación en la que involucramos activamente al propietario del producto durante las reuniones de refinamiento de la cartera de pedidos y la planificación de sprints, aunque algunas de las empresas con las que trabajamos dudaban al principio porque no estaban familiarizadas con el marco Scrum. Dicho esto, estaban felices de acompañarlos, ya que les dio mucho más control del proceso. El problema es que, aunque conocen las reglas sobre no cambiar el backlog de sprint durante un sprint, la mayoría cambia el backlog al menos una vez cada sprint. Sus intenciones son buenas ("descubrimos que un color diferente funciona mejor, cámbielo" / "Nuestro cliente quiere probar en el navegador X hoy, haga un servidor de prueba ahora", etc.) pero no parecen/quieren entender eso esto afectará el trabajo que podemos terminar durante un sprint.
Ahora pensamos que sería una buena idea dejar que el propietario del producto firme un contrato de lanzamiento de sprint, que contenga fechas clave, la acumulación de sprint y definiciones de terminado. Mientras investigamos la teoría de scrum, asumimos que la presencia del PO en las reuniones de planificación de sprint y un acuerdo verbal para comprometerse con el trabajo pendiente era suficiente, pero en realidad ese no es siempre el caso.
Mi pregunta: ¿es una buena idea dejar que el PO firme un contrato que contenga los detalles del lanzamiento del sprint? ¿Y hay algún ejemplo de tal documento en la literatura de Scrum al que pueda hacer referencia?
TL; DR No, porque lo que describe no es estrictamente Scrum: debe corregir el proceso en lugar de inventar una solución alternativa. El PO puede cambiar el backlog del producto, pero no el backlog del sprint. Si el equipo no está de acuerdo con el cambio requerido o no puede implementarlo sin poner en peligro el sprint, PO puede cancelar el sprint (e incurrir en todos los costos asociados), o dejarlo así y colocar una nueva historia en la cartera de productos para abordar los cambios. .
¿Hay algún ejemplo de dicho documento en la literatura de Scrum al que pueda hacer referencia?
El documento principal para usted es una Guía Scrum ( http://www.scrumguides.org/scrum-guide.html ). Me referiré a él varias veces a continuación.
El problema es que, aunque conocen las reglas sobre no cambiar el backlog de sprint durante un sprint, la mayoría cambia el backlog al menos una vez cada sprint.
Según la guía,
Durante el Sprint:
- No se realizan cambios que puedan poner en peligro el Sprint Goal;
- Los objetivos de calidad no disminuyen; y,
- El alcance puede aclararse y renegociarse entre el propietario del producto y el equipo de desarrollo a medida que se aprende más.
y
Solo el Equipo de Desarrollo puede cambiar su Sprint Backlog durante un Sprint.
Si el cambio solicitado por PO está poniendo en peligro el objetivo del sprint, entonces no debe aceptarse. Usted como Scrum Master está a cargo de eso. Su respaldo en la conversación con el POS es la Guía Scrum.
no parecen/quieren entender que esto afectará el trabajo que podemos terminar durante un sprint.
Ese es su trabajo como Scrum Master para explicárselo. Es probable que entiendan que afecta tu trabajo, pero no le prestan suficiente atención.
Ahora pensamos que sería una buena idea dejar que el propietario del producto firme un contrato de lanzamiento de sprint, que contenga fechas clave, la acumulación de sprint y definiciones de terminado.
No. No y no. De nuevo, por la guía,
Cuando un elemento de la Lista de Producto o un Incremento se describe como "Terminado", todos deben entender lo que significa "Terminado". Aunque esto varía significativamente según el Equipo Scrum, los miembros deben tener una comprensión compartida de lo que significa que el trabajo esté completo , para garantizar la transparencia. Esta es la definición de "Terminado" para el Equipo Scrum y se usa para evaluar cuándo se completó el trabajo en el Incremento del producto.
Su definición de hecho es un contrato. El sprint en sí es un cuadro de tiempo, que no se puede cambiar, solo cancelar.
En resumen, debe trabajar con el PO y explicarle las reglas del proceso que está tratando de seguir. La introducción de "contratos" adicionales muestra una falta de transparencia y confianza, y esas son las cosas que deben abordarse.
Los contratos de Sprint, como los que describe, no deben usarse, ya que anula el propósito de Scrum/Agile. En cambio, haga el trabajo por adelantado para asegurarse de que el proyecto se pueda ejecutar correctamente. Para hacerlo, debe ocurrir lo siguiente (como mínimo)
Asegúrese de que el cliente esté debidamente educado en Scrum antes de que comience el proyecto. Idealmente, esto comienza a suceder en el proceso de preventa/venta.
Explique las reglas básicas de la metodología de entrega en el acta de constitución del proyecto. Asegúrese de que el cliente sepa que, al firmar el acta de constitución del proyecto, da su bendición para que el proyecto se lleve a cabo de acuerdo con la acta de constitución. Los cambios a la carta deberían requerir un proceso algo formal. El proceso de cambio de estatutos y los riesgos potenciales de cualquier cambio de estatutos también deben detallarse en el estatuto original.
No, no es una buena idea, ya que desafía uno de los principios fundamentales de Agile :
Da la bienvenida a los requisitos cambiantes, incluso al final del desarrollo. Los procesos ágiles aprovechan el cambio para la ventaja competitiva del cliente.
Cancelación de un Sprint :
Si los cambios son tan grandes que ponen en peligro los objetivos del sprint, dígale al propietario del producto que rompa el sprint y comience uno nuevo. Los costos deben ser que todo el trabajo sin terminar se pierda, asegúrese de que el precio sea claro. Posteriormente, el PO puede decidir continuar y terminar el sprint actual y poner el trabajo adicional encima del backlog o detener el sprint y comenzar uno nuevo con los nuevos conocimientos adquiridos.
Consulte también la cancelación de sprints en la guía de Scrum para obtener más información:
Sprint se puede cancelar antes de que finalice el tiempo de Sprint. Solo el propietario del producto tiene la autoridad para cancelar el Sprint, aunque puede hacerlo bajo la influencia de las partes interesadas, el equipo de desarrollo o el Scrum Master.
Kanbán :
Tal vez Scrum no sea lo adecuado para sus clientes y prefieran más flexibilidad. Echa un vistazo y compara Scrum vs Kanban . Concéntrese en comenzar el trabajo antes de aceptar un nuevo trabajo, pero cambie la cartera de pedidos a corto plazo continuamente según se adapte a las necesidades de sus clientes.
Si acortar el sprint ayudaría a proteger los objetivos, esto, por supuesto, implica más gastos generales de planificación, pero podría brindarle al cliente la flexibilidad que necesita. Tal vez un nuevo plan a mitad de sprint podría brindarle una mayor previsibilidad en cuanto a los cambios que se avecinan más tarde.
Los contratos probablemente no sean el camino correcto a seguir, como ya se ha señalado, ya que Agile da la bienvenida al cambio. Si el trabajo de sprint está fragmentado, ¿es posible identificar lo que no se hará como resultado y acordarlo con el cliente cuando llegue el cambio? Tal vez eso con un período de corte de cambio, digamos 4-5 días antes para sprint final podría ayudar a las cosas.
Los sistemas como scrum son convenciones que las personas han acordado para crear una confianza razonable en sus expectativas futuras (cercanas). Un sprint proporciona una garantía/confianza razonable en lo que puede esperar ver al final del sprint.
Dicho esto, los planes siempre pueden cambiar. Nunca podemos excluir que el cliente tenga una preocupación válida que justifique alterar el sprint planificado. Por ejemplo, es posible que sus desarrolladores deban ser llamados urgentemente para otra misión que no se pudo haber previsto pero que aún supera el objetivo de desarrollo actual.
Técnicamente, Scrum no prescribe que esto suceda. Asume que un sprint está escrito en piedra y no cambia. Pero la realidad puede ser muy diferente. Y eso está perfectamente bien, pero tiene el costo de reconocer que esto afecta el sprint planificado y, por lo tanto, las expectativas futuras (cercanas) ya no pueden garantizarse razonablemente.
Personalmente, dejo esto en manos de la persona con la máxima autoridad en esta discusión. Se puede jugar con el sprint si es necesario, pero no sin aceptar que las garantías hechas durante la planificación del sprint son efectivamente nulas y sin efecto.
Una pequeña excepción: permitiría cosas menores como cambiar un color, si aún no ha comenzado con ese ticket en su sprint, o si la solución lleva menos tiempo que explicar por qué no lo va a hacer ( en sentido figurado). No tiene sentido discutir sobre cosas realmente inofensivas si su impacto es insignificante.
Dicho esto, su situación podría ser diferente. Por ejemplo, la persona que confía en su sprint planificado podría no ser la misma persona que ahora está pidiendo que se altere el sprint. Esa es una bestia muy diferente para abordar, porque primero requiere que refieras a la última persona a la primera.
Sin aprobación, no dejaría que los extraños interfirieran en el sprint. Con aprobación, puede volver a consultar el punto anterior que debe significar inherentemente que los objetivos del sprint son nulos y sin efecto.
Esta es mi opinión sobre cómo abordar el desarrollo en general. Lo menciono porque ayuda a explicar los puntos que estoy tratando en la siguiente sección.
Un contrato no es el camino a seguir aquí, en mi opinión. Es innecesariamente formal y va a fomentar una actitud defensiva. No puede tratar un sprint de la misma manera que trataría un contrato de precio fijo (en el que, de hecho, adopta este enfoque exacto: firma el trabajo solicitado y nunca se desvía de él).
Lo que está tratando de hacer aquí es hacer una cascada de sus sprints individuales, lo que no solo va en contra del objetivo original de hacer scrum, sino que también puede morderlo en el trasero cuando no logra alcanzar un objetivo por cualquier motivo. Una OP que se ve obligada a firmar un contrato prácticamente en contra de su voluntad, incluso si lo aceptan en primer lugar, es probable que solicite una indemnización por daños y perjuicios si no se entrega el contrato completo. ¿De verdad quieres rodar esos huesos?
Sin embargo, puede haber consideraciones contractuales entre su empresa y la empresa cliente que reemplazan esto. Por ejemplo, si la empresa cliente es responsable de desconectar todo el contrato si usted no cumple con un objetivo de sprint o si no cumple con sus caprichos, esa es una situación que está condenada al fracaso.
Si, por el motivo que sea, su empresa no está en condiciones de imponer un límite razonable a este comportamiento, entonces es posible que deba imponer un formato de comunicación entre su empresa y el cliente, pero yo diría que en esta etapa la relación ha terminado. se deterioró a uno sin confianza y los sistemas como scrum o ágil simplemente no funcionan en esa atmósfera. Casi de manera inherente, tendría que caer en un enfoque en cascada donde cada iteración se define y acuerda rigurosamente, hasta un grado casi legal, antes de comenzar a trabajar en ella.
En general, le insto a fomentar un espíritu de cooperación con su PO, explicándoles las consecuencias de meterse con el sprint; y si insisten en hacerlo, deben consentir inherentemente en anular los objetivos del sprint actual (es decir, recibirán un subconjunto, pero no el conjunto completo, de los objetivos que se establecieron).
Si no están de acuerdo con eso, entonces no debería aceptar hacer nada que no haya sido planeado en el sprint.
Si ambas opciones fallan, y su empresa no puede simplemente alejarse de este cliente y buscar un cliente realmente compatible con scrum, su último recurso parece ser terminar con el enfoque scrum y optar por un enfoque en cascada.
Todd A. Jacobs