Entre 1844 y 1879, se produjeron varias apariciones de la Virgen María en una gruta cerca de Lourdes (Francia). A raíz de dichas apariciones, que la Iglesia Católica admitió como veraces, se creó el Santuario de Lourdes, al que muchas personas peregrinan cada año. La Iglesia Católica eligió a Nuestra Señora de Lourdes como patrona de los enfermos. Desde entonces, más de ocho millones de personas peregrinan hasta Lourdes en busca de un milagro.
Las empresas que desarrollan software (propio o para terceros) llevan años buscando técnicas de productividad o trabajo que permitan estimar un proyecto al empezar y que la fecha acordada de finalización se cumpla. Hay miles de técnicas creadas en las últimas décadas y todas ellas tratan de dar control al desarrollo software. Debido a que sigue sin lograrse, muchas empresas han buscando en Scrum una nueva “bala de plata” sanadora que les permita solucionar sus problemas de gestión. Pues bien, si el problema es que las fechas no se cumplen, no acudas a Scrum, porque ahí no está la solución, acude a Lourdes, ya que lo que necesitas no es productividad, es un milagro.
Estrategia o carta a los Reyes Magos
Existe en las empresas una tremenda desconexión entre la estrategia y los equipos, sobre todo en desarrollo de software. El problema es que entendemos por estrategia el lanzar muchos deseos con la frase “esto tiene que estar”, “esto es estratégico”, “esto es crítico”. El problema de no decidir, de no priorizar es que entonces pones tu decisión en manos del mercado. Al querer hacer demasiadas cosas a la vez, provocas que el tiempo de entrega se retrase, lo que aumenta tu probabilidad de perder oportunidades y, ahí, el mercado no perdona.
Una estrategia efectiva se basa en una priorización real de aquellas actividades que queremos lanzar. Es más, debería contener estas características:
- Alineado con aquello que podemos hacer, no con lo que nos gustaría hacer.
- Ordenado: construir un listado de productos/servicios/mejoras/acciones que queramos realizar
- Adaptativo en el tiempo, pero con flexibilidad para obtener resultados de los experimentos que se lancen.
- Validación constante de todo lo que se haga, es mejor poco con resultados, que muchas cosas sin terminar que no podemos validar.
- Con métricas de valor conocidas por todas las personas que integran los equipos, si no nos centramos en dar resultados difícilmente los obtendremos
El primer punto es el más relevante, debes conocer tu capacidad de entrega antes de planificar (y no al revés). Para ello, es mejor la previsión probabilística (basada en la entrega real) que utilizar alguna técnica de estimación, porque nos la acabamos inventando. Es más, al calor de “esto tiene que estar”, muchas estimaciones son ejercicios de auténtica invención.
La empresa que no quiso decidir
Durante el último año, estuvimos trabajando en una organización pequeña con mucho ánimo por crecer. Durante las primeras conversaciones, nos comentan que, para ellos, era importante terminar una serie de proyectos (más de 90) que eran necesarios para este año. Meses más tarde, llegó la mala noticia: había que reducir un 20% la plantilla.
Los motivos eran varios: habían dedicado mucho esfuerzo a proyectos que no salían y que no aportaban valor, por otra parte, estaban perdiendo el foco en aquellos donde podían mejorar su cuenta de resultados. Además, habían perdido foco en métricas que no les aportaban valor real y había que rentabilizar todo lo que se hiciera.
Si lo pensamos como un agente externo, no quisieron tomar la decisión de renunciar a proyectos, así que fue el mercado y la realidad quién ha tenido que tomar la decisión. No hacer nada es una decisión, por tanto, siempre tenemos que decidir, aun cuando no queramos hacerlo.
Los requisitos cambian, ¡acéptalo!
El gran problema del desarrollo software y del mundo del conocimiento es que las necesidades que tratamos de cubrir cambian. Esto supone que los requisitos que definen nuestras tareas están en constante evolución. Por tanto, tratar de orientarnos, cogiendo ese trabajo, analizándolo y dando una fecha de finalización no tiene sentido debido al continuo cambio. ¿Cómo voy a saber lo que tardo en hacer algo que mañana va a cambiar?
No se trata de trabajar sin fechas, sino de hacerlo cuando tienes ciertas garantías. Por ejemplo, cuando la vacunación contra la COVID-19 empezó en España, el Gobierno fue dando fechas cada vez más cerradas. Al principio, se hablaba de verano, después de finales de verano y, finalmente, del 31 de agosto. Sin entrar en una discusión política sobre el buen o mal hacer del gobierno, lo que podemos aprender es que, ante una situación con incertidumbre, podremos dar fechas cuando vayamos ganando experiencia real en la resolución del problema.
Scrum es útil para entregar valor
Si Scrum no nos ayuda a garantizar un alcance en una fecha determinada, ¿para qué nos sirve? Scrum nos ayuda a visualizar el trabajo real que tenemos que hacer, a hacerlo transparente y, después, toca decidir qué partes son las que más valor nos aportarán. En el modelo tradicional (waterfall), descubrimos lo que aporta valor al final, cuando entregamos. Sin embargo, Scrum propone un marco en el que validamos lo antes posible con el objetivo de averiguar dónde está el verdadero valor para nuestros clientes.
Por tanto, en Scrum no tratamos de acometer todo lo que nos piden, eso es imposible. Se trata de averiguar qué guerras luchar para ganar lo máximo posible. Tratar de hacerlo todo es restarles energía a lo importante.
Y tú ¿vas a Lourdes o prefieres decidir qué te aportará valor?
