Retorciendo Agile para no ser ágil

Leo en el último párrafo de un blog:

Constatando, como solemos comentar, que la teoría ágil se debe adaptar a cada caso en particular, muchas veces relajando la agilidad, obteniendo la verdadera riqueza y productividad de las múltiples soluciones que ofrece la ingeniería del software.

Lo que me recuerda la keynote que JB Rainsberger dió este año en la Conferencia Agile-Spain 2011.

Rainsberger explica en la keynote cómo, en estos 10 años de Agile, muchos nos frustramos porque no nos funciona nuestra implementación de Agile y por ello comenzamos rápidamente a “innovar” y crear cosas como “post-Agile” pero sin experiencia real en practicar con éxito los fundamentos. Como colofón a su charla, Rainsberger nos aconseja leer sobre eXtreme Programming (XP) y practicar mucho hasta interiorizar los fundamentos. Sólo entonces estaremos en condiciones de adaptar con éxito los procesos a “el mundo real”. Afirmar esto en “el mundo real” parece muy radical, utópico y no sé qué otras palabras más pronunciadas con un tono poco amable, pero lo cierto es que ya era algo que hace un par de años Xavi Gost me avisaba cuando le comentaba mi intención de explorar el Agile coaching y ahora refrendado por la experiencia. Cada vez que me acerco a “el mundo real” y tratamos de hacer Agile (llámese Scrum, XP o lo que sea), el mayor obstáculo es el rechazo de las organizaciones (y las personas que las forman) a cambiar sus procesos. Esos procesos, que presuntamente funcionan, no se pueden cambiar por otros, que siendo “lo que se debería hacer” según ellos mismos, porque los nuevos son muy costosos en el plano de las responsabilidades personales, nos sacan a todos de nuestra zona de confort y nos ponen en la tesitura de atrevernos a equivocarnos (y luego reconocerlo). Y por ello comienzan a retorcer los principios ágiles (los de la parte de atrás del Manifiesto) para hacer el cambio posible y no sé cuantas cosas más, en vez de echar mano de los valores de XP, en particular del coraje y atreverse a realmente intentarlo.

Lecturas recomendadas

Además del seminal de Beck, XP Explained, yo recomendaría también la lectura del de Jeffries, XP Installed, también citado por Rainsberger en esa keynote.

  • jorge

    ya que hablas de tu experiencia, podrías poner algunos ejemplos de adaptaciones, porqué no funcionan y qué es lo que hay que cambiar? 🙂

  • Abel

    Según estaba leyendo me acordaba de una frase que habla de que la gente busca “aprender los trucos del negocio, y no aprender el negocio”.

    Entiendo que es humano embelesarnos por las ceremonias y tradiciones (y en Agile hemos caído en esta misma trampa, ¿de cuanto son tus standup meetings? ¿haceis retrospectivas? …), pero lo realmente necesario es centrarnos los valores y principios en los que se basan las ceremonias del momento.

    Yo interpreté el final de la charla de Reinsberger así, en una vuelta a los origenes del movimiento para que descubramos los invariantes, lo que no ha ido cambiando en las diferentes aproximaciones (XP, Scrum, Kanban, …) que vamos probando.

    Y me gusta que recuerdes lo del coraje (yo añadiría disciplina, que a veces nos relajamos).

    My 2 cents,
    Abel.

    P.S.:Espero que la fiesta de esta tarde salga como todos esperamos :-).

  • Últimamente son cada vez mas las empresas a las que voy a contar que es todo esto del Agile. Siempre trato de explicar los valores y fundamentos que hay detrás de cada ceremonia. Me da igual Extreme Programming, Scrum, Kanban, Scrumban o cualquier otro palabro que se nos ocurra. Los valores son los mismos.

    Coincido al 100% con este post y con la opinión de J.B. Pensamos que estamos muchas veces en el post-agile porque lo intentamos una vez en un proyecto y fue mal cuando, deberíamos seguir buscando formas de tratar de transmitir todos los valores que hay detrás del agilismo.

    Es un trabajo complicado pero es nuestra responsabilidad como miembros del movimiento de no caer en lo fácil de quedarnos en la superficie y si intentar hacer el esfuerzo de llegar al fondo.

    Agile es complicado, coincido con Abel en que es mucha disciplina (nos relajamos siempre que podemos :D).

    ¡He dicho! 🙂

  • Creo que el problema es que queremos que Agil sea “adaptación y mejora continua”. Y lo es, pero no es SOLO eso. También marca un horizonte hacia el que caminar.

  • A mí lo que me sorprende es que no se den cuenta de que esas “tecnologías que funcionan” de siempre, bien mirado, nunca han funcionado…

    Retrasos, proyectos inacabados, expectativas de clientes frustradas, no se ajusta a los requisitos, tienen fallos garrafales, … Pero es que “no hay otra manera de hacerlo”.