It occurred to me one day that Scrum Teams are the customers of the Scrum Master. If we don’t already know it, Scrum teaches us that customers of our enterprise don't really know what they want until they have seen it, or at least something to define what they don’t want. So why would we expect Scrum Teams to know how to set up, for example, their Sprint Planning Meetings if they haven't seen a working prototype?
Este enfoque se documentó en la presentación de Agile 2009 titulada "Shock Therapy" (disponible en http://www.rapidscrum.com/resources.php), de la que son coautores Jeff Sutherland y Bjorn Granvik.
Cuando me uno a un equipo como su Scrum Master, dicto unas cuantas normas no negociables (con suavidad si es posible, con firmeza si es necesario). Estas normas siguen vigentes hasta que el equipo cumple tres criterios:
- 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.
Again, this one is sometimes met with a ceremonial rolling of the eyes but – so far, anyway – they have all eventually come around to this. It's usually at about week three when I can intentionally spark a debate over whether a card is a 3 or a 5, then have the pleasure of pointing out to them the passion with which they are debating these recently-meaningless values. I also make a point of shouting "BA!" whenever they all vote the same value for a given card. My intent is to show them how often they actually agree in their vote. As the mood on the team lightens up, some teams begin scanning the other votes and cheering themselves when that happens. Only one has returned my "Ba!" with a "Humbug!" In any event, they all start having fun with it and that's important.
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.
I have a basic template that I use initially for all teams. It includes four columns that are drawn to be the exact width of the User Story cards we use (to prevent creating rows of cards in a single swim lane). The columns are “Product Backlog”, “Sprint Backlog”, “In Progress” and “Done.” This is usually met with complaints that the board doesn’t allow the Team to represent enough “states” (Design, Coding, Code Complete, Testing, Test Complete, Bug Fix, etc.). This is the perfect chance to educate the Team about the true purpose of the Board as an Information Radiator to non-Team members. It is there to reflect what the Team knows about a card. It is not a communication tool between Team members, so any states that are meaningless to external observers are not appropriate on the board.
I choose the location of the Scrum Board unilaterally and use it as the focus of the Daily Stand-Up Meeting. When the team is first formed, I let them focus on the interaction with their teammates (the three Achievement questions, plus my Fourth Question described in Scrum Metrics for Hyper Productive Teams paper from Agile 2010) and I move their cards across the Radiator's surface myself. Within a couple of weeks, they start moving cards themselves without having been asked. This is usually my first indication that I can begin slowly stepping back and relaxing my demands.
Las reuniones de planificación del Sprint serán de cuatro horas, una vez por semana.
The first complaint of most Engineers is that they perceive Scrum imposing a highly disruptive schedule on them, with more meetings than they somehow think they have ever had before. To minimize this common concern, I consolidate everything but the Daily Stand-Up meetings into a single, four-hour meeting. Within a few weeks, most Teams only need a couple of hours to achieve it all. And by the end of about eight Sprints together, the meetings are becoming ninety minutes or less in duration for a one week Sprint.
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 signals that the meeting is nearly complete. They happen in a single motion with my new teams, though more mature teams eventually choose to split these activities into unique meetings. The Product Owner participates in an advisory role only during this phase of the meeting but never votes or tries to influence the estimates. I spend most of my time in this phase trying to keep the teams from unnecessarily breaking Story Cards down into task sequences, which some tend to do. The INVEST mnemonic is really handy here. As soon as a card passes all six INVEST checks, we stop breaking it down, estimate it and get to work.
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.
Some Engineers understand this right away. Others feel most productive or fulfilled when they have multiple projects in progress. They don't appreciate my pointing out that there is no value in incomplete work – but point it out, I do. Often. I insist and enforce that they work on cards without multi-tasking and in priority order. Sometimes this leads to petulant protests with people sitting idle but they’re doing less damage in that mode than with their hands in nine projects, none of which will be done.
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.
This is roughly how I have driven teams into hyper-productivity in as few as four weeks, and why one of my co-workers calls me "The Scrum Whisperer." I have one team that has achieved 1,650% higher targeted value contribution per week after just four months (16 Sprints) together. We are pretty proud of those numbers. I've also noticed that teams using this immersive training approach tend to hit their Velocity elbow much sooner, giving Product Owners a greater and more stable view of the roadmap than teams who use longer Sprints or spend their inaugural period hashing out where they want their Scrum Board to be located.
It's a fairly large culture shock for most teams and doesn't yield a lot of friendly lunch invitations at first. But, per feedback from my VP of Engineering, they only “…hate [me] for about 2-3weeks. Then they're indifferent to [me] for another few weeks. Then they scream bloody murder if [he tries] to take [me] away from them." I do stay in touch with teams that I've kick-started like this and, with one notable exception, they have all continued their trend of improvements in my absence, which was always my goal.
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