Las 11 trampas de la metodología Scrum
La metodología Scrum es una de las más extendidas de los métodos ágiles de gestión de proyectos. Cada vez son más las empresas que se deciden a probar este enfoque, reafirmándose en su elección tras comprobar los primeros resultados positivos. Sin embargo, lo que muchos no saben es que, incluso quienes alcanzan el éxito aplicando la metodología Scrum suelen caer en algunas trampas, más comunes de lo que pudiera pensarse.
Evita los errores más frecuentes al trabajar con la metodología Scrum
La metodología Scrum tiene sus propias reglas, que la diferencian de otros enfoques de gestión de proyectos ágiles y, aún más de formas más tradicionales de abordarlos. Y, precisamente, en estas particularidades es donde suelen presentarse los problemas. Cuestiones que tienen que ver con:
- Ardua planificación: no hay que excederse en la preparación puesto que hacerlo es ir directamente en contra de todo lo que la metodología Scrum implica. No es necesario, supone una pérdida de tiempo y puede provocar retrasos en el inicio del proyecto. En lugar de eso, es recomendable que el equipo comience a trabajar cuanto antes y se centre en la retroalimentación que va recibiendo, que es donde ha de encontrar las directrices que le permitirán seguir desarrollando sin perder el ajuste necesario con los objetivos.
- Elección tecnológica: cuando se pueden automatizar algunos procesos y eliminar determinadas tareas manuales se minimiza el riesgo. Sin embargo, en un entorno Scrum, lanzarse a escoger una solución de software sin conocer bien el método puede conducir al fracaso. Es preferible comenzar sin estos apoyos y, una vez se haya iniciado la marcha, buscar la alternativa que mejor concuerda con las necesidades reales el equipo y el proyecto.
- Scrum diario: esta reunión debe tener una duración moderada. No hay que permitir que se utilice para otros asuntos y, para lograrlo es esencial el rol que juega el Scrum Master. Cuando el daily Scrum deja de ser breve pierde significado y da una pista de que no se están haciendo las cosas bien. La resolución de problemas y otros asuntos de interés para el proyecto pueden tratarse en reuniones aparte, a las que sólo acudan los interesados.
- Asignación de tareas: este concepto no existe como tal en la metodología Scrum. No existe ningún tipo de líder cuyo cometido sea imponer tareas a los miembros del equipo. Si la autogestión no es lo suficientemente proactiva, es preferible recordar la importancia de la actividad y el motivo por el que es necesario que alguien se responsabilice de su ejecución a atribuirsela a cualquiera de los desarrolladores, como una decisión unilateral.
-Scrum Master participativo: por más urgente que sea una actividad, por mucho que al Scrum Master le apetezca erigirse como colaborador y a pesar de que todo el equipo pudiera estar e acuerdo, ésa no es su función. En la metodología Scrum no existen demasiadas reglas, pero una de ellas es la que determina que el Scrum Master no debe participar en el desarrollo más allá de como simple observador, eliminando obstáculos y previniendo interrupciones.
- Participación del propietario del producto: en la práctica sucede que, pese a que el propietario del producto se compromete a comparecer en todas las reuniones diarias, termina desapareciendo progresivamente, haciéndose cada vez más difícil de localizar. Al principio se salta los encuentros para la planificación o la revisión y, progresivamente, va espaciando su participación en los scrums diarios. Su visión es importante y debe estar presente en todas estas reuniones, como también disponible durante el curso de los trabajos.
- Metas ajustadas: aumentar la presión sobre el equipo engrosando el volumen de tareas asociadas a cada sprint o ajustando su deadline hasta límites arriesgados es una estrategia peligrosa. No sólo se incrementa la propensión a errores, sino que el equipo sufre un estrés que no era necesario y que puede terminar haciendo mella en su motivación y nivel de productividad.
- Cabezas visibles en el equipo: la fuerza del grupo de desarrollo en proyectos Scrum proviene de la cohesión, la unión de distintas personalidades y el trabajo en equipo. Nadie tiene que llevar sobre sus hombros el peso de la responsabilidad ni hacerse cargo de todas las tareas que otros no pueden asumir por el bien común. El desgaste de un componente de esta maquinaria casi perfecta puede tener consecuencia muy negativas para los resultados globales, no sólo en el proyecto presente. Hay que prestar atención a los síntomas de burn out para prevenirlo a tiempo.
- Interrupciones: el Scrum Master debe evitarlas a toda costa pero, en la vida real, quienes las causan están armados con todo tipo de excusas para lograr sus objetivos. Una de las más recurrentes es calificar de urgente el tema a tratar. Si éste es el caso, y puede probarse esta urgencia, entonces se debe cancelar el sprint, pero nunca partirlo para tratar otros asuntos o dedicarse a tareas distintas, siquiera por unos instantes.
- Suposiciones: son como jugar con fuego. En la dinámica Scrum sólo hay que basarse en la objetividad de los datos. No valen las opiniones ni las intuiciones. Hay que aplicar esta regla a todos los casos, incluso cuando se dé la circunstancia de que los miembros del equipo no puedan pedir al propietario del producto detalles importantes o aclaraciones sobre el trabajo. La retroalimentación entre uno y otros debe ser continua a lo largo de todos los días del Sprint, y no caben excepciones.
- Abandonos y nuevas incorporaciones: este tipo de situaciones pueden afectar al rendimiento de un equipo de Scrum. Si el núcleo de los miembros cambia hay que volver a iniciar el proceso de formación y normalización, es preciso volver a adaptarse al trabajo de nuevo y supone, en cualquier caso la pérdida de una inversión en tiempo y recursos que puede prevenirse si se cuida a estos profesionales y se asegura la calidad de sus condiciones de trabajo.
