Según sus creadores, Ken Schwaber y Jeff Sutherland, Scrum es un framework (marco) dentro del cual las personas pueden tratar y resolver problemas complejos mientras construyen productos de forma creativa y eficiente, con el valor más elevado posible (Guía del Scrum, 2017).
No llega a ser un método, pues especifica solo lo que se debe hacer, pero no cómo debe hacerse. Por ejemplo, es necesario que haya un momento de planificación del Equipo de Scrum para el próximo ciclo de desarrollo, pero la Guía no describe cómo se realiza este momento. Habla sobre los artefactos que deben existir, pero no exhaustivamente. No se muestra el formato de los mismos. El Scrum siempre requerirá adaptaciones a los contextos específicos de las organizaciones.
Los tres pilares y los valores
Cualquier adopción del Scrum descansa en valores y en tres pilares: Transparencia, Inspección y Adaptación.
Transparencia
El proceso utilizado por el Equipo de Scrum, sus actividades y expectativas deben ofrecer visibilidad a los interesados en los resultados del equipo. No debe esconderse nada debajo de la alfombra. Además, es necesario que los partícipes utilicen un lenguaje común comprensible por todos para que la comunicación fluya.
Normalmente esta transparencia se implementa con la Tabla de Tareas en la cual el equipo da visibilidad al flujo de trabajo y a los elementos de valor que se están desarrollando.
Tabla de Tareas que muestra el flujo completo de entrega de valor.
Los equipos más maduros son más transparentes. La relación y la confianza entre ellos y las demás partes interesadas ejercen una fuerte influencia en la transparencia. Si hay una relación de desconfianza o inmadurez, tendremos mucho trabajo “escondido” y poca visibilidad.
Además, la transparencia está relacionada con los roles que las personas desempeñan durante el desarrollo del producto, los resultados alcanzados, las expectativas, la colaboración, etc.
Inspección
El trabajo debe ser inspeccionado a menudo. El Equipo de Scrum se pregunta si está caminando hacia los objetivos y resultados de negocio. También debe preguntarse cómo puede perfeccionar su método de trabajo, el ambiente del equipo y la calidad del producto que se entrega. Utilizar Scrum es hacerse constantemente la pregunta: ¿Cómo podemos mejorar?
Adaptación
Si la inspección determina que no estamos progresando hacia nuestros objetivos, es hora de adaptarse. Esta adaptación puede estar motivada por diversos factores: cambios de mercado, competidores, necesidades del cliente, necesidades del negocio, hipótesis invalidadas, entre otros muchos.
“Aceptamos que los requisitos cambien, incluso en etapas tardías del desarrollo. Los procesos Ágiles aprovechan el cambio para proporcionar ventaja competitiva al cliente."
(Los 12 principios del Manifesto Ágil, Ágil, 2001)
Valores del Scrum
Son cinco los valores del Scrum:
- Compromiso con el equipo, los acuerdos y la entrega y calidad del producto o servicio.
- Coraje para hacer lo que hay que hacer y tomar decisiones aunque sean difíciles.
- Focalización o enfoque en el cliente, el resultado y objetivos del negocio.
- Apertura (openness) para permitir que las personas sean transparentes y disfrutemos de un entorno seguro para compartir el conocimiento.
- Respeto a las personas y organizaciones.
Pilares y valores del Scrum
El Equipo de Scrum
Se compone de solo tres roles, que son el Scrum Master (S.M.), el Product Owner (P.O.) y el Equipo de Desarrollo.
Scrum Master (S.M.)
El Scrum Master es el facilitador del equipo. Busca insistentemente construir el mejor equipo del mundo y por eso trabaja para mantener al Scrum funcionando. Es un líder servicial que ayuda al Product Owner, al Equipo de Desarrollo y demás partes interesadas a comprender y practicar el Scrum. Es él quien ayuda al Equipo de Scrum a eliminar impedimentos y, si es necesario, promover los cambios organizativos para que la empresa sea más eficaz y eficiente.
En el artículo Scrum Master: quién es y qué hace, Lucas Gomes desarrolla este rol. Y en Disfunciones del rol de Scrum Master, escribo sobre lo que NO debe ser el Scrum Master.
Product Owner (P.O.)
Es quien define la dirección del producto. Es responsable de analizar los problemas desde la perspectiva del cliente y, en conjunto con el Equipo de Desarrollo, de elaborar una solución que los resuelva y que aporte resultados de negocio para la organización. Es el responsable de priorizar cuáles son las próximas rebanadas del producto que han de desarrollarse y verificar los impactos causados por las entregas a través de métricas de eficacia. Es una persona de visión sistémica que entiende de estrategias de negocio, producto, clientes, competidores, resultados, etc.
En el artículo Product Owner: descubrir el rol del PO, Andressa Chiara escribe sobre otros atributos necesarios para desempeñar este rol. En O trabalho de FDP do Product Owner (en portugués), Magno Santana escribe sobre la esencia del trabajo del P.O.
Equipo de Desarrollo
Son todas las personas necesarias para hacer que un elemento del backlog del producto se transforme en un Incremento del producto (ya veremos esos artefactos en breve). Debe ser multidisciplinar, autoorganizado, autónomo, autogestionado, comprometido e incansable en la búsqueda de mejorar su proceso de trabajo, así como el resultado y calidad de sus entregas.
Usuarios, clientes, gestores, consumidores finales y demás partes interesadas
Estos papeles NO están recogidos en la Guía del Scrum, pero sabemos que tienen influencia sobre el Equipo de Scrum. Estas personas tienen necesidades que nuestro producto debe resolver. Son ellas quienes consumen lo que el Equipo entrega. El valor de la entrega depende de la percepción que tienen sobre el producto. En breve, veremos que participan en algunos eventos.
El Ciclo Scrum
La imagen inferior explica el Ciclo de desarrollo de Scrum. Contiene los roles (ya descritos), los eventos, artefactos y algunas buenas prácticas que utilizamos y facilitan la vida al Equipo de Scrum.
Ciclo de Desarrollo del Scrum
Planificación del Sprint (Sprint Planning)
Es el momento en que el Product Owner discute con el Equipo de Desarrollo qué elementos del backlog se desarrollarán en el próximo ciclo de construcción del producto. El Scrum Master facilita la reunión garantizando que todos mantengan la focalización y que se alcancen los objetivos de la misma.
El Equipo planificando el próximo sprint
Product Backlog (P.B.)
El principal artefacto de entrada es el Product Backlog. Es el conjunto de todas las necesidades de los clientes y del negocio que resolverá el producto. El Product es el responsable de su valoración y priorización.
Los elementos no tienen el mismo nivel de detalle. Aquellos que están en la cima del backlog (más prioritarios) contienen más información sobre lo que haremos, cuál es el propósito y a quién se lo entregaremos. Cuanto mayor sea la prioridad, mayor será el detalle.
Objetivo del Sprint
Una de las primeras cosas que el Equipo de Scrum debe hacer en la planificación es definir cuál es el Objetivo del Sprint. Sirve de guía para elegir los elementos. Ejemplos de Objetivos:
- Tener disponibles los productos del Día de la Madre en las tiendas piloto de tres localidades: San Sebastián, Granada y Valladolid.
- Tener disponible la compra rápida en el sitio web.
- Lanzar el seguro de vida en las ciudades de Madrid, Barcelona y Valencia.
Comprenda que ahora está claro adónde queremos llegar al final del Sprint. Imagínese que usted está en el equipo que va a ofrecer productos del Día de la Madre. ¿Tendría algún sentido construir un artículo de backlog relacionado con la Navidad? ¿O hacer algo para ser evaluado en Bilbao?
¡Atención! No confundir el Objetivo del Sprint con llevar a cabo todos los elementos seleccionados en el Sprint Backlog. De esta forma, perdemos el propósito principal y podemos acabar seleccionando de forma descoordinada elementos de la estrategia comercial.
Sprint Backlog
Una vez definido el Objetivo de Sprint, el Equipo de Desarrollo, junto con el Product Owner, define qué elementos se construirán en el Sprint. Es importante que la capacidad del equipo sea respetada y que el Scrum Master esté allí para garantizarlo. Es frecuente que los equipos de Scrum utilicen el Planning Poker para definir esta capacidad.
El Equipo de Desarrollo puede detallar aún más el elemento del backlog y para ello “romperlo” en tareas técnicas necesarias para transformarlo en Incremento del producto. El Sprint Backlog es el conjunto de elementos del Backlog del producto seleccionados para el Sprint más las tareas técnicas.
Sprint
Es el evento principal del Scrum y todo el trabajo sucede durante el mismo. Se inicia cuando empezamos la Planificación del Sprint y termina al final de la Retrospectiva. Es un evento con un periodo fijo (time-boxed).
Una analogía para facilitar la comprensión del time-box es como si colocáramos el tiempo dentro de una caja de acero que no puede expandirse. El tiempo es como un líquido que llena la caja. Cuando se llene la caja, se acabó el tiempo. No se puede poner nada más en ella. No existe eso de: "Deme una semana más para terminarlo”.
Durante Sprint, los elementos del Sprint Backlog se construyen y se transforman en un Incremento del producto potencialmente entregable.
Incremento del producto potencialmente entregable
Nombre largo y extraño. Vamos a explicarlo por partes. Incremento del producto es la aplicación del concepto de desarrollo iterativo e incremental adoptado por los Métodos Ágiles. En vez de pasar meses o años desarrollando un producto para entregarlo todo al final del proyecto, en el Scrum el producto se construye en varias iteraciones (i, i + 1, i + 2...). Con cada iteración incrementamos y perfeccionamos el producto.
Algunos ejemplos de Incremento:
- En el desarrollo de software, el Incremento son las funcionalidades del software (features).
- Para la industria de cosméticos, los Incrementos pueden ser el conjunto de productos que se lanzarán en un paquete. Por ejemplo, en el Día de la Madre, los Incrementos podrían ser: Lápiz de labios, perfume, aceite para el cuerpo. Cada uno entregado en un ciclo y ya pueden probarlo algunos consumidores finales antes de comenzar la promoción.
- En marketing, los formatos de campaña de un producto: Campaña en redes sociales, e-mail marketing, marketing fone, promotor, etc.
- Para abogados, la elaboración de documentos jurídicos.
- Ingeniería de producción, el Incremento de los módulos operativos.
- Etc.
Potencialmente entregable porque el Incremento tiene que estar en un estado que pueda ser utilizado por el consumidor. No puede decirse: Está hecho, solo falta probarlo. Tampoco es un prototipo que será descartado. Puede ser algo todavía incompleto, pero ES UN PRODUCTO / SERVICIO consumible.
La entrega para el consumo es una decisión comercial y, por lo tanto, depende de la decisión del Product Owner. Esto sucede porque el equipo puede entregar algo que todavía no es estratégicamente interesante lanzar al mercado. Por ejemplo, digamos que el Equipo está trabajando en octubre para el sitio web de promoción de Navidad. Puede y debe llamar a los clientes para probar el nuevo sitio y recoger comentarios durante las iteraciones, pero no sería interesante lanzar este sitio antes de mitad de noviembre.
Definición de "Hecho" (Definition of "Done")
Para saber si el Incremento está hecho para ser entregado al consumidor, utilizamos la Definición de "Hecho". Son todas las restricciones que el producto debe cumplir antes de ser entregado. Una especie de lista de verificación (checklist).
- Ejemplo de definición de "Hecho"en el desarrollo de software: código en el repositorio; ha pasado todas las pruebas en el servidor de integración continua; paquetes generados, etc.
- Ejemplo en la ingeniería de producción: robot instalado; manual de funcionamiento actualizado; reglas de seguridad fijadas en lugar visible, etc.
Si el elemento no cumple todos los requisitos de la definición de "Hecho", no está hecho y no puede entregarse. En el Scrum, no existe ½ hecho o 99,99% hecho.
Duración del Sprint
La duración es fija y puede ser de hasta un máximo de cuatro semanas, preferentemente el menor tiempo posible. Este periodo NO varía. Esto significa que si el Equipo de Scrum decide que el Sprint tendrá una duración de dos semanas, todos los Sprints tendrán una duración de dos semanas.
¿Puedo reducir la duración del Sprint?
Sí. Sin embargo, debe ser algo en lo que todos están de acuerdo y debe estar motivado por algún hecho importante. Por ejemplo, el Equipo de Scrum ha automatizado una parte del proceso y cree que puede realizar entregas de valor semanalmente. A partir de ahora, todos los Sprints serán de una semana.
¿Puedo ampliar la duración del Sprint?
Mucho cuidado al hacerlo. El tiempo puede estar sólo ocultando un problema, en lugar de resolverlo en su causa raíz. Por ejemplo: el equipo alarga el Sprint una semana más porque la calidad del producto es baja y los encargados de calidad solo tiene algunas horas para comprobar el producto. Ahora serán dos semanas de desarrollo más una semana de prueba.
Al principio, todos creen que esto resuelve el problema, pero no es verdad. En breve ese equipo aumentará a cuatro semanas, pues en la práctica el tiempo de desarrollo también aumentará. La raíz del problema que debería tratarse es la baja calidad en el desarrollo.
Las consecuencias de alargar la duración del Sprint:
- Evita tratar la causa raíz de los problemas;
- Reduce significativamente la capacidad de adaptación tanto del Equipo como del producto;
- Reduce la cantidad de experimentos que el Equipo hará;
- Disminuye la eficiencia;
- La entrega de valor (eficacia) también cae;
- Hace que el equipo esté más sujeto a interrupciones externas;
- Disminuye la cantidad de feedback sobre el producto;
- Retarda la mejora continua;
- Entre muchas otras.
Una cuenta sencilla para observar porque es un Sprint demasiado largo es negativo:
Se percibe que cuanto más largo sea la Sprint, menos experimentos tendremos y, por lo tanto, quedamos expuestos a sufrir las consecuencias enumeradas arriba.
Reunión Diaria (Daily Scrum)
Después de que el Equipo de Scrum establezca el Sprint Backlog, comienza el trabajo de transformar los elementos seleccionados en el Incremento del producto. Durante ese periodo, diariamente, el Equipo de Desarrollo se reúne frente a la Tabla de Tareas para celebrar la Reunión Diaria. Esta es una reunión del Equipo de Desarrollo para el Equipo de Desarrollo. El Scrum Master facilita si es necesario y la presencia del Product Owner no es obligatoria. Las personas externas (gestores, partes interesadas, curiosos) solo participan si el Equipo de Desarrollo está de acuerdo y permanecen en silencio durante todo el evento. Queremos crear un ambiente seguro de colaboración y no un momento de status report y justificaciones.
Este evento tiene una duración máxima de 15 minutos y el objetivo es definir lo que el Equipo de Desarrollo hará para avanzar ese día hacia el Objetivo del Sprint. Es un momento para que el equipo realice el control (¿alcanzaremos el Objetivo de Sprint?) y la adaptación (¿qué haremos para corregir el curso y alcanzar el Objetivo del Sprint?).
Ejemplo de Reunión Diaria
Para contribuir a este propósito, hay tres preguntas sugeridas en la Guía del Scrum, pero no son obligatorias.
- ¿Qué hice ayer que ayudó al Equipo de Desarrollo a alcanzar el Objetivo del Sprint?
- ¿Qué haré hoy para ayudar al Equipo de Desarrollo a alcanzar el Objetivo de Sprint?
- ¿Veo algún obstáculo que me impida a mí o al Equipo de Desarrollo alcanzar el Objetivo del Sprint?
Tabla de Tareas
Es una herramienta de transparencia del Equipo de Scrum. Contiene todo el trabajo que el equipo debe hacer durante el Sprint, incluyendo actividades que no están relacionadas con el desarrollo del producto (participaciones en comités, apoyo a otros equipos, mantenimiento en otros productos, reuniones, etc.).
La tabla puede comenzar en el formato más simple con tres etapas de desarrollo: cosas que hacer, lo que el Equipo de Desarrollo está haciendo y lo que ya ha hecho.
Tabla de Tareas sencilla
Con el paso del tiempo, la tabla puede reflejar un flujo de trabajo más completo.
Tabla de Tareas de mapeo de todas las etapas de la cadena de valor
Gráficos de Seguimiento
El Equipo de Scrum también puede mantener gráficos de seguimiento para ver más fácilmente la evolución del Sprint o la construcción del producto completo. Los gráficos más comunes de seguimiento son el Burn Down Chart, Burn Up Chart, Gráfico de Valor y el Cumulative Flow Diagram (CFD).
Gráficos de Seguimiento de Proyectos Ágiles
Una pregunta común: ¿Quién es el responsable de actualizar el gráfico? Si el gráfico es relevante para el Equipo de Desarrollo, el debe mantenerlo actualizado. Si es un gráfico utilizado para facilitar información a otras partes interesadas, esta actualización puede ser hecha por el Scrum Master, el Product Owner o el propio Equipo de Desarrollo.
Revisión del Sprint (Sprint Review)
Al final de Sprint el Incremento del producto se presenta a consumidores, usuarios, clientes, gestores y demás partes interesadas. Todo el Equipo de Scrum participa. El objetivo principal de este evento es obtener feedback sobre el producto. El libro The mom test, de Rob Fitzpatrick, contiene excelentes consejos sobre cómo hacer preguntas para obtener buenos feedbacks.
Los comentarios proporcionados por los invitados pueden convertirse en nuevos elementos del Backlog del producto. Pueden ser muy estratégicos y entrar en la parte superior del backlog. De lo contrario, pueden entrar en el centro o al final del mismo. Existe también la posibilidad de descartar el feedback si resulta irrelevante.
Lo correcto en este evento es que el consumidor utilice el producto. No es una reunión para mostrar diapositivas o elementos que no cumplen la definición de "Hecho".
Danilo, Coach Ágil de Knowledge21 desempeña el rol de consumidor final para un Equipo de Scrum durante el EVDnC.
En esta reunión, se puede presentar información sobre el progreso del proyecto, pero el foco estará puesto siempre en el feedback sobre el uso del producto o servicio.
Retrospectiva del Sprint (Sprint Retrospective)
Es el momento de la mejora continua. Todo el Equipo de Scrum participa: Product Owner, Scrum Master y todos los miembros del Equipo de Desarrollo. Su objetivo es mejorar la forma de trabajo de todo el equipo.
Es un entorno seguro en el que el Equipo de Scrum discute sobre fallos y puntos débiles. Por lo tanto, no debemos contar personas externas. La única excepción es si el equipo completo está de acuerdo en invitar a alguien externo.
En el artículo Retrospectiva: Mejora Continua de su Equipo, hablo un poco más sobre este evento importantísimo. Knowledge21 posee un e-book sobre Retrospectivas.
¡Descargue el e-book gratuito sobre Retrospectivas Ágiles! También tenemos varias dinámicas de retrospectiva en este enlace.
Refinamiento del Backlog del Producto
Este no es un evento oficial en Scrum, pero es una buena práctica. El refinamiento puede hacerse en cualquier momento y podemos organizar reuniones para ello. El objetivo es mantener el Backlog del Producto actualizado y priorizado con insumos de: nuevas ideas, resultados anteriores, clientes, gestores, cambios en el mercado, cambios en los competidores, innovaciones, etc.
También es interesante que el Equipo de Desarrollo participe en el refinamiento para estimar el esfuerzo o discutir la complejidad técnica de los elementos más prioritarios. Sin embargo, no debe consumir más del 10% de la capacidad del Equipo de Desarrollo durante el Sprint.
Si el refinamiento no se realiza antes, se realizará en la planificación del Sprint. En ese caso, celebraremos una reunión muy larga. Lo ideal es que en el momento de la planificación el Backlog del producto ya haya sido objeto de actualización, valoración, priorización y, si es posible, que se haya realizado ya la estimación del esfuerzo.
Definición de "Preparado" (Definition of "Ready")
A algunos equipos les gusta usar una definición mínima que garantice que el elemento ha sido refinado y puede ser discutido en la planificación del Sprint. La definición de "Preparado" tampoco es oficial de Scrum, pero ayuda al equipo a perder menos tiempo y estar más focalizados durante las discusiones de planificación. Un ejemplo podría ser:
- El elemento debe escribirse en el formato de Historia de Usuario;
- Los criterios de aceptación están definidos;
- Se han seleccionado las métricas para medir el impacto del elemento;
- Se ha definido el valor de negocio del elemento;
- Los consumidores del artículo fueron invitados a la revisión del Sprint;
- El esfuerzo para la construcción del elemento ha sido objeto de estimación.
Conclusión
Este artículo trata sobre los aspectos generales del Scrum. Escribo sobre elementos oficiales de la Guía del Scrum y buenas prácticas que nosotros, Knowledge21, hemos aprendido a lo largo del tiempo. Espero que el texto le ayude a adoptar el framework. Si tiene alguna duda, compártala en los comentarios.
Le invito a conocer un poco más sobre este framework.
Si quiere convertirse en un Scrum Master o Product Owner, le invito a participar en los cursos de formación de Certified Scrum Master (CSM) y Certified Scrum Product Owner (CSPO).
Siga en nuestro blog otros artículos sobre Scrum.
