Scrum es un marco ágil utilizado por la gran mayoría de las empresas de consultoría, profesionales de IT independientes y departamentos de IT en todo el mundo. A pesar de su uso generalizado, existen muchos errores y malentendidos sobre su aplicación en casos y entornos reales. Este artículo presentará una breve descripción de qué es Scrum, dónde es aplicable, dónde no, sus beneficios, algunos problemas comunes, las razones detrás de ellos y soluciones basadas en la experiencia.

Introducción

Entendemos que todos trabajamos en estructuras muy complejas, con fuerzas igualmente complejas empujando unas contra otras, por lo que la aplicación del marco puro y “fuera de la estantería” no siempre es posible. Dicho esto, al igual que con una vara de bambú, podemos doblar el marco, pero entendemos que en un punto se romperá. El propósito de este artículo es resaltar los desafíos comunes que enfrentan las organizaciones al adoptar o implementar Scrum y mencionar experiencias pasadas para superarlos.

Qué es Scrum?

Scrum es un marco ágil para el desarrollo de software.

Qué significa eso?

Ágil: el poder de moverse rápido y con facilidad; rapidez. Se refiere a la capacidad de pensar y sacar conclusiones rápidamente; con agudeza intelectual. Y lo más importante, una mentalidad de responder al cambio con un “hacerlo mejor que perfecto”. Framework: conjunto estándar de conceptos, buenas prácticas y criterios para abordar problemas específicos, que funciona como referencia para enfrentar y resolver nuevos problemas de características similares. Así que, Scrum es un lienzo en blanco con algunas reglas, que puede ponerse en práctica de la mejor manera que veamos, pero sin romper esas reglas. A menudo, Scrum se malinterpreta, malinterpreta o aplica de forma incorrecta, añadiendo complejidad adicional a su complejidad inherente. Se dice que “Scrum es fácil de entender pero difícil de dominar”. Antes de empezar, deberías asegurarte de que realmente no conoces los requisitos, si el equipo va a contar con alguien para aclarar cualquier duda que pueda surgir, y si realmente necesitas incrementos de valor a intervalos regulares. Y por favor hazte esta pregunta: ¿conoces Scrum, o crees conocerlo?

Beneficios sobre marcos “tradicionales”

Existen ciertos beneficios en la implementación de Scrum, y estos han contribuido a su uso generalizado, mientras que, por otro lado, generan algunos de los problemas que veremos a continuación. Tiempo de lanzamiento al mercado más rápido: a medida que los resultados entregables aparecen pronto en el ciclo de vida del producto, sin esperar un lanzamiento “big bang”. Mejora de la calidad: el alcance para probar y validar es menor en cada iteración. Reducción de riesgos: el producto se valida de forma iterativa, con el mercado o los usuarios finales guiando la siguiente fase, ayudando con la tracción y la adopción. MVPs/MLPs/MMPs orgánicos: ¿quieres un Producto Mínimo Viable (MVP), un Producto Mínimo Amable (MLP) o un Producto Mínimo Comercializable (MM P)?

Problemas encontrados en la aplicación de Scrum y cómo los solucioné

He descubierto, tras varios años de experiencia implementando Scrum, que los problemas se pueden catégorizar como se detalla a continuación.

Resistencia organizacional

En empresas con una cultura jerárquica, algunos gerentes son reacios a compartir la toma de decisiones y evitan decir “no lo sé”, por lo que se sienten con la pérdida de poder. Por otro lado, puede haber inmadurez en la ejecución de proyectos en equipos acostumbrados a que se les diga qué hacer. Incentiva a los gerentes a adoptar un enfoque de líder servidor, involucrar a la dirección desde el inicio del proceso y proponer una “prueba” donde solo evalúen el resultado. Por otro lado, muestra al equipo que ahora pueden hacerlo como se sientan más cómodos, y la oportunidad de brillar está en ellos.

En cuanto al miedo al cambio, todo el equipo y los interesados de la empresa necesitan entender y aprender a amar el concepto de responsabilidad compartida y trabajo independiente; sin temer lo desconocido o preocuparse por interrupciones potenciales de procesos establecidos. Para calmar los miedos y aumentar la confianza, se pueden establecer puntos de control y métricas para detectar desviaciones. También explique en detalle las razones y beneficios detrás de cada paso y resultado, fomentando puertas abiertas y la discusión de preocupaciones. En especial en empresas pequeñas o en aquellas que están cambiando de mentalidad, he observado casos de optimismo excesivo o resistencia causada por preconceptos infundados. Cosas como “oí que Scrum”, “un amigo implementó Scrum y XYZ” o “Google no usa Scrum, ni Facebook ni Amazon” abunda. Existe la idea errónea de que todo el mundo y para todo entorno ya está implementando Scrum, como si fuera una tendencia. Explique claramente dónde Scrum es útil y dónde probablemente fracasará.

Para todos los tipos de resistencia organizacional, encontré útil, en las etapas iniciales de la implementación, hacer “terceros en el coche” y luego soltar las manos cuando sea necesario. Es de suma importancia que el Scrum Master asegure que se sigan los valores de Scrum.

Falta de comprensión

Una de las causas más frecuentes de los problemas es la capacitación insuficiente, con malentendidos sobre roles y responsabilidades. Se cita que hay alrededor de 55 millones de profesionales de IT en el mundo, pero solo alrededor de 2 millones de Scrum Masters, Desarrolladores y Product Owners certificados (3.6%). Incluso considerando múltiples factores y multiplicando ese número por 10, encontramos que solo 1 de cada 3 profesionales está certificado en un marco utilizado en casi el 100% de las organizaciones de IT. La solución evidente es mitigarlo con capacitación interna, coaching y shadowing; además de buscar financiamiento para capacitaciones y certificaciones externas.

También hay dificultad para entender la ausencia de “roles nombrados” (sin BA, QA, UI/UX, Dev, DevOps, etc.) y la responsabilidad y rendición de cuentas distribuidas del equipo (en corto, el PO decide qué hacer y el equipo de desarrollo decide cuándo y cómo hacerlo). Para cerrar esa brecha, se necesita coaching y shadowing para que funcione (por supuesto, un experto en React trabajará en React, y un buen QA con ISTQB hará pruebas, pero el equipo necesita la mentalidad adecuada). Asegura que al menos la mitad del equipo tenga una senioridad suficientemente alta. Esto no necesariamente significa todos los miembros sean seniors, pero sí tener la mezcla adecuada para la ocasión.

Equipos fragmentados

Como en el punto anterior, en organizaciones en silos cada persona tiene un rol y se apega a él, con lo que falta colaboración cross-funcional, mientras que Scrum fomenta lo contrario. He obtenido buenos resultados trabajando en equipos que entrelazan sus tareas con las de otros miembros. Para ello, cada miembro debe confiar en los demás, así que es buena idea facilitar actividades de construcción de equipo. Para entender otros puntos de vista, fomenta trabajar en parejas (programación, revisiones de código, recorridos funcionales), pruebas entre equipos y entrenamiento cruzado.

Cuando hay brechas de comunicación, a menudo causadas por estructuras jerárquicas, el equipo tiende a aislarse y aparecen cuellos de botella y dependencias, afectando la claridad y la comunicación abierta. Un buen enfoque es crear un plan de comunicación claro, con fuentes de información, buenas herramientas en equipos remotos (por ejemplo, un canal general en una herramienta de mensajería, una herramienta de gestión de proyectos, una plataforma de compartición de documentos) y fomentar políticas de puertas abiertas. Además, los stand-ups y las retrospectivas bien conducidos por el Scrum Master y la acción cuando sea necesario marcan una gran diferencia.

Romper silos: los departamentos aislados o unidades funcionales pueden crear barreras para una implementación eficaz de Scrum. Cuando los equipos trabajan de forma aislada, pueden priorizar sus propios objetivos por encima de las metas del proyecto, resultando en un enfoque fragmentado para entregar valor. Aborda esto promoviendo una visión compartida y metas de proyecto comunes entre equipos y departamentos. Fomenta una cultura de cooperación y responsabilidad compartida. Incentiva la colaboración multifuncional mediante iniciativas interdepartamentales, sesiones conjuntas de planificación y una responsabilidad compartida por el éxito del proyecto. Asegúrate de que el Product Owner participe activamente con las partes interesadas de diferentes departamentos para recabar insumos y alinear las prioridades.

Al abordar los desafíos de equipos fragmentados, las organizaciones pueden fomentar la colaboración, mejorar la comunicación y crear un entorno que permita una implementación eficaz de Scrum. Romper silos y promover la colaboración entre funciones conducirá a una mayor productividad, propiedad compartida y la capacidad de entregar productos de alta calidad.

Expectativas poco realistas

Discute el desafío de establecer expectativas poco realistas durante la adopción de Scrum. Resalta cómo la presión por obtener resultados rápidos puede socavar los principios de Scrum, llevando a un desarrollo apresurado, calidad comprometida y equipos desmotivados. Enfatiza la importancia de gestionar las expectativas y establecer metas y plazos realistas.

Uno de los desafíos que suelen enfrentar las organizaciones al aplicar Scrum es la presencia de expectativas poco realistas. Las expectativas poco realistas pueden originarse de varias fuentes, como la presión por obtener resultados rápidos, fechas límite exigentes o una falta de comprensión de la naturaleza iterativa e incremental de Scrum. Profundicemos en este desafío:

Presión por resultados rápidos: En un entorno empresarial de ritmo acelerado, a menudo hay una sensación de urgencia por entregar resultados rápidamente. Sin embargo, Scrum es un proceso iterativo que se centra en entregar valor de forma incremental a lo largo del tiempo. Esta desalineación de expectativas puede provocar impaciencia, frustración y una despreocupación por la naturaleza incremental de Scrum.

Cómo afrontarlo: Educar a las partes interesadas, incluida la dirección y los clientes, sobre los principios y beneficios de un enfoque iterativo. Enfatizar la importancia de entregar valor en incrementos pequeños, lo que permite recibir retroalimentación continua y mejorar. Establecer expectativas realistas sobre el ritmo de progreso, destacando que el impacto acumulativo de lanzamientos incrementales llevará a mejores resultados globales. Desarrollo apresurado y compromiso de calidad: Las expectativas poco realistas pueden empujar a los equipos a acelerar el desarrollo, resultando en pruebas deficientes y validación insuficiente, y una autonomía del equipo reducida. En ese caso trabajé con mucha paciencia para definir y hacer cumplir cada fase del SDLC. Ninguna fase debe ser evitada, y cada fase necesita su tiempo suficiente.

Equipos desmotivados: Las expectativas poco realistas también pueden desmotivar a los equipos. Cuando las metas parecen inalcanzables dentro de las limitaciones dadas, la moral puede caer, llevando a menor productividad, agotamiento y posibles renuncias. La solución es fomentar un entorno de apoyo, empoderar al equipo para expresar lo que no está bien y cómo se sienten, y asegurar un estilo de dirección que apoye. Compartir el alcance del Sprint con la dirección y los interesados y convocarlos a las Revisiones de Sprint para recibir retroalimentación. Permitir que el equipo defina el alcance del Sprint y que el PO defina el alcance de la versión.

Conclusión

¿Pero entonces funciona Scrum? Sí, funciona, pero requiere esfuerzo, a veces mucho. ROI: 1 dólar invertido en mejorar Scrum en la organización se traduce en 10 dólares. Time to Market: un 50% más rápido que en entornos tradicionales. Defectos: una reducción del 75% frente a entornos tradicionales durante la fase de desarrollo.

Pasos clave

Confía en tu equipo. Confía en la empresa que contrataste para hacer tu producto. Deja que hagan lo que saben hacer. Establece métricas compartidas y revísalas con frecuencia. Capacita a todas las partes interesadas necesarias en el marco. No tengas miedo de decir “no sé” y “quiero aprender”.

Referencias

i Time Management, sin fecha, 9 razones por las que hacer las cosas bien es mejor que hacerlas perfectas, EE. UU., Planning Mindfully, https://www.planningmindfully.com/done-is-better-than-perfect/ ii Shah, Kunal, 09/2020, Scrum is difficult to master, Sin fecha, Serious Scrum, https://medium.com/serious-scrum/scrum-is-difficult-to-master-heres-how-you-can-make-it-easier-3ca6b7162998 iii West, Dave, 2016, Updates to the Scrum Guide, EE. UU., Scrum.org, https://www.scrum.org/resources/blog/5-scrum-values-take-center-stage iv Scrum Alliance: https://www.growingscrummasters.com/scrum-training/how-well-recognised-and-respected-is-the-csm-course/ y Scrum.Org: https://www.scrum.org/professional-scrum-certifications/count v Garzas, Javier, 2017, El retorno de la inversión de los marcos ágiles, España, Javier Garzas Blog, https://www.javiergarzas.com/2017/12/roi-los-frameworks-agiles.html vi Kremic, Ned, Sin fecha, Why is Agile Time To Market Delivery 50% faster?, EE. UU., Deltra Matrix, https://www.deltamatrix.com/why-is-agile-time-to-market-ttm-felivery-50-faster/