RUCK, aplicación de metodologías ágiles en equipos dinámicos

RUCK, aplicación de metodologías ágiles en equipos dinámicos

RUCK, APLICACIÓN DE METODOLOGÍAS ÁGILES EN EQUIPOS
DINÁMICOS.
Etxebarria, A.
Jiménez, J.
Sansano, A.
Unidad Asociada UVA-CSIC a través del Centro de Astrobiología (España)
Resumen
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
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. 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
(http://www.openspaceworld.org). É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
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:

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
156
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 (http://wave.google.com). 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
(http://www.gedip.org) que están a disposición del público general.
157
5. Resultados
La prueba de concepto dio como resultados después de dos meses de iteraciones,, dos artículos
para el blog (http://www.gedip.org/Bitacora), 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
Referencias
Geraldi, J. G. et al, “Innovation in Project management: Voices of researchers” International
Journal of Project Management, Vol.26, 2008, pp.586–589.
Murphy, C. “Adaptive Project Management Using Scrum”, Methods & Tools, Vol.12, nº4, 2004,
pp 10-22.
Owen, H., “Open Space Technology: A User's Guide (3rd edition ed.)”. Berrett-Koehler. ISBN
978-1576754764. 2008
Takeuchi, H. & Nonaka, I, “The New New Product Development Game” Harvard Business
Review, Jan-Feb 1986.
Villegas, F.(Trad), “Reglamento del Juego del Rugby”, Federación Vasca de Rugby, 2007.
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-47151 Boecillo – Valladolid (ESPAÑA)
Telefono +34 983 140 502
Fax
+34 983 140 514
e-mail: [email protected]
WEB: www.gedip.org
159
160