Mientras actualizaba su documento para Scrum "Terapia de choque", Scott Downey de Rápido Scrum encontró uno de los correos electrónicos originales que escribió sobre cómo impulsó a docenas de equipos hacia la hiperproductividad. Él comenta a continuación y el documento completo fue publicado como:
J. Sutherland, S. Downey y B. Granvik, "Terapia de choque: Una solución para un Scrum hiperproductivo" en Agile 2009, Chicago, 2009.
Jeff estará en Agile 2012 en Dallas y hablando de hiperproductividad a las 9:30 del jueves 16 de agosto.
- Un aumento mínimo de 240% en Velocidad
- Han completado con éxito tres Sprints consecutivos
- Han identificado una buena razón comercial para empezar a cambiar las normas
Mis reglas iniciales son más o menos las siguientes:
Todos los miembros del equipo asistirán a una sesión de formación Scrum.
Imparto un curso muy resumido de Introducción a Scrum y todo el equipo se reúne en una sola sesión. Hasta que no se haya formado a todo el mundo, no empezaremos nuestro primer Sprint.
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:
Ingeniero: "¡Pero no puedo hacer nada en una semana!"
Scott: "Entonces las simples matemáticas sugieren que sólo puedes 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.
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:
- Característica completa
- Código completo
- Sin defectos conocidos
- Aprobado por el Product Owner
- Listo para la producción
Todos los presupuestos se harán exclusivamente en Story Points.
Independientemente del modelo Scrum que finalmente siga, los Story Points son una parte fundamental. Algunos autores recomiendan el uso de Story Points sólo para la estimación del Product Backlog, pero exigen que se cambie a estimaciones basadas en horas cuando se construye el Sprint Backlog. Personalmente, después de haber aprendido que las estimaciones basadas en horas son erróneas por un factor de 50% o más, nunca quiero una unidad tan inexacta y fácil de abusar en mis métricas.
Pero mi razonamiento va más allá.
Como al final hay que aprender a utilizar los Story Points, aunque sólo sea para el Product Backlog, es lógico que cuanta más práctica se tenga, más rápido se aprende. Así que al limitar todas las votaciones y estimaciones a la escala de Story Points, los equipos aprenden rápidamente a utilizar este nuevo mecanismo para categorizar rápidamente el trabajo.
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 en torno a 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 les grito "¡BA!" cada vez que todos votan el mismo valor para una carta determinada. Mi intención es mostrarles con qué frecuencia coinciden realmente en su voto. A medida que se anima el ambiente en el equipo, algunos empiezan a escudriñar los otros votos y a animarse cuando eso ocurre. Sólo uno me ha devuelto mi "¡Ba!" con un "¡Humbug!". En cualquier caso, todos empiezan a divertirse con ello y eso es importante.
Utilizaremos un radiador físico de información.
No sólo insisto en un radiador de información físico, sino que también dejo de utilizar cualquier software de gestión de proyectos y herramientas de gestión de backlog. Quiero que mis equipos disfruten de una experiencia física y táctil durante el proceso de arranque para que, incluso si las tarjetas se convierten en electrónicas más adelante, puedan sentir e imaginar el flujo de lo que está ocurriendo.
Tengo una plantilla básica que utilizo inicialmente para todos los equipos. Incluye cuatro columnas que se dibujan para que tengan el ancho exacto de las tarjetas de Historias de Usuario que utilizamos (para evitar crear filas de tarjetas en un solo carril de natación). Las columnas son "Product Backlog", "Sprint Backlog", "In Progress" y "Done". Esto se suele encontrar con quejas de que el tablero no permite al Equipo representar suficientes "estados" (Diseño, Codificación, Código Completo, Pruebas, Pruebas Completas, Corrección de Errores, etc.).
Esta es la oportunidad perfecta para educar al Equipo sobre el verdadero propósito del Tablero como Radiador de Información para los no miembros del Equipo. Está ahí para reflejar lo que el Equipo sabe sobre una carta. No es una herramienta de comunicación entre los miembros del Equipo, por lo que los estados que no tengan sentido para los observadores externos no son apropiados en el tablero.
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, más mi Cuarta Pregunta descrita en el documento Scrum Métricas para equipos hiperproductivos de Agile 2010) y yo mismo muevo sus tarjetas por la superficie del Radiador.
Al cabo de un par de semanas, empiezan a mover las cartas sin que se lo pida. Este suele ser el primer indicio de que puedo empezar a dar poco a poco un paso atrás y relajar mis exigencias.
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 en una sola reunión de cuatro horas todo lo que no sean las reuniones diarias.
En pocas semanas, la mayoría de los Equipos sólo necesitan un par de horas para conseguirlo todo. 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:
Demostraciones, donde el equipo muestra al Product Owner el trabajo realizado y recibe premios Story Point en función de su precisión.
En 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 la velocidad, la reducción, la capacidad de trabajo y la precisión de los compromisos.
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 cualquier Historia de Usuario mal formada en nombre del equipo, pero siempre me esfuerzo por reunirme con el Product Owner antes de esta reunión, revisar su trabajo y darle la oportunidad de corregir los errores antes de que se convoque la reunión.
Estimación y negociación indica que la reunión está a punto de terminar. Se realizan en una sola moción con mis equipos nuevos, aunque los equipos más maduros acaban optando por dividir estas actividades en reuniones únicas. El Product Owner sólo participa en calidad de asesor durante esta fase de la reunión, pero nunca vota ni intenta influir en las estimaciones.
En esta fase paso la mayor parte del tiempo intentando evitar que los equipos descompongan innecesariamente las Story Cards en secuencias de tareas, algo que algunos tienden a hacer. La nemotecnia INVEST es muy útil en este caso. En cuanto una tarjeta supera las seis comprobaciones INVEST, dejamos de desglosarla, la estimamos y nos ponemos a trabajar.
Compromiso Sprint Backlog es el acto final de este Ubermeeting. En los primeros Sprints, leo literalmente en voz alta lo que significa y lo que no significa "Comprometerse" para que nadie tenga dudas. Una vez que el equipo se compromete con el trabajo, se levanta la sesión.
Durante el Sprint, la multitarea está prohibida. El trabajo debe abordarse y completarse por orden de prioridad.
Algunos ingenieros lo entienden enseguida. Otros se sienten más productivos o realizados cuando tienen varios proyectos en marcha. No les gusta que les diga que el trabajo incompleto no tiene valor, pero se lo digo. A menudo.
Insisto y hago cumplir que trabajen en las tarjetas sin multitarea y por orden de prioridad. A veces esto lleva a protestas petulantes con gente sentada sin hacer nada, pero hacen menos daño en ese modo que con las manos en nueve proyectos, ninguno de los cuales se hará.
También tengo diseños estándar que utilizo para sus Tableros de Planificación de Sprint iniciales, Historias de Usuario, Story Cards, Burndown Charts y seguimiento de Velocity.
Como dije al principio, intento que todo esto se haga con una sonrisa amable y un "por favor", pero generalmente tengo que insistir -a veces con bastante fuerza- para que todos se muevan. Aunque los comienzos son difíciles, al cabo de una semana solemos empezar a reírnos y divertirnos en las reuniones. Y a medida que se centran más y son más competentes con Scrum, rápidamente aflojo mi control sobre algunas de las normas y les dejo que rediseñen su entorno a su gusto, siempre que sigan respetando los principios de Scrum. Mi objetivo es siempre dejar de ser el centro de atención, devolver el control al Equipo y convertirme en un asesor cuya participación no sea necesaria para que el Equipo tenga éxito.
Tres razones clave por las que creo que tengo éxito con este enfoque son:
- Encuentro el problema más grave y desagradable que tiene el equipo y, si es posible, lo resuelvo en uno o dos días después de 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 en el caso de 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 me esfuerzo por hacer de su mundo un lugar mejor.
- Como soy el jefe de Prácticas Ágiles de toda la empresa, nunca soy el Scrum Master permanente de un nuevo equipo. Esto me da la libertad de crear un poco (pero muy poco) de ambiente de "nosotros contra él" al principio. Esto hace que el equipo se vincule de una forma que a menudo es totalmente nueva, y también prepara a su Scrum Master permanente para ser el "poli bueno" en el futuro. 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 unas 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 haga sentir un poco como un maestro.
- 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 o resistente 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 formación inmersiva tienden a alcanzar su codo de velocidad mucho antes, lo que proporciona a 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 periodo inaugural resolviendo dónde quieren que se sitúe su Scrum Board.
Es un choque cultural bastante grande para la mayoría de los equipos y al principio no hay muchas invitaciones amistosas a comer. Pero, según los comentarios de mi vicepresidente de ingeniería, sólo "...me odian durante 2-3 semanas. Luego se muestran indiferentes durante otras semanas. Luego gritan como locos si [él intenta] alejarme de ellos".
Sigo en contacto con los equipos que he puesto en marcha y, con una notable excepción, todos han seguido mejorando en mi ausencia, lo que siempre ha sido mi objetivo.
Espero que todo esto le resulte útil cuando intente que sus equipos alcancen un rendimiento Scrum óptimo.
Scott Downey
Propietario, RapidScrum.com
Scott@RapidScrum.com
Spanish 
English 
French