Pasos para iniciar un proyecto con Scrum

Si estas como yo luego de haber realizado cursos, haber leído libros o materiales por internet sobre las Metodologías Agiles y especialmente de Scrum te preguntas y ahora como lo puedo poner en practica.

A mi me toco salir al ruedo con los leones con solo la teoría y comenzar a experimentar lo cual considero que me ayudo muchísimo pero me causo mucho estrés, dolores de cabeza y muchos fracasos, estos me ayudaron a mejorar pero no me fue nada fácil ni alegre tener que probar cosas y no tener resultados, por lo que decidí buscar algunos libros mas para conocer mas y me tope con uno del co-creador de scrum Jeff Sutherland, al final del libro escribe 11 pasos con los cuales se puede iniciar un proyecto.

He aquí, en pocas palabras, cómo iniciar un proyecto con Scrum. Ésta es una descripción del proceso en líneas muy generales, espero que les pueda servir o por lo menos los ayude al momento de iniciar el proyecto.

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.

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.

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.

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.

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.

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.

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.

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:

a. ¿Qué hiciste ayer para ayudar al equipo a terminar el sprint?

b. ¿Qué harás hoy para ayudar al equipo a terminar el sprint?

c. ¿Algún obstáculo te impide o impide al equipo cumplir la meta del sprint?

Eso es todo, en eso consiste la reunión. Si se prolonga más de quince minutos lo estás 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? Las tareas no se asignan desde arriba; el equipo es autónomo: él lo hace. Tampoco se rinden informes detallados a la dirección. El Scrum Master se encarga de eliminar los obstáculos, o impedimentos, contra el progreso del equipo.

9. Revisión del sprint. Ésta es la reunión en la que el equipo muestra lo que hizo durante el sprint. Todos pueden asistir, no sólo el responsable del producto, el Scrum Master y el equipo, sino también los demás interesados, la dirección, clientes, quien sea. Ésta es una reunión abierta 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 sí una función concluida de uno de ellos.

10. Retrospectiva del sprint. Una vez que el equipo ha mostrado lo que logró en el sprint más reciente –la cosa “terminada” y en posibilidad de enviarse a los clientes en busca de realimentación–, piensa en qué marchó bien, qué pudo haber marchado mejor y qué puede mejorar en el siguiente sprint. ¿Cuál es la mejora en el proceso que como equipo pueden implementar de inmediato?

Para ser eficaz, esta reunión requiere cierto grado de madurez emocional y una atmósfera 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? Es crucial que la gente, como equipo, asuma la responsabilidad de su proceso y de sus resultados y busque soluciones también como equipo. Al mismo tiempo, debe tener fortaleza para tocar los temas que le incomodan de un modo orientado a la solución, no acusatorio. Y el resto del equipo ha de tener la madurez de oír la realimentación, aceptarla y buscar una solución, no ponerse a la defensiva.

Al final de la reunión, el equipo y el Scrum Master deben acordar una mejora al proceso que implementarán en el siguiente sprint. Esa mejora al proceso, también llamada kaizen, debe incorporarse en la bitácora del sprint siguiente, con pruebas de aceptación. De esta manera, el equipo podrá ver fácilmente si en verdad implementó la mejora y qué efecto tuvo ésta en la velocidad.

11. Comienza de inmediato el ciclo del siguiente sprint, tomando en cuenta la experiencia del equipo con los impedimentos y mejoras del proceso.

Otras publicaciones las puedes leer en Medium.