James Shore declaró que la agilidad está en declive. Cita como por ejemplo diversos equipos están haciendo 'sprints' y reuniones de parado, sin adoptar ninguna de las técnicas prácticas necesarias para producir software de alta calidad en el largo plazo. En su opinión, este hecho ha provocado que miles de equipos de Scrum práctiquen métodos ágiles en forma tan pobre que casi con toda seguridad fracasarán y probablemente llevarán al movimiento ágil con ellos.

James señala que una gran parte de la culpa es de Scrum, y el mal uso de Scrum. Él compara Scrum con Programación Extrema (XP) y nota que Scrum intencionalmente deja de lado las prácticas de ingeniería que se incluyen en XP. Scrum no dice nada se sobre temas tales como programación en parejas, desarrollo orientado por las pruebas, integración continua, y automatización de pruebas. Sin esas prácticas, un equipo puede construir rápidamente una gran base de código, de muy poca calidad e imposible de ser mantenido. Entonces se convierte en un peso en las espaldas del equipo, que les impide responder rápidamente a los cambios, como un equipo ágil debería.

Sin embargo, James cree que no es todo culpa de Scrum, ya que cada equipo debe ser responsable de su éxito o fracaso. Muchos optan por adoptar sólo las partes superficiales y fáciles de Scrum, como ciclos cortos de desarrollo y reuniones diarias, haciendo caso omiso de las prácticas difíciles y mas críticas como la reflexión y la mejora continua. Es a través de este proceso que los equipos tienen la capacidad de identificar y adoptar las prácticas de la ingeniería que ellos necesitan para tener software listo en cada iteración.

Lamentablemente, muchos equipos fallan en dar este paso.

Proceso vs. personas

Varios han preferido ver que el problema no es de Scrum en sí mismo, sino en las personas que están aplicandolo en forma débil. Por ejemplo, Dustin Whitney dijo: "Para mí usted está simplemente describiendo la mediocridad, que nunca desaparecerá. Yo no creo que sea justo culpar a Scrum por las deficiencias de los desarrolladores y un director de proyecto mediocre".

En la visión de James, los fracasos, sea cual sea el motivo, pueden conducir a la agilidad a ser tratada de fracaso y llevarla al colapso.

Así que, por desgracia, muchos auto-titulados proyectos Ágiles fracasarán. Ellos están fracasando en este momento. Y, eventualmente, Ágil recibirá la culpa, y ella pasará, al igual que todas las novedades finalmente pasan.

Simon Kirk responde a todo esto de forma más optimista:

No estoy de acuerdo con la premisa de que todo se ha hecho bajo el nombre de "ágil" es cualquier cosa. Por otra parte estoy convencido de que esta etapa es un paso inevitable para una adopción mas amplia de la agilidad (que, en cualquier caso, se hace de forma ágil).

La diferencia entre la Historia y la Futurología

Mucho debate se está llevando adelante con este artículo y es bueno que conozcamos otros artículos similares para comprender mejor donde estamos parados y porque a veces se hacen este tipo de notas. Es interesante recordar el libro de Edward Yourdon titulado "The Decline and Fall of the american programmer" (Declive y caida del programador americano). Yourdon previó en el libro que las organizaciones y los desarrolladores de software estadounidenses perderían por completo sus negocios y puestos de trabajo por los desarrolladores en otros países. Evidentemente, esto no ha sucedido y Yourdon escribió una retractación de sus previsiones en el libro "Rise and Ressurrection of the american programmer" (Alzamiento y resurreción del programador americano).

Pocos deben haber percibido la similitud del título del artículo de James Shore, y el libro de Yourdon. Menos personas aún deben hacer la alusión al libro clásico de la Historia de Edward Gibbon, titulado "The History of the decline and fall of the roman empire" (Historia del declive y caida del Imperio Romano). La gran diferencia es que Gibbon escribió su libro después de los hechos relatados (por eso es Historia), mientras que Shore y Yourdon escriben como previsiones (por eso es Futurología). Este comentario es sólo para recordar que incluso grandes maestros y profundos conocedores en ciertos campos cometen errores.

Las buenas prácticas de ingeniería son la clave del éxito

Pero vamos a pasar ahora a los argumentos de Shore.

Según él, cientos de empresas que están aplicando mal el desarrollo ágil. Muchos están fallando porque no logran alcanzar sus objetivos de la iteración, están teniendo mucha deuda técnica y no consiguen probar sus aplicaciones. De acuerdo con Shore, el problema están en que estas organizaciones y equipos usan sólo lo que es más fácil de Scrum (iteraciones y scrums) y hacer caso omiso de las prácticas de ingeniería. Estoy de acuerdo 100% con él en este sentido: los equipos ágiles necesitan adoptar prácticas de ingeniería ágil para realmente tener una productividad y calidad por encima del estándar del mercado.

Suelo creer, que en parte, el problema de estos eventos tiene que ver con Scrum. Como el scrum no tiene prácticas de ingeniería en su proceso, esto llevaría a la gente a creer que TDD, Refactoring, y otras no son importantes. En este punto es que desacuerdo con Shore.

Como el propio Ken Schwaber acostumbra decir sobre Scrum: al comienzo de su adopción por parte de una empresa lo que Scrum hará es mostrar todos los problemas de su equipo y su empresa. Scrum va a tirar toda la suciedad en el ventilador y va a mostrarla a todos los niveles jerárquicos. Y eso es esencial para entender lo que quería Scwaber cuando creó el Scrum. Tal vez el problema es que esto es lo poco o mal comentado que está por los instructores de Scrum y por algunos consultores de Scrum. Es una parte esencial de Scrum.

Scrum, fuerza a hacer entregas cortas de resultados en pequeños plazos de tiempo. Al comienzo, esto levantará decenas o cientos de problemas que tiene la organización para lograr estos objetivos cortos. Y es desde allí las reuniones de retrospectiva al final de cada iteración y sus propios scrums diarios demostrar su valor. Los problemas va a aparecer diariamente y el equipo, con el apoyo de la empresa, tendrá que actuar para resolverlos. En este punto es donde un buen mentor de Ágil debe proceder para ir aplicando, mentorizando y convenciendo de a poco sobre el uso de prácticas técnicas de ingeniería. Ese es el gran valor de Scrum que tal vez es poco clara.

Sería ideal que los equipos ya adhiriesen desde el inicio a un proceso ágil lleno de prácticas técnicas como la programación extrema (XP), el desarrollo de manejado por funciones (FDD) o OpenUP. El problema es que la mayoría de las personas ya tienen dificultades para entender y un simple plan iterativo, TDD y refatorizar continuamente su trabajo.

Yo diría que Scrum es apenas una puerta de entrada a la agilidad. Un equipo que no evoluciona despues de eso, seguramente irá a fracasar como mostró James Shore. Pero, al mismo tiempo, adoptar y enfrentarse a un proceso ágil mas completo también puede llevar a estos equipos a abandonar rápidamente sus intentos, porque son incapaces de usarlo y ellos encontrarán que la agilidad no es para ellos.

¿Ágil es una novedad? ¿Es muy difícil para la mayoría de los equipos lograrlo eficientimente? ¿Ágil está experimentando dolores de crecimiento para tener mayor adopción y éxito?

Basado en O Declínio e a Queda do Agile y en Declínio e Queda do Movimento Ágil?