El equipo Scrum está sirviendo a muchas partes interesadas, todas las cuales compiten por la atención del equipo. Las solicitudes y demandas llegan al equipo desde la gerencia, desde el Cliente A hasta el Cliente Z, y desde ventas y marketing. Además, el trabajo en progreso puede descubrir deficiencias sorpresa en el producto en sí que requieren atención. La frecuencia e importancia de estas solicitudes varía con el tiempo, y ocasionalmente su volumen y urgencia son abrumadores.
Las prioridades cambiantes o los problemas en el campo a menudo interrumpen el trabajo de los equipos de Scrum durante un Sprint. Las demandas de ventas y marketing, combinadas con la interferencia de la administración, pueden causar disfunción crónica en un equipo, fallas repetidas de Sprint, incumplimiento de las fechas de lanzamiento e incluso fallas de la empresa.
En muchos sentidos, el equipo Scrum es un recurso comunitario que satisface las necesidades de muchas partes interesadas. La tragedia de los bienes comunes es un dilema que surge de la situación en la que múltiples individuos, actuando de manera independiente y racional consultando su propio interés, finalmente agotarán un recurso limitado compartido, incluso cuando está claro que no es del interés a largo plazo de nadie que esto suceda. El ecologista y filósofo estadounidense Garret Hardin describió por primera vez este dilema en un influyente artículo titulado "La tragedia de los comunes", que se publicó por primera vez en la revista Science en 1968. [1]
El equipo Scrum es un recurso crítico para crear nuevo software y mantener software antiguo. Esto lo convierte en un recurso central para resolver problemas que surgen durante el desarrollo y el uso del producto, para comunicaciones técnicas con clientes, para demostraciones de marketing y para proyectos especiales para satisfacer las necesidades de todos en la organización. Ver flujos de trabajo hacia adentro.
A menudo, la mala propiedad del producto permite que las prioridades competitivas en una empresa lleguen a un equipo Scrum. Algunos equipos incluso han sido sobornados para trabajar en características que no están en el Product Backlog.
En casi todos los casos, es deseable que el equipo Scrum "coma su propia comida para perros". Si producen un defecto que entra en el campo, necesitan arreglarlo lo antes posible. La creación de equipos de mantenimiento especiales para corregir defectos incentiva al equipo de Scrum a no estar atento a los defectos latentes.
Por estas y muchas otras razones, un equipo Scrum siempre está expuesto a interrupciones que interrumpen la producción. Por lo tanto: Primero Asignan explícitamente tiempo para interrupciones y no permiten más trabajo del que cabe dentro de la asignación. Si el trabajo excede la asignación, cancele el Sprint.
Establezca tres reglas simples que harán que la organización se autoorganice para evitar interrumpir la producción. Esta estrategia ayudará al equipo a replanificar durante el Sprint para aumentar las posibilidades de entregar el incremento completo del producto.
1. El equipo crea un búfer para elementos inesperados basado en datos históricos. Por ejemplo, digamos que un tercio de los El trabajo del equipo en promedio proviene del trabajo no planificado que ingresa al Sprint inesperadamente. Si la velocidad del equipo promedia 60 puntos, el equipo reserva 20 puntos para el búfer de interrupción.
2. Todas las solicitudes no triviales deben pasar por el propietario del producto para su clasificación. (Los errores ortográficos de la página web y los errores de compilación son ejemplos de errores triviales en los que la corrección es tan obvia que no hay ningún beneficio de información empresarial adicional. Los desarrolladores pueden dedicar una pequeña cantidad de tiempo a abordar incluso defectos no triviales antes de escalar al propietario del producto). El propietario del producto dará a algunos elementos baja prioridad si no hay un valor percibido en relación con el plan de negocios. El propietario del producto enviará muchos otros artículos a los Sprint posteriores, incluso si tienen un valor inmediato. Algunos elementos son críticos y el equipo debe completarlos en el Sprint actual, por lo que el propietario del producto los coloca en el búfer de interrupción.
3. Si el búfer comienza a desbordarse, es decir, el Product Owner pone un punto más de 20 puntos en el Sprint, el Scrum Team debe abortar automáticamente, el Sprint debe ser replanificado y el Product Owner notifica a la gerencia que las fechas se deslizarán.
Es esencial obtener un acuerdo de gestión sobre estas reglas y hacerlas cumplir. El Product Owner debe estar siempre disponible para el equipo y otras partes interesadas. En ausencia del propietario del producto, el equipo de Scrum debe designar a uno de los suyos para que ocupe temporalmente ese rol.
Esta estrategia es independiente del enfoque en arreglar todos los defectos que surgen en el Sprint de los elementos atrasados trabajados durante el Sprint .
También es independiente de PBIs asignados a un Sprint por el Product Owner como parte de la Planificación del Sprint para reducir la deuda técnica.
OJO exceder el búfer generalmente genera al menos una reducción del 50 por ciento en la velocidad.
El Product Owner debe usar el sentido común para equilibrar estas fuerzas.
Fuente : scrumbook.org/product-organization-pattern-language/illegitimus-non-interruptus.html
