He oído hablar de problemas con varios proyectos últimamente. Funciona así:

  • Quieren utilizar un proceso ágil y eligen Scrum
  • Adoptan las prácticas de Scrum, y tal vez incluso los principios
  • Después de un tiempo, el progreso es lento porque la base de código es un desastre.

Lo que sucedio es que no han prestado suficiente atención a la calidad interna de su software. Si cometes ese error, pronto verás cómo tu productividad se reduce porque añadir nuevas funciones es mucho más difícil de lo que te gustaría. Has asumido una deuda técnica abrumadora y tu scrum se ha debilitado. (Y si has estado en un Scrum de verdad, sabrás que eso es malo).

Mencioné Scrum porque, cuando vemos este problema, Scrum parece ser particularmente común como el proceso nominativo que sigue el equipo. Para muchos, esta situación se ve agravada por Scrum, ya que es un proceso centrado en técnicas de gestión de proyectos y omite deliberadamente cualquier práctica técnica, a diferencia de, por ejemplo, Extreme Programming.

En defensa de Scrum, es importante señalar que el hecho de que no incluya actividades técnicas dentro de su alcance no debería llevar a nadie a concluir que no las considera importantes. Siempre que he escuchado a prominentes practicantes de Scrum, han enfatizado que es necesario contar con buenas prácticas técnicas para tener éxito en un proyecto Scrum. No imponen cuáles deberían ser esas prácticas técnicas, pero sí que son necesarias. Después de todo, los proyectos se meten en problemas constantemente por mala calidad interna, y el hecho de que muchos proyectos surjan bajo la bandera de Scrum puede deberse más a su popularidad actual que a algo específico de Scrum. La popularidad y la difusión semántica tienden a ir de la mano.

Entonces ¿qué hacer al respecto?

La comunidad Scrum necesita redoblar sus esfuerzos para asegurar que la gente comprenda la importancia de unas prácticas técnicas sólidas. Sin duda, cualquier revisión de proyecto debe incluir el examen de las prácticas técnicas presentes. Si participa o está conectado con un proyecto de este tipo, protesta si la parte técnica se está descuidando.

Si buscas introducir Scrum, asegúrate de prestar mucha atención a las prácticas técnicas. Solemos aplicar muchas de las técnicas de Extreme Programming y funcionan muy bien. Los expertos en XP suelen bromear, con cierta razón, diciendo que Scrum es simplemente XP sin las prácticas técnicas que lo hacen funcionar. Dejando a un lado las críticas, las prácticas de XP son un buen punto de partida y, sin duda, serán mucho mejores que no hacer nada.

Siempre me gusta señalar que no son las metodologías las que triunfan o fracasan, sino los equipos. Implementar un proceso puede ayudar a un equipo a mejorar su rendimiento, pero al final, es el equipo el que importa y tiene la responsabilidad de hacer lo que le funciona. Estoy seguro de que los numerosos proyectos de Scrum con problemas que se están ejecutando dañarán la reputación de Scrum, y probablemente también la reputación ágil en general. Pero como considero que la difusión semántica es inevitable, no me alarmo demasiado. Los equipos que fracasan probablemente fracasarán con cualquier metodología que apliquen mal; los equipos que tienen éxito basarán sus prácticas en buenas ideas, y el papel de la comunidad Scrum es difundirlas ampliamente.

Mucha gente ve a Lean como la próxima gran revolución ágil. Pero cuanto más popular se vuelve Lean, más se enfrenta a los mismos problemas que Scrum. Esto no invalida Lean (ni Scrum), simplemente nos recuerda que las personas y las interacciones son más valiosas que los procesos y las herramientas.

Nota: Este post es una traduccion de Flaccid Scrum