daily Scrum

Facilitación Gráfica – Eventos en Scrum

¿Sabes qué es un Sprint o una Review? En este post de facilitación gráfica – Eventos en Scrum vamos a decirte qué es un evento y cuáles son.

Eventos, ¿para qué?

Scrum prescribe una serie de eventos que crean regularidad y evitan las reuniones no planificadas. Son un total de cinco eventos y todos ellos tienen un límite de tiempo. Estas reuniones planificadas nos permiten inspeccionar y adaptar cada poco tiempo, y facilitan la transparencia.

¿Cuáles son?

Los eventos que define Scrum son:

– Sprint (el que engloba el resto de eventos, un metaevento)
– Planning
– Daily
– Review
– Retrospective

En próximas entradas os iremos contando qué hacemos en cada uno de los eventos, quién debe asistir a cada uno de ellos y cuál es el time-box aproximado.

Scrum vs Kanban, el combate definitivo

Una de las cuestiones que se plantean habitualmente en organizaciones, equipos y Agile Coaches, es el uso de un método que permita organizar el trabajo de forma ágil. El uso de un método como Scrum o Kanban va mucho más allá del proceso en sí, sino que suponen una herramienta para mejorar la capacidad de adaptación, gestión de riesgo e innovación.

El método más usado del mundo es Scrum. Según el informe CHAOS de Standish, Agile tiene cuatro veces más probabilidad de éxito que los métodos tradicionales en proyectos de IT. Kanban le ha ido comiendo terreno, especialmente debido a su baja disrupción de los procesos existentes en la organización.

A primera vista, puede parecer que Kanban es una alternativa a Scrum y viceversa, sin embargo no es así. Son dos maneras distintas de llegar al mismo sitio: la agilidad organizacional. Veamos las diferencias entre Scrum y Kanban.

Primer round: Scrum no funciona porque no podemos planificar. Utilicemos Kanban.

Algunos equipos se encuentran que en su camino hacia la agilidad, usando Scrum se encuentran con muchas interrupciones durante su trabajo diario.

Los miembros de los equipos de desarrollo o el Product Owner, avisan de que dada la naturaleza de su trabajo (gestionar incidencias, por ejemplo) no son capaces de hacer reuniones de planificación cada dos semanas, necesarias para que Scrum funcione.

También se quejan de la imposibilidad de cambiar el commitment para acomodar el trabajo no planificado y que al final no son capaces de entregar todo lo que se habían propuesto. La gestión de la demanda no es adecuada y buscan una alternativa en el método de trabajo, en lugar de en resolver esos problemas de gestión de la demanda.

Por tanto se pasan a Kanban.

Cuando empiezan a hacer Kanban, lo tienen todo en un tablero con Post-its®. Como tienen tanto trabajo, no pueden limitar el WIP (Trabajo en curso).

Tampoco realizan reuniones de Replenishment, y los daily meetings no sirven para gestionar el flujo de trabajo. Solamente se distribuyen tareas. A veces ni eso. Las clases de servicio no están claras y todo es trabajo urgente que hay que hacer “para ayer”.

Finalmente, deciden quedarse con el tablero para visualizar notas que viajan de un sitio a otro y descartar los demás elementos necesarios en un sistema Kanban. Un momento: ¿No es esto lo que estaban haciendo con Scrum?

Algunas conclusiones:

La duración de los Sprints en Scrum se deciden en función del tiempo que necesita el equipo para entregar un incremento y de un horizonte de planning aceptable para el Product Owner.
Si no podemos planificar a dos semanas, igual tenemos que planificar a una, o a dos días.
Los Daily Scrums sirven para hacer gestión de riesgos y ver el trabajo urgente, que se incorporará al Sprint Backlog en función de las prioridades del negocio.
Kanban necesita de WIP, visualización, clases de servicio y feedback loops. Más en el siguiente round.

Segundo Round: Utilizamos un tablero con Post-its® dentro de Scrum para distribuirnos el trabajo, ¿Hacemos Scrum o Kanban?

No. El simple hecho de poner post-its® en un tablero o en una pared no convierte a tu equipo en un equipo Kanban. El método Kanban tiene seis prácticas generales que se usan para gestionar el flujo de trabajo.

Puede ser que utilices un tablero para gestionar el flujo de trabajo dentro de Scrum. Puede o no ser un tablero Kanban. Incluso si usas un sistema Kanban completo dentro de Scrum, puedes seguir llamándolo Scrum. O Scrumban.

Ambos se complementan, no son una alternativa el uno al otro.

Kanban, al igual que Scrum, se basa en la autoorganización de la gente alrededor del trabajo, no en la asignación de tareas.

Un sistema Kanban tiene políticas explícitas que se exponen en el tablero. ¿Las tiene tu tablero Scrum? Si no las tiene, quizás existan pero no sean explícitas. En ocasiones los miembros de los equipo desconocen dichas políticas: ¿Cómo se determina la urgencia de algo? ¿Quien decide que se hace? ¿Cómo sabemos que algo está terminado?

Algunas conclusiones:

Scrum y Kanban se basan en la autoorganización y la optimización del sistema, no de las personas.
En un entorno donde se prioríza la “gente ocupada” sobre la “gestión del flujo de valor” ni Scrum ni Kanban aportarán nada a la organización.
Algunas organizaciones simplemente cambian de Scrum a Kanban y viceversa porque no son capaces de resolver problemas internos.
Adaptar Scrum o Kanban no resuelve tus impedimentos organizacionales. Sólo los hace más visibles.

Último round: En un equipo maduro, ¿Utilizamos Scrum o Kanban? ¿O lo mejor de dos mundos?

Tu equipo es muy maduro. Tenéis que decidir si usar Scrum o Kanban. ¿Lo mejor de dos mundos?

Cuando un cliente me dice que usa lo mejor de “Scrum y Kanban” automáticamente se que tiene un problema. Hablan sobre métodos para no hablar de sus impedimentos. Los equipos y organizaciones maduras no tienen este problema.

Las organizaciones maduras entienden que al final todo lo que pueden hacer está gobernado por la Ley de Little, que es una demostración de la relación directa de la capacidad de un sistema, la velocidad a la que llegan las cosas y el ratio de entrega de cosas finalizadas.

Este video sobre el WIP lo explica mucho mejor.

Como ves, no hay tantas diferencias entre Scrum y Kanban. Son maneras distintas de llegar al mismo resultado y ambas requerirán que tu organización cambie para adaptarse a ellas y no al revés.

Sí que hay una gran diferencia entre ambas: Implementar Scrum supone un impacto grande en la forma de trabajar en la organización, mientras que la implementación de Kanban usando STATIK sigue el camino de menos resistencia.

Tarde o temprano, tendremos que implantar una cultura de transparencia, inspección y adaptación, lo que requerirá cambiar nuestra organización. No importa el camino que elegimos. Importa lo que hagamos en el mismo.

En realidad, cuando las organizaciones y los equipos discuten si usar Scrum o Kanban, están discutiendo otro asunto: ¿Qué es lo que nos implica tocar menos el statu quo? Ni Scrum ni Kanban te ayudaran a mantener el status quo de tu organización. Precisamente todo lo contrario.

17 Mitos y falacias de Scrum

Cuando las organizaciones deciden adoptar agilidad, la mayoría opta por Scrum por ser el MÉTODO MAS POPULAR Y UTILIZADO DEL MUNDO. Sin embargo, muchas caen en los mismos mitos y falacias de Scrum. Veamos algunas de ellas y como evitarlas

Un Scrum Master por equipo

Scrum recomienda que en cada equipo exista un Scrum Master y un Product Owner, sin embargo no dice que tenga que ser una persona dedicada totalmente al equipo. Sí advierte de que si no están dedicadas al equipo, eso puede suponer un impacto en la productividad.

Mi opinión es que tener un Scrum Master por equipo es algo fundamental, sobre todo cuando se trata de nuevos Scrum Masters que requieren de tiempo antes de empezar a tener una visión holística del proceso. Hay diferencia de opiniones en este aspecto.

Debe haber un Product Backlog antes de empezar el Sprint

Mito. Aunque es muy positivo que exista un Product Backlog antes de empezar el Sprint, este puede perfectamente realizarse como parte del Sprint Planning e ir refinándose durante el Sprint. De hecho, puede ser una tarea totalmente factible para un primer Sprint.

Lo que Scrum dice es que, independientemente de como se haya iniciado el Sprint, al final de este debe haber un Incremento, es decir, Software listo para entregar al cliente, por pequeño que éste sea.

Los Sprints deben durar dos semanas

Falacia. Los Sprints deben durar lo necesario para poder entregar un Incremento completo y nunca más de cuatro semanas. El motivo es que si duran más, se pierden oportunidades para inspeccionar y adaptar. Si con Sprints de dos semanas no se consigue tener un Incremento “Listo”, entonces hay que revisar la duración del Sprint.

Debe existir una Definición de “Hecho” (Definition of Done)

Falso. La definición de “Hecho” o Definition of “Done” es una práctica recomendada pero no forma parte del núcleo de Scrum. La definición de “Hecho” recoge todas aquellas actividades recurrentes que deben de tenerse en cuenta antes de terminar un Incremento. Esta práctica mejora la transparencia de los Incrementos.

El Daily Scrum es una reunión de sincronización

Falso. El objetivo del Daily Scrum es tener una oportunidad diaria para Inspeccionar y Adaptar. El resultado del Daily Scrum es un Sprint Backlog actualizado con un plan para las próximas 24 horas y lo que va a ocurrir en los próximos días. Muchos equipos acuden al Daily Scrum y se limitan a decir lo que han hecho y lo que harán, o para comunicar impedimentos. Muy pocos realmente tienen un Sprint Backlog actualizado después del Daily Scrum.

Los ítems del Product Backlog deben estar estimados

Verdadero. Scrum dice que los ítems del Product Backlog deben estar lo suficientemente refinados y ser suficientemente pequeños para ser potencialmente entregables al final del Sprint y, además, estar estimados. Scrum no dice si esta estimación debe ser hecha en Puntos de Historia, mediante Slicing u otras técnicas. La estimación es necesaria porque mejora la transparencia y la inspección.

Esto significa que algunos ítems del Product Backlog, los que están más arriba estarán más refinados y mejor estimados y otros, los que estén más abajo, no lo estarán.

Un Product Owner por equipo

Esta es una falacia. Lo que es necesario es un Product Owner por producto. Uno. No más. Es posible tener representantes del Product Owner o Proxy Product Owners en los equipos, y siempre las decisiones serán tomadas por el único Product Owner.

Aquí es donde los Analistas de Negocio pueden jugar un papel fundamental, estando integrados en cada equipo y ayudando al Product Owner en sus tareas.

El Daily Stand-Up tiene que ocurrir con todo el equipo junto de pie

Falso. El Daily Stand-Up no existe en Scrum. Se llama Daily Scrum y puede ocurrir de pie, sentado o a través del teléfono. El Stand-Up es una práctica de eXtreme Programming.

El Scrum Master facilita las retrospectivas

Falso. No sólo no tiene obligación de facilitar las retrospectivas sino que además tiene que participar de ellas. Muchos Scrum Masters comenten el error de que facilitar retrospectivas es su responsabilidad y muchos de ellos no participan como uno más durante la retrospectiva. El Scrum Master es un miembro más del equipo Scrum y, como tal, tiene en la Retrospectiva un espacio perfecto para Inspeccionar y Adaptar el proceso.

El Scrum Master tiene que estar en el Daily Scrum

Falso. El Scrum Master tiene que asegurarse de que existe un Daily Scrum, que este dura como máximo 15 minutos y que se utiliza para mejorar la transparencia del Incremento en proceso. No tiene por qué atender físicamente al evento ni facilitarlo.

Las estimaciones tienen que estar hechas en Puntos de Historia (Story Points)

Falso. Los Story Points son una técnica más para estimar ítems en el Product Backlog. Hay muchas otras técnicas que son igual de efectivas -o más- que los Story Points. Los Story Points no se pueden cambiar de un equipo a otro y son una visión subjetiva de la estimación hecha por un equipo determinado.

Las estimaciones se pueden usar para medir la productividad y predecir cuando un producto estará terminado

Falacia. Uno de los mitos y falacias de Scrum mas típicos. La única manera de medir el progreso en Scrum es software finalizado y listo para entregar al cliente. Eso puede cambiar de Sprint a Sprint dependiendo del entorno. Scrum es genial para desarrollar productos en entornos complejos. Realizar estimaciones en entornos complejos basados en estimaciones subjetivas no sólo es infantil (o wishful thinking) sino que además es peligroso.

Una buena herramienta para reducir la incertidumbre es usar “conos de incertidumbre”. Cuanto más grande sea el Product Backlog, más difícil será tener estimaciones precisas.

El Product Backlog solo puede contener Historias de Usuario

Mito. El Product Backlog debe contener cualquier tipo de tarea necesaria para asegurar que el producto queda como el Product Owner quiere. Esto puede incluir tareas técnicas, documentación o tipos de testing. El uso de una Definición de “Hecho” reduce la complejidad para tareas recurrentes que deben ser completadas cada Sprint

Los requerimientos no funcionales tienen que estar en el Definition of Done

Otro de los mitos y falacias de Scrum. Los requerimientos no funcionales (estabilidad, rendimiento) también pueden estar en el Product Backlog.

El Scrum Master no es un puesto de management.

Falacia. El Scrum Master es un puesto de Management, ya que gestiona el proceso Scrum.

El equipo de desarrollo o el Scrum Master no pueden cancelar un Sprint

Verdadero. El Sprint sólo puede ser cancelado por el Product Owner, cuando este ve que no tiene sentido terminarlo, principalmente debido a que los ítems del Sprint Backlog ya no tienen valor.

Equipo Scrum tiene que tener 7 +/- 2 personas

El ultimo de esta serie de mitos y falacias de Scrum. Scrum recomienda que el tamaño del equipo de desarrollo sea de 3 a 9 personas, pero no prescribe que éste sea el número necesario de personas en un equipo Scrum. El tamaño de un equipo Scrum debe de medirse atendiendo a las necesidades del Transparencia, Inspección y Adaptación