Todo sobre Scrum
Por Vanessa Amaya
Lo más importante que debes de saber para iniciar o para aclarar sobre Scrum. Este blog está inspirado en las preguntas más frecuentes que me han hecho en los 10 años en los que me he dedicado a dar cursos y charlas sobre este marco ágil tan popular.
¿Cuál es el origen?
“Grandes descubrimientos y mejoras implican invariablemente la cooperación de muchas mentes.” Alexander Graham Bell
Alguna vez escuché una frase que decía que no hay inventos, solo descubrimientos. Al final, el conocimiento es un resultado colectivo.
Se crea como marco de trabajo a partir de 1993, cuando Jeff Sutherland y Ken Scwaber se unen para proponer una nueva forma de hacer las cosas en el desarrollo de software porque hasta ese momento, la mayoría de los proyectos de desarrollo de software se hacían con la metodología de cascada que en su mayoría no tenía los resultados esperados, se completaban los proyectos en etapas separadas y muy largas que terminaban en retrasos de meses (y con frecuencia años) resultando en productos que la gente terminaba por no necesitar.
Dos de las principales influencias de Jeff Sutherland fueron Rodney Brooks, un Profesor de inteligencia artificial del MIT y su interés por hacer una tesis que lo hizo buscar información sobre cómo una célula se vuelve cancerosa y se metió en el mundo de las reglas de los sistemas adaptativos complejos.
¿Qué es Scrum?
Scrum es un marco que ayuda a los equipos a generar valor a través de soluciones adaptables para problemas complejos.
Scrum se basa en:
Empirismo: Implica basarse en la experiencia y en la observación de los hechos.
Pensamiento Lean: Implica enfocarse en reducir desperdicios y centrarse en lo esencial. El desperdicio es todo lo que no genera valor, es decir, todas actividades y recursos, que se podrían omitir en nuestro día a día, sin afectar la calidad de nuestros entregables.
Enfoque iterativo: Trabajar en periodos donde se revisa y se mejora el entregable.
Enfoque incremental: Trabajar por partes el producto grande, para ir integrando a medida que se van completando dichas partes.
¿Qué significa la palabra “Scrum”?
La palabra Scrum no es un acrónimo, es una referencia un equipo de rugby en una jugada que lleva ese nombre. Inspirados en un estudio de dos profesores japoneses llamados Hirotaka Tekeuchi e Ikujiro Nonaka que publicaron en 1986 un estudio que se llamó “The New Product Development Game” (El nuevo desarrollo de productos). Estos dos profesores habían estudiado equipos de empresas productivas y muy innovadoras y comparaban el trabajo en común con un equipo de rugby en una jugada de Scrum.
Cuando en 1995 Jeff Sutherland y Ken Schwaber presentan esta nueva forma de trabajar la presentaron como “SCRUM Development Process” (Proceso de desarrollo con SCRUM). Como también este marco ha tenido sus iteraciones y aplicación del pensamiento Lean, conforme pasaron los años se le quitaron palabras y mayúsculas y por ello ahora se conoce como “Scrum”.
¿Metodología Scrum o Marco de trabajo Scrum?
Popularmente se conoce Scrum como una metodología, pero no porque lo sea, sino porque es más popular el concepto de metodología que el de marco de trabajo.
Una metodología es un conjunto de procedimientos para lograr un objetivo. Este concepto nace de su aplicación en la investigación científica pero se empezó a usar en otros rubros también.
Un marco de trabajo es conjunto estandarizado de conceptos y criterios para enfocar un tipo de problemática particular que sirve como referencia, para enfrentar y resolver nuevos problemas.
Por lo tanto, Scrum es un marco de trabajo porque no tiene procedimientos repetibles sino criterios para enfocarse dentro de un contexto de incertidumbre, es decir, aquel que está altamente susceptible a cambios. El cambio es esperado, no se analiza cuando sucede o se cambia el plan cuando el cambio aparece. Scrum asume que va a haber descubrimientos que lleven a cambios en cada periodo.
Mi hipótesis de porque a pesar de tantos años, se sigue hablando de la Metodología Scrum, es porque es más fácil aceptar un procedimiento pensando en que vamos a tener recetas o procesos repetibles que recibir una forma de trabajo enfocada a la adaptación.
A las personas se nos dificulta manejar la incertidumbre a pesar de que ésta, es parte esencial de la vida. Preferimos rutinas y recetas cuando la complejidad es demasiado grande.
¿Qué necesitamos para habilitar Scrum?
Lo primero es cambiar el enfoque de la planeación, esto es el primer paso y como todo primer paso es difícil pero al hacerlo bien, los demás pasos fluyen.
En mi experiencia el primer paso con Scrum es cambiar la forma de planear. En Scrum la planeación es a corto plazo, teniendo presente que por el enfoque incremental, alcanzaremos un objetivo a largo plazo pero nos moveremos en plazos cortos, estos plazos cortos son el corazón de Scrum y se les llama Sprints y éstos periodos duran entre 2 y 4 semanas.
También necesitamos tener habilitadas las 3 responsabilidades de Scrum, así que en el equipo deben de estar:
Scrum Master - es responsable de la efectividad del equipo (Scrum Team). Y puede lograr hacerlo al ayudar a que el equipo Scrum mejore sus formas de trabajar, dentro del marco de Scrum.
Product Owner - Quien funja como Propietario del Producto es responsable de que el equipo genere valor. Especifica y aclara lo suficiente para que lo que se construya esté alineado a los objetivos del producto.
Scrum Developers - Los desarrolladores son las personas del equipo Scrum que se comprometen a crear cualquier aspecto de un Incremento útil (funcional, entregable) en cada Sprint. Es todo ejecutor o como les digo yo, los “hacedores de realidades”. El término developers se asocia a quien crea las partes de los productos y ya no se asocia solo al rol del desarrollo de software.
Necesitamos en cada Sprint, hacer los eventos de Scrum
Inicia el Sprint con el evento de Planeación o Sprint Planning. Este evento tiene como objetivo activar la planeación colaborativa. De todos los eventos de Scrum, este es el que he visto que más trabajo cuesta, porque rompe muchos paradigmas ya que la transición de la forma de planear en la metodología tradicional es totalmente diferente.
Dejamos la planeación exhaustiva y nos vamos a planeación a corto plazo.
Olvidamos la planeación de juicio experto y le regresamos la voz y opinión a quién realiza el trabajo.
Cada día se hace un evento diario (Daily Scrum) para poder mantener el objetivo vivo y hablar de lo que el equipo va descubriendo mientras avanza, estos descubrimientos incluyen impedimentos, todo aquello que los hace ir más lento de lo planeado o que los detiene. Por ser usado Scrum en entornos de incertidumbre asume que tiene que haber ajustes en el camino así que este evento ayuda a que los ajustes se hagan de manera temprana.
Se revisa lo hecho en el Sprint con un evento de revisión (Sprint Review) Este evento tiene como objetivo revisar el resultado del Sprint y determinar en equipo las futuras adaptaciones. En este evento se invitan a involucrados relevantes y se habla sobre el progreso hacia el objetivo del producto.
Y para cerrar el Sprint y antes de irnos de nuevo a planear el siguiente, se hace el evento para enfocarse en la mejora contínua del equipo (Retrospective). Este evento se enfoca en el equipo, en analizar las formas para aumentar calidad y eficacia a través de conversaciones y revisiones sobre cómo les fue en el sprint con respecto a sus interacciones, sus procesos, sus herramientas y su definición de hecho.
La Definición de Hecho es una descripción formal del estado del Incremento cuando cumple con las medidas de calidad requeridas para el producto
Aprovecho para aclarar, que el término oficial no es “ceremonias de Scrum”, esto se empezó a usar dentro de algunas comunidades de agilidad, pero el término que viene en la guía es “eventos”. Recientemente también he escuchado algunos que les dicen “las rutinas de Scrum”.
¿Cuáles son los principales retos de las responsabilidades de Scrum?
Product Owner: Filtrar y priorizar el trabajo. Filtrar la información que necesita el equipo para entender y desarrollar el producto ya que al ser “la voz del cliente” su voz se alimenta de muchas otras voces y muchos conocimientos. Y también el reto es priorizar el trabajo orientado al valor, ya que, con frecuencia la priorización es inexistente o los criterios de priorización no están claros o no son eficientes.
Scrum Master: Facilitar el trabajo. No caer en la tentación de ser intermediario entre Product Owner y Developers, no ponerse en medio sino facilitar la comunicación y el entendimiento. Muchos creen que facilitar solo tiene que ver con coordinar juntas y no es así, es parte del trabajo pero no es lo único. Aparte de facilitar el trabajo en equipo y el entendimiento, también facilita el conocimiento de Scrum y su adaptación dentro del equipo.
Scrum Developers: Realizar el trabajo colaborativamente. Trabajar en equipo entre ellos y con los Product Owners. En Scrum, todos los que realizan el trabajo son Developers, esto incluye a aliados y proveedores también. Scrum no distingue en qué área o equipo están, si son quienes hacen realidad el mismo producto, todos son del mismo equipo y todos son developers.
Se les conocía como los roles en Scrum sin embargo, en la guía actualizada en noviembre del 2020, se hace énfasis al término “responsabilidades”. Mi teoría sobre este cambio es ir más allá del rol, ya que en muchos lugares solo le cambian de nombre al rol esperando que con ese cambio sea más que suficiente y haga magia en la transición de las personas en la forma de trabajar. Y cambiaban de nombre de rol pero seguían actuando igual o trabajando doble, haciendo lo de siempre y pretendiendo hacer lo que Scrum les pide.
¿Por qué si es simple se dificulta llevarlo a cabo?
Porque aunque en definición es simple y sus conceptos son fácilmente entendibles, para llevarlo a cabo tenemos que pasar por una transición. La transición implica cambios que impactan a años de costumbres y hábitos distintos. En esa transición se puede caer en dos tentaciones principales:
Hacer dos disciplinas a la vez: Es decir, no soltar la metodología tradicional y hacer al mismo tiempo un marco ágil. Esta decisión deriva en retrabajo y frustración ya que ambas son disciplinas y exigen diferentes conocimientos y acciones por lo que es muy fácil crear (o aumentar) la carga de trabajo.
Es tan simple que es un contenedor, tiene una estructura pero no tiene prácticas. Está incompleto. Y esto no lo digo yo, lo dicen sus creadores y viene en la página 4 de la guía:
“El marco de Scrum es deliberadamente incompleto, solo define las partes necesarias para implementar la teoría de Scrum. Scrum se basa en la inteligencia colectiva de las personas que lo utilizan. En lugar de proporcionar a las personas instrucciones detalladas, las reglas de Scrum guían sus relaciones e interacciones. En el marco se pueden emplear diversos procesos, técnicas y métodos. Scrum envuelve las prácticas existentes o las hace innecesarias.”
El texto anterior es para mí de los más importantes, sobre todo por destacar la relevancia de la inteligencia colectiva y aclarar que dentro de Scrum se pueden aplicar las técnicas y métodos que se necesiten.
Mis prácticas favoritas para complementar Scrum son las relacionadas con: Agile Business Analysis (Análisis de Negocio ágil), Método Kanban y eXtreme Programming.
¿Certificación o no certificación?
Tomando en cuenta que el nombre de Scrum viene de una jugada de rugby y que para realizar esta jugada el equipo tiene que estar debidamente capacitado, traslado este concepto a las necesidades de formación con respecto a Scrum:
Podemos adquirir conocimientos de un blog o de un video, sin embargo, la capacitación para mí es relevante no por el conocimiento en sí mismo sino por la transición en las formas de trabajo y de las dudas que surgen en las personas al realizar esta transición.
Hablar desde la teoría de Scrum (casi) cualquiera puede, para vivir ayudar en la transición es indispensable hablar desde la experiencia.
Una certificación es una forma de capacitación y en la actualidad hay muchas formas de certificarse solo que, por todo lo comentado en este Blog lo que te recomiendo es:
Al elegir una capacitación o certificación considera:
La institución que respalda la capacitación o la certificación. Cuántos años tiene de existir, qué plataforma ha creado para sus estudiantes para facilitar el aprendizaje contínuo.
La empresa que respalda la capacitación o la certificación. Porque dichas instituciones a veces dan la capacitación directamente pero muchas otras veces es a través de Partners o Aliados.
Quién imparte el curso. Recuerda que a quien le permites transmitirte conocimiento le abres una puerta enorme en tu vida profesional, así que averigua quién imparte el curso y busca información de esa persona: ¿dónde ha ejercido Scrum? ¿Desde cuándo ejerce proyectos con Scrum? ¿Hay algún escrito (Blog) o libro de esa persona publicado? ¿Participa en eventos dando conferencias?
Conclusión
Scrum sigue siendo el marco ágil más popular, su corazón, su esencia es el Sprint y sus eventos funcionan cuando se aplican los siguientes pilares: transparencia, inspección y adaptación. En la guía se menciona que aunque la implementación de sólo algunas partes de Scrum es posible, el resultado final no es Scrum. Así que aplica partes de Scrum o aplícalo todo, pero aplícalo.
Lee la guía oficial aquí.
Por Vanessa Amaya
