Uno de los cambios que ha incorporado Scrum en su nueva guía 2020 es el concepto de producto usable, sustituyendo al de “producto releaseable” (listo para subir a producción). Recordemos que el Incremento es un artefacto que refleja nuestro producto terminado, por lo que entender muy bien este concepto es clave para el éxito de un equipo Scrum ¡Lo analizamos!
El objetivo de Scrum
Scrum tiene una misión clara: buscamos maximizar valor en entornos complejos. Como tenemos un grado de incertidumbre elevado, buscamos tomar decisiones que maximicen nuestro valor dentro del contexto donde trabajamos.
Por tanto, es esencial que definamos “valor” para nuestro Scrum Team, y métricas acordes que alerten sobre nuestros resultados ¿Estamos generando valor?
La gran dificultad radica en que si hemos valorado la entrega en fecha, nos ceñimos al plan que construimos al principio. Como diría el personaje de Hannibal en el Equipo A: “me encanta que los planes salgan bien”. El concepto de valor es diferente al que hemos vivido. Buscamos crear productos de valor para personas que, muchas veces, no nos lo han pedido. Nadie pidió Google, ni Facebook, ni Amazon, pero se crearon productos que fueron capaces de generar nuevas necesidades.
Valor lo define nuestro customer
El valor lo determina el impacto generado por nuestro producto. A veces, es el usuario final; otras, personas que se ven afectadas por nuestro producto. Son ellas las que nos dicen si les ha gustado, si pagarían por ello o si les ha mejorado sus vidas. Por tanto, el valor es teoría cuando analizamos, diseñamos y construímos; es humo hasta que nuestro customer puede beneficiarse de él (o le perjudica, lo que supone “valor negativo”).
Es por este motivo que entregar producto usable es tan importante. El concepto usable es muy ambiguo y, por ello, puede llevarnos a una situación poco beneficiosa. Si construimos un producto que se puede usar, pero que no se está usando porque la subida a producción se hace cada seis meses, entonces tardaremos demasiado tiempo en validar si estamos haciendo el producto correcto, el que aportará valor de verdad.
Dado que necesitamos al usuario activo con nuestro producto, solo cuando llegamos a producción, podemos realmente ser conscientes de que estamos teniendo éxito. Por eso, muchos equipos funcionan bien en “mantenimiento y evolutivos”, porque es ahí donde empiezan a entregar en pequeñas entregas incrementales, lo que el cliente quiere.
Retrasar la entrega impide tener métricas de valor
Muchas de las métricas que nos dicen que estamos construyendo el producto correcto dejan de tener sentido si no estamos entregando. Por ejemplo, si mido lead-time, no es realista, porque solo estoy midiendo el tiempo que tardo en terminar tareas que no están realmente completadas. Además, cuando un equipo está completando un producto, pero no lo entrega, hay trabajo invisible que se pierde.
Cuando tenemos un producto que está en uso, tenemos que equilibrar la demanda de nuevas features, con incidencias provocadas por el producto en uso, con la estrategia a largo plazo y con mejoras técnicas. En este tipo de contextos, es donde las métricas como lead-time (tiempo que tardamos en hacer las cosas), tienen sentido porque tenemos al sistema de trabajo “estresado”.
Las métricas que estudian el uso del producto tampoco son relevantes hasta que los usuarios no tienen dicho producto. Estas métricas nos ayudan a entender el comportamiento y esta información es clave para construir el producto adecuado. Si una feature es usada por el 1% de los usuarios, ¿merece la pena mantenerlo?
Además, las métricas relacionadas con ingresos, gastos, costes y demás tienen una función limitada. Cuando construimos y no entregamos, todo es coste, por lo que podemos medir si salimos de lo presupuestado, sin poner foco en el beneficio generado.
Si el objetivo es sacar el trabajo, apuesta por Kanban
Cuando vamos a construir un producto en una fecha concreta, trabajar con el marco Scrum no es la mejor opción. Scrum se centra en la entrega de valor y, si la posponemos hasta el final, entonces muchas partes de Scrum no tienen sentido. ¿Para qué sirve una Sprint Review donde no podemos inspeccionar si estamos generando un buen producto? En este tipo de situaciones, que son tan típicas, recomendamos apostar por el método Kanban.
En el método Kanban, buscamos que el trabajo salga, sin mirar tanto el resultado como en Scrum. Para que el trabajo salga, deberemos dividirlo en trozos manejables que podamos medir y usar métodos, como Montecarlo, para hacer predicciones sobre qué probabilidad hay de acabar todo el trabajo en una fecha.
Con el método Kanban, visualizamos el trabajo y tratamos de mejorar el proceso para que el “trabajo salga” lo antes posible. Ahora bien, nadie garantiza que dará tiempo, sobre todo, si reducimos la calidad y generamos retrabajo.
Y tú, ¿qué mides cuando no estás en producción?
