Hay 2 partes de Scrum que suelen quedar olvidadas al momento de implementar esta metodología ágil. Como Scrum es un marco de trabajo minimalista, sólo con lo mínimo para mantener a un equipo fuera del caos, pueden surgir problemas cuando falta una pieza de Scrum. Las 2 partes que comunmente quedan afuera son:
- Visión del producto
- Incremento de producto potencialmente productivo
Visión del producto
Cuando estemos trabajando en u proyecto, preguntemos al equipo qué están desarrollando. Si la respuesta involucra un listado de requerimientos y el equipo tiene dificultad para describir cómo entregar valor eso que desarrollan, entonces falta una visión del producto. Esto ocurre más seguido de lo pensado. Para saber si el equipo comprende en conjunto la visión, probar el siguiente ejercicio:
Cada persona del equipo escribe, en 1 párrafo, lo que el software le va a dar a los usuarios. Luego de todos escriben el párrafo lo comparten con el resto del equipo.
Si al compartir las visiones alguien está en desacuerdo con una parte o la totalidad de lo que dijo otro, entonces el equipo no tiene una visión del producto. Al menos, no se les comunicó la visión del producto al equipo completo.
Una forma simple de generar una visión de producto es utilizar la plantilla elevator statement del libro Crossing the Chasm por Geofrey Moore. Dice:
PARA (cliente) QUIEN (necesidad) EL (nombre del producto) ES UN (tipo de producto) QUE (brinda esta razón para comprarlo). A DIFERENCIA DE (productos de la competencia), NUESTRO PRODUCTO (factores distintivos)
Al completar esta plantilla con la información en los paréntesis, el equipo podrá empezar a generar un entendimiento compartido sobre la visión del producto. Si el producto no tiene una visión coherente, o si al llenar esta plantilla no se encuentra el valor del producto, entonces podría significar que el equipo no debería estar trabajando en ese producto. De ser el caso, el equipo debería empezar a trabajar en algo que brinde más valor.
Incremento de producto potencialmente productivo
Muchos equipos deciden no crear software potencialmente productivo al finalizar algunos sprints. Al equipo le resulta dificil trabajar de manera de poder entregar un incremento de producto potencialmente productivo. Esto podría ser porque:
- Los roles del equipo son demasiado especializados.
- Falta de motivación para trabajar juntos.
- Hay elementos del Backlog del Producto que sólo los puede completar una persona del equipo.
- Se está haciendo "scrumerfall" o "FrAgile" (fases de cascada dentro del ciclo del sprint).
- etc...
El primer paso para lograr incrementos potencialmente productivos es crear una Definición de Terminado. La Definición de Terminado involucra a todos los miembros del equipo en acordar lo que van a entregar al finalizar cada spring, generando un producto con calidad interna consistente. El equipo incluye miembros con conocimientos en programación, testing, análisis, diseño y otras disciplinas dentro del desarrollo de software. La discusión que surge al crear la Definición de Terminado ayudará a cada miembro del equipo a entender más el producto, y brinda una forma de mantener la calidad interna a medida que se entregan características de forma iterativa.
Resumiendo
Si un equipo no sabe hacia dónde se dirige, las decisiones del día-a-día van a generar una implementación mediocre sin un foco coherente. Crear una visión de producto y comunicarla al equipo de forma efectiva ayuda a brindar una guía durante toda la vida del proyecto.
Si el equipo no puede entregar software con calidad productiva al finalizar cada sprint, entonces el producto siempre va a tener trabajo extra para hacer que llegue a los usuarios. Este trabajo incluye estabilizar e integrar las partes de forma coherente, lo cual suele resultar impredecible generando una disminución en la calidad (y fechas que no se cumplen). Hay que trabajar en una Definición de Terminado como primer paso para comprender lo que significa un incremento potencialmente productivo. De esta manera se logrará software con calidad productiva en cada iteración, incluso aunque el Dueño del Producto decida avanzar otro sprint (o más) sin llegar a ponerlo productivo para los usuarios. Las prácticas de Extreme Programming (XP) ayudan a crear software de forma incremental que puede ayudar a cumplir una Definición de Terminado de manera mucha más efectiva.
