Scrum, como el baile o tocar un instrumento, es algo que sólo puedes aprender con la práctica. 

Implementando Scrum

1. Elige un responsable del producto (Product owner). Alguien que sepa cuál es la visión y donde radica el valor del producto. Debe ser capaz de proporcionar al equipo realimentación del cliente en todos y cada uno de los sprints. Tiene que dedicar la mitad de su tiempo a hablar con las personas que compran el producto (clientes) y la otra mitad a crear con el equipo los pendientes. El cliente es cualquier persona que obtendrá valor de lo que tú haces. 

El responsable del producto debe tener las siguientes características:

• Conocer el terreno: comprender el proceso que el equipo recorre para saber qué puede hacerse y qué no. Pero también debe conocer el qué para saber cómo traducir lo qué puede hacerse en valor verdadero y significativo.

• Debe tener autoridad para tomar decisiones sobre la visión del producto y qué debe hacerse para realizarla.

• Debe estar a disposición del equipo para explicar qué se debe hacer y por qué.

• El responsable del producto debe hacerse cargo del valor.

2. Selecciona un equipo. ¿Quiénes son las personas que pueden realizar el trabajo? Este equipo debe contar con todas las habilidades necesarias para tomar la visión del responsable del producto y hacerla realidad. El equipo debe ser de tres a nueve personas por regla general. Si se requiere un equipo más grande recuerda que scrum es escalable. Algunas características que el equipo debe tener:

• Cross functional. El equipo debe contar con todas las habilidades necesarias para convertir los ítems del product backlog en un incremento del producto tras cada sprint.

• Los miembros del equipo deben ser capaces de hacer las cosas bien y a la primera. Si un error es atacado el mismo día en que se cometió, corregirlo puede llevar una hora. Detectarlo y arreglarlo días después puede implicar hasta veinticuatro veces más esfuerzo. ¿A quién le importa cuántas horas trabajó alguien en algo? Lo relevante es que se entregue rápido y sea de gran calidad.

• Trabaja a un ritmo sostenible. Trabajar mucho tiempo no permite hacer más, sino menos.

3. Elige un Scrum Master. Esta es la persona que capacita al resto del equipo en el enfoque Scrum y que ayudará al equipo a eliminar todo lo que le atrasa.

4. Crea y prioriza el product backlog. Se trata de una lista de alto nivel de todo lo que debe hacerse para volver realidad la visión. El product backlog evoluciona durante el periodo de vida del producto. La clave es tener esta lista priorizada y evaluada. ¿Cuáles son los elementos con mayor efecto de negocios, los más importantes para el cliente, los que pueden producir más dinero, y los más fáciles de hacer? El ochenta por ciento del valor de un producto radica en un veinte por ciento de la funcionalidad. La clave de Scrum es saber cómo hacer primero ese veinte por ciento. Deduce que puede ofrecer más valor con menos esfuerzo.

5. Afina y estima el product backlog. Es crucial que el equipo que hará realidad el producto estime cuánto esfuerzo implica cada uno de los elementos del product backlog. El equipo debe examinar cada elemento del product backlog y ver si es viable.

• ¿hay información suficiente para llevar a cabo el elemento?

• ¿Es el elemento lo bastante pequeño para estimarse?

• ¿existe una definición de “terminado”?

• ¿Esto crea valor visible?

No calcules en horas, calcula por tamaño relativo: pequeño, mediano, 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.

6. Planeación del sprint. El equipo, el Scrum Master y el product owner se sientan a planear el sprint. Los sprints son siempre de duración fija, de un mes o menos. El equipo examina el product backlog 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 acumulo en el mas reciente. Este número se conoce como velocidad del equipo. El Scrum Master y el equipo deben de tratar de incrementar la velocidad en cada sprint. Durante esta reunión, todos deben acordar una meta de sprint, que todos han de cumplir en ese sprint. El sprint 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. ¡Planea realidades, no fantasías!

La clave es ir afinando el plan a lo largo del proyecto, no dejarlo terminado desde el principio. Planea en detalle apenas lo suficiente para cumplir el próximo incremento de valor y calcula el resto del proyecto en líneas generales.

7. Vuelve visible el trabajo. La forma más común de hacerlo en Scrum es usando un tablero 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 (burndown chart. En el eje Y aparece el número de puntos que el equipo introdujo en el sprint y en el eje X el número de días que durará el sprint. 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 que conduzca a cero puntos para el último día del sprint.

8. Parada diaria. Este 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 contesta tres preguntas: ¿Qué hiciste ayer para ayudar al equipo a terminar el sprint? ¿Qué harás hoy para ayudar al equipo a terminar el sprint? ¿Algún obstáculo te impide o le impide al equipo cumplir la meta del sprint? Eso es todo, en eso consiste la reunión. Si demora más de quince minutos lo estas haciendo mal. Lo que esto hace es ayudar al equipo a saber exactamente dónde se encuentra todo en el curso de un sprint. ¿Todas las tareas serán terminadas a tiempo? ¿Hay oportunidades de ayudar a otros miembros del equipo a vencer obstáculos?

9. Revisión del sprint. Esta es la reunión donde el equipo muestra lo que realizó durante el sprint. Todos pueden asistir, no solo el responsable del producto, el Scrum Master y el equipo, sino también los demás interesados, la dirección, usuarios, clientes, etc. Esta es una reunión en la que el equipo hace una demostración de lo que pudo llevar a “terminado” durante el sprint. 

El equipo debe mostrar únicamente lo que satisface la definición de “terminado”, lo total y completamente concluido y que puede entregarse sin trabajo adicional. Esto puede no ser un producto terminado, pero si una función concluida de uno de ellos.

• ¿esto es lo que quieren?

• ¿Resuelve al menos una parte de su problema?

• ¿Vamos en la dirección correcta?

 10. Retrospectiva del sprint. Una vez que el equipo ha mostrado lo que logró en el sprint más reciente, piensa en qué marchó bien, qué pudo haber marchado mejor, y qué puede mejorar en el siguiente sprint. ¿Cuál es la mejora que como equipo pueden implementar de inmediato?

Para ser eficaz, esta reunión requiere cierto grado de madurez emocional y de un ambiente de confianza. La clave es que no se trata de buscar a quién culpar; lo que se juzga es el proceso. ¿Por qué tal cosa ocurrió de tal manera? ¿Por qué pasamos por alto tal otra? ¿qué podríamos hacer más rápido? Al final de la reunión, el equipo y el Scrum Master debe acordar una mejora al proceso que implementaran en el siguiente sprint. Debe incorporarse en el sprint backlog del siguiente sprint, con pruebas de aceptación. De esta manera el equipo podrá ver si de verdad se implementó esta mejor y qué impacto tuvo en la velocidad del equipo.

11. Comienza de inmediato el ciclo del siguiente sprint.