Scrum: Caos controlado

Scrum es un proceso ágil de administración de proyectos. Por su naturaleza es iterativo y pretende tener un producto listo al final de cada iteración. Toma su nombre de una jugada de rugby, y que Ken Schwaber, uno de los padres del método, describe como “caos controlado”.

Historia

En 1995, Ken Schwaber, un metodólogo de software reconocido, decidió descubrir porqué las metodologías de desarrollo funcionaban tan mal cuando se intentaban seguir al pie de la letra. Con este fin, reunió a varios expertos de teoría de procesos de DuPont, y les presentó diversas metodologías. La respuesta de los expertos fue reveladora e inesperada. La industria de desarrollo de sistemas está usando el modelo de control de procesos equivocado. Existen dos aproximaciones al control de procesos:

• El proceso definido, en el que todos los elementos y componentes son bien conocidos y controlados. Dado un conjunto de entradas, se obtiene un conjunto de salidas igual y consistente siempre.
• El proceso empírico, por otro lado, espera lo inesperado. Como no se conoce el proceso con suficiente detalle, y producen resultados inesperados e irrepetibles, la única manera de controlarlos es a través de inspecciones constantes y minúsculas correcciones aplicadas con frecuencia.

El desarrollo de software, siendo una actividad tan profundamente intelectual, y que necesita tanta creatividad, es un mal candidato al proceso definido. El desarrollo de software, entonces, no debería entenderse como una línea de montaje, sino como una serie de inspecciones constantes acompañadas de correcciones inmediatas. Schwaber llama a esta forma de trabajar el proceso caórdico, y nota que espontáneamente, los equipos de trabajo se coordinan con muy poca intervención de entidades externas. Schwaber llama a este proceso la auto-organización

Roles de Scrum

Hay cuatro roles para los participantes de un proyecto que se administre con scrum:

• Dueño del producto. Es quien determina las prioridades. Debe ser una sola persona.
• Dueño del scrum. Administra y facilita la ejecución del proceso.
• Equipo de trabajo. Son los encargados de entregar resultados al final del sprint.
• Interesados. Asesoran y observan el proceso. Tienen interés en el resultado final.

El Scrum

El método es iterativo en su naturaleza. Cada iteración, o sprint, dura un mes calendario. Este inicia con una reunión entre el equipo de trabajo, el dueño del scrum (scrum-master) y los patrocinadores del proyecto. En esta reunión, los patrocinadores exponen y aclaran los requerimientos del proyecto, y también se encargan de priorizarlos. Este es el alcance acumulado del producto (product backlog). Posteriormente el equipo de trabajo decide qué funcionalidad puede entregar al final del sprint – el alcance acumulado del sprint (sprint backlog).

Es de gran importancia que los patrocinadores del proyecto respeten el alcance, y no alteren o interfieran con el equipo de trabajo durante el sprint. Aquí se hace una estimación inicial del trabajo necesario para entregar la pila del sprint. También es indispensable no violar el principio ágil de trabajar únicamente 40 horas a la semana. Después de esta reunión, el equipo es libre de organizarse como considere conveniente. Cada día, el equipo de trabajo se reúne con el dueño del scrum en la junta scrum.

La Junta Scrum

La junta scrum debe ser breve, no más de 15 minutos al día. Si no se puede mantener en esos niveles, entonces hay muchas personas. Será necesario identificar quién debe participar en esa reunión. En esta reunión, se le toma el pulso diario al proyecto. El dueño del scrum detecta qué problemas existen, y busca quitarlos de en medio, fungiendo como un facilitador más que como un líder de proyecto.

El objetivo principal de la junta scrum es que los participantes del sprint hablen entre ellos y descubran qué necesidades tienen, las resuelvan en el momento, y si no es posible, buscar los foros adecuados posteriormente. En esta reunión se hacen estimaciones del trabajo restante de cada participante. Estas estimaciones se recogen y tabulan en las gráficas de consumo. Estas gráficas deben mostrar que el trabajo pendiente para entregar la funcionalidad acordada debe disminuir con el paso del tiempo, de otra manera, lo que demuestran es que el equipo fue demasiado optimista y ahora se está enfrentando con la realidad. El maestro del scrum puede tomar la decisión de acordar una disminución del alcance con el dueño del producto, o informarle con tiempo que no se va a lograr la meta, pero que es lo que sí es realmente factible. En el caso remoto de que los resultados sean de verdad terribles, es posible cancelar todo el sprint.

Sashimi

El sashimi es un plato japonés en el que se presentan finas rodajas de pescado apoyadas parcialmente sobre la anterior. En el contexto de scrum, y de los métodos ágiles en general, cada rebanada se entiende como un pedacito del todo que está listo para consumirse en cualquier momento. Cuando se planean las actividades del scrum, los productos resultantes deben estar listos para consumo del usuario. Eso quiere decir que no sólo debemos contar con el sistema de software. También debe estar lista la documentación, el instalador, y el manual de usuario, por ejemplo.

La Presentación

Al final del sprint se hace una presentación con el dueño del producto. En esta reunión se evalúa el resultado del sprint, y se revisa el alcance acumulado del producto, y con base al producto que el usuario final tiene ahora, se revaloran los requerimientos, para escoger un nuevo alcance para el próximo sprint. Es importante que el producto final del sprint tenga la calidad necesaria para que el cliente pueda usarlo por sí mismo. Esto le permitirá tener un mejor entendimiento sobre a dónde quiere dirigir el desarrollo de su producto. Además de que le permitirá ver un progreso real sobre su proyecto, en un corto tiempo. Idealmente, la reunión de presentación al final del sprint debiera fungir como la junta de planeación del próximo sprint.

Pero... ¿En Realidad Funciona?

La premisa básica de scrum, y en gran medida de los métodos ágiles, es que si el colaborador está comprometido con el equipo de trabajo, y el jefe confía en ellos, entonces el equipo invierte el tiempo en producir algo, en lugar de estar justificando el avance o falta del mismo. Esto reduce la necesidad de reuniones y reportes de situación. Básicamente, se parece mucho a las tareas universitarias, en las que el profesor dice qué hay que hacer y cuando hay que entregarlo. Al principio, todos los involucrados, y en especial el equipo de trabajo, se sentirán extraños, pues no hay una estructura centralizada de control. Pero en el momento en que el equipo se organiza, la falta de control central se vuelve la principal ventaja del método.

Es muy difícil otorgarle al equipo de trabajo el control que requiere scrum. La técnica es aventurada, y existe un riesgo de toparse con límites reales, que puedan llegar a cancelar el proyecto. Una falla puede tener mucho impacto en los miembros del equipo de trabajo por los niveles de envolvimiento personal con el proyecto.

Lo Que No Funciona

A continuación comparto una lista de las trampas más comunes de una implementación primeriza de scrum en una organización con métodos tradicionales, y que en mi experiencia son señales claras de que no se está trabajando de acuerdo al principio inicial de scrum de autorregulación.

• La junta scrum no es un reporte de avance. Los participantes del equipo deben ver la junta scrum como una oportunidad para resolver sus problemas inmediatos. Una clara señal de que las juntas no están funcionando como deberían es que los integrantes del equipo miran al dueño del scrum y le relatan sus actividades, como en un reporte de situación, en lugar de hablar entre ellos o solicitar la intervención del dueño del scrum en algún asunto relacionado con las áreas periféricas de la organización.

• No se contemplan todas las actividades necesarias en el sprint. Esto es, se viola el principio del sashimi, siempre tener un producto entregable para el usuario final. Es muy común que en los primeros sprints se olviden algunas actividades, típicamente las que se podrían clasificar de poco ágiles o poco sexy, como mantener los documentos o los manuales de usuario. Es normal, pero también es importante que se corrija el rumbo una vez detectado esto. Una actividad no puede considerarse completa sin estos productos adicionales. El dueño del scrum debiera desincentivar que un miembro del equipo cambie de actividad antes de terminarla por completo.
• Interferir con el equipo de trabajo durante el scrum. Es muy tentador para el dueño del producto acercarse al equipo para solicitar un pequeño cambio. Y es también muy fácil para el equipo aceptarlo – al fin y al cabo, estamos siendo ágiles, ¿o no? El dueño del scrum debe combatir estas intervenciones para mantener al equipo centrado en entregar la funcionalidad en tiempo y en forma.

Referencias

1. www.controlchaos.com
2. Ken Schwaber. Agile Project Management with Scrum. 2004, Microsoft Press