Scrum tiene una gran ventaja, le da a las organizaciones la capacidad de responder a los cambios y de reinventarse, ayuda a reducir riesgos, ahorrar tiempo, así como recursos, tomar mejores decisiones y trabajar con equipos ágiles. Este marco de trabajo es tan valioso, que hoy se ajusta a todos los proyectos complejos y lo usan compañías que día a día buscan reinventarse.
De hecho, los autores Ken Schwaber y Jeff Sutherland explican en la Guía de Scrum que este marco de trabajo ha sido usado para gestionar el desarrollo de productos complejos y adaptativos, desde principios de los años 90.
Scrum se utiliza para proyectos que necesitan resultados exitosos en tiempos cortos, en los que prima la innovación, la competitividad y la productividad. Es un framework, basado en los principios y valores del agilismo, que ayuda a la detección y corrección de errores, así como a la adaptación de cambios en tiempos muy cortos.
El framework invita a tomar el proyecto que hay en mente para detallarlo progresivamente a través de historias de usuario, que ayudan a conocer con profundidad todo el espectro del proyecto y a definir cuáles de esas historias dan valor al producto de manera inmediata.
En esta guía podrás conocer este marco de trabajo, los equipos Scrum, sus roles, eventos, artefactos y reglas asociadas. Además, sabrás cuál es la funcionalidad y los beneficios de esta metodología ágil, que se aplica a distintos sectores: financiero, salud, educación y tecnología.
Tal y como lo explica la guía de Scrum, es un marco de trabajo, un framework por el cual las personas pueden abordar problemas complejos adaptativos, a la vez que entregan productos del máximo valor posible de forma productiva y creativa.
Desde los años 90, Scrum se usa en todo el mundo para investigar e identificar mercados viables, tecnologías y capacidades de productos; para diseñar productos; liberarlos y mejorarlos; así como para desarrollar y mantener ambientes en la Nube (en línea, seguros, bajo demanda).
Los autores Ken Schwaber y Jeff Sutherland explican que “Scrum se ha usado para desarrollar software, hardware, redes de funciones interactivas, vehículos autónomos, escuelas, gobiernos, mercadeo y para gestionar la operación de organizaciones. Scrum demostró ser especialmente efectivo en la transferencia iterativa e incremental de conocimiento”.
Este marco de trabajo no solo se usa para desarrollar productos digitales, de hecho, también es estratégico para la política. Por ejemplo, el equipo de campaña de Barack Obama usó metodologías ágiles para lograr su reelección a la presidencia de Estados Unidos, en 2012.
La estrategia del candidato demócrata era ver resultados para hacer ajustes rápidos, a través de redes sociales. Su equipo medía grandes volúmenes de datos y analizaba resultados para ajustar su ruta de forma ágil, lo que permitió diseñar una mejor estrategia en tiempo real y tener una amplia participación ciudadana y coherente con los ideales democráticos.
Cuando proponemos hablar de los fundamentos de Scrum, no nos referimos a ninguna receta fundamental ni a un paso a paso sino a su esencia: ¿Qué es Scrum? ¿Para qué Scrum? ¿Qué elementos lo componen? y, finalmente, entender que dentro de este marco de trabajo, se pueden (y se deberían) emplear varios procesos, prácticas, así como herramientas.
Quienes lo usamos, debemos desarrollar el criterio para seleccionar las que mejor nos convengan, según el contexto y el problema que estamos resolviendo y, sobre todo, el criterio para ajustarlas y perfeccionarlas cuando se requiera para poder ser más efectivos.
Vamos pues a recorrer los fundamentos, pero antes debemos hacer un corto viaje al año 1986, cuando Hirotaka Takeuchi e Ikujiro Nonaka publicaron en Harvard Business Review un artículo titulado: “El nuevo juego del desarrollo de nuevos productos (The new new product development game)”, en el que plantean que hoy (1986) en este mundo cada vez más competitivo y dinámico del desarrollo de nuevos productos, la velocidad y la flexibilidad son esenciales. Por supuesto, más de 30 años después, este planteamiento es aún más válido que en ese entonces.
Según Nonaka y Takeuchi, las empresas se estaban dando cuenta de que con los enfoques secuenciales antiguos para desarrollar productos, no estaban logrando los objetivos y que en contraposición, algunas compañías tanto en Japón como en Estados Unidos empezaron a usar enfoques más holísticos, como cuando en un juego de Rugby el balón pasa dentro del equipo, mientras se mueve como una unidad dentro del campo; de ahí la inspiración del nombre del marco de trabajo que hoy conocemos como Scrum.
Este enfoque holístico que encontraron Nonaka y Takeuchi en sus investigaciones tiene seis características:
Estos seis elementos forman un rompecabezas que representa un proceso veloz y flexible para el desarrollo de productos.
A principios de los años 90, tanto Ken Schwaber, como Jeff Sutherland, basándose en los conceptos iniciales del enfoque holístico del juego de Rugby, utilizaron en sus empresas un enfoque similar que luego se convertiría en el hoy viejo y conocido Marco de trabajo Scrum y que luego formalizarían en La guía de Scrum.
Desde sus inicios y alrededor de 30 años, este marco de trabajo ha sido usado ampliamente en todo el mundo, aunque en Colombia es posible que lleve alrededor de 10 años en el contexto del desarrollo de productos de software.
Precisamente, para el desarrollo de nuevos productos de software y la evolución de los existentes, ha demostrado ser una buena alternativa, teniendo en cuenta que la posibilidad de tener un incremento terminado al final de cada iteración, nos confiere la velocidad y la flexibilidad necesarias para reaccionar adecuadamente a los aprendizajes y nuevos retos del mercado que nos confiere la retroalimentación del uso de dichos incrementos.
Scrum se basa en la teoría de control de procesos empírica o empirismo, que asegura que el conocimiento procede de la experiencia y de tomar decisiones basándose en lo que se conoce.
Tres pilares soportan toda la implementación del control de procesos empírico:
Transparencia: los aspectos significativos del proceso deben ser visibles para aquellos que son responsables del resultado.
Inspección: los usuarios de Scrum deben inspeccionar frecuentemente los artefactos y el progreso hacia el objetivo para detectar variaciones indeseadas
Adaptación: cuando a partir de la inspección se detectan variaciones, deben realizarse los ajustes necesarios lo antes posible.
El uso exitoso de Scrum depende de que las personas lleguen a ser más virtuosas en la convivencia con sus valores.
1. Compromiso: las personas se comprometen de manera individual a alcanzar las metas del Equipo Scrum.
2. Coraje: los miembros del Equipo Scrum tienen coraje para hacer bien las cosas y para trabajar en los problemas difíciles.
3. Foco: todos se enfocan en el trabajo del Sprint y en las metas del Equipo Scrum.
4. Apertura: el Equipo Scrum y sus interesados acuerdan estar abiertos a todo el trabajo y a los desafíos que se les presenten al realizar su trabajo.
5. Respeto: los miembros del Equipo Scrum se respetan entre sí para ser personas capaces e independientes.
Consiste en un dueño de producto (Product owner), el Equipo de Desarrollo (Development team) y un Scrum Master. Es auto organizado y multifuncional. Entregan productos de forma iterativa e incremental.
Encargado de maximizar el valor y de gestionar la Lista de producto (Product backlog).
Es la persona que sabe y entiende cuáles son las necesidades de los usuarios, conoce el negocio de pies a cabeza y se encarga de transmitir ese entendimiento al equipo de desarrollo (o equipo solucionador). Por ello, ayuda a definir las prioridades del proyecto en función del valor a obtener y mantiene visible la información, de tal forma que las decisiones para optimizar el valor y controlar el riesgo se toman basadas en el estado percibido de los artefactos.
Está conformado por desarrolladores, quienes ejecutran el trabajo complejo más allá del código. Realizan las actividades del proyecto para crear y entregar en cada "sprint" un avance del producto terminado.
Son autoorganizados, en la medida en que ellos mismos deciden cómo convertir los elementos del product backlog en un verdadero incremento de producto a lo largo del sprint.
Juntos, como equipo, tienen todas las competencias y habilidades necesarias para crear el incremento. Esto se conoce como cross funcionalidad o multifuncionalidad, aclarando que no significa que todos sean especialistas en todo, pero sí pueden tener habilidades especializadas al servicio de la responsabilidad del equipo como un todo.
Todos los miembros del equipo son eso, miembros del equipo, no se reconocen títulos ni etiquetas ni tampoco subgrupos dentro del equipo de desarrollo.
Es un líder que está al servicio del Equipo Scrum y de la organización, ayudándoles a que entiendan y vivan la agilidad. Es el responsable de promover y apoyar Scrum, su teoría, prácticas, reglas y valores.
Es un líder que está al servicio del Equipo Scrum y de la organización, ayuda al Dueño de Producto a gestionar adecuadamente el product backlog, a entender la planificación en un entorno empírico
Conoce el estado del proyecto, se encarga de facilitar los eventos, se preocupa por que el equipo sea autogestionado y multifuncional y por su mejora continua, ayuda a remover obstáculos que puedan presentarse durante el trabajo y que puedan impedir lograr los objetivos y hace de muro de contención para cuando llegan las presiones externas.
Son bloques de tiempo para crear regularidad y minimizar la necesidad de reuniones innecesarias y no definidas en Scrum.
Cuando un equipo empieza un Sprint, su duración es fija y no puede ser menor o mayor a lo planeado. Por ello, hay cuatro reuniones o eventos para inspeccionar o adaptar algo del proyecto: Planificación del sprint (Sprint planning), Scrum diaria (Daily Scrum), Revisión del sprint (Sprint review) y Retrospectiva del sprint (Sprint restrospective). Saltarse alguna, es un error porque puede llevar a muchas fallas y reduce la transparencia.
El plan del sprint es creado por todos los miembros del equipo Scrum de forma colaborativa. En esta ceremonia se toman todas las historias de usuario priorizadas y se decide sobre cuáles hacer el Sprint tomando como base el objetivo del sprint y la capacidad del equipo. Se define qué puede entregarse en el Incremento resultante del Sprint que comienza y cómo se conseguirá hacer el trabajo necesario para entregar el Incremento. Si bien Scrum no establece un método para estimar es recomendable utilizar alguno, como por ejemplo, la estimación en puntos de historia para cada uno de los elementos del sprint backlog.
Es una reunión diaria, de máximo 15 minutos, con todos los integrantes del equipo de desarrollo para discutir el progreso que se ha tenido hacia el objetivo del Sprint y planear el trabajo para el siguiente día, entonces cada miembro responde para los demás miembros del equipo estas preguntas o algunas similares: ¿He cumplido con el compromiso que hice ayer para ayudar al Equipo a lograr el Objetivo del Sprint?, ¿qué compromiso haré hoy para ayudar al Equipo a lograr el Objetivo del Sprint?, ¿veo algún impedimento que evite que el Equipo de Desarrollo o yo logremos el Objetivo del Sprint?.
Se trata de una reunión informal, no de seguimiento. Al final del Sprint se lleva a cabo una revisión de este para inspeccionar el Incremento y adaptar la Lista de Producto, si fuese necesario. Durante la revisión del Sprint, el equipo y los interesados colaboran para determinar las siguientes cosas que podrían hacerse para optimizar el valor.
Asiste el Equipo Scrum completo y son invitados los interesados (stakeholders). Se explica brevemente qué cosas fueron terminadas y qué cosas no y de que manera se cumplió o no el objetivo del Sprint, haciendo una demostración del trabajo que se ha “Terminado”.
Se proyectan los objetivos probables para el siguiente Sprint (o los siguientes) tomando como base el product backlog, la retroalimentación acerca del incremento y el progreso obtenido hasta ahora.
Es una oportunidad para el equipo Scrum de inspeccionarse a sí mismo y crear un plan de mejoras que sean abordadas durante el siguiente Sprint.
El propósito de la Retrospectiva de Sprint es:
Aunque las mejoras pueden implementarse en cualquier momento, la Retrospectiva de Sprint ofrece un evento dedicado para este fin, enfocado en la inspección y la adaptación.
Representan el trabajo o valor en diversas formas que son útiles para proporcionar transparencia y oportunidades de inspección y adaptación.
Es una lista ordenada de todo lo que se conoce que es necesario en el producto. Es la única fuente de requisitos para cualquier cambio a realizarse en el producto. El Dueño de Producto (Product Owner) es el responsable de la Lista de Producto, incluyendo su contenido, disponibilidad y ordenación.
La Lista de Producto evoluciona a medida de que el producto y el entorno en el que se usará también lo hacen. cambia constantemente para identificar lo que el producto necesita para ser adecuado, competitivo y útil.
El refinamiento (refinement) de la Lista de Producto es el acto de añadir detalle, estimaciones y orden a los elementos de la Lista de Producto. Se trata de un proceso continuo en el cual el Dueño de Producto y el Equipo de Desarrollo colaboran acerca de los detalles de los elementos de la Lista de Producto.
El Equipo de Desarrollo es el responsable de proporcionar todas las estimaciones. El Dueño de Producto podría influenciar al Equipo ayudándoles a entender y seleccionar sus compromisos, pero las personas que harán el trabajo son las que hacen la estimación final.
Es el conjunto de elementos de la lista de producto seleccionados para el Sprint, más un plan para entregar el incremento de producto y conseguir el objetivo del Sprint.
Hace visible todo el trabajo que el Equipo de Desarrollo identifica como necesario para alcanzar el Objetivo del Sprint. Para asegurar el mejoramiento continuo, la Lista de Pendientes del Sprint incluye al menos una mejora de procesos de alta prioridad identificada en la Retrospectiva inmediatamente anterior.
Es la suma de todos los elementos de la Lista de producto completados durante el Sprint.
Recordemos que Scrum es liviano y fácil de entender, lo que no es tan fácil en mantenerse consciente de su esencia y no dejarse caer en el común error de aplicar una serie de prácticas solo por aplicarlas.
Las compañías que buscan innovar implementan marcos ágiles para crear mejores productos, servicios y experiencias que le brinden valor a los usuarios. Las industrias de todo el mundo, sobre todo de los sectores de educación, salud y tecnología usan Scrum para ofrecer a sus consumidores productos y servicios que faciliten sus vidas.
Así lo revela el estudio State of Scrum (2017-2018), que además, asegura que el trabajo en el mundo está cambiando rápidamente, con nuevas demandas tanto de los empleados como de los consumidores. Por ello, el verdadero poder de Scrum es mejorar directamente los resultados financieros e impulsar la cultura de trabajo, la satisfacción del cliente, la lealtad del cliente y la entrega de mejores productos y servicios a lo largo del camino.
Por ejemplo, las clínicas ágiles están salvando la vida de sus pacientes de una manera más estratégica y están mejorando la cultura en el lugar de trabajo. Desde que los médicos de la clínica de salud mental Monash Health, en Melbourne (Australia), adoptaron prácticas ágiles, la transformación del centro es sorprendente.
Melissa Casey, directora de psicología de Monash Health, quien participó en el estudio, le dijo a los investigadores de State of Scrum que desde que adoptaron prácticas ágiles, hay una mejora del 46 por ciento en las medidas de atención, en la satisfacción laboral de los proveedores y en tasas de enfermedades de licencia.
La clínica pudo mejorar sus sistemas de Tecnología de la Información (TI), proporcionó servicios más rápidos y eficientes sin comprometer la calidad; además pudo ofrecer atención inmediata en la urgencia, el diagnóstico, el tratamiento y la recuperación de sus pacientes. La estrategia es clasificar a los médicos y psicólogos, después de cada sesión médica con pacientes complejos, para usar en tiempo real la retroalimentación como una oportunidad para aprender, mejorar y brindar servicios a la medida de cada cliente. Para saber más, lee: Scrum también se aplica a la salud y a la política
En estas clínicas ágiles, las interacciones son valoradas más que los procesos. Hay un intercambio equitativo entre clientes, médicos y psicólogos. Tanto los médicos como los pacientes se adaptan al cambio en lugar de adherirse a protocolos rígidos.
El análisis State of Scrum (2017-2018), realizado por la firma Scrum Alliance, con una muestra de 2.000 personas de 27 industrias, ubicadas en 91 países del mundo, muestra que cuando se trata de elegir Scrum para un proyecto, el 71 por ciento de los ejecutivos está de acuerdo con que la entrega de valor al cliente es su mayor prioridad; seguido de flexibilidad y capacidad de respuesta; mejora del diseño y la cultura organizacional.
Si bien, las organizaciones eligen Scrum para entregar más valor para el cliente, también lo escogen para dar mayor bienestar a sus empleados. Precisamente, el 85 por ciento de los encuestados dice que Scrum ayudó a mejorar la calidad de la vida laboral.
En la siguiente gráfica verá cifras clave del estudio State of Scrum:
%2010.32.25%20a.%20m..png?width=500&name=Captura%20de%20Pantalla%202019-05-21%20a%20la(s)%2010.32.25%20a.%20m..png)
%2010.32.20%20a.%20m..png?width=500&name=Captura%20de%20Pantalla%202019-05-21%20a%20la(s)%2010.32.20%20a.%20m..png)
%2010.32.33%20a.%20m..png?width=500&name=Captura%20de%20Pantalla%202019-05-21%20a%20la(s)%2010.32.33%20a.%20m..png)
%2010.31.58%20a.%20m..png?width=500&name=Captura%20de%20Pantalla%202019-05-21%20a%20la(s)%2010.31.58%20a.%20m..png)
%2010.32.07%20a.%20m..png?width=500&name=Captura%20de%20Pantalla%202019-05-21%20a%20la(s)%2010.32.07%20a.%20m..png)
%2010.32.14%20a.%20m..png?width=500&name=Captura%20de%20Pantalla%202019-05-21%20a%20la(s)%2010.32.14%20a.%20m..png)
%2010.36.49%20a.%20m..png?width=500&name=Captura%20de%20Pantalla%202019-05-21%20a%20la(s)%2010.36.49%20a.%20m..png)
%2010.36.56%20a.%20m..png?width=500&name=Captura%20de%20Pantalla%202019-05-21%20a%20la(s)%2010.36.56%20a.%20m..png)
%2010.37.15%20a.%20m..png?width=500&name=Captura%20de%20Pantalla%202019-05-21%20a%20la(s)%2010.37.15%20a.%20m..png)
%2010.37.02%20a.%20m..png?width=500&name=Captura%20de%20Pantalla%202019-05-21%20a%20la(s)%2010.37.02%20a.%20m..png)
%2010.37.09%20a.%20m..png?width=500&name=Captura%20de%20Pantalla%202019-05-21%20a%20la(s)%2010.37.09%20a.%20m..png)
*Muestra: 2000 personas de 27 industrias, ubicadas en 91 países del mundo. State of Scrum
Una historia de usuario es una descripción sencilla y corta de una funcionalidad, creada con la perspectiva del usuario, el área de negocio y el cliente, quienes realmente saben qué necesitan y si el producto que se desarrollará será útil.
Por ello, a la hora de comenzar un proyecto, las necesidades del usuario deben escribirse y detallarse lo mejor posible para que el Product owner y el equipo de desarrollo estén en sintonía.
Para elaborar historias de usuario, antes de iniciar el desarrollo del proyecto con metodologías ágiles, se realiza una reunión (sprint planning) con el Product owner, los stakeholders y el equipo Scrum para definir las necesidades que tiene el proyecto.
Las consideraciones que se deben tener en cuenta al momento de redactar las historias de usuario son:
Independencia: una historia no puede depender de otra, ya que al momento del desarrollo pueden resultar muchos factores bloqueantes.
Negociables: deben ser ambiguas en su enunciado para poder debatirlas, no son propiamente un contrato así que deben dar espacio al momento de definir los alcances y limitaciones de la misma.
Valoradas: deben definir cuánto valor le aportan al proyecto del cliente, cuál aporta más que otra.
Estimable: se debe poder predecir el tiempo que le tomará a la persona hacerla realidad.
Pequeñas: las historias son complicadas de estimar y si tenemos historias muy grandes, el grado de dificultad aumenta, por lo que se recomienda dividirlas en historias más pequeñas.
Verificables: tener los criterios de aceptación ayuda a la persona que la lleva a cabo, saber si la ha realizado correctamente.
Una vez tengamos redactadas todas las historias de usuario correspondientes al proyecto y cuando el cliente ya esté satisfecho, pasamos a un proceso conocido como priorización de historias.
En dicho paso, el Product owner inicia una discusión sobre qué historias le añaden un valor más inmediato al proyecto. De esta forma, deciden cuáles historias deben llevarse a cabo antes que otras. Así, tenemos las historias redactadas y priorizadas.
Cuando se tienen proyectos de mucho alcance o muy grandes, no es práctico tener un montón de historias priorizadas, pues el desperdicio de tiempo puede ser enorme. Es por eso que se hace uso de un elemento conocido como “release”: el conjunto de varias historias de usuario priorizadas. Lee: qué no debería tener una historia de usuario
La cantidad de historias para cada “release” va a depender del valor que las historias aporten al proyecto, según el usuario. El refinamiento de historias de usuario ocurre por primera vez en la definición del product backlog y se repite iterativamente a lo largo del desarrollo del proyecto.
En esta primera vez debemos tomar las historias cuyas características nos indiquen que son muy grandes, que estimarlas será muy complicado y que deben ser divididas para poder elaborarlas. En síntesis, en eso consiste el proceso de refinamiento.
Una vez tengamos las historias de usuario redactadas, refinadas, priorizadas y divididas en “releases”, hemos hecho todos los pasos para obtener así nuestro product backlog.
Si quieres saber más sobre el marco de trabajo Scrum, escucha la explicación de Carlos Palacio, agile Coach de Pragma.
Ciudad del Saber,
Edificio #104, Clayton, Ancón.
Panamá.
