Jeff Sutherland - Scrum

N ingún proyecto es resultado del trabajo de una sola persona; es producto de un equipo y este libro no es la excepción.

Quiero dar primero las gracias a mi hijo, J. J. Sutherland. Fue él quien sugirió que escribiéramos juntos un libro sobre el notablilísimo viaje por el que Scrum me ha llevado en unos cuantos años. Él quería un descanso tras una década de correr de una guerra y un desastre a otros para NPR y pensó que contar la historia de cómo surgió Scrum, por qué da resultado y cómo ha cambiado al mundo sería no sólo importante, sino también entretenido. El texto que tienes ahora en las manos narra mi historia, pero es producto de muchas horas con mi hijo, quien llevó las palabras a la página.

Howard Yoon, el más hábil de los agentes literarios, nos pidió pensar en grande, vasto y lejos. Su discernimiento, consejos, sabiduría y simple y astuto conocimiento práctico no sólo hicieron posible este libro, sino que también lo llevaron a una escala completamente distinta.

No es común tener la oportunidad de trabajar con un verdadero maestro en su oficio y yo tuve la increíble suerte de disponer de esa oportunidad con Rick Horgan, del Crown Publishing Group. Su tacto, diestro y consumado, hace sencillamente que las cosas mejoren. Y consigue que todo parezca fácil. Me quito el sombrero; gracias de verdad.

El primer responsable del producto Alex Brown, Joe Justice y el resto del equipo de Scrum, Inc., compartieron ideas decisivas, energía ilimitada y vasta experiencia.

Gracias también:

A los profesores Hirotaka Takeuchi e Ikujiro Nonaka, cuyo trabajo dio origen a la idea de Scrum y quienes son desde entonces mis buenos amigos.

A mi cocreador, Ken Schwaber, cuya irascible obstinación me ayudó a dar forma a Scrum y convertirlo en la fuerza que es hoy.

Y, sobre todo, a mi esposa, Arline, quien ha estado a mi lado desde el principio y, como ministra unitaria-universalista, introdujo Scrum en muchas iglesias. Hizo un mundo mejor cuando nos enseñó cómo aplicar Scrum a una organización entera.

Gracias, por último, a los cientos de miles de Scrum Masters, responsables de productos y equipos de todo el planeta que realmente viven Scrum cada día. Ustedes hacen de Scrum la fuerza vibrante y positiva que es en el mundo y nunca dejan de sorprenderme con lo que han logrado con él.

IMPLEMENTACIÓN DE SCRUM: CÓMO EMPEZAR

A hora que ya has leído este libro, he aquí, en pocas palabras, cómo iniciar un proyecto con Scrum. Ésta es una descripción del proceso en líneas muy generales, pero debería ser suficiente para comenzar. Este libro fue escrito para darte el porqué detrás de Scrum. Esta sección te proporcionará, en forma abreviada, el cómo.

1. Elige un responsable del producto. Este individuo es quien posee la visión de lo que vas a hacer, producir o lograr. Toma en cuenta los riesgos y recompensas, qué es posible, qué puede hacerse y qué es lo que le apasiona. (Véase el capítulo ocho: Prioridades, para más información).

2. Selecciona un equipo. ¿Quiénes serán las personas que harán efectivamente el trabajo? Este equipo debe contar con todas las habilidades necesarias para tomar la visión de los responsables del producto y hacerla realidad. Los equipos deben ser pequeños, de tres a nueve personas por regla general. (Véase el capítulo tres: Equipos, para más información).

3. Elige un Scrum Master. Ésta es la persona que capacitará al resto del equipo en el enfoque Scrum y que ayudará al equipo a eliminar todo lo que lo atrasa. (Véase el capítulo cinco: Desperdicio, para más información).

4. Crea y prioriza una bitácora del producto. Se trata de una lista de alto nivel de todo lo que debe hacerse para volver realidad la visión. Esta bitácora existe y evoluciona durante el periodo de vida del producto; es la guía de caminos hacia éste. En un momento dado, la bitácora del producto es la visión definitiva de «todo lo que el equipo podría hacer, en orden de prioridad». Hay sólo una bitácora del producto; esto significa que el responsable del producto debe tomar decisiones de priorización en todo el espectro. El responsable del producto debe consultar tanto a todos los interesados como al equipo para cerciorarse de que representa lo que la gente necesita y lo que se puede hacer. (Véase el capítulo ocho: Prioridades, para más información).

5. Afina y estima la bitácora del producto. Es crucial que la gente que realmente se hará cargo de los elementos de la bitácora del producto estime cuánto esfuerzo implicarán. El equipo debe examinar cada elemento de la bitácora y ver si, en efecto, es viable. ¿Hay información suficiente para llevar a cabo el elemento? ¿Éste es lo bastante pequeño para estimarse? ¿Existe una definición de «terminado»; es decir, todos están de acuerdo en los criterios que deben cumplirse para poder decir que algo está «terminado»? ¿Esto crea valor visible? Cada elemento debe poder mostrarse, demostrarse y (es de esperar) entregarse. No calcules la bitácora en horas, porque la gente es pésima para esto. Calcula por tamaño relativo: pequeño, mediano o grande. O, mejor todavía, usa la serie de Fibonacci y estima el valor puntual de cada elemento: 1, 2, 3, 5, 8, 13, 21, etcétera. (Véase el capítulo seis: Planea realidades, no fantasías, para más información).

6. Planeación del sprint. Ésta es la primera de las reuniones de Scrum. El equipo, el Scrum Master y el responsable del producto se sientan a planear el sprint. Los sprints son siempre de extensión fija, inferior a un mes. La mayoría de la gente ejecuta en la actualidad uno o dos sprints semanales. El equipo examina el inicio de la bitácora y pronostica cuánto puede llevar a cabo en este sprint. Si el equipo ha pasado por varios sprints, debe considerar el número de puntos que acumuló en el más reciente. Este número se conoce como velocidad del equipo. El Scrum Master y el equipo deben tratar de aumentar ese número en cada sprint. Ésta es otra oportunidad para que el equipo y el responsable del producto confirmen que todos comprenden a la perfección cómo esos elementos cumplirán la visión. Durante esta reunión todos deben acordar asimismo una meta de sprint, que todos han de cumplir en este sprint.

Uno de los pilares de Scrum es que una vez que el equipo se compromete con lo que cree que puede terminar en un sprint, eso se queda ahí. No puede cambiar ni crecer. El equipo debe ser capaz de trabajar en forma autónoma a lo largo del sprint para terminar lo que pronosticó que podía hacer. (Véase el capítulo cuatro: Tiempo, y el capítulo seis: Planea realidades, no fantasías, para más información).

7. Vuelve visible el trabajo. La forma más común de hacerlo en Scrum es crear una tabla de Scrum con tres columnas: Pendiente, En proceso y Terminado. Notas adhesivas representan los elementos por llevar a cabo y el equipo avanza por la tabla conforme los va concluyendo, uno por uno.

Otra manera de volver visible el trabajo es crear un diagrama de finalización. En un eje aparece el número de puntos que el equipo introdujo en el sprint y en el otro el número de días. Cada día, el Scrum Master suma el número de puntos completados y los grafica en el diagrama de finalización. Idealmente, habrá una pendiente descendente que conduzca a cero puntos para el último día del sprint. (Véase el capítulo siete: Felicidad, para más información).

8. Parada diaria o Scrum diario. Éste es el pulso de Scrum. Cada día, a la misma hora, durante no más de quince minutos, el equipo y el Scrum Master se reúnen y contestan tres preguntas: