Scrum
Todo lo que debes saber sobre Scrum
Juan Serrano López
Planificación de la iteración (Sprint Planning)
La planificación de las tareas a realizar en la iteración se divide en dos partes:
- QUÉ: Se realiza en un timebox de alrededor de 2 horas:
- CÓMO: Se realiza en un timebox de alrededor de 2 horas. El equipo planifica la iteración, elabora la táctica que le permitirá conseguir el mejor resultado posible con el mínimo esfuerzo.
- Productividad: mediante comunicación y creación de sinergias
- Potenciación del compromiso del equipo sobre el objetivo común de la iteración.
- Una estimación conjunta es más fiable, dado que tiene en cuenta los diferentes conocimientos, experiencia y habilidades de los integrantes del equipo.
Ejecución de la iteración
En Scrum un proyecto se ejecuta en bloques temporales cortas y fijas (iteraciones de un mes natural y hasta de dos semanas). Cada iteración tiene que proporcionar un resultado completo, un incremento de producto que sea potencialmente entregable, de manera que cuando el cliente (Product Owner) lo solicite sólo sea necesario un esfuerzo mínimo para que el producto este disponible para ser utilizado. Para ello, durante la iteración el equipo colabora estrechamente y se llevan a cabo las siguientes dinámicas:
- Cada día el equipo realiza una reunión de sincronización, donde cada miembro inspecciona el trabajo de los otros para poder hacer las adaptaciones necesarias, comunica cuales son los impedimentos con que se encuentra, actualiza el estado de la lista de tareas de la iteración (Sprint Backlog) y los gráficos de trabajo pendiente (Burndown charts).
- El Facilitador (Scrum Master) se encarga de que el equipo pueda mantener el foco para cumplir con sus objetivos.
- Para poder completar el máximo de requisitos en la iteración, se debe minimizar el número de objetivos/requisitos en que el equipo trabaja simultáneamente (WIP, Work In Progress), completando primero los que den más valor al cliente. Esta forma de trabajar, que se ve facilitada por la propia estructura de la lista de tareas de la iteración, permite tener más capacidad de reacción frente a cambios o situaciones inesperadas.
- No se puede cambiar los objetivos/requisitos de la iteración en curso.
- En la reunión de planificación de la iteración el equipo realizó una previsión de los objetivos que podría completar en la iteración unos requisitos concretos, basó su plan y organización en ellos. Cambiar los objetivos/requisitos de la iteración dificulta la concentración del equipo, baja su moral y su compromiso.
- El hecho de no poder cambiar los objetivos/requisitos de la iteración una vez iniciada facilita que el cliente cumpla con su responsabilidad de conocer qué es lo más prioritario a desarrollar, antes de iniciar la iteración.
- Notar que Scrum minimiza esta necesidad ya que, por un lado, los objetivos/requisitos que se están desarrollando eran los más prioritarios justo antes de iniciar la iteración y, por otro lado, las iteraciones en Scrum son suficientemente cortas (2 o 4 semanas) como para que la probabilidad de cambios una vez iniciada la iteración sea mínima.
Terminación anormal de la iteración
Sólo en situaciones muy excepcionales el cliente o el equipo pueden solicitar una terminación anormal de la iteración. Esto puede suceder si, por ejemplo, el contexto del proyecto ha cambiado enormemente y no es posible esperar al final de la iteración para aplicar cambios, o si el equipo encuentra que es imposible cumplir con la previsión de objetivos que se planteó entregar. En ese caso, se dará por finalizada la iteración y se dará inicio a otra mediante una reunión de planificación de la iteración.
Reunión diaria de sincronización del equipo (Scrum daily meeting)
El objetivo de esta reunión es facilitar la transferencia de información y la colaboración entre los miembros del equipo para aumentar su productividad, al poner de manifiesto puntos en que se pueden ayudar unos a otros.
Cada miembro del equipo debe responder las siguientes preguntas en un timebox de cómo máximo 15 minutos:
- ¿Qué he hecho desde la última reunión de sincronización para ayudar al equipo a cumplir su objetivo?
- ¿Qué voy a hacer a partir de este momento para ayudar al equipo a cumplir su objetivo?
- ¿Qué impedimentos tengo o voy a tener que nos impidan conseguir nuestro objetivo?
Como apoyo a la reunión, el equipo cuenta con la lista de tareas de la iteración, donde se actualiza el estado y el esfuerzo pendiente para cada tarea, asi como con el gráfico de horas pendientes en la iteración.
- Aumentar la productividad en el proyecto y potencia el compromiso de equipo.
- Fomentar el aprendizaje de los miembros del equipo, ya que pueden ver cómo trabajan los otros según sus especialidades y experiencias.
- Conocer el estado de la iteración, ver si es posible completar los requisitos a que se comprometió el equipo, en vista de las desviaciones y de las tareas pendientes.
- La reunión diaria de estado y sincronización del equipo no es para resolver problemas, los problemas se resuelven después de la reunión.
- El equipo debe contar con unos criterios consensuados sobre el proceso de ejecución de las de tareas
- Realizar la reunión diaria de sincronización de pie, para que los miembros del equipo no se relajen ni se extiendan en más detalles de los necesarios.
- Realizar las reuniones de colaboración entre miembros del equipo justo después de la de sincronización.
Demostración de requisitos completados (Sprint Review)
Reunion informal donde el equipo:
- Revisa los resultados obtenidos respecto al objetivo de la iteración, problemas identificados y cómo se resolvieron.
- Presenta al cliente los requisitos completados en forma de incremento de producto preparado para ser entregado y usado con el mínimo esfuerzo, haciendo un recorrido por ellos lo más real y cercano posible al objetivo que se pretende cubrir.
- El cliente puede ver de manera objetiva si se cumplen sus expectativas
- Al inspeccionar un producto tangible, el cliente puede entender mejor qué es lo que necesita y tomar mejores decisiones respecto al proyecto.
- El equipo puede ver si realmente está entendiendo cuáles son los requisitos que le está solicitando el cliente y ver en qué puntos hay que mejorar la comunicación entre ambos.
- El equipo se siente más satisfecho cuando puede ir mostrando los resultados que va obteniendo. No está meses trabajando sin poder exhibir su obra.
- Sólo se debería mostrar los requisitos completados, para que el cliente no se haga falsas expectativas y pueda tomar decisiones correctas y objetivas en función de la velocidad de desarrollo y el resultado realmente completado. Un requisito no completado quedará como un requisito más a replanificar.
Retrospectiva (Sprint Retrospective)
Con el objetivo de mejorar de manera continua la productividad y la calidad del producto que está desarrollando, la motivación del equipo, cómo están engranando entre ellos, como fue la última iteración o cómo está yendo el proyecto… el equipo analiza cómo ha sido su manera de trabajar durante la iteración, por qué está consiguiendo o no los objetivos a que se compremetió al inicio de la iteración y por qué el incremento de producto que acaba de demostrar al cliente era lo que él esperaba o no:
- Qué cosas han funcionado bien.
- Cuales hay que mejorar.
- Qué cosas quiere probar hacer en la siguiente iteración.
- Qué ha aprendido.
- Cuales son los problemas que podrían impedirle progresar adecuadamente. El Facilitador se encargará de ir eliminando los obstáculos identificados que el propio equipo no pueda resolver por sí mismo.
Como resultado de una retrospectiva, se pueden encontrar los siguiente:
- Plan de acciones de mejora.
- Nuevas best practices.
- Acuerdos de equipo actualizados.
- Impedimentos a escalar.
- Incrementa la productividad en el proyecto, la calidad del producto (cosa que permite hacerlo crecer de manera sostenida) y potencia el aprendizaje del equipo de manera sistemática, iteración a iteración, con resultados a corto plazo.
- Aumenta la motivación del equipo dado que participa en la mejora de proceso, se siente escuchado, toma decisiones consensuadas (y más sostenibles) para ir eliminando lo que molesta e impide que sea más productivo.
- En necesario que el Equipo y el Facilitador dispongan de autoridad, mecanismos y recursos para ir mejorando su forma de trabajar y el contexto del proyecto. Es frustrante encontrar sistemáticamente los mismos obstáculos y no poder solucionarlos.
Refinamiento de la lista de requisitos y cambios en el proyecto – Product Backlog Refinement
En las reuniones de planificación de entregas y durante el transcurso de una iteración (en el Product Backlog Refinement o Grooming), el cliente / Product Owner va trabajando en la lista de objetivos/requisitos priorizada del producto o proyecto, añadiendo requisitos, modificándolos, eliminándolos, repriorizándolos (cambiando el contenido de iteraciones, definiendo un calendario de entregas que se ajuste mejor a sus nuevas necesidades) [1] y detallando los requisitos conforme se acerca el momento de su desarrollo. Para poder hacer esta repriorización con toda la información necesaria, el equipo proporciona la estimación de los nuevos ítems y el impacto de los cambios que se necesita realizar.
Los cambios en la lista de requisitos pueden ser debidos a:
- Modificaciones que el cliente solicita tras la demostración que el equipo realiza al final de cada iteración sobre los resultados obtenidos, ahora que el cliente entiende mejor el producto o proyecto.
- Cambios en el contexto del proyecto (sacar al mercado un producto antes que su competidor, hacer frente a urgencias o nuevas peticiones de clientes, etc).
- Nuevos requisitos o tareas como resultado de nuevos riesgos en el proyecto.
Para realizar esta tarea, el cliente colabora con el equipo:
- Para cada nuevo objetivo/requisito, conjuntamente se hace una identificación inicial de sus condiciones de satisfacción (que se detallarán en la reunión de planificación de la iteración).
- El cliente obtiene del equipo la re-estimación de costes de desarrollo para completar los objetivos/requisitos siguientes, según la definición de hecho.
- El cliente re-prioriza la lista de objetivos/requisitos en función de estas nuevas estimaciones.
- El cliente puede tomar decisiones con tiempo respecto al progreso del proyecto y posibles desviaciones
- El plan de proyecto se actualiza con la velocidad de desarrollo del equipo, se evitan sorpresas de última hora.
Su principal misión es encargarse de que exista una priorización clara de los objetivos a conseguir, con el propósito de maximizar el valor del trabajo que lleva a cabo el equipo. Las responsabilidades del Cliente / Product Owner son:
- Conocer el mercado y los comportamientos de los clientes / usuarios finales, con muy buena visión de Negocio.
- Ser el representante de todas las personas interesadas (stakeholders) para conseguir una buena definición de los objetivos del producto o proyecto y de los resultados esperados.
- Encargarse de que exista una priorización clara de los objetivos a conseguir. De este modo, dirige los resultados del proyecto para maximizar su ROI (Return Of Investment):
- Actuar como interlocutor único ante el equipo, con autoridad para tomar decisiones (es decir, con libertad para decidir qué hacer de manera alineada con los objetivos de su área de trabajo, que no se vea invalidada por personas en una posición superior).
- Colaborar con el equipo para planificar, revisar y dar detalle a los objetivos de cada iteración
- Proporcionar suficiente dedicación para hacer este trabajo (usualmente un Product Owner no suele poder estar con más de 1-2 equipos, en función del tipo de producto y equipos).
Por ello, una buena selección de Product Owners (y una esfuerzo especial en su coaching de Producto/Cliente) es fundamental para un inicio de transformación ágil exitoso, es decir, aportar resultados a la empresa de manera más ágil.
Facilitador (Scrum Master)
Su principal misión es conseguir un equipo de alto rendimiento (entendiendo como equipo al Equipo de desarrollo y al Cliente / Product Owner, así como sus relaciones con la organización y stakeholders). Se encarga de conseguir el equipo que conozca y sienta los principios y valores de Agile, así como la teoría y prácticas de Scrum, con el objetivo de que los usen en sus procesos de toma de decisiones. El Scrum Master actúa como facilitador de reuniones donde pensar de manera conjunta y quita los obstáculos más allá del equipo que le impiden ser ágil.
De este modo, es el coach y lider al servicio del equipo, llevando a cabo las siguientes responsabilidades:
- Velar por que todos los participantes del proyecto sigan los valores y principios ágiles, las reglas y proceso de Scrum y guiar la colaboración intraequipo y con el cliente / Product Owner) de manera que las sinergias sean máximas.
- Conocer el grado de motivación de cada uno de los miembros del equipo, trabajarla con ellos y/o con las personas de la organización más relacionadas con este aspecto.
- Quitar impedimentos que el equipo tiene en su camino para conseguir el objetivo de cada iteración (proporcionar un resultado útil al cliente de la manera más efectiva) y poder finalizar el proyecto con éxito. Estos obstáculos se identifican de manera sistemática en las reuniones diarias de sincronización del equipo y en las reuniones de retrospectiva.
- Proteger y aislar al equipo de interrupciones externas durante la ejecución de la iteración (introducción de nuevos requisitos, “secuestro” no previsto de un miembro del equipo, etc.). De esta manera, el equipo puede mantener su productividad y el compromiso que adquirió sobre los requisitos que completaría en la iteración [notar, sin embargo, que el equipo debe reservar tiempo para colaborar con al cliente en la preparación de la lista de requisitos para la próxima iteración]
- Trabajar con otros Scrum Masters y el equipo de transformación / mejora continua con el objetivo de que la organización sea cada vez más ágil.
Notar que una distancia de 3-5 metros del equipo puede llegar a ser una barrera demasiado alta para poder descubrir los comportamientos y tipos de relaciones que hay entre sus miembros, y los impedimentos que les están dificultando el día a día.
Equipo de desarrollo (Development Team)
El equipo en Agile incluye al Cliente / Product Owner y al Facilitador / Scrum Master. Cuando se habla específicamente de “equipo de desarrollo” se refiere al conjunto de personas más “técnicas” que de manera conjunta desarrollan el producto del proyecto. Tienen un objetivo común, comparten la responsabilidad del trabajo que realizan (así como de su calidad) en cada iteración y en el proyecto.
Para ir alcanzando un estado de alto rendimiento, este equipo es:
- Autónomo y multidisciplinar.
- Tamaño de equipo de 5 a 9 personas.
- Estable y dedicado.
- Se auto-organizan, tienen responsabilidad compartida y piensan juntos
- Están motivados.
- Están sentados juntos.
- Interaccionan con Stakeholders.
Lista de objetivos / requisitos priorizada (Product Backlog)
La lista priorizada de objetivos/requisitos representa la visión y expectativas del cliente respecto a los objetivos y entregas del producto o proyecto
El cliente es el responsable de crear y gestionar la lista (con la ayuda del Facilitador y del equipo, quien proporciona el coste estimado de completar cada requisito). Dado que reflejar las expectativas del cliente, esta lista permite involucrarle en la dirección de los resultados del producto o proyecto.
- Contiene los objetivos/requisitos de alto nivel del producto o proyecto, que se suelen expresar en forma de historias de usuario.
- En la lista se indican las posibles iteraciones y las entregas (releases) esperadas por el cliente (los puntos en los cuales desea que se le entreguen los objetivos/requisitos completados hasta ese momento), en función de la velocidad de desarrollo del (los) equipo(s) que trabajará(n) en el proyecto.
- La lista también tiene que considerar los riesgos del proyecto e incluir los requisitos o tareas necesarios para mitigarlos.
En el caso de un proyecto, conforme éste avance irán apareciendo los requisitos menos prioritarios que falten. Esto produce varias ventajas:
- Se evita caer en parálisis de análisis al inicio del proyecto, de manera que se puede iniciar antes el desarrollo y el cliente puede empezar a obtener resultados útiles.
- Se evita analizar en detalle requisitos no prioritarios que podrían cambiar durante el transcurso del proyecto.
- Puede llegar a un punto del proyecto en que no valga la pena analizar ni desarrollar los requisitos restantes, dado el poco retorno de inversión (ROI) que tienen.
Iteración de entrega (release sprint)
Cuando el cliente solicita una entrega de los objetivos/requisitos completados hasta ese momento, el equipo puede necesitar añadir una iteración de entrega, más corta que las iteraciones habituales, donde realizar alguna tarea que no ha sido necesaria o posible hasta el momento de la entrega final y acabar de corregir defectos detectados en la última demostración.
Idealmente esta iteración de entrega no debería existir (o reducirse a tareas mínimas dentro de una iteración) si:
- Se ha trabajado con una buena Definición de Hecho durante cada iteración del proyecto.
- Se hacen entregas muy cortas cada poco tiempo, con lo que la cantidad de cosas a entregar, integrar y probar es pequeña.
- Se está realizando un esfuerzo de automatización de estas tareas de pruebas, iteración y entrega durante todo el proyecto (con lo cual se gana en eficiencia y seguridad).
Uso de la lista de objetivos priorizada
- Para medir la velocidad de desarrollo del equipo, ver una progresión constante y extrapolar la fecha de las entregas.
- Cada requisito tiene asociado un factor de complejidad, que permite ajustar su coste estimado en función de la incertidumbre de la complejidad de su desarrollo en el momento de introducirlo en la lista.
- Si un requisito depende de otro, se coloca en algún punto por debajo del que depende.
- Si un requisito no se finaliza en una iteración, se le vuelve a poner en alguna de las siguientes iteraciones, indicando el coste pendiente de desarrollo.
- El “origen” permite saber quién podría participar en la definición de un objetivo/requisito y sería conveniente que estuviese presente en el momento de su demostración.
Lista de tareas de la iteración (Sprint Backlog)
Subconjunto de objetivos/requisitos del Product Backlog seleccionado para la iteración actual y su plan de tareas de desarrollo. Esta lista permite ver las tareas donde el equipo está teniendo problemas y no avanza, con lo que le permite tomar decisiones al respecto.
- Los objetivos/requisitos están ordenados por orden de prioridad para el cliente.
- Si una tarea depende de otra, se coloca en algún punto por debajo de la que depende.
- Las tareas deben estar identificadas de manera que tengan un coste semejante para ser completadas, entre 4 y 16 horas
El tablero de tareas (Scrum Taskboard)
Al lado de cada objetivo se ponen las tareas necesarias para completarlo, en forma de post-its, y se van moviendo hacia la derecha para cambiarlas de estado (pendientes de iniciar, en progreso, hechas).
La lista va evolucionando (nuevas tareas, cambios, estado, esfuerzo pendiente, …) a medida que la iteración avanza, especialmente durante la reunión diaria de sincronización.
Este tablón o cuadro de mandos actúa como radiador de información tanto para el equipo como para cualquier otra persona relacionada con el proyecto.
