Scrum
Antipatrones de Scrum: Scrum but
Scrum no funciona. He escuchado esta frase muchas más veces de las que me gustaría admitir,
aunque la realidad es que, cuando profundizamos en cómo estos equipos llevan Scrum en su día a día, salen a flote diversas prácticas que desvirtúan Scrum, prácticas que se llevan a cabo de manera incorrecta (de manera intencional o no intencional), y por lo tanto un efecto aparente es que Scrum “no está funcionando”, cuando la causa raíz es, en realidad, una mala práctica, o lo que se conoce como un **antipatrón**.
Scrum un marco de trabajo, pero más que eso, hoy siendo las 5:34 a.m. del 8 de julio de 2024, continúa siendo **el marco de trabajo más utilizado en el mundo**, no lo digo yo, lo muestran los diversos estudios anuales sobre Agilidad o Agilismo que se publican por diversas organizaciones.
Scrum establece una forma de colaborar evaluando de manera continua cómo construir un producto (o servicio), obtener retroalimentación del cliente/usuario final, y adaptar creativamente en base a la información obtenida siempre centrados en entregar un incremento de producto que agregue valor al cliente/usuario final.
En este artículo no abordaremos lo que Scrum es, no es un artículo introductorio (si quieres leer un poco sobre los principios de Scrum, (link: https://leonelzapien.com/blog/que-es-scrum text: te comparto aquí un artículo que escribí sobre este tema hace un par de años)), aquí abordaremos sobre eso que “no es Scrum”, esos antipatrones que desvirtúan el marco de trabajo y consecuentemente llevan a equipos a sufrir el proceso y concluir que “Scrum no funciona”.
(image: scrum-logo.webp)
# Anti… ¿qué?
Aquí abro un breve paréntesis.
Primero lo primero, no sé si conozcas el término **antipatrón**, pero vamos iniciando aquí. Un antipatrón es un enfoque que nos va a conducir a una mala solución a un problema, pueden ser en ocasiones enfoques “generalizados” o que se utilicen ampliamente, pero, aun así, no deja de ser una solución inadecuada y por lo mismo son ineficaces y/o improductivos para resolver determinada clase de problemas comunes.
Una vez aclarado lo anterior, ya hemos calentado motores, entremos directo en tema sobre de antipatrones en Scrum, ¡Aquí vamos!
Cierro paréntesis.
# Scrum but
Hoy vengo a platicarte sobre algo que se conoce como **Scrum but…**, que traducido sería algo como **Scrum pero…**, y se le conoce así precisamente porque, cuando a alguien le preguntan:
- Y ustedes, ¿utilizan Scrum?
- ¡Claro que sí!
- ¿Y cómo les va con *[inserte-aquí-cualquier-tópico-relacionado-con-Scrum]* (por ejemplo, las retrospectivas / producto backlog / incrementos de producto / la definición de terminado, etc.)?
- Ah, bueno. Es que sí utilizamos **Scrum, pero…** *[inserte-aquí-cualquier-“parche”-o-forma-de-hacer-algo-que-no-está-alineado-con-La-Guía-Scrum]*
Y ahí es donde surge el “pero”, es ahí donde, como decimos acá en México, la puerca torció el rabo.
Por esto, hoy hablaremos sobre **Scrum but,** ya que esta lista de “peros” puede ser virtualmente infinita, vamos a ver algunos de los principales ejemplos que he tenido oportunidad de ver de primera mano en diversos equipos, así como posibles soluciones.
Un tiene la siguiente estructura:
**Scrum + pero + Antipatrón + Forma alternativa de “solucionar” la situación**
(image: leonel-zapien-lopez-ideas-agilidad-agilismo-scrum-but-estructura-antipatron-cursos-consultor-guadalajara-mexico.webp)
¿Estás listo? ¡Ponte cómoda o cómoda y relájate, no lo tomes personal si con algunos de estos antipatrones sientes que “le queda el saco a tu equipo”, cualquier parecido con la realidad es mera coincidencia!
## Antipatrón #01: El Daily eterno
(image: leonel-zapien-lopez-ideas-agilidad-agilismo-scrum-but-antipatron-antipatrones-01-guadalajara-mexico.webp)
**Usamos Scrum + pero… + hay demasiados temas por conversar en nuestra Daily + así que, en vez de 15 minutos, este evento dura entre 45 minutos y 1 hora.**
Este es por mucho el antipatrón que más comúnmente he visto, pero así mismo, es de los más sencillo de reenfocar.
Primero lo primero, ¿Cuál es la esencia del Daily Scrum? De acuerdo con La Guía Scrum, el Daily Scrum es un evento de hasta 15 minutos para los Desarrolladores del Equipo Scrum. Para reducir la complejidad, se lleva a cabo a la misma hora y en el mismo lugar todos los días hábiles del Sprint.
¿Cómo podemos ayudar al equipo a que se cumpla el bloque de tiempo (timebox) de 15 minutos?, aquí te comparto uno tip súper simple y no por eso menos poderoso:
• Utilizar un** Estacionamiento de temas** o **Parking lot**, donde podemos “estacionar” los temas que surjan durante el Daily que necesiten conversarse, la idea es no resolver los problemas durante el Daily, sino identificarlos, y posteriormente conversarlos solo con las personas directamente implicadas, puede ser de manera inmediata al terminar el Daily (algunos le llaman a esto post-Daily), o en algún momento posterior. La esencia es no alargar el Daily, y que, cuando se vaya a conversar, solo se involucre a las personas necesarias y no a todo el equipo.
## Antipatrón #02: Saltarse la retrospectiva
(image: leonel-zapien-lopez-ideas-agilidad-agilismo-scrum-but-antipatron-antipatrones-02-guadalajara-mexico.webp)
**Usamos Scrum + pero… + tenemos tanto trabajo al final del Sprint + que mejor aprovechamos el tiempo de la retrospectiva para trabajar en lo que tengamos pendiente.**
Este antipatrón me recuerda el meme de un cavernícola que está empujando una montaña de piedras sobre una carreta con “ruedas cuadradas”, claro que va sudando a chorros y sufriendo tremendo, mientras un segundo cavernícola le muestra una “rueda redonda” diciéndole que su invento le va a hacer la vida más fácil, y el primer cavernícola solo puede responder con el poco aire que le queda: “No tengo tiempo, estoy muy ocupado jalando esta carreta”.
Tristemente, es el segundo antipatrón más común que he visto, donde los equipos no se dan el tiempo de hacer una pausa para analizar el último periodo de trabajo o Sprint, y reflexionar sobre cómo pueden mejorar.
La Guía Scrum menciona que “El Equipo Scrum inspecciona cómo fue el último Sprint con respecto a las personas, las interacciones, los procesos, las herramientas y su Definición de Terminado. El Equipo Scrum analiza qué salió bien durante el Sprint, qué problemas encontró y cómo se resolvieron (o no) esos problemas.”
Sin estos espacios para identificar los principales problemas que afectaron el equipo, sin conversaciones que les puedan ayudar a mejorar su efectividad, no se puede llegar a la mejora continua. Cada evento en Scrum tiene un propósito específico, en este caso, la retrospectiva fomenta este espacio para detenernos a “Afilar la sierra”, por más ocupados que estemos es fundamental tener y fomentar estos espacios, así como escuchar todas las voces, priorizar los elementos que se identifiquen en base a su posible impacto, y darles seguimiento.
## Antipatrón #03: Un día sí, y al otro día quién sabe
(image: leonel-zapien-lopez-ideas-agilidad-agilismo-scrum-but-antipatron-antipatrones-03-guadalajara-mexico.webp)
**Usamos Scrum + pero… + tener el Daily todos los días quita demasiado tiempo + así que tenemos el Daily Scrum un día a la semana.**
El evento Daily Scrum debe de ser diariamente. Un antipatrón que tiene un impacto muy negativo en el potencial que marco Scrum puede ofrecer es el no tener los Daily ahora sí que dice la palabra, diariamente. He tenido oportunidad de coincidir con equipos que tienen los Daily en frecuencias distintas a lo definido en La Guía Scrum: 1 vez a la semana, o cada tercer día, por mencionar algunos ejemplos.
Entre las principales razones para hacer esto (la verdad debo de confesar que se puede dedicar mucho esfuerzo y creatividad para justificarlo muy bien), he escuchado cosas como:
• Es muy costoso detener a todo el equipo de trabajar, todos los días.
• Nuestro proceso es muy estable, no necesitamos reunirnos a diario.
• Es un desperdicio de tiempo.
• Mejor nos reunimos cuando surja algo.
• Entre otras cosas.
¿Te suena familiar?
La Guía Scrum menciona que el Daily Scrum se lleva a cabo a la misma hora y en el mismo lugar todos los días hábiles del Sprint, el Daily es una oportunidad para inspeccionar y adaptar el plan para lograr el objetivo del Sprint, y este es precisamente el sustento por el cual debe de realizarse diariamente, ya que trabajamos en entornos con alta volatilidad e incertidumbre, así mismo los productos o servicios que construimos, y las personas que colaboramos para construirlos, somos complejos. Hay infinitas variables que pueden afectar a un equipo, algo puede afectarnos durante un sprint, solo para asentarlo y nombrar algunas a manera de ejemplo:
• Una persona se ha enfermado y no tenemos capacidad para realizar lo que él o ella hacía.
• Para realizar algo en particular, acabamos de darnos cuenta de que se requiere un recurso específico (una licencia de un determinado software, un servidor, un servicio o proveedor, etc.), y se necesita conseguir a la brevedad posible, o bien, ver alguna opción alterna.
• Ha surgido un defecto que es urgente solucionar.
• Determinada situación ha provocado escasez o tiempos de entrega más largos de algún insumo.
• Acaba de surgir una nueva pandemia, situación social que ha afectado al entorno del equipo, un apocalipsis zombi, etcétera y etcétera.
La inspección frecuente permite la adaptación temprana, este es uno de los propósitos del Daily, identificar de manera oportuna problemas, riesgos, bloqueos que puedan presentarse, por eso la importancia de que sea diariamente, para proporcionar un ritmo o cadencia al equipo, y termina formando parte de los hábitos del equipo, por eso debe de celebrarse todos los días a la misma hora y en el mismo lugar (o en utilizando el mismo link de reunión recurrente, en caso de ser de manera remota), para de esta manera reducir la complejidad que implica el estarla reprogramando o moviendo de lugar (físico o remoto).
## Antipatrón #04: Sin retroalimentación real
(image: leonel-zapien-lopez-ideas-agilidad-agilismo-scrum-but-antipatron-antipatrones-04-guadalajara-mexico.webp)
Usamos Scrum + pero… + nuestro cliente/usuario final está muy ocupado y no tiene tiempo para atender las Revisiones del Sprint + así que le enviamos un correo para informarle de las funcionalidades que se liberarán.
La revisión del Sprint es un evento que, de acuerdo con La Guía Scrum, tiene como propósito inspeccionar el resultado del trabajo realizado durante el Sprint, y en base a esto, determinar futura adaptaciones. Aquí el punto clave es que el Equipo Scrum presente los resultados de su trabajo a los interesados clave y se discuta el progreso hacia el Objetivo del Producto.
Pero, ¿Quiénes pueden ser interesados clave?
La verdad es que depende del contexto, de entrada, es imprescindible que esté ahí el cliente / usuario final, esa persona quien finalmente va a utilizar nuestro producto. Lo que queremos es que este cliente / usuario final pruebe el producto, lo vea funcionar, lo tenga entre sus manos, le haga clic y vea qué hace… y en base a su experiencia con este incremento de producto real, nos proporcione retroalimentación valiosa que nos permita determinar si vamos bien, hacemos algunos ajustes, o definitivo no es por este camino y debemos girar el timón.
Esta figura de cliente / usuario final es fundamental, pero aunado a esto y dependiendo del contexto, un interesado clave puede ser un determinado gerente, director, el patrocinador del proyecto o producto, inclusive dependiendo del caso, alguna figura externa como un proveedor, o algún representante de un organismo o grupo.
Debido a todo esto, una Revisión de Sprint sin los interesados relevantes y sin esta figura principal que es el cliente / usuario final que viva en primera persona la experiencia del incremento de producto que el Equipo Scrum ha construido durante el Sprint, sin ellos, una revisión de Sprint carece totalmente de sentido.
La Guía Scrum menciona también que, durante la Revisión del Sprint, el Equipo Scrum y los interesados revisan lo que se logró en el Sprint, conversan sobre lo que ha cambiado (prioridades, alguna cuestión del entorno, etc.), con base en esta información y con la experiencia de probar el incremento de producto, los asistentes a este evento colaboran para determinar qué hacer a continuación. Esto es fomenta un ambiente donde se transpiran los pilares de Scrum: Transparencia, inspección y adaptación.
## Antipatrón #05: No necesitamos un Scrum Master
(image: leonel-zapien-lopez-ideas-agilidad-agilismo-scrum-but-antipatron-antipatrones-05-guadalajara-mexico.webp)
**Usamos Scrum + pero… + no necesitamos un Scrum Master, el equipo ya sabe Scrum + así que el resto del equipo cubre las actividades del Scrum Master.**
La Guía Scrum define que el Scrum Master es responsable de establecer Scrum como se define en la Guía de Scrum. Lo hace ayudando a todos a comprender la teoría y la práctica de Scrum, tanto dentro del Equipo Scrum como de la organización.
Un tema algunas veces controversial es, ¿Y qué hace el Scrum Master todo el tiempo?, es normal que esta pregunta surja sobre todo cuando el equipo Scrum ya tiene cierto grado de madurez y se puede decir que el equipo “ya sabe” Scrum. Pero el Scrum Master hace (o debería de hacer) muuucho más que eso, apoya al equipo Scrum (Desarrolladores y Product Owner), así como a la organización.
La Guía Scrum menciona que el Scrum Master es responsable de lograr la efectividad del Equipo Scrum, por lo tanto, es el responsable final de que el equipo mejore continuamente, y siendo completamente honestos, esto implica **ver más allá de Scrum**, complementar con otras herramientas, métodos, prácticas, metodologías, etc., probar, experimentar, ayudar al equipo a descubrir nuevas formas de reducir los despilfarros o desperdicios, avanzar hacia mejores formas de colaborar. Esto puede incluir, por citar algunos ejemplos, complementar Scrum con **Kanban**, Pensamiento** Lean**, utilizar **Estructuras Liberadoras** para facilitar las sesiones ayudar a descubrir problemas, así como fomentar conversaciones, agregar prácticas de **Management 3.0** para centrarnos en las personas, prácticas de **Extreme Programming**, **Agile / Lean Inception**, **Lean Startup**, y una lista infinita de etcéteras y etcéteras.
Por lo tanto, el Scrum Master es esencial, y si esta responsabilidad o rol (o cualquiera de los otros dos) no está, realmente no estamos trabajando con Scrum.
¿Cómo sabemos qué tal está haciendo su trabajo el Scrum Master?, su trabajo se ve indirectamente, se refleja en la forma en que el Equipo Scrum se está desempeñando, por eso es imprescindible esta figura para, como dice (link: https://agilemanifesto.org/ text: El Manifiesto Ágil): Continuar descubriendo mejores formas de trabajar.
# Conclusiones
Creo que una lista de antipatrones conocidos o potenciales en Scrum es virtualmente infinita, los cinco que he mencionado aquí creo que son algunos de los que he tenido oportunidad de ver de manera más recurrente. Lo triste del asunto es que este tipo de prácticas llevan a personas y equipos a sentir frustración porque **“Scrum no funciona”**, cuando la causa raíz es que se está llevando a cabo de una manera que no permite que los verdaderos super poderes de Scrum se muestren con todo su esplendor.
Scrum define cómo un equipo autogestionado podría estructurar mejor su trabajo para ofrecer incrementos de producto y crear el mayor valor posible para todas las partes interesadas, funciona muy bien donde se trabaja con alta complejidad, donde existe alta incertidumbre, donde los requisitos del producto no están claros. De verdad que Scrum puede aportar enorme apalancamiento en todo esto.
Solo, hay una consideración, y no es una que me haya inventado, sino que viene mencionada en la página 13 de La Guía Scrum 2020 (es la guía más reciente y, por lo tanto, la que está vigente). Dice lo siguiente:
“El marco de trabajo Scrum, como se describe aquí [en La Guía Scrum], es inmutable. Si bien es posible implementar solo partes de Scrum, **el resultado no es Scrum**. Scrum existe solo en su totalidad y funciona bien como un contenedor para otras técnicas, metodologías y prácticas.”
Así que podemos complementar Scrum con otros métodos, prácticas, herramientas, metodologías… pero no podemos “quitarle” cosas a como Scrum viene definido. Requiere de sus 3 roles, 5 eventos y 3 artefactos, tal y como se definen en La Guía Scrum. Cuando lo lleves a tu equipo, es esencial que lo acotes a tu contexto, experimentando lo que mejor funciona, pero dentro de lo que es válido para este marco de trabajo.
Nunca dejemos de experimentar hacia la mejora continua, los resultados, más temprano que tarde, siempre, siempre, siempre llegan.
**¿Qué opinas de estos antipatrones?, ¿Qué otros antipatrones agregarías?**
8 de julio de 2024
