Terapia de choque: Bootstrapping Hiperproductivo Scrum

1. Todos los miembros del equipo asistirán a una sesión de formación Scrum.
   Llevo a cabo una Scrum en MySpace curso en unas cuatro horas, y todo el equipo se reúne en una sesión. Hasta que no se haya formado a todo el mundo, no empezaremos nuestro primer Sprint.
2. Los sprints tendrán una duración de una semana.
   Lo justifico señalando que hay una razón por la que los genetistas estudian las mutaciones en las moscas de la fruta en lugar de en los elefantes: quieren ver las mutaciones rápidamente y adaptar sus estudios en consecuencia. Por lo general, los equipos odian esta parte tanto o más que cualquier otra cosa que les exija, pero he conseguido convencer a todos los equipos para que me concedan al menos cuatro Sprints de una semana a modo de prueba. Este es uno de mis intercambios favoritos que casi siempre surge - siéntete libre de usarlo:
   Ingeniero: "Pero no puedo hacer cualquier cosa en una semana".
   Scott: "Entonces las matemáticas simples sugieren que sólo se puede hacer cuatro nada en un mes".

   Curiosamente, cuando los equipos han cumplido los tres criterios para cambiar esta regla, hasta ahora sólo uno ha optado por cambiarla.

3. Empezarán utilizando mi definición de "Hecho".
   Esta suele ser una de las cuestiones más espinosas que hay que resolver con un equipo, así que la retiro de la mesa hasta que tengan algún éxito compartido como base. Mi definición inicial de "Hecho" es la siguiente:

1. Listo para la producción
1. Todos los presupuestos se harán exclusivamente en Story Points.
   De nuevo, a veces me encuentro con un ceremonial gesto de los ojos en blanco, pero, hasta ahora, todos han acabado comprendiéndolo. Suele ser alrededor de la tercera semana cuando puedo provocar intencionadamente un debate sobre si una carta es un 3 o un 5, y luego tengo el placer de señalarles la pasión con la que están debatiendo estos valores recientemente sin sentido. También grito "¡BA!" cuando todos votan el mismo valor para una carta. Mi intención es mostrarles con qué frecuencia coinciden en su voto. A medida que se anima el ambiente en el equipo, algunos empiezan a escrutar los votos de los demás y a "baa" como ovejas cuando eso ocurre. Sólo uno me ha devuelto el "¡Ba!" con un "¡Humbug!". En cualquier caso, todos empiezan a divertirse con ello y eso es importante.
2. Utilizaremos un radiador físico de información.
   No sólo insisto en que haya un Radiador de Información físico, sino que tengo una plantilla básica que utilizo inicialmente para todos los equipos. Elijo unilateralmente la ubicación del Tablero Scrum y lo utilizo como centro de la Reunión Diaria de Puesta en Marcha. Cuando el equipo se forma por primera vez, dejo que se centren en la interacción con sus compañeros de equipo (las tres preguntas de Logro) y yo mismo muevo sus tarjetas por la superficie del Radiador. Al cabo de un par de semanas, empiezan a mover ellos mismos las tarjetas sin que nadie se lo pida. Este suele ser el primer indicio de que puedo empezar a dar poco a poco un paso atrás y a relajar mis exigencias.
3. Las reuniones de planificación del Sprint serán de cuatro horas, una vez por semana.
   La primera queja de la mayoría de los ingenieros es que perciben que Scrum les impone un horario muy perturbador, con más reuniones de las que creen haber tenido nunca. Para minimizar esta preocupación tan común, reúno todo menos las reuniones diarias en una única reunión de cuatro horas. Al cabo de unas semanas, los equipos solo suelen necesitar un par de horas. Y al final de unos ocho Sprints juntos, las reuniones se están convirtiendo en noventa minutos o menos de duración para un Sprint de una semana. Mi agenda inicial es la siguiente:
   1. Demostraciones donde el Equipo muestra al Product Owner el trabajo realizado y recibe premios Story Point en función de su precisión.
   2. Retrospectiva y me ayudo de una serie de parámetros de los que hago un seguimiento. Sólo hago un seguimiento de las métricas de todo el equipo, nunca de las métricas individuales. Al principio, aunque publico muchas métricas, solo me centro en Velocidad, Burndown, Capacidad de trabajo y Compromiso Precisión.
   3. Presentación de la cartera de productos pendientes a continuación, durante la cual el Product Owner debate el contenido del Backlog en ese momento. El Equipo es libre de cuestionar los motivos, sugerir alternativas y añadir requisitos en este punto. Rechazo en nombre del equipo cualquier Historia de Usuario mal formada.
   4. Estimación y negociación indica que la reunión está a punto de terminar. En mis equipos nuevos se realizan en un solo movimiento, aunque los equipos más maduros optan finalmente por dividir estas actividades en reuniones únicas. El Product Owner sólo participa como asesor durante esta fase de la reunión. Paso la mayor parte de mi tiempo en esta fase tratando de evitar que los equipos descompongan innecesariamente las Story Cards en secuencias de tareas, cosa que algunos tienden a hacer. La nemotecnia INVEST es muy útil en este caso.
   5. Compromiso Sprint Backlog es el acto final de la Reunión de Planificación. En los primeros Sprints, leo literalmente en voz alta lo que significa y lo que no significa "Comprometerse" para que nadie tenga ninguna duda. Una vez que el equipo se compromete con el trabajo, se levanta la sesión.
4. La multitarea está prohibida. El trabajo debe realizarse por orden de prioridad.
   Algunos ingenieros lo entienden enseguida. Otros se sienten más productivos o realizados cuando tienen varios proyectos en marcha y no aprecian que les señale que no hay valor en el trabajo incompleto, pero señalarlo, lo hago. Y a menudo. Insisto y les hago cumplir que trabajen en las tarjetas sin multitarea y por orden de prioridad.

1. Encuentro el problema más grave y desagradable que tiene el equipo y lo resuelvo en uno o dos días tras la primera reunión de planificación. Algunos equipos me presentan rápidamente este problema en su primera retrospectiva, mientras que otros requieren observación, escucha atenta y reconocimiento entre bastidores para descubrirlo. Especialmente para los equipos que aún no han trabajado directamente conmigo, la desaparición de ese gran problema pone de relieve que son importantes para mí, que me los tomo en serio y que estoy trabajando duro para hacer de su mundo un lugar mejor.
2. Como soy el evangelista Scrum Master/Scrum principal de toda la empresa, casi nunca soy el Scrum Master permanente de un equipo determinado. Esto me da libertad para crear bit (pero muy poco) de "nosotros contra él" al principio. Esto hace que el equipo se vincule de una forma totalmente distinta a como lo había hecho antes, y también prepara a su Scrum Master permanente para ser el "poli bueno" en el futuro. También me permite ser más firme a la hora de mantenerme en pie durante la puesta en pie, mantener tus estimaciones en privado hasta el momento de la votación durante la estimación, etc. Teniendo en cuenta que, por lo general, tengo que retirarme y pasar a otro equipo al cabo de 6-12 semanas, momento en el que ya funcionan muy bien y están (de media) en torno a los 500%, la mayoría de los equipos lo toleran muy bien y aprenden buenos hábitos más rápidamente, aunque me deje un poco como un maestro.
3. Creo que Sócrates tenía razón. Cuando veo que algo va mal -por ejemplo, que alguien está sentado durante el "Daily Stand-Up"- no siempre me dirijo directamente al transgresor. En lugar de eso, a veces detengo la reunión y pregunto al equipo: "Equipo, ¿alguno de vosotros ve que algo va mal en nuestra reunión en este momento?". Irónicamente, casi siempre es la persona más escéptica la primera en corregir al compañero insolentemente encaramado. Pronto empiezan a llamarse unos a otros para que se inclinen o se sienten mucho antes de que yo detenga la reunión y pregunte qué está fallando. Esto les ayuda a empezar a vigilarse a sí mismos, de modo que no siempre tengo que estar cerca para provocar un buen comportamiento.

Así es más o menos como he llevado a los equipos a la hiperproductividad en tan sólo cuatro semanas, y por qué uno de mis compañeros de trabajo me llama "El Scrum Whisperer". Tengo un equipo que ha logrado 1,650% mayor contribución de valor objetivo por semana después de sólo cuatro meses (16 Sprints) juntos. Estamos muy orgullosos de esas cifras. También me he dado cuenta de que los equipos que utilizan este enfoque de "formato rápido" tienden a alcanzar su codo de Velocity mucho antes, dando Product Owners una visión mayor y más estable de la hoja de ruta que los equipos que utilizan Sprints más largos o pasan su período inaugural resolviendo dónde quieren que se ubique su Scrum Board.