El objetivo de este artículo es describir casos en los que el marco Scrum es mal utilizado — a veces a propósito — , lo que lleva como consecuencia a la explotación del equipo de desarrollo. Cubriremos los siguientes temas:
¿Listo? ¡Comencemos!
Según scrum.org —la casa de scrum — Scrum es unmarcodentro del cual las personas pueden abordar problemas adaptativos complejos, mientras entregan productos del mayor valor posible de manera productiva y creativa. Piensa en ello como una forma de hacer el trabajo en equipo en pequeñas partes a la vez, con ciclos de experimentación y retroalimentación en el camino.
Scrum reemplaza un enfoque algorítmico por uno heurístico, conrespeto por las personas y la autoorganización para lidiar con la imprevisibilidad y resolver problemas complejos.
Este gráfico representa muy bien todo lo que implica el marco Scrum.
Los eventos prescritos se utilizan en Scrum para crear regularidad y minimizar la necesidad de reuniones no definidas en Scrum. Los Eventos Scrum son:
Los artefactos de Scrum representan trabajo o valor para brindar transparencia y oportunidades de inspección y adaptación. Los artefactos de Scrum son:
Los Sprints son el latido del corazón de Scrum, donde las ideas se convierten en valor. Son eventos de duración fija de un mes o menos para crear consistencia.
Todo el trabajo necesario para alcanzar el objetivo del producto a desarrollar, incluyendoSprint Planning,Daily Scrums,Sprint Review ySprint Retrospective, ocurre dentro de Sprints.
Estos valores son los siguientes:
A pesar de ser un marco muy famoso, los Valores de Scrum no siempre se tienen en cuenta.
Según scrum.org, el Scrum Master es responsable de establecer el marco Scrum como se define en la Guía de Scrum. Lo hace ayudando a todos a comprender la teoría y la práctica de Scrum, tanto dentro del equipo Scrum como en la organización.
Vamos a desglosarlo. Cuando dicen “…estableciendo Scrum como se define en la Guía Scrum” debes saber quenadie debe inventar sus propias reglas. Todo debe estar de acuerdo con la Guía Scrum.
Ahora, cuando dicen “…ayudar a todos a comprender la teoría y la práctica de Scrum…”, se refieren a que el Scrum Master puede actuar como instructor (una persona que enseña algo) o como coach (una persona que ayuda a un alumno a lograr un objetivo específico personal o profesional proporcionando formación y orientación). Basado en lo anterior, el Scrum Master debe guiar al Equipo Scrum para mejorar sus prácticas dentro del marco Scrum yasegurarse de que todos lo sigan a fondo.
El Scrum Master, además de servir alProduct Ownery a la organización, también sirve al Equipo Scrum de varias maneras, entre ellas:
Sí, si es que se usa de mala manera como veremos.
El propósito del proceso de estimación es crear una comprensión compartida de la tarea por delante entre todos los miembros del Equipo Scrum. Esta estimación se puede realizar en cualquier momento antes o incluso durante la planificación del Sprint, siempre que permita al equipo comprometerse con un pronóstico para el próximo sprint.
La estimación nos ayuda a saber si una tarea es lo suficientemente pequeña como para incluirla en un Sprint.
Imagina que tienes que estimar para las siguientes tareas:
¿Qué tan seguro te sientes al estimar estas tareas? Una forma de abordar este problema de estimación es utilizandopoker planning.
En poker planning, el número en cada carta representa estimaciones relativas del esfuerzo (también conocido como puntos de historia y es mejor que tengas cuidado de no tomarlos como horas o días). La idea aquí es fomentar la discusión. Si yo dijera 1 unidad de esfuerzo y tú dijeras 5 unidades de esfuerzo, ¿qué debería pasar? Muchos equipos tienden a tomar el promedio (3 en este caso). Gran error. Al hacerlo, se pierde la esencia de esta técnica, que es discutir y llegar a un consenso. En este escenario, se esperaría que el junior que dijo 5 unidades de esfuerzo logre esa tarea dentro del tiempo que normalmente toma una tarea de 3 unidades de esfuerzo, lo que lo frustrará si no cumple con las expectativas.
Ten cuidado de tratar las estimaciones como fechas límite. Si se estimaron muy pocos puntos de historia para esa tarea, es posible que no se complete en el Sprint y, por lo tanto, no se cumpliría el compromiso del Sprint. Si el desarrollador se ve obligado a llevarse el trabajo a casa, ¿de qué tipo de respeto por las personas estamos hablando en los Valores del Scrum?
Otro caso es cuando sólo se toma el juicio de los gurús. Para los jóvenes, esto puede parecer como jugar en modo difícil.
El Daily Scrum esun evento (solamente 1) de 15 minutosal día para los Desarrolladores del Equipo Scrum. El propósito del Daily Scrum es inspeccionar el progreso hacia la meta del Sprint yadaptar el Sprint Backlog según sea necesario, ajustando el próximo trabajo que se tenía planificado.
Contrario a la creencia popular, el Daily Scrum no es una reunión para dar el estado.
En un Daily Scrum cada miembro del equipo debe responder estas tres preguntas:
Imagina que dices que vas a terminar una tarea hoy, por presión social o lo que sea. Sin embargo, no puedes terminarlo. ¿Qué pasará al día siguiente? Dos alternativas:
UnDarth Scrum Mastero incluso unEvil Product Owner pueden usar esta situación para hacerte sentir que estás atrasado y que debes trabajar horas extra para terminar con esos pendientes y así ayudar al equipo a alcanzar la meta del Sprint.
La Retrospectiva del Sprint es donde el Equipo Scrum busca mejoras en sus procesos y colaboración. Si algo está mal, es importante ponerlo sobre la mesa. Ya sea relacionado con el proceso, con el equipo o con la relación del equipo con sus líderes. Pero, si los líderes se han estado comportando como capataces y luego piden retroalimentación al equipo… se obtendrá poca o ninguna retroalimentación útil. ¡Como si todo fuera de color rosa!
Otro caso que se puede presentar es cuando se señala con el dedo al responsable de que no se alcance el objetivo del Scrum. Este “señalar y culpar” definitivamente baja la moral de esa persona, ¿no crees?
Para mayor información, recomiendo las siguientes lecturas:
Y puedo ayudar a tu empresa a no caer en el Lado Oscuro del Scrum.
Si presionas 50 veces el botón de 👏 y algo maravilloso sucederá.
I think therefore I write (and code!) | VP of Engineering @Stealth Startup | Founder @Data Engineering Latam community | More stuff:beacons.ai/davidregalado