Por Damián Buonamico
¿Qué sentido tiene trabajar en ciclos? ¿Cuál es el valor real? 19 motivos que justifican trabajar en Sprints.
En Scrum, se trabaja de manera Iterativa e Incremental. Esto significa que cuando un Sprint termina, como resultado se obtiene un “Incremento de Producto” que se encuentra “Estable” y entrega “Valor de Negocio”. Esto es una gran diferencia, con la idea más simple de cerrar tareas y empezar con otras nuevas.
Analicemos un poco
- “Incremento de Producto“: nos referimos tanto a una nueva funcionalidad (Algo nuevo que el usuario puede hacer y antes no) o una mejora de la funcionalidad existente (Algo que ahora puede hacer mejor, con mayor calidad o mejor experiencia de usuario).
- “Estable“: significa que el trabajo esta listo para ser entregada al usuario. No hay tareas pendientes por hacer. También llamado “Con Calidad Integrada”. Esto no significa que la funcionalidad está completa respecto a su diseño o idea; puede ser una implementación parcial (un slice), pero puede ser usada y no tiene errores.
- “Valor de Negocio” nos referimos que nuestros usuarios encuentran relevante ese Incremento de Producto. En otras palabras, es lo que estaban necesitando!
Esta es una condición necesaria del trabajo en Sprint de Scrum.
No cumplir con esta condición es Fallar al objetivo de Sprint.
¿Qué sucede si se falla en cumplir esta condición?
Todos podemos fallar cuando intentamos cumplir nuestros objetivos. Si la tasa de fallo es baja es un signo que tener objetivos desafiantes. Sin embargo, la confiabilidad de un equipo Scrum está directamente relacionada con su efectividad para cumplir lo comprometido. Si efectividad es baja es necesario analizar las causas y tomar acciones que incrementen la efectividad. Algunas causas podrían ser:
- Falta de claridad en la funcionalidad a implementar. Falta de Criterios de Aceptación.
- Falta de habilidades técnicas para entender el esfuerzo requerido. Fallar al estimar la cantidad de trabajo que se puede construir en un Sprint.
- Fallar en dividir el trabajo en porciones pequeñas. Uno de los desafíos está en partir el funcionalidad de porciones pequeñas, manteniendo la característica de “Valor de Negocio”. Para esto la técnica de “User Stories” juega un papel fundamental.
- Duración del Sprint demasiado corta.
- Falta de motivación y compromiso del Equipo Scrum.
- Falta de entendimiento de el sentido de Scrum.
- Interrupciones o distracciones externas que alejen al equipo de su objetivo.
- Falta de trabajo colaborativo en equipo.
- Poca madurez como equipo.
¿Cual es el propósito y beneficios de trabajar en Sprints?
- El usuario se beneficia de utilizar las nuevas funcionalidades desde temprano y con frecuencia.
- Nos habilita a recibir feedback de usuarios reales de manera frecuente El feedback puede ser directo del usuario o análisis del comportamiento del usuario. Esta información ayuda a tomar mejores decisiones de producto basadas en datos reales.
- El Equipo de desarrollo encuentra una fuente de motivación al entender el impacto del producto construido durante la iteración en los usuarios. Genera mayor responsabilidad por la calidad el producto.
- El Product Owner y el Cliente se benefician de poder verificar consistentemente como el producto desarrollado satisface las expectativas, validando el trabajo realizado.
- El Equipo de desarrollo mitiga los riesgos de tecnología verificando con frecuencia como el producto construido responde en el ambiente real productivo.
- Mayor previsibilidad del equipo y mayor confianza con el resto de la empresa.
- Con Sprints, hay una fuerte sentido de compromiso de entregar al final del Sprint el trabajo comprometido. El compromiso no viene solo, pero los Sprints proveen el contexto adecuado para ello.
- Los Sprints permiten verificar la efectividad del equipo para entregar, de manera fácil y frecuente.
- Trabajar orientado a objetivos es más productivo, motivante y provee alineamiento y dirección. Completar con el Sprint es el objetivo del Equipo. Es recomendable además incluir una oración que resuma el objetivo a alto nivel.
- Es fácil recolectar métricas (como la Velocidad del Equipo) y comparar en el tiempo cómo esas métricas mejoran.
- Las planificaciones y predicciones se basan en datos reales empíricos de Software funcional entregado en iteraciones previas.
- El equipo se puede auto-organizar alrededor del trabajo. El equipo es libre de tomar decisiones técnicas y estrategias para cumplir con el Sprint. Paralelizar trabajo, cambiar el orden de las tareas, etc. Esto es posible sabiendo cual es el trabajo y sabiendo que no va a cambiar durante la iteración.
- El equipo se libera de la sobrecarga organizacional sabiendo que el trabajo a realizar no va a cambiar durante el desarrollo de la iteración. Permite al equipo a focalizarse en el objetivo e incrementar la productividad.
- Es motivante para el Equipo comenzar cada Sprint. No importa cómo fue el Sprint pasado; este es uno nuevo, con nuevas tareas. Provee una sensación de “nuevo comienzo”. Limpiar el tablero físico y tirar las viejas User Stories completadas da una sensación de alivio. El mismo alivio de cuando se termina un proyecto o una etapa. Especialmente si el trabajo hecho fue trabajo duro.
- Similar a las técnicas de “Gamificación”, los Sprints dan la oportunidad de ver los resultados del esfuerzo y dan una razón para celebrar y reconocer el buen trabajo. Refuerza la motivación y la buena voluntad de comprometerse a otro Sprint.
- El Sprint permite un ritmo de trabajo constante, sin sobrecargar o estresar al equipo de desarrollo, lo que permite una productividad mayor a largo plazo y mayor previsibilidad.
- Terminar un Sprint permite adaptar no solo el producto sino también el proceso que se sigue para construirlo. Esto significa que cada Sprint el equipo mejora en la forma que trabajan.
- El trabajo en Sprint permite sincronizar el trabajo del Equipo de Desarrollo con el Product Owner. Mientras el primero está construyendo el producto del Sprint actual el Product Owner está preparando el Sprint siguiente.
- Permite sincronizar el trabajo entre distintos equipos de desarrollo, sabiendo cuándo cada equipo va a entregar su parte.
¿Cuáles son las consecuencias de agregar trabajo extra dentro del Sprint?
De acuerdo a las reglas, una vez iniciado un Sprint, no es posible agregar o modificar el trabajo del Equipo.
No respetar esta regla implica poner en riesgo gran parte de los beneficios antes mencionados.
Como el equipo se comprometió con su capacidad completa, significa que no tienen ancho de banda para tomar trabajo extra.
El equipo completo se comprometió y comprendió el trabajo a realizar. Cambiarlo implicaría reunir al equipo nuevamente, analizar la nueva tarea, decidir que otra tarea remover, re-evaluar si la estrategia del equipo se ve afectada y pedir al equipo por compromiso nuevamente.
Es evidente que esto tiene un costo elevado. Además de que consume tiempo, distrae y desmotiva. El Product Owner siempre debe evaluar estos costos para decidir si el nuevo requerimiento puede esperar a la próxima iteración.
Publicado originalmente en http://www.caminoagil.com/
