Las 11 trampas de la metodologa Scrum

La metodologa Scrum es una de las ms extendidas de los mtodos giles de gestin de

proyectos. Cada vez son ms las empresas que se deciden a probar este enfoque,
reafirmndose en su eleccin tras comprobar los primeros resultados positivos. Sin
embargo, lo que muchos no saben es que, incluso quienes alcanzan el xito aplicando la
metodologa Scrum suelen caer en algunas trampas, ms comunes de lo que pudiera
pensarse.

Evita los errores ms frecuentes al trabajar con la metodologa Scrum

La metodologa Scrum tiene sus propias reglas, que la diferencian de otros enfoques de
gestin de proyectos giles y, an ms de formas ms tradicionales de abordarlos. Y,
precisamente, en estas particularidades es donde suelen presentarse los problemas.
Cuestiones que tienen que ver con:

- Ardua planificacin: no hay que excederse en la preparacin puesto que hacerlo es ir

directamente en contra de todo lo que la metodologa Scrum implica. No es necesario,
supone una prdida 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 retroalimentacin que va recibiendo, que es donde ha de encontrar las
directrices que le permitirn seguir desarrollando sin perder el ajuste necesario con los
objetivos.

- Eleccin tecnolgica: 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 solucin de software sin conocer bien el mtodo 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 reunin debe tener una duracin 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 estn haciendo las cosas bien. La resolucin de problemas y otros asuntos de inters
para el proyecto pueden tratarse en reuniones aparte, a las que slo acudan los interesados.

- Asignacin de tareas: este concepto no existe como tal en la metodologa Scrum. No

existe ningn tipo de lder cuyo cometido sea imponer tareas a los miembros del equipo. Si
la autogestin 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
ejecucin a atribuirsela a cualquiera de los desarrolladores, como una decisin unilateral.

-Scrum Master participativo: por ms 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 funcin. En la metodologa Scrum no existen
demasiadas reglas, pero una de ellas es la que determina que el Scrum Master no debe
participar en el desarrollo ms all de como simple observador, eliminando obstculos
y previniendo interrupciones.

- Participacin del propietario del producto: en la prctica sucede que, pese a que el
propietario del producto se compromete a comparecer en todas las reuniones diarias,
termina desapareciendo progresivamente, hacindose cada vez ms difcil de localizar. Al
principio se salta los encuentros para la planificacin o la revisin y, progresivamente, va
espaciando su participacin en los scrums diarios. Su visin es importante y debe estar
presente en todas estas reuniones, como tambin disponible durante el curso de los
trabajos.

- Metas ajustadas: aumentar la presin sobre el equipo engrosando el volumen de tareas

asociadas a cada sprint o ajustando su deadline hasta lmites arriesgados es una estrategia
peligrosa. No slo se incrementa la propensin a errores, sino que el equipo sufre un
estrs que no era necesario y que puede terminar haciendo mella en su motivacin y nivel
de productividad.

- Cabezas visibles en el equipo: la fuerza del grupo de desarrollo en proyectos Scrum

proviene de la cohesin, la unin 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 comn. El desgaste de un
componente de esta maquinaria casi perfecta puede tener consecuencia muy negativas para
los resultados globales, no slo en el proyecto presente. Hay que prestar atencin a los
sntomas de burn out para prevenirlo a tiempo.

- Interrupciones: el Scrum Master debe evitarlas a toda costa pero, en la vida real,
quienes las causan estn armados con todo tipo de excusas para lograr sus objetivos. Una de
las ms 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 dinmica Scrum slo 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 retroalimentacin entre uno y otros debe ser continua a lo
largo de todos los das 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 ncleo de los miembros cambia hay que volver
a iniciar el proceso de formacin y normalizacin, es preciso volver a adaptarse al trabajo
de nuevo y supone, en cualquier caso la prdida de una inversin en tiempo y recursos que
puede prevenirse si se cuida a estos profesionales y se asegura la calidad de sus condiciones
de trabajo.