Scrumízate
Cuando trabajamos en un producto o proyecto debemos escoger dónde ponemos nuestros esfuerzos y qué hacemos primero. Podemos escoger concentrar nuestros esfuerzos solamente en lo que podemos construir. En este caso es probable que se acabe haciendo algo que en realidad nadie quiere, por más que a uno le entusiasme. Por el contrario, si nos concentramos solamente en lo que se puede vender, es probable que prometas cosas que no puedas construir. Por último, si sólo construyes lo que se puede vender, pero no te entusiasma, acabarás trabajando duro para construir algo mediocre.
Scrum te proporciona una herramienta para gestionar todos los objetivos pendientes. En el backlog debe incluirse todo lo que teóricamente pueda incluirse en el producto, aunque nunca se llegará a construir absolutamente todo. Parte del éxito radica en escoger que hacemos primero de la lista. Para ordenar el backlog podemos plantearnos las siguientes preguntas:
- Qué items representan el mayor impacto empresarial?
- Cuáles son más importantes para el cliente?
- Qué puede generar más dinero?
- Qué es lo más fácil de hacer?
En el software existe la regla del 80/20: el 80% del valor de un producto radica en el 20% de sus características. Cuando no conocemos este 20% podemos afirmar que el 80% del tiempo lo hemos desperdiciado. Si por el contrario, conocemos este 20%, podríamos entregar las cosas 5 veces más rápido que la competencia. Cuando trabajamos en un producto debemos saber dónde reside el 80% del valor. Para hacerlo debemos definir el producto mínimo viable y enseñarlo al público lo antes posible. De este modo podemos empezar a recibir feedback de nuestros usuarios o clientes y así, modificar nuestras prioridades.
Me gustaría recomendarte dos posts que profundizan en la creación y lanzamiento constante de nuevos MVP y el ciclo de vida iterativo e incremental:
- Desarrollo iterativo + Mínimo Producto Viable = Scrum
- Historias de usuario, trucos y consejos
- ¿Cómo luchar contra la deuda técnica?
Por ejemplo, vamos a suponer que estamos trabajando en una app que es una cámara de fotos. Hemos definido como producto mínimo viable una cámara puede hacer fotografías pero que no puede enfocar, aplicar filtros, formatos de las fotos... En un punto inicial, antes del lanzamiento de la aplicación, los posibles usuarios habían valorado igual que la cámara tuviera modo paisaje y que pudiera compartir las fotos hechas en Facebook. A partir del lanzamiento del MVP los usuarios nunca pidieron el modo paisaje y sí que pudieran compartir en Facebook las fotos hechas. Aunque sea un ejemplo sencillo es muy ilustrativo para ver como debemos ir actualizando la información y las prioridades.
Cómo podemos mejorar nuestro rendimiento? OODA = Observar + Orientar + Decidir + Actuar
Una vez hemos completado un sprint, realizado la entrega y hemos recibido el feedback de los clientes o usuarios, debemos actualizar la información de nuestro backlog. Eso se taduce a repriorizar la lista de items, subiendo los que proporcionan más valor al cliente y que se pueden hacer de una forma más rápida. Existe un mal hábito que es querer priorizarlo todo. Normalmente se debe a que no se está aprovechando suficientemente el feedback recibido y de no conocer dónde reside el valor.
Primero debemos ordenar las características según el valor percibido. De este modo sabemos que con el 20% inicial de las características conseguimos el 80% del valor percibido por el cliente o usuario. Podríamos definir el PMV alrededor del 25% del valor percibido por el cliente o usuario y una primera entrega, lo que podríamos considerar la primera fase, al 20% de las características (las que aportan el 80% del valor).
En cada nueva iteración debemos ordenar las características que el cliente o usuario valora primero. Cuando recibimos el feedback de los usuarios o clientes sabremos los siguientes puntos más valiosos. Es el momento de volver a desarrollar el 20% de las características y volver a entregar.
De este modo podemos multiplicar el valor percibido por nuestros clientes o usuarios a cada nueva entrega. Debemos asumir que habrá muchas características en nuestro backlog que nunca se desarrollaran. Cuanto más tiempo pase una característica en la zona inferior de la lista más números tiene de no desarrollarse nunca y acabar siendo archivada para un posible futuro.
Si quieres entender mejor las ventajas de las entregas frecuentes de software funcionando te recomiendo la lectura de Software en 30 días, de Ken Schwaber y Jeff Sutherland, creadores de Scrum.
Actualizando, añadiendo, repriorizando y eliminando items de nuestro backlog podemos destinar nuestro tiempo en las características realmente más importantes y en cada nueva entrega aumentar el valor percibido. Para conseguir esto debemos escuchar el feedback del cliente y analizar el comportamiento del usuario, a partir de las métricas, son los puntos clave para conseguir multiplicar nuestra efectividad en el desarrollo de una aplicación.
Te ha gustado el post? Ayúdanos a dar a conocer Scrumízate i comparte este post en la redes sociales para que llegue a más personas o envíalo a alguien a quien también le pueda interesar. Gracias!
