La mentira Agile

Publicado el 16 de septiembre de 2013

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

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

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

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 😛

10 comentarios en este post

Feed de comentarios
  1. Avatar

    lop 16 septiembre. 2013 - 04:41

    My bueno el post y muy real lo que decis. Ágile se usa más para vender que en la práctica como metodología.
    En el mejor de los casos se hacen algunas estimaciones y se pilotea trabajar en sprints pero lo de mandar todo a la mierda cuando las papas queman, o cambiar de pisada a la mitad del sprint me pasó casi que siempre.

    Otro problema es que muchas veces no se le invierte tiempo al sprint planning o lo hace sólo una persona,y en particular es difícil cuando el cliente no entiende la importancia de esta instancia y prefiere invertir ese tiempo en que codees (“produzcas”) y lo resuelvas sobre la marcha.

    Safari 533.1 Android
    • Avatar

      Fernando 16 septiembre. 2013 - 14:59

      Creo que todo se reduce a la falta de conocimiento y experiencia en las metodologías y la falta de confianza en el equipo.

      Que se entre en caos cuando las papas queman es un error enorme de gestión. La primera vez se conversa en la retro, se detecta el error y se intenta corregir. Si sigue pasando hay graves problemas en el equipo o en la gestión (generalmente en las expectativas que se le generan al cliente, y todos sabemos quién es el responsable la mayoría de las veces 😛 ).

      Firefox 23.0 Ubuntu 64 bits
  2. Avatar

    Juan'd 17 septiembre. 2013 - 12:26

    Muy interesante el post, a pesar que me desempeño en el medio del VFX también codeo pero no a nivel profesional, y en las mayoría de las empresas donde he estado presentan los mismos problemas de organización y planificación.

    Para mi estas metodologías son aplicables a diversas empresas, no necesariamente desarrollo de software como muchos dicen que es el caso donde funcionan. Creo que debería existir un ente con unas personas vestidas de trajes negros xD que ayuden a las empresas para que adopten estas metodologías en función de los objetivos de la empresa. Porque de verdad que en muchas empresa sería de gran utilidad.

    Buen post nuevamente, espero ver más artículos de estos pronto por aquí, Salu2.!

    Google Chrome 29.0.1547.65 Mac OS
    • Avatar

      Fernando 25 septiembre. 2013 - 05:47

      Gracias por tu punto de vista “externo” a la industria del desarrollo de software. Sí hay gente que se dedica a orientar y entrenar a empresas y grupos para que rabajen bajo estas metodologías. Pero hasta que los que mandan no abran un poco la cabeza, cuesta un poco. De todas formas hay mucho trabajo para hacer “desde las trincheras” como para ir convenciendo gerentes y demás 🙂

      Me alegro que haya gustado el post, tengo algunas ideas más relacionadas al tema que probablemente transforme en posts más adelante.

      ¡Saludos!

      Firefox 25.0 Ubuntu 64 bits
  3. Avatar

    Jorge Abad 20 septiembre. 2013 - 10:54

    Excelente Post,

    quisiera compartir algo adicional que he notado..

    ahora resulta adicionalmente que todos son Agile: CMMi, PMI, Jacobson… algunos llegan tarde al tren agile, pero bienvenidos..algunos se lograrán montar. unos lo perseguiran. otros fallarán… y echarán la culpa al agilismo…

    Aun asi.. el hecho de que usen o no usen la palabra ágil, nos estan dando la razón… ÁGIL/AGILE es el camino y es la mejor forma de hacer software…

    Google Chrome 29.0.1547.76 Windows 7
    • Avatar

      Fernando 20 septiembre. 2013 - 12:11

      Estoy totalmente de acuerdo. Como digo bien al principio, la experiencia me ha demostrado que por ahora es la mejor forma conocida de hacer software. Y es algo que la gente no termina de entender. No solo hay que sacar cartel, sino ponerlo en acción, ¡y las cosas van a funcionar mejor!

      Firefox 24.0 Ubuntu 64 bits
    • Avatar

      Fernando 27 septiembre. 2013 - 18:14

      Jeje, me descubriste. El post está basado en experiencias en distintas empresas y proyectos, pero esa parte específicamente viene de Globant sí. Aunque lo he escuchado en otros lugares como “hacemos nuestra versión de Scrum”. Lo cual no es muy inteligente, ya que Scrum te da algunas pautas y herramientas, pero también te dice que tenés que adaptarlo y usar lo que a tu equipo le sirve. Así que sí, cada equipo implementa “su versión” de Agile o Scrum en el proceso.

      Firefox 24.0 Ubuntu 64 bits
  4. Avatar

    Ivo 13 agosto. 2020 - 01:11

    Agile es la mentira más grande que hay!!! Voy a escribir algún día un libro sobre esto!!! Genera muchísima deuda técnica, muchísimo re-trabajo por qué claro, hay que abrazar el cambio, pero el único que lo abraza es el developer por qué el PO. Y el SM Siguen pensando que aunque te cambien en mitad de desarrollo el requerimiento onte llenen de bugs a resolver en el medio la feche de entrega es la misma! Odio scrum no es más que una palabra de moda para arruinar una profesión que amo!!! Presión mata creatividad 🙁

    Google Chrome 84.0.4147.125 Android
  1. WordPress La mentira Agile 2 | Picando Código | 8 octubre. 2013 - 10:30

    […] sonó muy parecido a La Mentira Agile, así que lo comento por estos lados. Básicamente hace el mismo ejercicio que hice en su momento […]

Dejar un comentario

Notificarme los nuevos comentarios por correo electrónico. Tambien puedes suscribirte sin comentar.

Toasty!