Qué es Scrum

Qué es Scrum

Ha llegado el momento de dedicar un monográfico a Scrum. Y es que no se puede hablar de agilidad sin hacer referencia a este popular método.

Este artículo será el primero de una larga lista en los que comenzaremos a profundizar en Scrum, que como ya he comentado en otros posts es el marco de trabajo agile de referencia.

Trataré de diseccionarlo punto por punto, de forma que, tras varios artículos, puedas comenzar a aplicarlo en tu trabajo. Te ayudaré a extraer de este framework agile todos los beneficios que puede proporcionar a tus proyectos software.

Comenzamos.

Personalmente Scrum es mi método agile favorito, quizá porque es en el que tengo más experiencia. Desde luego es el método más utilizado (con mucho). Según el informe 13th Annual State of Agile Report de Mayo del 2019 que realiza CollabNet VersionOne, es el método ágil más usado de forma individual en un 54%:

13th Annual State of Agile Report

Te dejo aquí el enlace al informe completo:

https://www.stateofagile.com/#ufh-i-521251909-13th-annual-state-of-agile-report/473508

Antes de nada, veamos un poco de historia y el motivo de ese nombre tan peregrino…

Orígenes de Scrum

En 1986 dos expertos en gestión japoneses, Hirotaka Takeuchi e Ikujiro Nonaka, publicaron un artículo en la Harvard Business Review titulado New New Product Development Game. Este paper versaba sobre un nuevo enfoque mejorado de desarrollo de productos comerciales.

Como inspiración usaron los procedimientos de varias empresas que destacaban especialmente entre su competencia, concretamente Fuji-Xerox, Canon, Honda, Nec, Epson, Brother, 3M y Hewlett-Packard.

En ese artículo, Takeuchi y Nonaka utilizaron como símil de un equipo de desarrollo cohesionado la típica formación en melé de los equipos de rugby, donde los jugadores hacen piña para avanzar frente al equipo contrario y obtener el balón.

Pues bien, melé, en inglés, se dice Scrum.

Melé
¡¡Todos a una, juntos como una piña, en pos un objetivo común!!

Aunque en ese momento Takeuchi y Nonaka no estaban pensando en el desarrollo software, sus ideas en el desarrollo de productos pronto se extrapolaron a la industria del software como un método en oposición a los procesos establecidos de gestión tradicional o waterfall de proyectos.

Años después el doctor Jeff Sutherland, junto sus colaboradores John Scumniotales y Jeff McKenna, originó el primer proyecto Scrum en 1993 inspirándose en el paper de Takeuchi y Nonaka.

Te recomiendo el libro de Sutherland Scrum: El arte de hacer el doble de trabajo en la mitad de tiempo, donde el mismo autor cuenta con bastante detalle el nacimiento de su criatura.

Sutherland, junto con con Ken Schwaber, desarrolló formalmente Scrum en 1995, presentándolo en Austin, Texas, en la famosa conferencia OOPSLA (rebautizada actualmente como conferencia SPLASH).

En 2001, Sutherland y Schwaber, junto con varios gurús del pensamiento ágil se reunieron en una estación de esquí en Utah y crearon el Manifiesto Ágil, que es el panfleto que define qué es la agilidad. En este post puedes leer cómo se originó todo esto.

Historia de Scrum
Cronología de Scrum: desde un artículo a un método

La guía oficial de Scrum

La principal fuente a la que debes acudir para aprender Scrum es su guía oficial y te recomendaría que la tengas siempre presente. Te dejo aquí su enlace:

https://www.scrum.org/resources/scrum-guide

La primera publicación de la Guía Scrum fue realizada por Ken Schwaber y Jeff Sutherland en 2010 y cada cierto tiempo se actualiza. A pesar de que Ken y Jeff siguieron cada uno su camino por separado, el mantenimiento de la guía sigue pasando por ellos con el objetivo de que Scrum no se fragmente en un conjunto de dialectos que terminen por matar el espíritu de lo que ellos idearon hace 20 años.

Por tanto, la guía es la referencia obligada al marco de trabajo y deberías conocerla al dedillo. Que no te engañe que sea un documento de unas pocas páginas, cada párrafo no tiene desperdicio y establece algún aspecto vital de Scrum.

Personalmente no me parece la lectura más amena, sobre todo si eres novato. Con la idea de sintetizar en muy poco espacio toda la esencia de Scrum y hacerlo versátil a cualquier tipo de proyecto y de circunstancia, sus creadores escribieron un documento denso y completamente falto de ejemplos o consejos a seguir.

Por tanto, no esperes encontrar en ella pautas muy al detalle ni de índole práctica, como por ejemplo qué técnicas utilizar para estimar una historia de usuario o cómo priorizar el Backlog. Pero está claro que representa el espacio en el que deberás circunscribirte si quieres realizar un Scrum ortodoxo (aunque habrá quien te diga que no existe eso de Scrum ortodoxo o heterodoxo. O haces Scrum o no lo haces).

Características de Scrum

Antes de comenzar, conviene indicar que muchas veces utilizaré la terminología en inglés de Scrum. La razón es simplemente porque es más común hablar de daily que hablar de reunión diaria, o de Product Owner (o PO) que de Dueño de Producto. Dicho esto, vamos al lío.

Scrum presenta una serie de características que indico a continuación:

Enfoque iterativo e incremental

Iterativo porque iremos trabajando de forma cíclica a través de breves periodos de 1-4 semanas denominados Sprints. Al final del Sprint generaremos un entregable terminado, tal que podríamos implantarlo en Producción.

Incremental porque en cada iteración iremos mejorando y añadiendo funcionalidades a las realizadas en las iteraciones previas, siempre con un enfoque de más importante a menos importante.

Por cierto, ¿por qué se usa el término Sprint, en vez de iteración, ciclo o cualquier otro sinónimo? Se usa Sprint porque la idea es dar un acelerón de 1-4 semanas y después parar para mostrar lo realizado (la review) y ver qué se hizo y cómo mejorarlo (la retro).

Entrega de valor constante Sprint tras Sprint

Insisto: siempre entregaremos de lo más importante a lo menos importante. El objetivo de esto está claro: quítate lo antes posible lo imprescindible, lo que realmente aporta valor al producto, y ya se irán completando funcionalidades menos importantes en posteriores iteraciones.

Rápido retorno

Permite rápido retorno de inversión gracias a esas entregas frecuentes.

Empirismo

Scrum es un método empírico: prueba, experimenta y quédate con lo que funcione para tu proyecto o empresa. No aceptes dogmas sin antes probarlos en tus carnes. Este empirismo se sostiene gracias a tres pilares: Transparencia, Inspección y Adaptación.

Mejora continua

La mejora continua es fundamental: en cada Sprint debemos trabajar un poquito mejor que en el anterior. Esta idea de mejora es lo que los japoneses llaman Kaizen.

Gestión del riesgo

Scrum minimiza el riesgo recibiendo feedback frecuente de la experiencia del cliente.

Pilares sobre los que basamos Scrum

Los pilares en los que se basa Scrum constituyen su columna vertebral. No los concibas como tres simples palabras que quedan bien en una guía de referencia: realmente cada uno de estos tres pilares condensa la esencia de este marco de trabajo. Veámoslos:

Trasparencia

Consiste en que todo el proceso de trabajo debe ser visible a aquellos que trabajan sobre él y que son responsables del resultado final.

A esta visibilidad ayudan los diferentes eventos de Scrum, en los que posteriormente profundizaremos: en el Sprint Planning dejamos visible a todo el equipo Scrum sobre qué se va a trabajar durante el Sprint; en la Daily se pone de manifiesto a qué se va a dedicar la jornada y qué posibles impedimentos nos encontramos y la Sprint Review muestra el resultado del trabajo del Sprint, tanto los logros como los fracasos.

La transparencia no siempre cuenta con el suficiente apoyo por parte de la gerencia en las organizaciones. El secretismo, por desgracia, suele ser una constante debido a todas aquellas personas que, por cuestiones puramente espurias, no quieren que la información circule libremente.

Te dejo aquí esta cita de Jeff Sutherland de su famoso libro Scrum: El arte de hacer el doble de trabajo en la mitad de tiempo, que ilustra perfectamente esta cuestión:

El grado en que un equipo fabuloso comparte y ejerce transparencia amenaza estructuras fundadas en la reserva y la confusión. En general, a los gerentes no les gusta que sus colegas, equipos ni otras personas dentro de la estructura de poder sepan lo que ellos hacen o harán, ni cuán rápido. Creen que mantener esto en secreto es crucial para su poder. En vez de hacerlo con los intereses del bien mayor, armonizan con sus motivaciones propias, las que a menudo se reducen a codicia y ambición.

En fin, más claro, agua.

Esto me lleva a incidir de nuevo en la importancia del cambio de mentalidad a la hora de aplicar Scrum o cualquier otra forma de agilidad.

Da igual qué cambios metodológicos quieras implementar, qué herramientas quieras utilizar o que empapeles de postits todas las paredes de tu empresa. Si no pasas por el cambio de mentalidad adecuado no estarás aplicando agile, estarás aplicando una forma de gestión obsoleta barnizada con una pátina de agilismo.

Inspección

Consiste en la observación frecuente del proceso de trabajo para identificar y corregir variaciones indeseadas.

Mediante esto, evitas en gran medida un problema típico de la gestión de proyectos software: terminar entregando, tras mucho esfuerzo, un producto que no es el que el cliente esperaba ni necesitaba.

Aquí de nuevo tenemos a los eventos Scrum que nos ayudan a tal fin. En todos ellos se revisa qué camino estamos siguiendo (por ejemplo, en la daily) o cuál fue el resultado del trabajo del Sprint (en la Sprint Review) o cómo trabajó el equipo durante el Sprint (la Sprint Retrospective).

Adaptación

Consiste en corregir las desviaciones y enmendar las malas prácticas que se han detectado durante la Inspección. La Retrospectiva es el principal evento para tal fin.

Para ir familiarizándonos con la jerga de Scrum, hablaremos de tres conceptos: roles, eventos y artefactos.

Roles de Scrum

Scrum reconoce tres roles posibles dentro de un equipo:

El Product Owner

El Dueño del Producto o Product Owner (PO) es sin lugar a duda el rey de la fiesta, la estrella, el rol primordial de Scrum.

Esta persona (porque debe ser una persona en concreto, no un comité ni nada por el estilo) es el que representa las necesidades de negocio y por tanto es responsable de la definición del producto que se va a construir.

Imagínate, en sus manos recae la responsabilidad de definir un producto que tenga valor de negocio. Si el PO es mediocre, poco importará cuán bueno sea el equipo técnico, estos últimos construirán un producto técnicamente sublime, pero de poco valor de negocio. Será como construir un frigorífico perfecto para venderlo en el Polo Norte…

Ya iremos profundizando en este rol, pero quédate con la idea de que el PO define el producto, prioriza los requisitos de más valor de negocio frente a los de menos y encabeza a todas las áreas y stakeholders del proyecto. Casi nada…

El Equipo Desarrollo (Development Team o DevTeam)

El Equipo de Desarrollo Scrum lo constituyen las personas que construyen el producto. Aquí incluimos no sólo a programadores, también estarían testers, devops, technical leads y, en resumen, todos aquellos técnicos necesarios para, a partir de los requisitos de negocio, construir un producto que puedas poner en producción.

No obstante Scrum no cree en jerarquías: da igual si eres tester o devops, para Scrum todos los componentes del DevTeam son desarrolladores y ninguno es más que otro.

Además, apuesta por un equipo con estructura en «T», semejante a la estructura de un equipo de fútbol en el que cualquiera podría hacer de todo si surge la necesidad. Es decir, un especialista de front podría testear y un tester podría desarrollar backend.

El DevTeam no tiene jefes, nadie manda sobre ellos. Debe ser un equipo autogestionado y autoorganizado y el trabajo debe depender de ellos. En el mundo real esto no siempre es así y parte del trabajo del proyecto recae en agentes externos al DevTeam, lo que equivale a sufrir dependencias externas. Ya veremos este tema en posteriores artículos.

El Scrum Master

Es una figura un poco ecléctica, la verdad.

La guía scrum, como suele hacer, da unos parámetros más bien abstractos de lo que debe hacer este rol, de modo que los propios Scrum Master, cuando comienzan con su andadura profesional, tienen dudas sobre qué tareas están en su tejado y cuáles no. Puede que tú seas uno de ellos…

Por ahora diremos que primero, el Scrum Master debe ser el referente metodológico del proyecto y segundo, debe ayudar al PO y al DevTeam a desarrollar su trabajo, quitándoles del camino todas las piedras que les entorpezcan.

Corresponde al concepto de líder-servicial, es decir, aquel que motiva a todos a tirar para adelante y los ayuda en lo que necesiten. El Scrum Master no manda, no da órdenes, no es un jefe, pero sí un líder para todos. Sí, ya sé que estoy siendo tan críptico como la guía Scrum. Paciencia, ya profundizaremos en este rol.

Los eventos de Scrum

En Scrum realizamos una serie de ceremonias o reuniones que son imprescindibles, a las que se les denomina en general eventos.

Esto no quita que puedan celebrarse otras reuniones si es necesario, pero los eventos Scrum establecen una cadencia y además suplen en gran medida reunirse para otras cosas.

Además, al estar time-boxed (es decir, acotados por tiempo), se dedica un tiempo limitado para que las reuniones no se vayan de madre. Lo cual está muy bien ya que de lo contrario podemos caer en parálisis por análisis, que es algo diametralmente opuesto a la idea de la agilidad.

Los principales eventos ya los hemos ido nombrando: Sprint Planning, Daily Scrum, Sprint Review y Sprint Retrospective.

El tema de los eventos da para mucho, ya que representan en gran medida la práctica de Scrum, así que por ahora lo dejaré aquí y ya profundizaremos en posteriores artículos. Simplemente quédate con estas ideas:

Sprint Planning

Como su nombre indica, reunión en la que se planifica el Sprint que va a comenzar, es decir, en la que se discute y establece el trabajo que se abordará en el Sprint. Todo Sprint comenzará con este evento.

Daily Scrum

Reunión diaria de 15 minutos máximo que sirve para “sincronizar” al equipo de cara al trabajo que deberá desarrollar durante esa jornada.

Sprint Review

Evento final del Sprint en el que se mostrará a todos los interesados el resultado del trabajo de dicho Sprint.

A este resultado se le denomina en jerga Scrum incremento (el nombre, evidentemente, hace referencia a que el producto va incrementándose en funcionalidades Sprint tras Sprint) y corresponde al entregable que se ha desarrollado durante ese Sprint.

El objetivo de este evento no es lucirnos enseñando qué se ha construido, es recibir retroalimentación por parte del Product Owner, pero sobre todo, de los stakeholders. De hecho, es el Equipo Scrum al completo el que busca recibir feedback, no sólo el Equipo de Desarrollo.

Por tanto, el valor de este evento es fundamental y da sentido a la práctica de Scrum.

Sprint Retrospective (o simplemente, Retrospectiva)

Evento en el que, como su nombre indica, se realiza una retrospectiva de cómo se trabajó durante el Sprint que acabó y analizamos qué hicimos bien y qué fue mejorable. Todo ello orientado a la mejora continua y a tratar de hacerlo mejor la próxima vez (¿recuerdas el tercer pilar de Scrum, la Adaptación?).

En Scrum, nunca se es lo suficientemente bueno…

Refinamiento

Este evento se nombra en la Guía Scrum, pero no suele incluirse dentro de la lista de eventos porque no es de obligado cumplimiento (aunque sí que lo es si estás aplicando el framework de escalado Scrum Nexus).

Las reuniones de refinamiento son aquellas en las que detallamos los elementos del Product Backlog, haciéndolos más comprensibles al Equipo de Desarrollo. Normalmente es el Equipo de Desarrollo quien demanda este evento al Product Owner.

Tras estas sesiones los elementos vistos deben quedar mucho más claros al equipo de desarrollo, tanto para poder estimarlos como para poder comenzar con su construcción.

Y para acabar este apartado de eventos permíteme un consejo: si quieres que los asistentes al evento estén enfocados y concentrados en las tareas que se van a abordar en dicha reunión de forma que el evento se desarrolle de la forma más rápida y eficaz posible, no permitas que tengan su ordenador por delante.

De lo contrario, mientras unos tratan de sacar el evento adelante habrá otros que estarán mirando su correo, consultando Internet o haciendo cualquier otra cosa ajena al evento.

No hay nada más frustrante para el facilitador de un evento que ver a la gente con las narices metidas en sus ordenadores desatendiendo el objetivo por el cual se les reunió.

Los artefactos de Scrum

Con este nombre tan poco intuitivo, debido a la traducción literal del inglés artefacts, designamos a tres elementos o componentes: el Product Backlog, que es una pila de requisitos de negocio (semejantes a los casos de uso de toda la vida); el Sprint Backlog (entre otras tareas, corresponde a la parte del PB que se abordará en el Sprint en vuelo) y el incremento (o sea, el entregable que generaremos en cada Sprint).

El Definition of Done (DoD)

Consiste en la redacción explícita de qué debe hacer el Equipo de Desarrollo sobre un ítem del Product Backlog para considerar que lo ha terminado completamente. Esto puede parecer en principio trivial, ya que puede considerarse que es evidente cuándo se ha terminado algo.

Pero párate a pensarlo dos veces… ¿Consideraremos que una historia de usuario se ha completado cuando esté en entorno de Certificación, o es necesario testearla en Preproducción? ¿o la daremos por buena cuando le pasemos un testing manual, o será necesario también un testing automatizado? ¿o se dará por buena una historia de usuario cuando se programó sin errores, pero no se comentó el código?

Al final el DoD suele estar marcado por la política de la compañía, no es normal que el Equipo de Desarrollo se base en un DoD sólo para ellos. Sea como fuere, el Scrum Master debería preocuparse en que ese DoD exista y que el Equipo de Desarrollo sea plenamente consciente de esa definición y la respeta.

¿Cómo se desarrolla un proyecto mediante Scrum?

No incidiré mucho en esto, pues ya habrá tiempo de profundizar. Podemos resumir el ciclo de vida de un proyecto Scrum en los siguientes pasos:

¡Todo gira en torno al Producto Backlog!

Partimos de un Product Backlog, que es una pila que contiene todos los requisitos de negocio priorizados, tal que el Equipo de Desarrollo sepa en qué debe trabajar.

Planifica tu Sprint

Al principio de cada iteración o Sprint, de duración 1-4 semanas, se realizará una Sprint Planning para que el equipo de desarrollo sepa qué y cómo abordar los requerimientos del Product Backlog que corresponderán a ese Sprint y los irá desarrollando a lo largo de éste. El trabajo del Sprint se refleja en el Sprint Backlog.

Cada elemento sobre el que se trabajará será estimado por el Equipo de Desarrollo. Dichas estimaciones darán un peso global al trabajo abordado por el equipo durante ese Sprint y permitirá saber la velocidad de dicho equipo, es decir, que cantidad de trabajo puede admitir ese equipo de media por Sprint.

Transparencia e inspección diarias

Diariamente, el equipo tendrá una reunión de no más de 15 minutos que servirá para sincronizarse (aunque este es un término que no gusta a los puristas), no perder foco del trabajo a realizar en dicha jornada y levantar cualquier posible impedimento que puede afectar o frenar el trabajo.

Señor/a Scrum Master, ten en cuenta esos impedimentos que levante el equipo para removerlos.

Inspecciona el resultado final del Sprint

Al final del Sprint se celebrará la Review en la que el Equipo de Desarrollo mostrará el trabajo realizado durante el Sprint y recibirá feedback de los stakeholders., en especial de los usuarios y por supuesto del Product Owner.

Esta retroalimentación es imprescindible para calibrar en qué grado lo que estamos desarrollando está alineado con las necesidades del cliente y por tanto está realmente aportando valor o no.

¿Cómo hemos trabajado durante el Sprint?

Por último, antes de dar carpetazo a ese Sprint y comenzar con la siguiente iteración, se celebrará el evento Retrospectiva en el que se revisará cómo se ha estado trabajando durante el Sprint, con la idea de buscar en qué mejorar para la próxima iteración.

La Retrospectiva deberá traducirse en una serie de medidas concretas de mejora que deberán aplicarse en el siguiente Sprint. No es necesario que se apliquen todas las medidas, pero sí las suficientes para lograr dicha mejora.

Y vuelta a empezar…

Continuamos con el Sprint siguiente y se repite el ciclo.

¿Durante cuántos Sprints debemos estar trabajando?  Esa es una muy buena cuestión en la que la Guía no se mete. Aaainnsss, ese laconismo de la Scrum Guide…

Mucha gente cree erróneamente que Scrum consiste en ir desarrollando Sprint tras Sprint hasta que alguien de negocio, o el Product Owner, o la gerencia, diga hasta aquí hemos llegado. Pero no, esto no es así.

Evidentemente, no se puede ir Sprint tras Sprint sin rumbo. Más que nada porque ninguna organización admitiría que un equipo de desarrollo les dijese “mira, yo voy a ir trabajando en este Sprint, después en otro, y en algún momento, me detendré. Cuando el producto sea lo suficientemente bueno…”. Esto en un mundo ideal podría ser factible, pero en este mundo donde contamos con unos presupuestos y necesitamos planificar recursos y entregas, esa filosofía hace aguas.

Y tampoco el cliente admitiría eso de que algún día tendrá un producto estupendo, él querrá contar unas fechas a las que medianamente pueda atenerse. Que Scrum no sea un método predictivo no significa que no se planifique.

En artículos posteriores iremos abordando la planificación de un MVP (Producto Mínimo Viable) y en general de cualquier release de tu producto software.

Reflexión final

A la hora de agilizar un proyecto o empresa, Scrum personalmente me resulta un método bastante completo. No voy a decir que sea ni el mejor ni el peor, ya que eso dependerá del gusto personal, de las circunstancias del proyecto o de la empresa, etc.

Pero sí que es verdad que Scrum marca una serie de pautas que puedes ir llevando a la práctica desde el principio. Y eso aunque cuentes con poca experiencia en el marco de trabajo.

No obstante, déjame recordarte que Scrum no es una metodología, es, según sus autores un framework o marco de trabajo. Esto es la forma amable de decirte «te doy algunas pautas de trabajo, pero cómo las lleves a la práctica es cosa tuya».

Por eso la experiencia de los que lo apliquen marcará la diferencia. Ken Schwaber, uno de los dos padres de la criatura, compara Scrum con el ajedrez: sus reglas puedes aprenderlas en poco tiempo, pero para lograr la maestría puedes necesitar media vida.

Pero yo no quiero que necesites media vida para sacarle jugo a Scrum.

Mucha gente que se acerca por primera vez a este marco de trabajo termina por decepcionarle ya que las normas que incluye no parecen lo suficientemente significativas como para lograr una ventaja a la hora de gestionar un proyecto.

Yo fue uno de esos. La primera vez que leí sobre Scrum me pareció que vendía humo, que sus prácticas eran demasiado triviales y superficiales como para impactar positivamente en un proyecto.

Nada más lejos de la realidad. Estúdialo, practícalo y verás cuán poderoso es Scrum y cuánto puede hacer por ti y por tu empresa.

Si te quedaron dudas puedes dejarlas en la sección de comentarios, estaré encantado de responderte.

Y si el artículo te ha resultado útil, te agradeceré mucho que lo compartas en alguna de las siguientes redes sociales. ¡Nos vemos en el próximo post!

Deja un comentario