Escuché un comentario el otro día de un equipo de nuestra organización.
Tan pronto como aumenta la presión de liberación, las ceremonias de scrum se descuidan.
Pensé en conversar con Scrum Master y tener una sesión con nuestra organización sobre este tema porque creo que esto podría afectar a más de un equipo. No estoy seguro de cómo abordar esta reunión porque sé que todas las ceremonias son importantes.
Las ceremonias Scrum son elementos importantes del proceso ágil de entrega de software. No son simplemente reuniones por el hecho de tener reuniones. Más bien, estas ceremonias de scrum brindan el marco para que los equipos realicen el trabajo de manera estructurada, ayudan a establecer expectativas, capacitan al equipo para colaborar de manera efectiva y, en última instancia, generan resultados. Sin embargo, si no se administran adecuadamente, pueden abrumar los calendarios y ahogar el valor que se supone que deben proporcionar.
Al momento de escribir esto, no sé qué significa "descuidado" en el contexto de este equipo, pero igual tendré una reunión. El punto es que no se trata de si están haciendo estas cosas a la perfección o no, sino de que las están haciendo. Cada una de las ceremonias tiene una razón muy particular para su existencia y uso continuado, por lo que queremos centrarnos en esas razones, no ceñirnos a una definición innecesariamente rígida de lo que está "bien" o "mal".
La agilidad requiere que nos adaptemos a las condiciones cambiantes, pero comienza con la adopción de procesos que nos hacen más propensos a hacer las cosas correctas en los momentos correctos.
¿Tienes algún consejo cuando hable con los equipos?
El éxito a largo plazo se descuida por el éxito a corto plazo.
Una reunión como la retrospectiva lleva su tiempo y nada malo sucede inmediatamente si se cancela. Debe dejar en claro que las ceremonias de Scrum son a largo plazo.
Si no los hace, el equipo no crecerá e incluso podría acumular deudas técnicas en el camino al perder oportunidades para mejorar. Esto se debe principalmente al hecho de que la comunicación en ciertas partes deja de ocurrir.
Por lo tanto, señale que el tiempo invertido generalmente se recupera por un factor más importante, pero requerirá tiempo y paciencia.
Puedo tener una opinión ligeramente diferente al resto de las respuestas.
La estructura Scrum debe ser la herramienta que ayude a alcanzar los objetivos más rápido. La planificación efectiva, la revisión, el retro y el scrum diario deberían reducir el tiempo total dedicado a las reuniones y permitir que los equipos cambien según sea necesario para tomar siempre el mejor camino a seguir. Cuando el estrés es alto, es cuando esos eventos deberían rendir más. Así que esto plantea la pregunta: ¿por qué no lo son?
La razón más común que he encontrado es que los equipos son juzgados por su rendimiento, no por sus resultados; ese éxito se basa en la finalización de las tareas, no en la resolución de problemas y en la creación de productos efectivos. Sin embargo, no se ancle demasiado a esto. Sea genuinamente curioso y descubra por qué Scrum no está resolviendo el problema que debería.
Lamentablemente, esta es una situación que enfrentan muchos equipos en organizaciones que no entienden completamente cómo funciona Scrum.
El jugador clave en esto es el Scrum Master.
Los dos elementos principales del rol de Scrum Master son ayudar al equipo a eliminar impedimentos y garantizar que sigan Scrum. Abandonar las reuniones debido a los plazos es un buen ejemplo de una situación en la que el Scrum Master debería defender el método Scrum.
Los pasos que seguiría como Scrum Master en esta situación son:
Si después de hacer eso, el equipo (o alguien fuera del equipo) insiste en que se eliminen las ceremonias, informaré sobre el impacto. Por ejemplo, podría escribir un informe de sprint que diga algo como:
El equipo se negó a realizar una retrospectiva en este sprint para tener más tiempo para dedicarlo al desarrollo de características. Esto significa que no tuvimos la oportunidad de abordar varios problemas que están afectando el rendimiento del equipo. Como resultado, es probable que al no realizar la retrospectiva hayamos reducido la cantidad que podemos ofrecer de manera sostenible, en lugar de aumentarla.
¿Qué significa realmente "liberar presión" en el contexto de su(s) equipo(s)? A veces hay bloqueadores técnicos para los lanzamientos. Por ejemplo, ¿es realmente cierto que cada sprint genera un incremento potencialmente liberable? Si hay cosas adicionales que hacer para hacer un lanzamiento, entonces tal vez se podría mejorar la Definición de Listo (es decir, asegúrese de completar esas cosas para cada sprint y no solo cuando quiera lanzar). Quizás el proceso de lanzamiento en sí podría mejorarse. Existen herramientas y técnicas de Dev-Ops que pueden ayudar con eso.
Por otro lado, si el trabajo adicional es la fuente de "presión" (es decir, el PO quiere más), entonces tal vez liberar con más frecuencia ayudaría a suavizar las cosas. Trate de hacer que los lanzamientos no sean un evento en la medida de lo posible.
ricardopalmer
sontabo