Hoy quiero hablar de esta moda que parece extenderse últimamente de escribir artículos argumentando que Scrum es el mal que destruye a equipos de desarrollo, “mata la agilidad” (Oh, Dios mio … ) o incluso que fomenta las malas prácticas de desarrollo.

Voy a tratar de tocar algunos de los puntos de varios de los posts que han caído en mis manos últimamente. Algunos de los cuales reconozco que me han tocado mucho las narices por el revuelo injustificado y tóxico que generan.

La mayoría de estos artículos que veo parecen (sí, opinión pura) escritos por alguien en alguna de las siguientes circunstancias:

  • Nunca ha leído la guía de Scrum
  • Nunca ha trabajado con Scrum
  • Ha tenido la mala suerte de trabajar en un lugar donde Scrum se ha implementado realmente mal. (Lo cual es cierto que debe ser una tortura y sinceramente me da lástima)
  • Es alguien muy partidario de la gestión a través del control
  • Pretende que los desarrolladores tomen el control absoluto de todo, olvidando las necesidades de negocio

Venga, voy con algunos de los argumentos típicos que estoy harto ya de leer.

En Scrum no se cuida la calidad

No es cierto. En ningún momento se habla en Scrum de eso sino más bien de todo lo contrario.

Nadie (ni siquiera el Scrum Master) le dice a un equipo de desarrollo cómo hacer su trabajo. Los únicos responsables del nivel de calidad del código son los integrantes del equipo de desarrollo. La calidad no se negocia en Scrum. Es un hábito.

Nadie le dice al equipo el volumen de trabajo que introducen en el Sprint Backlog, por lo que nadie les obliga tampoco a correr para cerrar las cosas con poca calidad porque hay demasiado trabajo.

De hecho los equipos disponen de una definición de hecho que, entre otras cosas, les protege de tener que entregar basura sólo para cumplir plazos.

Cito textualmente:

As Scrum Teams mature, it is expected that their definitions of “Done” will expand to include more stringent criteria for higher quality.

A los Product Owners les da igual la calidad

Meeeec. Mentira. O generalización, al menos.

Un Product Owner vela por la calidad del producto y entiende que esa calidad pasa, entre otros muchos factores por el indice de errores, por la calidad del código.

Evidentemente ese no es su foco. Pero utilizar que eso no es su foco para sostener el argumento de que en Scrum no se cuida la calidad es como mínimo olvidar que en el equipo de Scrum se trabaja a través de la colaboración. En mi opinión es tratar además al equipo de desarrollo como a niños pequeños a los que no se les supone capaces de hacer valer su criterio técnico.

Por cierto que Scrum no entra en cómo el equipo técnico ejecuta su trabajo. Nada impide a un equipo (de hecho es lo deseable) incorporar a su trabajo prácticas de otras metodologías tipo Extreme Programming u otras. Ya sea TDD, Pair programming, Code Reviews … lo que el equipo considere que les funciona y tiene sentido para ellos.

La falta de jerarquía en el equipo de desarrollo no funciona

¿Dónde no funciona? ¿En qué equipo? ¿Cuando y por qué?

Otro argumento blando.

Tener un equipo con igualdad de responsabilidades favorece el liderazgo emergente. Y sí, esto ocurre y funciona y además lo veo casi a diario. Lo que pasa es que exige no creerse que uno es más listo que los demás y dejar que cada uno de un paso adelante cuando es el momento adecuado.

Habrá un desarrollador que tome la delantera en algún caso porque se acomete algo que para él está dentro de su área de experiencia, en otros casos otra persona porque lleva más tiempo con esa base de código, en otros quien tiene un momento de mayor creciemiento profesional …

Tener la obligación de incluir un “jefe del código” en cada pequeño grupo de desarrolladores, designado con su buena chapa de sheriff, puede producir situaciones en las que el criterio de esa persona es el que se tiene que imponer únicamente por título. Y la autoridad se gana, no se impone. Provoca la dependecia total de esa persona y un grado menor de implicación del resto, puesto que sólo tienen que estar atentos a lo que diga quien manda que ellos ya ejecutarán.

Pero además … si algo va mal ¿va a ser sólo responsabilidad de esa persona? ¿O entonces sí nos va a ir bien que la responsabilidad del desarrollo sea de todo el development team?

Que el equipo de desarrollo comparta responsabilidad posibilita además que todos sean libres de entrar a formar parte de una tarea por el bien común, para asegurar la entrega de producto y que no exista la propiedad sobre los elementos del backlog cuando alguien empieza a trabajar en implementar algo.

Con Scrum no se puede subir software tan a menudo

Lo primero me gustaría saber qué plazo de tiempo es “tan a menudo”, porque las ideas románticas del pasado a veces distorsionan la realidad de lo vivido.

El tema es que eso es completamente falso. Scrum habla de tener al final del sprint un incremento de producto potencialemente desplegable en producción. Nunca, en ningún punto, dice que no puedas ir haciendo mútliples entregas y múltiples subidas.

Lo que un equipo no debería admitirse a sí mismo es dar por bueno que un Sprint acabe y no haya una entrega de producto terminada.

Si tu sistema de desplieque lo permite y tiene sentido en tu empresa ¿por qué no hacer cinco despliegues al día? Minimizas el riesgo por acumulación de desarrollos, recoges feedback de manera mucho más frecuente y aportas valor de manera continua.

Los sprints producen presión

Este argumento me parece hasta ingenuo.

Trabajar con un time-box es una manera de conseguir entre otras cosas:

Minimizar el riesgo. Trabajando con un tiempo máximo, se asegura que en caso de error, si hay cambio de intenciones, si el desarrollo no va por donde se esperaba … el riesgo de perder demasiado tiempo y dinero sea mucho menor. Y sí, he escrito “dinero”, porque estamos desarrollando un producto y el sueldo de todos no se paga con buenas intenciones y ganas de hacerlo muy bien sino con el producto que se entrega de manera continua.

Responsabilidad ante la entrega. Lo que sí que produce un Sprint es responsabilidad por entregar producto. Los equipo se acostumbran a acotar su trabajo en iteraciones controladas que saben que deben entregar. Y es que hay que entregar. Insisto. Es que puede parecer una obviedad pero un desarrollo que se eteniza por infinitas razones es un agujero negro de tiempo y dinero y hay que hacerse responsables de eso.

Voy a volver a escribir esto: Nadie obliga al equipo de desarrollo a asumir una cantidad de trabajo determinada. Por lo que ellos deben gestionar (que es parte de volverse más profesional) la cantidad de trabajo que estiman que pueden llevar a cabo en un tiempo determinado. Es su responsabilidad no asumir cantidades inmanejables de tareas y luego no cerrar.

Es curioso porque la gente se enfadaría mucho si va a un restaurante y porque admiten a más clientes de los que pueden atender tardan cuarenta minutos en traerle cada plato, pero nos cuesta entender que a los clientes a quienes les entregas software (sí, también si tu cliente es tu propia empresa) también le debes entregar lo que has acordado que le entregarás al final del Sprint.

Otra historia

Me dejo para otro artículo en profundidad el hecho de que este tipo de argumentos y artículos parece, deliberadamente o no, obviar no sólo que los equipos trabajan en su propia mejora Sprint tras Sprint, sino que Scrum se fundamenta en cinco valores que son fundamentales para el equipo Scrum y que aseguran el funcionamiento de todo lo demás dentro de un ambiente sano y profesional.

  • Corage
  • Apertura
  • Foco
  • Compromiso
  • Respeto
Anuncios

One thought on “Haters de Scrum: la guía Scrum es de libre lectura

  1. Buenas,

    Voy a estrenar los comentarios. Te añado alguna más:
    – Se pierde mucho tiempo en reuniones. Este sale especialmente en empresas en las que tienen 40 reuniones al día y resulta que no son capaces de sacar, por ejemplo, 5 horas cada tres semanas para Review, Retro y Planning y 15 minutos diarios para Daily.
    – Nadie controla a los miembros de los equipos que no hacen nada y se dedican a escaquearse del trabajo.
    – Se genera denegación del servicio porque lo que se hace en el Sprint se define en el Planning y no se puede modificar.

    Un saludo.

Comments are closed.