Empieza por Scrum

Primavera buscó algo mejor

Bob Schatz llegó a Primavera hace unos años como nuevo Vicepresidente de Desarrollo. Traía consigo la experiencia de su carrera en General Electric y, posteriormente, en una start-up de software. Impregnado de los principios del liderazgo, Schatz introdujo una serie de cambios para aumentar la productividad y el trabajo en equipo de los desarrolladores; entre ellos, un nuevo espacio de oficinas, reuniones y programas de motivación y un reajuste de la organización. Las mejoras graduales que consiguió fueron muy positivas, pero insuficientes para satisfacer las necesidades de la empresa y sus clientes.

Mejores prácticas en gestión de proyectos Scrum y desarrollo ágil de software XP: Primavera Success Story. Libro Blanco de Object Mentor, Inc. y ScrumMaster, 2004.

Bob empezó por formar a todos sus directivos como ScrumMasters, el equivalente en Scrum a un gestor de proyectos. La función del ScrumMaster es facilitar la colaboración entre el departamento de marketing y los equipos de desarrollo para crear incrementos de funcionalidad en iteraciones mensuales.

La primera iteración, o "Sprint" en la terminología de Scrum, logró avances significativos en el principal riesgo de la versión 4.0: la integración de dos sistemas de software independientes. Primavera había decidido que una característica clave de la versión 4.0 era la integración de un nuevo sistema de flujo de trabajo y colaboración en su software de gestión de proyectos. Esta integración era amplia y endiabladamente difícil.

Al final del primer Sprint se llevó a cabo una revisión. El equipo demostró algunas funcionalidades del portal de gestión de proyectos a la dirección y a los ejecutivos. Dado que una de las normas de Scrum es que al final de cada Sprint sólo se pueden demostrar incrementos de funcionalidad de productos potencialmente comercializables, se trataba de una funcionalidad sólida, probada y documentada. Dick Faris, Joel Koppelman y la mayor parte del equipo directivo estaban presentes, junto con los directores y el equipo de marketing de producto. A medida que se demostraba la funcionalidad, todo el mundo se extasiaba. Probablemente se había eliminado el riesgo, porque todo el producto funcionaba a la perfección. Francamente, nadie podía creer lo que estaban viendo apenas un mes después de iniciado el ciclo de desarrollo.

Este éxito inicial dio a Scrum la credibilidad necesaria dentro de Primavera para seguir adelante. Se había establecido un punto de partida -en código- para ampliar el flujo de trabajo y la colaboración a todas las partes de la nueva versión de Primavera. El equipo se había demostrado a sí mismo, y a todos los demás, que podía crear funcionalidad cada mes. Y, lo que es más importante, como todos podían ver que la funcionalidad funcionaba, podían empezar a intercambiar ideas sobre los siguientes pasos más importantes que había que dar. Podían dirigir al equipo para construir la siguiente funcionalidad más valiosa durante el Sprint del mes siguiente. Primavera y Scrum estaban en camino.

La mejor y más rápida forma de entender el tipo de ambiente que Scrum produce en Primavera es presenciar una de sus Sprint Reviews. Primavera parece una feria de ciencias. Una gran sala está abarrotada con los diez equipos de desarrollo agrupados en torno a áreas de demostración, exponiendo sus objetivos y los resultados conseguidos en los últimos 30 días. Los propietarios del producto (responsables de marketing), las partes interesadas (patrocinadores del proyecto) y los ejecutivos de la empresa se unen a los debates y aportan sus comentarios, dedicando 15 minutos a cada equipo. Cada 15 minutos, una bocina (en realidad un claxon de bicicleta) indica que es hora de pasar al siguiente equipo. Este es el enfoque empírico en pleno modo de demostración.

Después de una de esas revisiones, Joel Capperella, Director de Producto de Primavera, dijo: "Es increíble todo lo que se consigue hacer en un mes, todos los meses".