Errores que se cometen dentro del marco Scrum

Hola a todos, en las próximas entregas seguiremos conversando un poco más sobre Scrum, pero no desde una base teórica, sino desde un punto basado en la experiencia y la práctica. Tendremos una serie de posts relacionados al uso incorrecto del marco, o de los roles. El día de hoy nos vamos con usos incorrectos o malas prácticas al aplicar Scrum.

Increíblemente aunque no lo crean, la mayoría de los equipos con más problemas son aquellos que tienen muchos años; por supuesto,

también es común en los que no tienen experiencia trabajando en ello.

Situaciones que pueden darse con el tiempo cuando por una razón u otra se pierde el enfoque, o desde un inicio para ser honestos cuando no se tiene la experiencia, estas son algunas de ellas:

• Tener mucho WIP (Work in Progress)

Un equipo con mucha experiencia, no inicia una actividad hasta haber terminado la anterior, permitiendo que el trabajo en paralelo disminuya.

Cuando termina el sprint, muchas de las actividades se pueden encontrar en estado In progress, y esto puede provocar que no se realice la integración correspondiente, En este tipo de situaciones el PO (Product Owner) suele empujar para poder lograr resultados más tangentes en la próxima Sprint Review, al mismo tiempo que el equipo de desarrollo continúa añadiendo lo que se conoce como deuda técnica, al backlog.

• No existe un Sprint Goal

El Sprint Backlog va acumulando cada vez más y más requerimientos que en muchos casos ni siquiera están relacionados entre sí, lo que provoca que no haya coherencia y que se distorsione la transparencia y el desarrollo iterativo e incremental en el proceso.

El Sprint Goal, es como se autodefine, la meta del sprint, el foco y objetivo que ayuda al equipo a tener claro el objetivo de este incremento. El Sprint Backlog cambia constantemente, pero el Sprint Goal no. Tener esta flexibilidad nos per

mite lidiar con situaciones o cambios que no estaban contemplados y nos ayuda a tener mayor claridad de lo que busca el negocio.

Sin la existencia de un sprint goal perdemos la dirección, dado que es una herramienta tan potente y relevante, que impacta en valores de scrum como el compromiso y el coraje.

• Responsabilidad

El rol responsable de responder respecto al incremento es el equipo de desarrollo. No nos confundamos, cuando decimos equipo de desarrollo nos referimos a todos los integrantes del mismo.

No debe existir en Scrum la individualidad del desarrollador. Lamentablemente, esto ha provocado que en muchos casos algunos miembros del equipo se sientan incómodos y se quejen, ya que entienden que como ellos han cumplido con sus asignaciones, no debería afectarles de igual manera.

Una de las formas de proceder, y en muchos casos la mejor opción, es dejar que sea el mismo equipo que se auto-organice y lidie con dichas situaciones. Y por su lado, la del Scrum Master debe ser que esta conversación se mantenga o realice dentro del equipo, sin necesidad de que tenga que ser escalado en la organización, no como ocurre en algunas situaciones, que actúa sobre los miembros que considera o entiende destacan o no. Finalmente el Product Owner, él es el responsable de la inversión y enfoque que realiza el equipo de desarrollo en cada Sprint. Para fines ejecutivos en muchos casos, debe proporcionar datos, por lo que debe ser capaz de medir indicadores durante el sprint, debido a que si la calidad técnica del producto decae, el PO se convertiría a la vuelta en el responsable.

• Asignación de actividades de forma individual

De forma inicial no debería ser un problema si posterior a esto tenemos una integración conjunta, sin embargo lo que sucede en muchos casos es que el desarrollador realiza todo el proceso de forma individual y al final aparecen conflictos con otras integraciones y con otras dependencias.

Algunas de las alternativas para lidiar con estos casos es el code review, normalmente sugerido dos reviewers por PR (pull request) así como el pair programming que también es otra alternativa utilizada, sin embargo, no tanto efectiva cuando existe una gran carga de trabajo.

Lamentablemente una de las formas más efectivas de lidiar con esta situación, es reducir la carga de trabajo asignada al equipo. Con esto logramos reducir la deuda técnica y aumentar el valor en la entrega de producto. Porque aunque la entrega no sea muy grande, se suele cumplir más con los tiempos y los entregables, y se asegura que los mismos sean de mayor calidad.

• Aumentar la utilización o eficiencia

Este es uno de los más habituales y peores que puede suceder, las organizaciones suelen cometer el error de pensar que mientras más tiempo dedique al proyecto más rápido obtendrá resultados, ¿pero a qué costo?

No nos sirve tener al equipo dedicado durante más de 8 horas (hasta horas extras) para no obtener el valor esperado en el entregable. No nos confundamos. Hay dos objetivos diferentes, Una cosa es entregar a tiempo y otra es entregar valor y calidad, sin embargo están relacionadas.

Por su naturaleza, debemos entender que cuando hablamos de desarrollo de software, no existe como tal un estándar referente a las actividades, problemas, estimaciones y buenas prácticas, es demasiado variable. Los proyectos por definición son algo único, en el caso del desarrollo de software se aplica de la misma forma, por más similar que parezca a otro siempre es diferente, basándonos en las necesidades del negocio, las cuales nunca son las mismas.

Es normal ver equipos sobrecargados, por el simple hecho de evitar que estén detenidos, se comienza a generar trabajo innecesario para agregar valor solo para que el equipo siempre tenga algo que hacer. Como resultado tenemos que, cuando realmente se requiere de ellos para avanzar en algo que sí genera un valor real y tiene prioridad, están ocupados en otras actividades.

• Pensar que el equipo de desarrollo son solo los desarrolladores.

En Scrum, el Development team o equipo de desarrollo, no está compuesto solamente de recursos técnicos, como arquitectos, desarrolladores o QAs; el rol del equipo de desarrollo posee los perfiles necesarios para generar un entregable, mejor dicho un incremento del producto, por tanto incluye de ser necesario recursos más funcionales como un BA (Business Analyst), UI/UX para la parte de diseño, incluso un conocedor de SEO (Search Engine Optimization), y estos también son considerados parte del equipo de desarrollo.

Existen otras situaciones que se puedan presentar aplicando este marco de trabajo, pero si identificas que en tu equipo se materializan o se aproximan a alguna de estas situaciones, puedes considerarlo una voz de alerta de que el proceso de Scrum no se está desarrollando o aplicando adecuadamente.

“Hay dos grandes días en la vida de una persona: el día que nace y el día que descubre por qué.”

JOHN MAXWELL

Infografia: https://www.freepik.com/