La mentira Agile

Basado en mi experiencia, trabajar en un equipo de desarrollo de software con una metodología ágil bien hecha es eficiente y los resultados son muy positivos. De otras metodologías que he usado, ninguna me ha hecho pensar lo contrario.

El problema con Agile es que en algún momento “se puso de moda”. Por lo que es una palabra más en la lista de buzzwords de una empresa a la hora de venderse. Ya sea de cara al cliente (porque si identifica el término va a pensar “resultados más rápido y con bajo costo”) o de cara a posibles contrataciones (“No vas a trabajar en una pesadilla Dilbertiana”).

Dilbert Agile

Y cuando pienso “¿qué hace que Agile se implemente bien”, mi respuesta es sencilla: seguir el Manifiesto Agil.

Recordémoslo:

Individuos e interacciones sobre procesos y herramientas
Software funcionando sobre documentación extensiva
Colaboración con el cliente sobre negociación contractual
Respuesta ante el cambio sobre seguir un plan

Esto es, aunque valoramos los elementos de la derecha, valoramos más los de la izquierda.

Hay información mas específica en los Principios del Manifiesto Ágil (MANAGERS: POR FAVOR LEAN ESTO)
Desde mi punto de vista, debería ser el manual sobre el cual se construye una empresa de desarrollo de software que pretende tener una cultura sana (sana como en: mantener la excelencia, mejoramiento contínuo, retener el talento, etc).

Incluso creo que la metodología es eficiente como forma de trabajo para muchas disciplinas distintas, y he leído que se ha usado en otros campos totalmente alejados del desarrollo de software. Así también he oído a diseñadores decir que ágile no es para ellos, porque las distintas fases por las que pasa su trabajo y las etapas de desarrollo no son compatibles con la metodología. En otras palabras no saben cómo funciona agile, pero ya saben que no es para ellos. También he trabajado exitosamente con diseñadores usando Agile, y así comprobé que funciona.

Habiendo pasado ya por algunas empresas distintas, estoy un poco cansado de la mentira Agile. Los vendedores y managers usan libremente el término, cuando uno se puede encontrar con una metodología de trabajo totalmente caótica y muy distante de lo que debería ser una metodología ágil. Probablemente mantienen la formación de gestión de otros tiempos…

La Mentira Agile

Algunas cosas (unas mas insólitas que otras) que he visto en “equipos ágiles”:

• Tu equipo tiene más de una reunión de Stand-up por día.
• Se usa más de un gestor de tareas para el proyecto.
• Tenés a alguien pidiéndote un día y hora para entregar una característica del sistema (y no una historia de usuario o tarea).
• Hay más de una persona a la que podrías definir como el Product Owner, o no hay un Product Owner.
• El “¿Cómo va eso?” varias veces por día por parte de un manager/coordinador (o como quiera llamarse porque en “Agile la palabra manager no se usa”).
• Cambias el rumbo hacia donde va el proyecto varias veces por semana.
• En las Sprint planning se habla a alto nivel de a dónde quiere ir el proyecto, pero no se planea ni estima nada.
• Recibes feedback / requerimientos / pedidos de trabajo específico de varios “stakeholders” del proyecto en momentos aleatorios del día/semana.
• Hacemos Scrum, pero cuando las papas queman nos olvidamos de todo y metemos días de 24 horas de trabajo con un manager arriba tuyo todo el tiempo

Cuando estés buscando trabajo, no te dejes llevar por el “usamos Agile”. Algunas empresas hasta te van a decir “inventamos nuestro propio framework Agile”, que para mí generalmente se ha traducido en “vas a trabajar con un manager encima, pero vamos a hacer standups todos los días”. No digo que haya que usar un manual y seguirlo al pié de la letra, pero el “usamos nuestro propio framework Agile” me pasó, y era fruta…

Preguntemos cuál es la reunión más importante de las ceremonias que provee Scrum (o “agile”). Si nos responden “la retrospectiva”, es posible que anden por buen camino. La reunión de retrospectiva pretende ser un punto de análisis para el equipo. Ver qué está funcionando y qué no. Si no es la reunión más importante entonces posiblemente se esté usando mal. De ahí se deberían desprender cosas para “hacer mejor”, lo que idealmente llevaría a un ritmo de trabajo de mejoramiento constante donde todo el equipo esté mejorando el proceso.

La standup es importante, pero se puede resolver con unas líneas de texto en un salón de chat interno o un correo electrónico. Sin embargo es la preferida de varios, ya que en vez de proveer transparencia al equipo e interacción, es un chequeo de estado o reporte para el manager de turno.

Otro buen indicador es la percepción de la gente de las reuniones. Si vemos un cierto descontento y disconformidad con las reuniones “porque son eternas” y “tenemos reuniones todo el tiempo”, seguramente no se estén limitando en tiempo (“timeboxing”). Tampoco se están moderando correctamente por lo que se van de tema y terminan en discusiones que agotan y no aportan al proceso.

Dilbert Agile

No soy un defensor fanático de Agile o Scrum. Simplemente creo que con los valores que aprendí a través de Scrum, y siguiendo el Manifiesto Ágil, tendríamos equipos de trabajo más felices. Se ha dicho hasta el cansancio que “Agile no es para todos los equipos” y “no es una bala de plata”, pero esta crítica va más por el lado del doble discurso de decir que se usa Agile cuando no, que de validar si Agile sirve o no.

Podría haber metido “Xtreme Programming” en este mismo post, pero eso es otro tema del que me gustaría escribir más adelante: XP y Scrum – Mejores amigos 😛