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 ha­bi­tua­l­me­n­te la me­to­do­lo­gía ágil, la cual prioriza un modo de trabajo flexible, de­sa­rro­llos in­cre­me­n­ta­les y pro­ce­di­mie­n­tos tra­n­s­pa­re­n­tes. En el ámbito de la gestión ágil de proyectos, cada vez es más común el término “Scrum”. Aunque ori­gi­na­ria­me­n­te fue pensado para el de­sa­rro­llo de software, este modelo ha ganado po­pu­la­ri­dad en muchos otros es­ce­na­rios. A co­n­ti­nua­ción te ex­pli­ca­mos qué se esconde exac­ta­me­n­te 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 Su­the­r­la­nd, que habían utilizado dos modelos parecidos por separado en sus empresas, pu­bli­ca­ron un artículo conjunto con el objetivo de hacer el trabajo más pro­du­c­ti­vo y, si­mu­l­tá­nea­me­n­te, in­tro­du­cir el menor número posible de reglas. Con ello pre­te­n­dían que la pro­du­c­ti­vi­dad no se viera reducida.

Para hacerlo posible, la me­to­do­lo­gía Scrum establece un marco (framework) que puede aplicarse en di­fe­re­n­tes si­tua­cio­nes con el propósito de mejorar co­n­ti­nua­me­n­te tanto el método de trabajo como el producto. El marco está formado por roles, eventos, ar­te­fa­c­tos y reglas. Dentro de estos límites, los equipos Scrum deben lograr los re­su­l­ta­dos más efi­cie­n­tes posibles ofre­cie­n­do al cliente el mejor producto posible. En Scrum, los clientes (o co­n­tra­ta­n­tes) y los usuarios adoptan una posición im­po­r­ta­n­te y el de­sa­rro­llo se basa en sus ne­ce­si­da­des.

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

• Iterativo: en Scrum los productos evo­lu­cio­nan co­n­ti­nua­me­n­te. El trabajo describe un ciclo que va desde la pla­ni­fi­ca­ción hasta la eva­lua­ción, pasando por el de­sa­rro­llo y las pruebas, y vuelve desde ahí a la fase de pla­ni­fi­ca­ción. Por co­n­si­guie­n­te, Scrum no solo se ocupa de la creación inicial, sino también del de­sa­rro­llo posterior.
   
• In­cre­me­n­tal: Scrum se basa en la idea de que un producto se crea por pasos y estos pasos son co­n­ce­bi­dos como objetivos in­te­r­me­dios. Así se evita un método de trabajo dirigido a un único gran objetivo final. Para obtener una mayor fle­xi­bi­li­dad, los proyectos más grandes se dividen en diversos proyectos pequeños.

Si se combinan ambos términos, el resultado es un pro­ce­di­mie­n­to iterativo-in­cre­me­n­tal, lo que quiere decir que el proyecto se de­sa­rro­lla de forma gradual y continua. Por un lado, se obtiene un proceso más tra­n­s­pa­re­n­te debido a que se prevén controles del trabajo fre­cue­n­tes (como resultado de un enfoque más re­s­tri­n­gi­do) y, por el otro, se mejora la calidad de los productos, dado que su fu­n­cio­na­li­dad se comprueba co­n­ti­nua­me­n­te.

Scrum procede ori­gi­na­ria­me­n­te del de­sa­rro­llo á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 ne­ce­sa­ria­me­n­te un producto en el sentido estricto de la palabra, pues cualquier proyecto orientado a re­su­l­ta­dos puede be­ne­fi­ciar­se de Scrum. Así, el modelo también se utiliza para organizar equipos de marketing u órganos de gestión o para de­sa­rro­llar servicios.

Sin embargo, el punto de partida de la me­to­do­lo­gí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 en­ve­r­ga­du­ra, 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 im­po­r­ta­n­te en este modelo: dentro de un equipo Scrum, cada uno de los miembros debe co­m­ple­me­n­tar­se con sus di­fe­re­n­tes ha­bi­li­da­des.

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 re­fe­re­n­cia fijos para de­sa­rro­llar su trabajo. En este marco existen de­te­r­mi­na­dos roles, eventos y ar­te­fa­c­tos.

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 re­fe­re­n­cia a los de­sa­rro­lla­do­res del producto y el grupo está definido de tal manera que puede or­ga­ni­zar­se por sí mismo y es­ta­ble­cer cómo se puede alcanzar un objetivo acordado. En Scrum ya no existen je­ra­r­quías en los equipos, por lo que cada tra­ba­ja­dor 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 de­te­r­mi­na­do co­n­cre­ta­me­n­te, pero debe erigirse de tal manera que pueda actuar con rapidez y fle­xi­bi­li­dad sin dejar de ser eficiente, por lo que no es co­n­ve­nie­n­te que sea ni muy grande ni muy pequeño. Schwaber y Su­the­r­la­nd re­co­mie­n­dan que tenga entre 3 y 9 miembros.

En Scrum, el product owner es el re­s­po­n­sa­ble 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 re­qui­si­tos del proyecto (puedes encontrar más in­fo­r­ma­ción sobre el product backlog en el apartado de ar­te­fa­c­tos de Scrum). Sus tareas incluyen dotar a los objetivos de un orden lógico y do­cu­me­n­tar­los de manera co­m­pre­n­si­ble. Con ello, el product owner tiene un rol au­to­ri­ta­rio: los equipos de­te­r­mi­nan la manera de conseguir los objetivos en el backlog, pero la de­li­mi­ta­ción de dichos objetivos queda a di­s­cre­ción del product owner, algo que no puede ponerse en duda. Para ga­ra­n­ti­zar la mayor pro­du­c­ti­vi­dad posible, el equipo debe confiar en las de­ci­sio­nes del product owner. No obstante, no puede hablarse de un líder: el product owner y el team tienen di­fe­re­n­tes 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 de­sa­rro­llo.

En co­m­pa­ra­ción con los otros dos roles, el Scrum master ejerce como art mediator y es re­s­po­n­sa­ble de integrar e in­tro­du­cir 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 in­te­r­vie­ne en el propio proceso de de­sa­rro­llo, sino que su función principal es facilitar los procesos de trabajo a los empleados im­pli­ca­dos en la pro­du­c­ción y aumentar con ello la pro­du­c­ti­vi­dad y la crea­ti­vi­dad.

Como persona de contacto, el Scrum master se ocupa de que todos los pa­r­ti­ci­pa­n­tes co­m­pre­n­dan los procesos co­rre­c­ta­me­n­te, ofre­cie­n­do consejos para crear backlogs, or­ga­ni­za­n­do el equipo y, en general, eli­mi­na­n­do los ob­s­tácu­los 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 ce­r­ti­fi­ca­ción de Scrum master, para lo que hay varias au­to­ri­da­des de ce­r­ti­fi­ca­ción que ofrecen la formación co­rre­s­po­n­die­n­te. Tanto Scrum Alliance como Scrum.org fueron fundadas por Ken Schwaber y ofrecen los ce­r­ti­fi­ca­dos Certified Scrum Master o Pro­fe­s­sio­nal Scrum Master.

Si los procesos de trabajo se organizan según el principio de Scrum, hay ciertos aco­n­te­ci­mie­n­tos que ocurren con fre­cue­n­cia. Dado que Scrum es un proceso iterativo, el trabajo se realiza en ciclos que se repiten: cada evento se reinicia con cada re­pe­ti­ción y la fre­cue­n­cia de los eventos Scrum hace que las reuniones no pro­gra­ma­das rara vez (o incluso nunca) tengan lugar, de ahí que todos los eventos tengan un plazo es­ta­ble­ci­do.

El ciclo recibe el nombre de sprint, concepto que describe el espacio de tiempo de una fase de de­sa­rro­llo. Al final de un sprint, el equipo de de­sa­rro­llo entrega un in­cre­me­n­to de producto ya terminado, lo que significa que el de­sa­rro­llo 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 es­ta­ble­ce­r­se de antemano y no debe superar los 30 días. Para de­te­r­mi­nar­lo deben tenerse en cuenta los si­guie­n­tes factores: un sprint no puede ni acortarse ni alargarse y los si­guie­n­tes 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 si­m­pli­ci­dad. Esta corta duración determina la rea­li­za­ción de un análisis del de­sa­rro­llo al menos una vez al mes. En casos ex­ce­p­cio­na­les, el product owner es el único que puede in­te­rru­m­pir el sprint. La ca­n­ce­la­ción es posible, por ejemplo, cuando ya no tiene que al­ca­n­zar­se el objetivo porque la empresa tiene otros pro­pó­si­tos. Fu­n­da­me­n­ta­l­me­n­te, los sprints no deben in­te­rru­m­pi­r­se, pues esto disminuye la pro­du­c­ti­vi­dad

Un sprint comienza con el sprint planning (pla­ni­fi­ca­ción de los sprints), donde pa­r­ti­ci­pan todos los roles del equipo Scrum. Durante una reunión de hasta un máximo de ocho horas, las partes im­pli­ca­das hablan del próximo in­cre­me­n­to de producto: ¿qué debe incluir el in­cre­me­n­to y cómo quiere lograrse? El punto de partida para la pla­ni­fi­ca­ción es el product backlog (lista de producto). El equipo de de­sa­rro­llo y el product owner acuerdan co­n­ju­n­ta­me­n­te cuáles son los objetivos que deben lograrse el próximo mes y, a co­n­ti­nua­ción, el equipo de de­sa­rro­llo habla sobre cómo deben llevarse a cabo las tareas. Al final de la reunión, los de­sa­rro­lla­do­res 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 or­ga­ni­za­ti­vos. En cada reunión, de 15 minutos, el equipo de de­sa­rro­llo conversa sobre las tareas pe­n­die­n­tes del día y lo que se ha logrado el día anterior. Asimismo, los de­sa­rro­lla­do­res evalúan el progreso general del proyecto: ¿cuál ha sido el progreso con respecto al pro­ce­sa­mie­n­to de las entradas del backlog? La co­m­pa­ra­ción diaria garantiza que las personas im­pli­ca­das no pierdan de vista los objetivos, lo que también aumenta la pro­du­c­ti­vi­dad.

Aunque el Scrum master se encarga de que tenga lugar el daily Scrum, pero son los de­sa­rro­lla­do­res los en­ca­r­ga­dos de de­te­r­mi­nar el curso de la reunión y quienes es­ta­ble­cen 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 en­to­r­pe­z­can el trabajo de los de­sa­rro­lla­do­res.

Cuando termina un sprint, el paso siguiente es el sprint review (revisión del sprint), en el que se examina el in­cre­me­n­to de producto. Los re­su­l­ta­dos 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 (de­no­mi­na­dos sta­keho­l­de­rs en el ámbito Scrum). En este contexto, también se habla del proceso de trabajo, se tratan los problemas en el de­sa­rro­llo y se in­te­r­ca­m­bian ideas sobre los di­fe­re­n­tes retos, lo que también influye en la pla­ni­fi­ca­ción posterior, puesto que el product owner se vale de la opo­r­tu­ni­dad de responder al avance del backlog. Los co­no­ci­mie­n­tos del sprint influyen en la previsión del re­n­di­mie­n­to 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 prio­ri­da­des pueden cambiar y los pre­su­pue­s­tos mo­di­fi­car­se. Estos temas también se tratan en la revisión del sprint, ya que modifican el pla­n­tea­mie­n­to 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 re­tro­s­pe­c­ció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 sta­keho­l­de­rs) 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 re­tro­s­pe­c­ció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 de­sem­pe­ñan un papel im­po­r­ta­n­te en la me­to­do­lo­gía Scrum reciben el nombre de ar­te­fa­c­tos y en ellos se engloban, por un lado, el product backlog (lista de producto) de una página y el sprint backlog (lista de pe­n­die­n­tes del sprint) y, por otro, el in­cre­me­n­to terminado.

En Scrum la tra­n­s­pa­re­n­cia juega un papel im­po­r­ta­n­te. Todos los im­pli­ca­dos en el proceso deben ser capaces de recibir toda la in­fo­r­ma­ción fá­ci­l­me­n­te y en cualquier momento. Por ello, en la co­n­ce­p­ción de los ar­te­fa­c­tos se presta atención a que estos estén fo­r­mu­la­dos de forma sencilla y co­m­pre­n­si­ble. En el product backlog el re­s­po­n­sa­ble es el product owner: un backlog es una lista cla­si­fi­ca­da de todos los elementos decisivos para el producto que recoge tanto las funciones del producto como las co­rre­c­cio­nes y las mejoras.

El trabajo en el product backlog es continuo: la lista se ad­mi­ni­s­tra de forma dinámica (los nuevos co­no­ci­mie­n­tos se integran en cualquier momento y co­n­tri­bu­yen a que las entradas se di­fe­re­n­cien más, se añadan nuevas tareas y se adapte la cla­si­fi­ca­ción). Al principio, el product owner tiene a su lado al Scrum master cuando crea el producto. Debido a su ex­pe­rie­n­cia, los masters saben cómo formular el documento para sa­ti­s­fa­cer las exi­ge­n­cias de tra­n­s­pa­re­n­cia y efe­c­ti­vi­dad. Las entradas deben orie­n­tar­se ge­ne­ra­l­me­n­te a las exi­ge­n­cias del cliente. Así, además de una de­s­cri­p­ción de las ca­ra­c­te­rí­s­ti­cas 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 pe­n­die­n­tes del sprint), que se genera a partir del anterior. Este último recoge todas las entradas del product backlog se­le­c­cio­na­das en el sprint planning para el próximo sprint. Para ello, el backlog presenta todos los pasos hasta el objetivo del sprint co­rre­s­po­n­die­n­te. Durante el dailiy Scrum (Scrum diario) se valora el progreso mediante el sprint backlog, lista que puede ac­tua­li­zar­se para sa­ti­s­fa­cer las exi­ge­n­cias y los desafíos del equipo. Por ello, el de­sa­rro­lla­dor también es re­s­po­n­sa­ble de realizar cambios en el sprint backlog, pero ni el product owner ni el master están au­to­ri­za­dos a modificar la lista.

Al final de un sprint, el equipo de de­sa­rro­llo presenta el in­cre­me­n­to, es decir, el resultado de la fase de de­sa­rro­llo. En el in­cre­me­n­to deben estar incluidas todas las entradas del sprint backlog y todos los in­cre­me­n­tos de sprints an­te­rio­res. Además, todo in­cre­me­n­to debe poderse entregar di­re­c­ta­me­n­te y debe estar listo para usarse, aun cuando no se haya planeado la entrega del in­cre­me­n­to de producto. En la sprint review, el equipo presenta el in­cre­me­n­to y así el product owner y el sta­keho­l­der pueden valorar el resultado.

La me­to­do­lo­gía Scrum ofrece algunas ventajas, tanto comparado con otros procesos ágiles como con métodos de gestión de proyectos más tra­di­cio­na­les. Esto se debe pri­n­ci­pa­l­me­n­te al pla­n­tea­mie­n­to si­m­pli­fi­ca­do y a las pocas normas que limitan al equipo Scrum:

• Co­mu­ni­ca­ció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 tra­ba­ja­do­res tengan una estrecha co­mu­ni­ca­ción entre sí. Por ello, los eventos Scrum suelen estar re­la­ti­va­me­n­te bien cro­no­me­tra­dos. La reunión diaria, a primera hora de la mañana, hace que ningún de­sa­rro­lla­dor trabaje más que los otros y en la última fase de revisión también se tratan los problemas internos del equipo.
   
• Fle­xi­bi­li­dad: en Scrum se elaboran sprints re­la­ti­va­me­n­te cortos. Dado que entre dos reuniones de pla­ni­fi­ca­ción tra­n­s­cu­rre máximo un mes, el proyecto puede mo­di­fi­car­se a corto plazo y adaptarse a las nuevas exi­ge­n­cias.
   
• Tra­n­s­pa­re­n­cia: la co­mu­ni­ca­ción continua de todos los miembros del equipo, así como la creación de ar­te­fa­c­tos Scrum, favorecen una tra­n­s­pa­re­n­cia elevada. Los backlogs se formulan de manera que todos los im­pli­ca­dos puedan orie­n­tar­se fá­ci­l­me­n­te y encontrar la in­fo­r­ma­ción necesaria sobre el proyecto.
   
• Control de calidad: a través del principio iterativo de Scrum se ofrece un control continuo del producto. La co­rre­c­ción de errores y los de­sa­rro­llos pe­r­te­ne­cen, también, al product backlog. Además, en el sprint review el equipo de de­sa­rro­llo presenta un in­cre­me­n­to terminado. Asimismo, el product owner y el sta­keho­l­der tienen la opo­r­tu­ni­dad de co­n­ve­n­ce­r­se de la calidad, con lo que puede reac­cio­nar­se con mayor celeridad a los errores en el de­sa­rro­llo que de­te­c­ta­n­do una función de­fe­c­tuo­sa al final de un proyecto.
   
• Crea­ti­vi­dad: Scrum se basa en la or­ga­ni­za­ción propia del equipo. En lugar de de­te­r­mi­nar desde arriba el proceso de trabajo, los de­sa­rro­lla­do­res trabajan con sus propias ideas. Debido a que el marco de Scrum es, en co­m­pa­ra­ción, abierto y no tiene muchas normas, cada uno de los co­m­po­ne­n­tes del equipo puede aportar sus propias ideas.
   
• Efe­c­ti­vi­dad: en co­m­pa­ra­ción con la gestión de proyectos clásica, en el método Scrum existe una obli­ga­ción de do­cu­me­n­ta­ción mucho menor, ya que el foco de la atención está en el producto en fu­n­cio­na­mie­n­to y no en la do­cu­me­n­ta­ción en sí, que requiere tiempo y recursos. En lugar de ello, el equipo puede co­n­ce­n­trar­se ple­na­me­n­te durante el sprint en el trabajo de de­sa­rro­llo y en eje­cu­tar­lo como estime co­n­ve­nie­n­te.

A pesar de sus co­n­vi­n­ce­n­tes ventajas, Scrum no resulta adecuado para todas las empresas debido, entre otras, a estos in­co­n­ve­nie­n­tes:

• Falta de pe­r­s­pe­c­ti­va general: lo que puede ser una gran ventaja para un equipo, puede co­n­ve­r­ti­r­se en una de­s­ve­n­ta­ja para otro: una pla­ni­fi­ca­ción a muy corto plazo puede dar lugar a que se pierda de vista la pe­r­s­pe­c­ti­va general en los proyectos de mayor en­ve­r­ga­du­ra.
   
• Co­mu­ni­ca­ción laboriosa: los eventos Scrum están muy cro­no­me­tra­dos, pero para algunos equipos y proyectos es in­ne­ce­sa­rio un nivel de co­mu­ni­ca­ción tan alto. Los daily Scrums ha­bi­tua­les impiden en tales casos la pro­du­c­ti­vi­dad, pues se dedica mucho tiempo a la or­ga­ni­za­ción y la co­mu­ni­ca­ción en lugar de trabajar en el producto.
   
• Dudas respecto a la pla­ni­fi­ca­ción y la co­m­pe­te­n­cia: Scrum prevé la propia or­ga­ni­za­ción del equipo. Esto puede ser ventajoso, pero en algunos campos y sectores esta jerarquía plana puede causar in­ce­r­ti­du­m­bre en la pla­ni­fi­ca­ción y confusión con respecto a la co­m­pe­te­n­cia.
   
• No in­te­gra­ble: en algunas es­tru­c­tu­ras em­pre­sa­ria­les solo es posible integrar Scrum rea­li­za­n­do grandes cambios, casos en los que se plantea la pregunta de si no se pierde más efe­c­ti­vi­dad de la que se gana con Scrum.

De­te­r­mi­nar si Scrum resulta apto para las empresas es algo que se debe juzgar y sopesar por sí mismo, al igual que si las je­ra­r­quías planas y la co­mu­ni­ca­ción frecuente en los equipos Scrum del propio negocio conllevan el aumento de la pro­du­c­ti­vi­dad y una mayor calidad del trabajo y los productos.