Scrum: gestión de proyectos con un enfoque flexible

Hoy en día, cuando se pone en marcha un proyecto, los equipos no se lanzan sin pensar a hacer el trabajo, puesto que las tareas de gran magnitud requieren una labor de gestión de proyectos o productos. En muchas empresas se aplica habitualmente la metodología ágil, la cual prioriza un modo de trabajo flexible, desarrollos incrementales y procedimientos transparentes. En el ámbito de la gestión ágil de proyectos, cada vez es más común el término “Scrum”. Aunque originariamente fue pensado para el desarrollo de software, este modelo ha ganado popularidad en muchos otros escenarios. A continuación te explicamos qué se esconde exactamente tras esta palabra de moda.

La historia de Scrum se remonta a la década de 1980, aunque fue adoptando su forma actual a partir de 1995, año en que Ken Schwaber y Jeff Sutherland, que habían utilizado dos modelos parecidos por separado en sus empresas, publicaron un artículo conjunto con el objetivo de hacer el trabajo más productivo y, simultáneamente, introducir el menor número posible de reglas. Con ello pretendían que la productividad no se viera reducida.

Para hacerlo posible, la metodología Scrum establece un marco (framework) que puede aplicarse en diferentes situaciones con el propósito de mejorar continuamente tanto el método de trabajo como el producto. El marco está formado por roles, eventos, artefactos y reglas. Dentro de estos límites, los equipos Scrum deben lograr los resultados más eficientes posibles ofreciendo al cliente el mejor producto posible. En Scrum, los clientes (o contratantes) y los usuarios adoptan una posición importante y el desarrollo se basa en sus necesidades.

Con respecto al trabajo con Scrum, hay dos términos cuyo papel resulta clave:

• Iterativo: en Scrum los productos evolucionan continuamente. El trabajo describe un ciclo que va desde la planificación hasta la evaluación, pasando por el desarrollo y las pruebas, y vuelve desde ahí a la fase de planificación. Por consiguiente, Scrum no solo se ocupa de la creación inicial, sino también del desarrollo posterior.
   
• Incremental: Scrum se basa en la idea de que un producto se crea por pasos y estos pasos son concebidos como objetivos intermedios. Así se evita un método de trabajo dirigido a un único gran objetivo final. Para obtener una mayor flexibilidad, los proyectos más grandes se dividen en diversos proyectos pequeños.

Si se combinan ambos términos, el resultado es un procedimiento iterativo-incremental, lo que quiere decir que el proyecto se desarrolla de forma gradual y continua. Por un lado, se obtiene un proceso más transparente debido a que se prevén controles del trabajo frecuentes (como resultado de un enfoque más restringido) y, por el otro, se mejora la calidad de los productos, dado que su funcionalidad se comprueba continuamente.

Scrum procede originariamente del desarrollo ágil de software, donde se recurre al modelo para mejorar el trabajo de forma continua, aunque también es un modelo efectivo para otros productos, como la creación de hardware. Al final de un proyecto Scrum no tiene que haber necesariamente un producto en el sentido estricto de la palabra, pues cualquier proyecto orientado a resultados puede beneficiarse de Scrum. Así, el modelo también se utiliza para organizar equipos de marketing u órganos de gestión o para desarrollar servicios.

Sin embargo, el punto de partida de la metodología Scrum son siempre los equipos pequeños –aunque el término “pequeño” es un término relativo. Para los grupos de trabajo de gran envergadura, este modelo no resulta muy apropiado. No obstante, a menudo es posible dividir un grupo grande en varios grupos pequeños. Scrum es ideal sobre todo para conectar los equipos entre sí, y es que el trabajo en equipo es muy importante en este modelo: dentro de un equipo Scrum, cada uno de los miembros debe complementarse con sus diferentes habilidades.

Scrum no se concibe como un método sólido o como una técnica de trabajo concreta, sino más bien como un marco que ofrece a los equipos puntos de referencia fijos para desarrollar su trabajo. En este marco existen determinados roles, eventos y artefactos.

Dentro de un equipo Scrum hay tres roles definidos: el team (equipo), el product owner (dueño de producto) y el Scrum master (líder de Scrum). El team hace referencia a los desarrolladores del producto y el grupo está definido de tal manera que puede organizarse por sí mismo y establecer cómo se puede alcanzar un objetivo acordado. En Scrum ya no existen jerarquías en los equipos, por lo que cada trabajador tiene su propio ámbito de actividad. No obstante, en la revisión final todos deben dar cuenta del producto.

El tamaño del team no se ha determinado concretamente, pero debe erigirse de tal manera que pueda actuar con rapidez y flexibilidad sin dejar de ser eficiente, por lo que no es conveniente que sea ni muy grande ni muy pequeño. Schwaber y Sutherland recomiendan que tenga entre 3 y 9 miembros.

En Scrum, el product owner es el responsable de la calidad del producto y del trabajo, por lo que dicha persona adopta la función de control. Los product owners organizan el product backlog (lista del producto), una lista que determina cuáles son los requisitos del proyecto (puedes encontrar más información sobre el product backlog en el apartado de artefactos de Scrum). Sus tareas incluyen dotar a los objetivos de un orden lógico y documentarlos de manera comprensible. Con ello, el product owner tiene un rol autoritario: los equipos determinan la manera de conseguir los objetivos en el backlog, pero la delimitación de dichos objetivos queda a discreción del product owner, algo que no puede ponerse en duda. Para garantizar la mayor productividad posible, el equipo debe confiar en las decisiones del product owner. No obstante, no puede hablarse de un líder: el product owner y el team tienen diferentes campos de actividad y son decisivos para estos. Así como el team no cuestiona el backlog, el product owner tampoco se entromete en el proceso de desarrollo.

En comparación con los otros dos roles, el Scrum master ejerce como art mediator y es responsable de integrar e introducir Scrum en el proceso de trabajo, así como de organizar los eventos Scrum: así, organiza las reuniones y ejerce de moderador. Asimismo, sirve de ayuda tanto para el Scrum master, el team y el product owner, para lo que no interviene en el propio proceso de desarrollo, sino que su función principal es facilitar los procesos de trabajo a los empleados implicados en la producción y aumentar con ello la productividad y la creatividad.

Como persona de contacto, el Scrum master se ocupa de que todos los participantes comprendan los procesos correctamente, ofreciendo consejos para crear backlogs, organizando el equipo y, en general, eliminando los obstáculos que puedan ir surgiendo. El Scrum master también cumple con la función de coach, rol para el que resulta decisivo conocer el método Scrum con precisión. Por ello, también puede obtenerse la certificación de Scrum master, para lo que hay varias autoridades de certificación que ofrecen la formación correspondiente. Tanto Scrum Alliance como Scrum.org fueron fundadas por Ken Schwaber y ofrecen los certificados Certified Scrum Master o Professional Scrum Master.

Si los procesos de trabajo se organizan según el principio de Scrum, hay ciertos acontecimientos que ocurren con frecuencia. Dado que Scrum es un proceso iterativo, el trabajo se realiza en ciclos que se repiten: cada evento se reinicia con cada repetición y la frecuencia de los eventos Scrum hace que las reuniones no programadas rara vez (o incluso nunca) tengan lugar, de ahí que todos los eventos tengan un plazo establecido.

El ciclo recibe el nombre de sprint, concepto que describe el espacio de tiempo de una fase de desarrollo. Al final de un sprint, el equipo de desarrollo entrega un incremento de producto ya terminado, lo que significa que el desarrollo debe haber conducido a un producto que tenga potencial. Por lo tanto, cada sprint tiene una misión concreta que al final se marca como “hecho”.

El plazo de tiempo para un sprint debe establecerse de antemano y no debe superar los 30 días. Para determinarlo deben tenerse en cuenta los siguientes factores: un sprint no puede ni acortarse ni alargarse y los siguientes sprints del proyecto deben tener la misma duración.

Los sprints son cortos para que, a la hora de formular los objetivos, se mantenga la simplicidad. Esta corta duración determina la realización de un análisis del desarrollo al menos una vez al mes. En casos excepcionales, el product owner es el único que puede interrumpir el sprint. La cancelación es posible, por ejemplo, cuando ya no tiene que alcanzarse el objetivo porque la empresa tiene otros propósitos. Fundamentalmente, los sprints no deben interrumpirse, pues esto disminuye la productividad

Un sprint comienza con el sprint planning (planificación de los sprints), donde participan todos los roles del equipo Scrum. Durante una reunión de hasta un máximo de ocho horas, las partes implicadas hablan del próximo incremento de producto: ¿qué debe incluir el incremento y cómo quiere lograrse? El punto de partida para la planificación es el product backlog (lista de producto). El equipo de desarrollo y el product owner acuerdan conjuntamente cuáles son los objetivos que deben lograrse el próximo mes y, a continuación, el equipo de desarrollo habla sobre cómo deben llevarse a cabo las tareas. Al final de la reunión, los desarrolladores deben dialogar sobre su plan con el product owner y el Scrum master.

En el sprint tiene lugar un daily Scrum (Scrum diario) todos los días, siempre a la misma hora y en el mismo lugar, lo que ahorra esfuerzos organizativos. En cada reunión, de 15 minutos, el equipo de desarrollo conversa sobre las tareas pendientes del día y lo que se ha logrado el día anterior. Asimismo, los desarrolladores evalúan el progreso general del proyecto: ¿cuál ha sido el progreso con respecto al procesamiento de las entradas del backlog? La comparación diaria garantiza que las personas implicadas no pierdan de vista los objetivos, lo que también aumenta la productividad.

Aunque el Scrum master se encarga de que tenga lugar el daily Scrum, pero son los desarrolladores los encargados de determinar el curso de la reunión y quienes establecen los temas que se van a tratar. Mientras que en términos de contenido se trate de conseguir el objetivo del sprint y no se superen los 15 minutos, el Scrum master no se inmiscuye, sino que se centrará en que otras personas presentes en el daily Scrum no entorpezcan el trabajo de los desarrolladores.

Cuando termina un sprint, el paso siguiente es el sprint review (revisión del sprint), en el que se examina el incremento de producto. Los resultados se analizan junto a aquellos que no forman parte del equipo Scrum pero que tienen un gran interés por el producto, como, por ejemplo, la gerencia de la empresa o los clientes (denominados stakeholders en el ámbito Scrum). En este contexto, también se habla del proceso de trabajo, se tratan los problemas en el desarrollo y se intercambian ideas sobre los diferentes retos, lo que también influye en la planificación posterior, puesto que el product owner se vale de la oportunidad de responder al avance del backlog. Los conocimientos del sprint influyen en la previsión del rendimiento futuro.

La situación del mercado en el momento también influye en el backlog: en el caso de los proyectos de larga duración sobre todo, las prioridades pueden cambiar y los presupuestos modificarse. Estos temas también se tratan en la revisión del sprint, ya que modifican el planteamiento futuro. En un sprint de un mes no deben emplearse más de cuatro horas para la revisión, la cual va seguida de otra revisión: la retrospección del sprint.

En una reunión de un máximo de tres horas, el equipo Scrum al completo (incluidos el product owner y el Scrum master, pero no los stakeholders) lleva a cabo una sesión de feedback. Mientras que en la revisión el elemento central es el producto y el avance del proyecto, en la retrospección prevalece el trabajo en equipo. El objetivo de esta segunda revisión es mejorar el trabajo entre las partes y sortear los problemas internos. Cuando acaba un sprint, el siguiente empieza con el sprint planning.

Los objetos que desempeñan un papel importante en la metodología Scrum reciben el nombre de artefactos y en ellos se engloban, por un lado, el product backlog (lista de producto) de una página y el sprint backlog (lista de pendientes del sprint) y, por otro, el incremento terminado.

En Scrum la transparencia juega un papel importante. Todos los implicados en el proceso deben ser capaces de recibir toda la información fácilmente y en cualquier momento. Por ello, en la concepción de los artefactos se presta atención a que estos estén formulados de forma sencilla y comprensible. En el product backlog el responsable es el product owner: un backlog es una lista clasificada de todos los elementos decisivos para el producto que recoge tanto las funciones del producto como las correcciones y las mejoras.

El trabajo en el product backlog es continuo: la lista se administra de forma dinámica (los nuevos conocimientos se integran en cualquier momento y contribuyen a que las entradas se diferencien más, se añadan nuevas tareas y se adapte la clasificación). Al principio, el product owner tiene a su lado al Scrum master cuando crea el producto. Debido a su experiencia, los masters saben cómo formular el documento para satisfacer las exigencias de transparencia y efectividad. Las entradas deben orientarse generalmente a las exigencias del cliente. Así, además de una descripción de las características exigidas, el documento también cuenta con una nota sobre la carga de trabajo y con una entrada para el nivel de prioridad.

Además del product backlog también existe el sprint backlog (lista de pendientes del sprint), que se genera a partir del anterior. Este último recoge todas las entradas del product backlog seleccionadas en el sprint planning para el próximo sprint. Para ello, el backlog presenta todos los pasos hasta el objetivo del sprint correspondiente. Durante el dailiy Scrum (Scrum diario) se valora el progreso mediante el sprint backlog, lista que puede actualizarse para satisfacer las exigencias y los desafíos del equipo. Por ello, el desarrollador también es responsable de realizar cambios en el sprint backlog, pero ni el product owner ni el master están autorizados a modificar la lista.

Al final de un sprint, el equipo de desarrollo presenta el incremento, es decir, el resultado de la fase de desarrollo. En el incremento deben estar incluidas todas las entradas del sprint backlog y todos los incrementos de sprints anteriores. Además, todo incremento debe poderse entregar directamente y debe estar listo para usarse, aun cuando no se haya planeado la entrega del incremento de producto. En la sprint review, el equipo presenta el incremento y así el product owner y el stakeholder pueden valorar el resultado.

La metodología Scrum ofrece algunas ventajas, tanto comparado con otros procesos ágiles como con métodos de gestión de proyectos más tradicionales. Esto se debe principalmente al planteamiento simplificado y a las pocas normas que limitan al equipo Scrum:

• Comunicación: una buena gestión de proyectos solo puede funcionar si todos los miembros del equipo están al mismo nivel. Scrum hace mucho hincapié en que los trabajadores tengan una estrecha comunicación entre sí. Por ello, los eventos Scrum suelen estar relativamente bien cronometrados. La reunión diaria, a primera hora de la mañana, hace que ningún desarrollador trabaje más que los otros y en la última fase de revisión también se tratan los problemas internos del equipo.
   
• Flexibilidad: en Scrum se elaboran sprints relativamente cortos. Dado que entre dos reuniones de planificación transcurre máximo un mes, el proyecto puede modificarse a corto plazo y adaptarse a las nuevas exigencias.
   
• Transparencia: la comunicación continua de todos los miembros del equipo, así como la creación de artefactos Scrum, favorecen una transparencia elevada. Los backlogs se formulan de manera que todos los implicados puedan orientarse fácilmente y encontrar la información necesaria sobre el proyecto.
   
• Control de calidad: a través del principio iterativo de Scrum se ofrece un control continuo del producto. La corrección de errores y los desarrollos pertenecen, también, al product backlog. Además, en el sprint review el equipo de desarrollo presenta un incremento terminado. Asimismo, el product owner y el stakeholder tienen la oportunidad de convencerse de la calidad, con lo que puede reaccionarse con mayor celeridad a los errores en el desarrollo que detectando una función defectuosa al final de un proyecto.
   
• Creatividad: Scrum se basa en la organización propia del equipo. En lugar de determinar desde arriba el proceso de trabajo, los desarrolladores trabajan con sus propias ideas. Debido a que el marco de Scrum es, en comparación, abierto y no tiene muchas normas, cada uno de los componentes del equipo puede aportar sus propias ideas.
   
• Efectividad: en comparación con la gestión de proyectos clásica, en el método Scrum existe una obligación de documentación mucho menor, ya que el foco de la atención está en el producto en funcionamiento y no en la documentación en sí, que requiere tiempo y recursos. En lugar de ello, el equipo puede concentrarse plenamente durante el sprint en el trabajo de desarrollo y en ejecutarlo como estime conveniente.

A pesar de sus convincentes ventajas, Scrum no resulta adecuado para todas las empresas debido, entre otras, a estos inconvenientes:

• Falta de perspectiva general: lo que puede ser una gran ventaja para un equipo, puede convertirse en una desventaja para otro: una planificación a muy corto plazo puede dar lugar a que se pierda de vista la perspectiva general en los proyectos de mayor envergadura.
   
• Comunicación laboriosa: los eventos Scrum están muy cronometrados, pero para algunos equipos y proyectos es innecesario un nivel de comunicación tan alto. Los daily Scrums habituales impiden en tales casos la productividad, pues se dedica mucho tiempo a la organización y la comunicación en lugar de trabajar en el producto.
   
• Dudas respecto a la planificación y la competencia: Scrum prevé la propia organización del equipo. Esto puede ser ventajoso, pero en algunos campos y sectores esta jerarquía plana puede causar incertidumbre en la planificación y confusión con respecto a la competencia.
   
• No integrable: en algunas estructuras empresariales solo es posible integrar Scrum realizando grandes cambios, casos en los que se plantea la pregunta de si no se pierde más efectividad de la que se gana con Scrum.

Determinar si Scrum resulta apto para las empresas es algo que se debe juzgar y sopesar por sí mismo, al igual que si las jerarquías planas y la comunicación frecuente en los equipos Scrum del propio negocio conllevan el aumento de la productividad y una mayor calidad del trabajo y los productos.