RUCK, APLICACIÓN DE METODOLOGÍAS ÁGILES EN EQUIPOS DINÁMICOS.

Transcripción

1 RUCK, APLICACIÓN DE METODOLOGÍAS ÁGILES EN EQUIPOS DINÁMICOS. Etxebarria, A. Jiménez, J. Sansano, A. Resumen Unidad Asociada UVA-CSIC a través del Centro de Astrobiología (España) En este trabajo se presenta una primera aproximación de aplicación de metodologías agiles en equipos dinámicos. RUCK es una nueva metodología en gestión de proyectos basada en SCRUM y Open Space Technology. Al igual que SCRUM, toma su nombre del rugby, donde un RUCK es una melé abierta, sin una estructura definida y a la que los jugadores pueden incorporarse o retirarse según sea necesario. La metodología trata de facilitar esfuerzos cooperativos realizados por pequeños grupos de individuos con una disponibilidad limitada. Al igual que en SCRUM, el proyecto se divide en paquetes de trabajo casi independientes denominados historias. Cada historia se divide a su vez en tareas autoconclusivas con un tiempo estimado relativamente corto. El trabajo se organiza en ciclos cortos con informes de estado frecuentes. Para organizar los equipos se utilizan los 4 principios de Open Space y la Ley de la Movilidad. En cada sprint, los participantes que puedan dedicar suficiente tiempo para finalizar una o más tareas, y sólo esos participantes, anuncian las tareas que podrán llevar a cabo. Si, por la razón que fuere, cualquiera de los participantes debe abandonar una tarea en medio de un Sprint, debe anunciarlo lo antes posible para que cualquier otro participante con interés en ello pueda tomar el relevo y alcanzar los objetivos del Sprint. En el presente trabajo se exponen los resultados preliminares de su aplicación a pequeños proyectos colaborativos y las primeras conclusiones de su uso. Abstract Within this work, the first approach on agile methodologies application for dynamic teams is presented. Ruck is a new project management methodology based on SCRUM and Open Space Technology. Like SCRUM, it takes its name from rugby where a ruck is a loose scrum, without a defined structure and in which players can join or leave as required. The methodology tries to allow collaborative efforts performed by reduced groups of individuals with a limited availability. Like SCRUM, the project is divided in almost independent work packages called histories. Each history is then divided in self-conclusive tasks with a relatively short lifetime. The work is organized in short lived iterative cycles with frequent status reports. Early problem reporting is encouraged so all the participants can help in solving them as soon as possible. For team organization, the four principles of Open Space and the Mobility Law are used. On each sprint, the participants who can dedicate enough time to finish one or more tasks, and only those participants, announce which tasks will they be able to achieve. If, for some 153

2 reason, any of the participants must abandon a task in the middle of a Sprint, it be must announced as soon as possible so any other interested participant can take the place and accomplish the objective for the Sprint. The present job presents the preliminary results as well as the first conclusions on the application and use of this new methodology for small collaborative projects. Palabras clave: Metodologías agiles, SCRUM, equipos dinámicos, Open Space Technology Keywords: Agile methodologies, SCRUM, dinamic teams, Open Space Technology 1. Introduccion La metodología RUCK que se presenta en este articulo, es una adaptación de SCRUM (Takeuchi & Nonaka, 1986), con elementos de Open Space Technology (en adelante OST) (Owen, 2008) para la coordinación de equipos dinámicos en proyectos colaborativos con una fuerte componente de innovación y creatividad. En RUCK, un equipo es dinámico cuando sus componentes tienen una disponibilidad limitada en el tiempo y con una distribución arbitraria que puede cambiar a lo largo del proyecto. De esta manera, no se puede asegurar una disponibilidad constante o controlada de los recursos asignados al proyecto que permitan una planificación en el largo plazo sino que dicha planificación debe considerarse como dinámica y adaptarse de la mejor manera posible a los cambios que se produzcan. La aplicación de metodologías ágiles como SCRUM (Murphy, 2004) en proyectos con requisitos cambiantes o poco definidos, así como su capacidad de adaptación a los cambios en el corto plazo, permitirá la organización del trabajo a realizar. La aplicación de la metodología se dirige a proyectos colaborativos, en los que los participantes tienen un grado de compromiso alto con el objetivo del proyecto. En estas condiciones, los participantes tratan de auto-organizarse de la manera más eficiente posible de forma que se aproveche de la mejor manera el esfuerzo común. La aplicación de las técnicas de OST en la organización de conferencias dinámicas, permitirá gestionar el trabajo con un equipo de estas características. Al igual que SCRUM, RUCK toma su nombre del juego del Rugby (Villegas, 2007). Ambos términos hacen referencia a diferentes jugadas que se producen en momentos distintos del juego. SCRUM toma el nombre de la melé, una jugada estática en la que un número fijo de jugadores con una estructura determinada, disputan el balón coordinados por el árbitro. En el caso del RUCK, también conocida como melé abierta, se trata una jugada dinámica provocada por una situación del juego, en la que los jugadores participan sin una estructura definida entrando y saliendo de la jugada según sea necesario para el progreso del juego. La similitud entre las jugadas es intencional, dado que RUCK pretende ser una versión más dinámica de SCRUM, sin una estructura definida. 2. Objetivos Los objetivos de este estudio son definir y perfilar la metodología RUCK, a partir de los métodos de SCRUM y de la OST, aplicarla a un grupo de trabajo pequeño y evaluar la efectividad del método mediante la prueba de concepto. 154

3 3. Metodología La metodología RUCK se fundamenta en dos partes; la coordinación de los equipos y el control del trabajo. La coordinación de los equipos se realiza utilizando Open Space Technology ( Ésta es una herramienta dirigida a la estructuración de eventos (reuniones, conferencias, etc.) con un tema claro y delimitado, pero sin ningún tipo de agenda formal definida. Para poder coordinar estos eventos, OST propone los 4 principios que se enuncian como sigue: Quienquiera que participa es la persona adecuada. Cualquier cosa que pase será lo único que se puede obtener Cuando quiera que empiece, será el momento correcto Cuando se acaba, se acaba En RUCK, estos principios se sugieren más como guías a seguir que como reglas de obligado cumplimiento y su aplicación de manera adecuada permite atenuar los riesgos inherentes de la disponibilidad dinámica de recursos en los proyectos a los que RUCK va enfocado. De la aplicación de los 2 primeros principios se extrae un factor que condiciona el éxito del proyecto: el compromiso por parte de los participantes. Se asegura, por una parte, que todos los participantes son las personas correctas por el hecho de comprometerse con el resultado del proyecto. Por otro lado, dicho compromiso garantiza que el esfuerzo de cada participante sea el mayor posible siendo éste lo único que se puede tener. Los dos últimos principios permiten adaptar el ritmo de trabajo a las condiciones cambiantes de disponibilidad de cada participante. Las tareas del proyecto, empiezan y acaban cuando es posible para los participantes llevarlas a cabo, con lo que la planificación, desde el punto de vista tradicional, no existe. En estas condiciones, el segundo factor que condiciona el éxito del proyecto es la capacidad de auto-organización del equipo. Además de los 4 principios, OST propone una ley de la movilidad que se enuncia de la siguiente manera: Si, en un momento dado, te encuentras en una situación en la que no puedes contribuir [ ] vete a otro lugar donde puedas hacerlo. Esta ley de la movilidad es de especial aplicación en RUCK dada la variable disponibilidad de los recursos. Cada participante debe asumir esta ley y apartarse del proyecto en los momentos que la falta de disponibilidad no le permitan aportar nada al esfuerzo global. Una vez el participante vuelve a estar disponible, podrá reincorporarse al proyecto y continuar trabajando sin problemas. De esta forma, todos los participantes son conscientes del número de recursos disponibles en cada momento del proyecto. Debido a la naturaleza dinámica de los equipos y al carácter colaborativo e innovador de los proyectos en los que se aplica, RUCK prescinde de la clasificación de los participantes en distintos roles. Todos los participantes son parte del equipo y, como tales, tendrán las mismas responsabilidades. La organización del trabajo se realiza utilizando técnicas procedentes de la metodología SCRUM, modificadas para adaptarlas a las nuevas condiciones de trabajo. Al igual que en SCRUM, se mantiene un registro detallado de todas las tareas a realizar en la 155

4 forma de un Product Backlog. Este registro contiene una descripción detallada de todo lo que se realiza en el proyecto así como su distribución en tareas concretas. Al tratarse principalmente de proyectos de innovación, en los que el ritmo de trabajo viene determinado por la creatividad, que es variable con el tiempo, el Product Backlog en RUCK es dinámico. A medida que se va detallando el proyecto, se modifica el registro incluyendo las nuevas tareas identificadas. El total del Product Backlog se divide en paquetes de trabajo concretos y bien definidos que reciben el nombre de "historias". Estas historias se dividen a su vez en tareas autoconclusivas de corta duración. A la hora de generar el Product Backlog, se utilizan las técnicas de OST. Cuando un participante detecta una nueva historia, la describe de forma breve pero concreta y la añade al registro. A partir de ese momento, el resto de participantes puede añadir nuevas tareas que lleven a la conclusión de la historia propuesta. Además de las historias detectadas durante el desarrollo del proyecto, la metodología pide que se incluya una historia específica para el seguimiento del trabajo realizado y que incluirá todas las tareas de control necesarias para el proyecto. Estas tareas serán, por lo general, cíclicas y recogerán las tareas que en SCRUM realiza habitualmente el rol del SCRUM Master. Al tratarse de equipos auto-organizados y sin roles, la realización de estas tareas de seguimiento recaerá en los distintos participantes según su disponibilidad. Una vez definido el Product Backlog, el proyecto se divide en fases cortas en las que se irán realizando las tareas identificadas. Estas fases coinciden con los Sprints definidos en SCRUM aunque de una duración mucho más corta (1 semana en contraposición a las 2-4 de cada Sprint en SCRUM) debido a la naturaleza dinámica de los proyectos y la alta variabilidad en la disponibilidad de los recursos. Al principio de cada fase se realiza una reunión presencial en la que: 156 Se revisa el trabajo realizado en la fase anterior Se determina la disponibilidad de los participantes para la siguiente fase En base a la disponibilidad, se distribuye el trabajo para la siguiente fase La distribución del trabajo en cada fase se realiza utilizando las técnicas de OST. Al principio de cada fase, los participantes que tienen disponibilidad para ello anuncian las tareas del Product Backlog que pueden llevar a cabo durante dicha fase. Al utilizar la ley de la movilidad en la coordinación de los equipos sólo los participantes que van a estar disponibles durante la fase (y tan sólo éstos) deberán anunciar las tareas que van a poder finalizar (y únicamente las que van a poder finalizar). Esto también debe aplicarse cuando la disponibilidad de un participante se modifica en mitad de una fase. En este caso, deberá anunciarse lo antes posible la situación con el fin de dejar claro qué tareas no pueden ser completadas en el transcurso de la fase. Para realizar el seguimiento, se utiliza un Taskboard similar al propuesto por SCRUM. En este Taskboard se recogen las tareas que se van a realizar durante la fase en curso organizándolas por historias. Cada tarea podrá estar en uno de 3 estados posibles; no iniciada, en progreso o finalizada. Los responsables de cada tarea actualizarán el estado de las mismas en el Taskboard según vaya progresando cada una. Durante las fases, cada participante activo deberá realizar un reporte diario del progreso en el que

5 indicará: Los progresos realizados Los problemas que se han encontrado Este reporte diario sustituye al Daily Meeting de SCRUM y no es presencial. Cada participante tiene el compromiso de dedicar a este reporte al menos 10 minutos. Al igual que las tareas de seguimiento, el facilitar la resolución de problemas, que en SCRUM es responsabilidad del SCRUM Master, pasa a los demás participantes que deberán colaborar para solucionar los problemas lo antes posible. Una vez finalizadas las tareas e historias, se irán registrando en el Product Backlog y se continuará con la siguiente fase hasta la finalización del proyecto. 4. Prueba de concepto de RUCK Con el fin de validar la metodología RUCK, se estableció una prueba de concepto de la misma. Esta prueba de concepto consistió en la ejecución de un pequeño proyecto de colaboración con un equipo de tres participantes. El proyecto utilizaría la metodología RUCK para la coordinación de los equipos de trabajo y la gestión general del proyecto. El objeto de este proyecto de prueba sería dotar de contenido al blog de la asociación GEDiP (Grupo de Expertos en Dirección Integrada de Proyectos). Los objetivos que se pretenden alcanzar son, de manera concreta, crear contenido publicable suficiente para poder actualizar el blog a un ritmo de 2 artículos por semana hasta fin de año. Dado que el tiempo del proyecto excede el de una mera prueba de concepto, se consideró que el período de análisis para la prueba fuera de dos meses. Para conseguir estos objetivos se fijó el alcance del proyecto, en este caso, que los artículos para el blog deberían tener una dimensión que permita su lectura en uno o dos minutos como máximo. La temática de los mismos sería variada aunque, en todo caso, relacionada con la Gestión de Proyectos. A la hora de establecer las historias y las tareas, se considera que los participantes deben proponer diferentes temáticas para los artículos que conformarán las historias y diferentes artículos en cada temática que conformarán las tareas. Las tareas de seguimiento se limitaron a una tarea cíclica en la que uno de los participantes actualizaba el Taskboard para la siguiente fase. Para el mantenimiento del Product Backlog, así como para el seguimiento del proyecto se utilizó la herramienta Google Wave ( Mediante los applets correspondientes (módulos que se añaden a la herramienta para aumentar su funcionalidad) los participantes han podido generar un Taskboard semanal y hacer el seguimiento de todas las tareas, su grado de ejecución etc. Esta herramienta de uso on-line permite a los usuarios acceder desde cualquier lugar y en cualquier momento a la información del proyecto, no siendo necesario la coincidencia ni en el espacio ni en el tiempo de los intervinientes en el mismo. Los participantes mantuvieron en ese tiempo una reunión presencial por fase en las que se organizaba el trabajo. El resto de comunicaciones se realizaron bien a través del correo electrónico, bien a través de la plataforma de colaboración montada sobre Google Wave. Los resultados finales, los artículos generados, se fueron colgando en la web de GEDiP ( que están a disposición del público general. 157

6 5. Resultados La prueba de concepto dio como resultados después de dos meses de iteraciones,, dos artículos para el blog ( publicados en la web, y otros tres en fase de borrador, aun en la herramienta colaborativa. Durante el desarrollo de la prueba se pudieron mantener reuniones presenciales en todas las fases menos en una, en la que ninguno de los participantes pudo aportar nada. Tan sólo en dos de las reuniones participaron todos los miembros del equipo. Los Taskboards de seguimiento (uno por fase) registraron las actividades de los participantes desde el comienzo. De los 3 participantes, dos pudieron cumplir con los requisitos de seguimiento sin demasiados problemas. No así el otro participantes cuya explicación de este hecho es que accedía con poca regularidad a la aplicación y que cuando lo hacia percibía cierta complejidad por lo que optaba por no actualizar el status de sus tareas. Esto provocó que no se pudiera hacer un seguimiento ordenado de sus tareas y que los contenidos aparecieran sin tener una constancia documental de ellos. Por otro lado, las tareas realizadas y documentadas por los usuarios que si hicieron el correspondiente seguimiento, permitieron generar contenidos completos, revisados y cuyo ritmo de crecimiento siguieron adecuadamente el principio de disponibilidad; cuando uno de los participantes estaba disponible y con recursos, avanzaba en su tarea. La disponibilidad variable durante el desarrollo de la prueba tuvo el efecto predicho; los participantes contribuyeron al proyecto cuando podían hacerlo y se quitaron de en medio cuando no. De esta manera, entrando y saliendo del RUCK, este iba cumpliendo sus objetivos. 6. Conclusiones De este estudio preliminar, se pueden sacar las siguientes conclusiones: Como ya era premisa en SCRUM, para que esta metodología funcione es necesaria la implicación y el compromiso de los participantes. Para que ese compromiso pueda tener reflejo en el desarrollo de las tareas, todos los usuarios tienen que estar familiarizados con la metodología y las herramientas. Si no es así, la motivación decrece y con el ella el compromiso con el proyecto. Con estos datos preliminares, el número mínimo de participantes parece pequeño, ya que la pérdida de uno de ellos tiene un gran impacto en el global. Será necesario aumentarlo en posteriores análisis con el fin de determinar el umbral de participantes y ver si es cercano a un óptimo. Aunque la metodología RUCK aun no ha sido probada extensamente, los resultados de la prueba han sido satisfactorios en general y prometedores en actividades futuras. A día de hoy, el proyecto de la prueba de concepto sigue abierto y sus resultados finales serán difundidos mas adelante. 158

7 Referencias Geraldi, J. G. et al, Innovation in Project management: Voices of researchers International Journal of Project Management, Vol.26, 2008, pp Murphy, C. Adaptive Project Management Using Scrum, Methods & Tools, Vol.12, nº4, 2004, pp Owen, H., Open Space Technology: A User's Guide (3rd edition ed.). Berrett-Koehler. ISBN Takeuchi, H. & Nonaka, I, The New New Product Development Game Harvard Business Review, Jan-Feb Villegas, F.(Trad), Reglamento del Juego del Rugby, Federación Vasca de Rugby, Correspondencia Asier Etxebarria GEDiP. Grupo de Expertos en Dirección integrada de Proyectos. (España) Edificio INDITI. Parcela 203. Parque Tecnológico de Boecillo E Boecillo Valladolid (ESPAÑA) Telefono Fax asier.etxebarria@gedip.org WEB: 159

8 160