Scrum es un marco de trabajo al que le está costando penetrar en las empresas. Scrum pone encima de la mesa la cultura de resultados, una cultura extraña para empresas latinas e incluso me atrevería a decir europeas. Tener equipos que sepan el valor (de negocio) que aportan a su organización y que sean capaces de centrarse en maximizarlo.
De hecho, muchos de los detractores de Scrum lo son porque consideran que no les ayuda a cumplir fechas y planes, muchos developers se quejan de su falta de propuesta con respecto a la calidad del desarrollo y también hay una corriente de muchos managers que desconfían de la autogestión.
¿Estamos orientando Scrum a Resultados o al Control?
Contemos Scrum, de otra manera
El dibujo típico de Scrum siempre arranca con la Sprint Planning. En este evento, planificamos el trabajo que creemos que haremos en el Sprint fijándonos un Sprint Goal. A partir de ahí, trabajamos contínuamente durante el Sprint con interacciones diarias (Daily Scrum) y generamos un incremento. Finalmente, acabamos el Sprint con la Sprint Review y con la Sprint Retrospective.
La manera habitual de explicar Scrum confunde mucho, precisamente porque todo parte de una planificación (cuando Agile es pura adaptación). Esto ha generado mucha confusión en las empresas que ven Scrum como una técnica donde se “planifica mejor”. Después, cuando descubren la realidad, muchas abandonan Scrum o lo adaptan de tal manera que apenas es reconocible.
Scrum orientado a resultados
¿Y si partimos de la Sprint Review? Un equipo Scrum es aquel que en menos de 30 días tiene que ser capaz de dar resultados (de negocio). Un Scrum Team tiene que basar toda su actividad en entregar valor y debe partir de la Sprint Review como eje central del marco de trabajo. Es decir, un Scrum Team empieza celebrando un evento con Stakeholders dónde inspeccionan los resultados y el estado del mercado para adaptar el Product Backlog. Este sería el primer paso, partimos del mercado para saber qué hacer y volver al mercado antes de 30 días para validar.
A partir de ahí, disponemos de un listado de posibles acciones a desarrollar recogidas en un Product Backlog. Este Product Backlog se encuentra ordenado buscando generar el mayor impacto en el mercado y favorecer el foco, podemos tener mil ideas pero solo tenemos tiempos para unas cuantas, ¡elijamos con sabiduría!
Una vez tenemos claro lo que haremos, disponemos de una Sprint Retrospective en la que analizamos cómo vamos a trabajar, qué técnicas o comportamientos debemos adaptar en nuestro trabajo para mejorar nuestra capacidad de entregar valor. Con este ejercicio conseguimos implementar acciones que nos lleven a una mejora contínua.
Con claridad en lo qué queremos hacer y en cómo lo vamos a hacer nos sentamos para la Sprint Planning. En ella, el Scrum Team (más alguna persona invitada si hiciera falta) se centra en los próximos pasos, ser capaces de construir un plan de trabajo (Sprint Backlog) que nos ayude a centrarnos en la entrega de valor de este nuevo Sprint.
Durante los días que dura el Sprint, realizamos una Daily Scrum que nos permite adaptar el plan a medida que avanzamos con el ánimo de conseguir el máximo valor. Además, realizamos Sprint Refinement para aclarar el futuro del Producto para saber cómo entregaremos valor más adelante.
El Sprint Finaliza volviendo al mercado, a validar nuestro trabajo y el impacto (en negocio) que ha tenido.
Scrum de Negocio
Pocos equipos son capaces de entender el valor que son capaces de aportar. De hecho, lo idílico es que incluso conocieran el aporte económico o el retorno de inversión que son capaces de crear en su empresa. Sin embargo, este análisis económico suele estar muy alejado de los propios equipos.
A pesar de que esta mentalidad requiere repensar las empresas, cambiar las métricas, la estructura, las conversaciones… Son muchos cambios y las empresas suelen evitar pagar este precio. ¡Solo quería que Scrum me ayudara con las fechas que nunca se cumplen!
¡Démosle la vuelta! Si Scrum está presente en forma de negocio podemos tener conversaciones muy diferentes. Para empezar, no es necesario tanto tiempo dedicado a la estimación, nuestro objetivo no es cumplir una determinada fecha. Las conversaciones con usuarios finales ganan sentido, tenemos que ser capaces de construir un producto por el que paguen o que usen. ¡El valor lo define el usuario final!
También cobra relevancia la calidad del producto. Si queremos generar valor y construir un producto con muchos errores, la satisfacción de nuestros usuarios será baja. Correr para cumplir fechas nos llevaba a una calidad deficiente pero cuando hablamos de negocio los clientes suelen preferir un buen producto que una calidad deficiente.
Cambios en la empresa
Muchas personas consideran que Scrum (y Agile en general) deben adaptarse a cada empresa y cada situación. Sin embargo, es todo lo contrario, las empresas son las que deben cambiar para interiorizar el nuevo paradigma de desarrollo orientado a resultados.
¡Cuidado! no se trata de cambiar nuestra compañía para “hacer Scrum”, eso sería absurdo. Hablamos de cambiar toda nuestra empresa para orientarla a resultados, para conectar la dirección con los equipos y con el mercado. Scrum solo nos ayuda a trabajar cuando queremos tener una orientación clara al negocio y a resolver problemas complejos.
Y tú, ¿orientas Scrum a resultados?
Muchas gracias por esta publicación, me ha gustado el enfoque y voy a trabajar con mis equipos el enfoque de empezar con retrospectiva.
Gracias 😊