Introducción
Un producto, cualquiera que éste sea, mientras está en una etapa temprana de su ciclo se basa en muchas suposiciones. Por ejemplo se supone que tenemos el conocimiento, los recursos económicos, y disciplina para construir el producto correcto.
Desde luego las suposiciones anteriores pueden o no ser ciertas, en el mejor caso si lo son nos llevaran a construir un producto pero ese no es el fin de la historia. También suponemos que conocemos el alcance del producto, quienes lo compraran, cuando dinero pagaran y en que mercado se venderá.
Ese segundo grupo de suposiciones son aun mas inciertas que las primeras pues están conectadas a factores externos variables como fluctuaciones del mercado, competidores y la economía misma de un país.
En esencia crear suposiciones y creer que se materializaran no es equivocado, pero la clave esta en validar si son verdaderas o no lo más pronto posible. Por tanto el gran servicio que un Product Owner presta no sólo al equipo sino a la organización, los clientes y el mercado mismo, es contribuir productivamente a la validación temprana de suposiciones.
Scrum Soporta la Validación de Suposiciones
Uno de los puntos centrales de Scrum es obtener retroalimentación sincera de clientes reales al final de cada Sprint, es precisamente a través de ésta dinámica que Scrum enfatiza la necesidad de validar suposiciones.
En muchos equipos he encontrado la tendencia a esperar un Sprint más para tener más cosas que mostrar a los clientes; desde luego esto no es recomendable y es generalmente un reflejo de que Scrum no se entendió bien o técnicamente el Equipo de Desarrollo esta abordando la construcción del producto usando un enfoque arquitectónico que no permite tener funcionalidad observable al final de cada Sprint.
Existen suposiciones técnicas que el Equipo de Desarrollo debe validar lo mas pronto posible, la mas común de ellas es que podemos poner código en producción fácilmente [Humble10].
Scrum a través del empoderamiento que concede al Equipo de Desarrollo para tomar decisiones técnicas favorece el que éste pueda invertir en aprender cómo poner código en producción desde los primeros dias del primer Sprint.
Una otra suposición técnica es que todo código que se construya luego se podrá probar a mano de forma rápida, eficaz y exhaustiva. Desde luego esta es una suposición muchas veces herrada pues el testo manual es lento, puede tener errores y omisiones.
Una vez más Scrum fomenta que el Equipo de Desarrollo mejore sus prácticas de ingenieria para que inserte la calidad en el producto mismo a través de pruebas automatizadas [Jeffries00].
Enfoques para la Validación de Suposiciones
Decidir qué suposiciones son las que se validaran primero tiene una influencia directa en el ordenamiento del Producto Backlog y por eso el Product Owner debe estar consciente de que existe varios enfoques. Estos son tres de los mas comúnmente empleados:
- Validar primero las suposiciones que implican el mayor riesgo de negocio
- Validar primero las suposiciones que implican el mayor riesgo técnico
- Validar primero las suposiciones que ofrecen las mayores posibilidades de aprendizaje
Balancear la incertidumbre en estas tres esferas (negocio, técnica y conocimiento) es complicado pues el Product Owner tiende a priorizar el negocio por encima de las otras dos. Si esta acaba siendo la tendencia en todos los Sprints muy probablemente el Equipo de Desarrollo acabara construyendo un producto plagado de deuda técnica y acarreara hacia el futuro una deuda de conocimiento.
Parte de la labor del Scrum Master es colaborar con el Product Owner para que el balance entre esas tres dimensiones se mantenga. La receptividad y pensamiento sistemico en el Product Owner son esenciales en este punto para poder entender y aceptar lo que el Scrum Master trate de exponer [Schwaber04].
Para decidir cual enfoque escoger muchas veces resulta util ver que tenemos disponible, es decir, si quiero validar riesgos de negocio tengo que tener disponible usuarios reales, si quiero validar riesgos técnicos tengo que tener la infraestructura o dispositivos, si quiero aprender tengo que tener disponibilidad de tiempo y recursos de aprendizaje.
En función de lo que haya disponible, sea más barato o sea mas accesible se podrá tomar una decision de que suposiciones validar primero.
Conclusiones
El trabajo en ciclos, el empoderamiento, la retroalimentación, la comunicación constante, y el espíritu de colaboración son algunos de los elementos que ofrece Scrum para permitir validar suposiciones lo más pronto posible.
Un buen Product Owner debe conocer y utilizar estos elementos y estar siempre dispuesto a cambiar el rumbo del producto en función de lo que vaya aprendiendo.
Una suposición también importe a considerar es que el Product Owner es el adecuado para el producto, quizás esto no sea cierto y una vez más Scrum a través de la transparencia y el coraje ofrece la oportunidad de que el mismo Product Owner pueda darse cuenta de que alguien más puede tomar su lugar.
Finalmente y reiterando lo antes mencionado, suponer no es malo pues es parte del ciclo de desarrollo de un producto, lo que es malo es no validar esas suposiciones a tiempo y generar gran desperdicio con un producto construido que no sirve a las necesidades de los clientes o simplemente es el producto equivocado.
Bibliografia
Humble10 Humble J., Farley D., 2010. Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation, Addison-Wesley
Jeffries00 Jeffries R., Anderson A., Hendrickson C., 2000. Extreme Programming Installed, Addison-Wesley Professional
Schwaber04 Schaber K., 2004. Agile Project Management with Scrum
