Terminar pronto, acelerar más rápido
Acaba pronto, acelera más rápido (FEAF) es un lenguaje de patrones Scrum compuesto por una serie de patrones Scrum utilizados conjuntamente. FEAF es un lenguaje de patrones increíblemente potente porque ayudará a los nuevos equipos a establecer buenas prácticas y a los equipos experimentados a ser hiperproductivos, lo que se define como una velocidad 400% superior a la velocidad inicial del equipo.
Tiempo estimado para este curso: 65 minutos
Audiencia: Intermedio
Requisitos previos sugeridos: Scrum Marco
Una vez finalizado:
- Conocer los nueve patrones que componen el lenguaje de patrones del FEFA
- Entender cómo los patrones trabajan juntos para acelerar los equipos
- Conozca los impedimentos más comunes con los que luchan los equipos
- Comprender cómo aplicar los patrones Sprint por Sprint.
- Cualificarse para el PMI PDUs. Véase PREGUNTAS FRECUENTES para más detalles
Patrones y PLoP
Scrum Inc. Diapositivas de clase
Patrones que ayudan a los equipos a prepararse
El tiempo ayer: En la mayoría de los casos, el número de Puntos de Estimación completados en el último Sprint es el predictor más fiable de cuántos Puntos de Estimación se completarán en el siguiente Sprint.El Tiempo de Ayer permite a los equipos construir un Registro de Sprint más preciso limitando la posibilidad de que el equipo ambiciosamente saque demasiados Puntos de Estimación y ponga en peligro el Sprint. Los equipos estables conocen su capacidad, lo que les permite utilizar Yesterday's Weather.
Patrones que ayudan a los equipos a terminar el Sprint
Enjambre: Concentra el máximo esfuerzo del equipo en un elemento del Sprint Backlog para que se realice lo antes posible. Quien se encargue de este elemento será el Capitán del equipo. Todos deben ayudar al Capitán si pueden y nadie puede interrumpir al Capitán. Tan pronto como el Capitán termine, quien asuma la responsabilidad del siguiente elemento prioritario del backlog será el nuevo Capitán.
Cuando a los equipos les cuesta terminar los Sprints, normalmente es porque tienen demasiado Trabajo en Proceso y no se están centrando en terminar el elemento del Product Backlog de mayor valor para el negocio. Swarming ayuda a los equipos a mover los elementos a "Hecho" rápidamente, aumentando la Velocidad. El Tiempo de Ayer permite a los Equipos de Enjambre aumentar la Velocidad porque el equipo está construyendo un Registro de Sprint realista.
Patrón de interrupción: Asigne un tiempo a las interrupciones y no permita que se sobrepase. Establezca tres reglas sencillas que hagan que la empresa se autoorganice para evitar interrumpir la producción:
1. El equipo crea una reserva para imprevistos basándose en datos históricos. Por ejemplo, 30% del trabajo del equipo de media se debe a trabajo no planificado que llega al sprint de forma inesperada. Si la velocidad media del equipo es de 60 puntos, se reservarán 20 puntos para el búfer de interrupciones.
2. Todas las solicitudes deben pasar por el Product Owner para su triaje. El Product Owner dará baja prioridad a algunos elementos si no se percibe valor en relación con el plan de negocio. Muchos otros elementos se pospondrán a Sprints posteriores aunque tengan un valor inmediato. Algunos elementos son críticos y deben realizarse en el Sprint actual, por lo que el Product Owner los coloca en el búfer de interrupciones.
3. Si el búfer empieza a desbordarse, es decir, si el Product Owner pone un punto más de 20 puntos en el Sprint, el equipo debe abortar automáticamente, el Sprint debe volver a planificarse y se notifica a la dirección que las fechas de entrega se retrasarán.
El patrón de interrupción, al igual que Swarming, permite a los equipos terminar sus Sprints porque han desarrollado un proceso para hacer frente al trabajo encontrado.
Código de limpieza diaria: Arreglar todos los errores en menos de un día. El objetivo es tener una base de código completamente limpia al final de cada día.Si un equipo no crea código limpio a diario, puede perder mucho tiempo volviendo a corregir errores. Los errores pueden limitarse incorporando el control de calidad al proceso de desarrollo, de modo que los problemas se descubran y corrijan en el punto de origen. Una investigación realizada en 2006 en Palm, Inc., en Silicon Valley, demostró que un error que no se corrige el mismo día de su creación puede tardar hasta 24 veces más en corregirse tres semanas después.
Al crear código limpio a diario, el Equipo limitará las interrupciones más adelante en el Sprint o en el siguiente Sprint, cuando el error sea más difícil de corregir. La idea es que una vez que se ha detectado, analizado y corregido un error, no debería volver a producirse. Eliminando errores y mejorando el proceso a diario, los equipos pueden mejorar continuamente, aumentando la calidad con la Velocidad correspondiente.
Procedimiento de emergencia: Cuando esté en lo alto del burndown, pruebe una técnica utilizada habitualmente por los pilotos. Cuando ocurran cosas malas, ejecute el procedimiento de emergencia diseñado específicamente para el problema. No retrase la ejecución mientras intenta averiguar qué va mal o qué hacer. En un avión de combate podrías estar muerto en menos tiempo del que tardas en averiguar qué está pasando. Es responsabilidad del Scrum Master asegurarse de que el equipo ejecuta inmediatamente el Procedimiento de Emergencia Scrum, preferiblemente a mitad del sprint, cuando las cosas se están saliendo de madre.
Pasos del procedimiento de emergencia(haga sólo lo necesario)
1 Cambiar la forma de trabajar. Hacer algo diferente.
2 Obtener ayuda, normalmente descargando el trabajo atrasado en otra persona.
3 Reducir el alcance
4 Abortar el sprint y replanificar
5 Informar a la dirección de cómo se verán afectadas las fechas de publicación
Hiperproductividad
Scrumming el Scrum: Identifique el impedimento más importante en la Retrospectiva del Sprint y elimínelo antes de que finalice el siguiente sprint. Para eliminar el impedimento más importante, colóquelo en el Backlog del Sprint como una historia de usuario con pruebas de aceptación que determinarán cuándo está Hecho. A continuación, evalúe el estado de la historia en la Revisión del Sprint como cualquier otra tarea.Si el equipo es capaz de capitalizar la Scrumming la Scrum deberían crear al menos una mejora del proceso por sprint. Esto contribuye a aumentar la Velocidad 10% cada Sprint. Si el equipo está utilizando el Tiempo de Ayer, entonces tienen una buena oportunidad de terminar su sprint antes de tiempo porque tendrán un impedimento menos arrastrando su Velocidad.
Métrica de la felicidad: La felicidad es una de las mejores métricas porque es un indicador predictivo. Cuando la gente piensa en lo feliz que es, en realidad está proyectando hacia el futuro cómo se siente. Si creen que la empresa tiene problemas o está haciendo las cosas mal, estarán descontentos. O si hay un obstáculo importante o un sistema frustrante con el que tienen que lidiar, estarán descontentos.Una forma eficaz de tomar el pulso al equipo es averiguar lo contentos que están.
El Scrum Master sólo hace 2 preguntas:-
¿Está contento con la empresa?
¿Está contento con su trabajo?
Se pide a los miembros del equipo que valoren sus sentimientos sobre estas preguntas en una escala del uno al cinco. Estas cifras se guardan en una hoja de cálculo y se controlan durante semanas. Siempre que la media cambia significativamente es importante hablar de ello y ver cómo se puede hacer más feliz al Equipo. Mediante el seguimiento de la felicidad del equipo, el Scrum Master puede anticiparse a las caídas de velocidad y hacer ajustes.
Los equipos que terminan pronto aceleran más rápido: A menudo, los equipos se toman demasiado trabajo en un sprint y no pueden terminarlo. El fracaso impide que el equipo mejore. Por lo tanto, hay que trabajar menos en un sprint. Maximice su probabilidad de éxito utilizando el patrón El tiempo de ayer. A continuación, aplique los cuatro Patrones que reducen los Impedimentos dentro del Sprint, que se ocuparán sistemáticamente de cualquier interrupción y le ayudarán a terminar antes.
Al finalizar antes de tiempo, tire hacia adelante del siguiente Product backlog, lo que aumentará el Tiempo de Ayer para sprints futuros. Para aumentar la probabilidad de aceleración, aplique el Scrumming el Scrum para identificar su kaizen en la retrospectiva. Coloque el kaizen en el backlog del sprint con las pruebas de aceptación para el siguiente sprint como máxima prioridad.Utilizando los patrones subyacentes de FEAF, los Equipos estables construyen un Sprint Log realista y luego Swarm.
Mitigar las interrupciones y hacer frente a los imprevistos ayuda a los equipos a terminar antes. Cuando el equipo termina pronto, puede sacar más elementos del Product Backlog. Cuando hacen esto, la Velocidad aumenta elevando la línea base para el Tiempo de Ayer. Como resultado, el Equipo sacará más puntos para el siguiente Sprint, acelerando. Si los Equipos son capaces de ejecutar estos patrones consistentemente, con el tiempo, el Equipo alcanzará un estado Hiper-Productivo.