¿Ignorar Scrum para ser más Agile?

Hablando con un amigo sobre agile, me hizo una pregunta interesante: a veces Agile y Scrum encajan mal, especialmente con las reuniones. Aquí van mis reflexiones.

“¿Crees que tendría sentido simplemente usar agile e ignorar scrum (sprints) completamente en una empresa basada en producto? Siento que es difícil ser agile cuando tienes 10 horas de reuniones por semana.” Filip G.

Esto conecta con la esencia de Extreme Programming: el primer valor es la Comunicación Efectiva.

“Probablemente algunas empresas no saben usar bien las reuniones y las hacen por costumbre.” Filip G.

No diría ignorar Scrum del todo. Scrum (bien hecho) es un gran “Framework de Gestión de Producto”. Para entenderlo mejor recomiendo: Scrum: The Art of Doing Twice the Work in Half the Time.

El problema principal con Scrum hoy es que la gestión tomó el control y los desarrolladores no saben practicarlo de forma realmente Agile. Ahí empieza el problema. Recomiendo Zombie Scrum Survival Guide, un libro divertido y fácil de leer que aborda los problemas típicos de equipos Scrum.

No es “Agile sí, Scrum no”. Son compatibles. El reto es enfocar los procesos del equipo desde una perspectiva agile.

Agile en pocas palabras

Recientemente escribí un post sobre fundamentos agile, que te recomiendo leer para entrar en los detalles: Trabajando agile con equipos no agile. Pero, el tl;dr: Agile es sobre retroalimentación rápida. Es sobre comunicación efectiva y reducir desperdicio mientras se apunta a la simplicidad.

Agile es sobre mantener estos valores siempre presentes:

• Individuos e interacciones sobre procesos y herramientas
• Software funcionando sobre documentación extensiva
• Colaboración con el cliente sobre negociación de contratos
• Responder ante el cambio sobre seguir un plan

Aunque hay valor en los elementos de la derecha, valoramos más los elementos de la izquierda.

Scrum en pocas palabras

Scrum es un framework de gestión de proyectos orientado al desarrollo de software, aunque se usa en ventas, marketing y más. Está pensado para equipos de 5-9 personas (ver número de Dunbar) autónomos y responsables de dividir su trabajo en partes pequeñas para completar en iteraciones llamadas sprints (1, 2 o 4 semanas).

Las ceremonias/reuniones típicas son:

• Stand-up: 15 min (o menos) para sincronizar al equipo y actuar si alguien está bloqueado o necesita ayuda.
• Refinement: ~2h para asegurar que los tickets están listos antes de planificarlos.
• Planning: ~2h para planificar el trabajo del siguiente sprint.
• Demo/Review: ~2h para mostrar el trabajo hecho al equipo, stakeholders e interesados.
• Retrospectiva: ~2h para que el equipo reflexione y mejore.

La pregunta clave es cómo organiza tu equipo estas reuniones y, sobre todo, si son efectivas. Estas son solo algunas de las reuniones de cualquier “Equipo Scrum”.

Pero además de estas, se acumulan muchas otras reuniones. De pronto el día entero se ha ido y sientes que no has producido el valor esperado. Si tu trabajo no consiste en estar en reuniones constantemente, algo está mal.

Reuniones aburridas

¿Has estado alguna vez en una reunión pensando “Esto es aburrido, qué pérdida de tiempo…”? Yo lo he vivido más de una vez. ¿A quién culpar? Esa suele ser la primera pregunta. Seguida de: “Mi jefe, obviamente. Él organizó esta reunión, me invitó, estoy obligado a asistir, y esta pérdida de tiempo es su culpa.”

No creo que sea una respuesta honesta. Culpar a otros y alejar responsabilidades es mucho más fácil que mirarse a uno mismo.

“Estoy obligado a asistir, y esta pérdida de tiempo es su culpa” puede ser cierto. Quizás estabas obligado y estás perdiendo el tiempo. Pero, ¿de verdad no hay forma de actuar al respecto?

Cuando algo no funciona como espero (no me gusta el resultado, creo que algo está mal), antes de culpar a otros prefiero reflexionar: ¿cuál es la raíz del problema? ¿Qué puedo hacer para mejorar la situación?

¿Qué puedes hacer al respecto?

Volviendo al tema de “muchas reuniones”: si estás en una que se siente mal o aburrida, pregúntate:

¿Me aburro? ¿Por qué? ¿Quizás no participo en el resultado de la reunión? Si es así, ¿mi presencia es realmente necesaria? ¿Podría pedir un resumen después y salir para hacer algo más productivo?

O al revés: ¿está bien aburrirse en esta reunión? ¿Debería participar más y contribuir al resultado?

Veo este patrón:

• Si la reunión no aburre, es productiva y dará buenos resultados para todos.
• Si aburre, hay dos opciones: A) está bien que aburra, pide salir educadamente y pide el resumen después; o B) no está bien que aburra porque tu participación es necesaria. Involúcrate más con tus compañeros y la reunión dejará de ser aburrida.

Hay muchas estrategias. Depende de ti actuar cuando veas algo mejorable.

Está bien señalar el “elefante en la habitación” y pedir ayuda para mejorar cualquier situación que sientas que no funciona como debería.