¿Para qué diablos sirven las metodologías ágiles?

Descubrí las metodologías ágiles en el año 2004, hace 12 años. Fue amor a primera vista, desde que entendí de qué trataban (o pensé haberlo hecho) quise aplicarlas y utilizarlas al pie de la letra a ver qué tal me iba. Muchas fueron las razones por las que sentí una alta conexión con el tema, además que se enlazaba perfecto con el modelo de Cuatro Capas que en ese momento estaba creando.

Me fascinó el foco en las personas y la manera en que colocaba sobre la mesa verdades que otras metodologías no querían aceptar (como por ejemplo que por más documentación que pidas hacer, el conocimiento siempre va a estar en la cabeza de las personas, así que lo mejor que puedes hacer es tratarlas bien y mantenerlas entretenidas haciendo que roten para que el conocimiento se difunda, eso es gestión de conocimiento ágil en pocas palabras).

Propuse activar un piloto en la empresa, junto a muy buenos amigos armamos una presentación (que hoy sólo nos arrancaría risas por todo lo que prometíamos), la llevamos al comité ejecutivo y nos aprobaron hacer una implementación utilizando Scrum. Según entiendo ese proyecto fue uno de los primeros en el país que se activaban llevando Scrum de la manera más pura posible.

El resultado tuvo cosas muy buenas, muy malas y algunas aterradoras (se dieron peleas entre algunos líderes muy fuertes, a uno literalmente lo sacaron de una reunión en camilla #truestory). Lo positivo fue que el proyecto salió y generó un impacto muy positivo en los usuarios, tanto fue así que junto con uno de mis colegas nos enviaron en el 2008 a certificarnos en Scrum en lo que era el primer evento Internacional de Ágiles, que en ese año se llevaba a cabo en Buenos Aires, Argentina. Ahí conocí a muchos de los que hoy considero grandes amigos y de los mejores consultores que existen en Agile a nivel mundial, de ahí en adelante (desde el evento del 2009 en Brasil) participé como expositor contando experiencias y aprendiendo de los errores. Y bueno, el resto es historia.

Desde aquel año he vivido diversas implementaciones de Agile a modo de líder, espectador, consultor, etc y en este post quiero compartir lo que para mí son las claves que cualquier manager/gerente/director/CIO debe entender sobre Agile antes de activar un piloto, proyecto o cualquier cosa pensando en metodologías ágiles.

Lo primero, ¿Qué es Agile?

El primer paso es entender que Agile es un concepto genérico que alberga a varias metodologías con diferencias importantes entre sí, pero todas con los mismos valores y principios. Si uno analiza la historia y los eventos cronológicos verá que muchas metodologías se crearon muchos años antes incluso que el mismo lanzamiento del concepto “Agile”. Para mí es algo similar a lo que ocurre en los movimientos artísticos en los que uno se da cuenta que por un lado del mundo surge un artista con una propuesta innovadora que se enlaza con otro que nace en otra parte del mundo y en algún punto, casi siempre posterior a cada uno de ellos se le da un nombre al movimiento (como el cubismo, romanticismo, renacentismo) creando un concepto paraguas que enmarca a todos en una sola idea. Agile es exactamente eso, un concepto creado para conglomerar una serie de propuestas contemporáneas y que profesan un mismo espíritu.

Este espíritu se definió y se dio a conocer al mundo como el manifiesto Agile. Existe un video muy bueno y didáctico que te explica de qué va esto del Manifiesto Ágil. Para mí tan importante como el manifiesto son los principios, recomiendo mucho darle una mirada a los principios ágiles.

Dicho esto, lo segundo es, ¿Entonces cuáles son las metodologías ágiles? ¿Existe un catálogo o algo así?

La verdad es que cada año salen nuevas propuestas interesantes de metodologías que se pueden enmarcar en Agile. Pero si quieres empezar por algo, las más populares y potentes son: Scrum, Kanban y Lean Development.

Mención honrosa a metodologías/técnicas que vale la pena revisar: XP, FDD, BDD, TDD, etc (aquí una lista completa). Pero para comenzar es más que suficiente con enfocarse en entender las tres primeras.

Entenderán que por esto no se puede decir de manera tajante para qué sirven “todas” las metodologías ágiles. Cada uno ataca problemas diferentes y por eso aplican y generan el mayor impacto en condiciones diferentes. Pero me atreveré a responder para qué sirve Agile  basándome en los años de experiencia jugando con estas metodologías.

La pregunta del millón de dólares ¿Para qué diablos sirven las metodologías Ágiles?

Si tuviera que decirlo en una frase: Las metodologías ágiles sirven para generar la máxima cantidad de valor y mostrarla lo más temprano en el tiempo generando a la misma vez la menor cantidad de desperdicio (costo).

¿Claro? ¿No tanto? No importa. Cuando entiendas cómo es que consiguen esto te quedará mucho más claro por dónde va el tema.

Y ¿cómo consiguen esto? Haciendo cuatro cosas:

  • Colocando al mando del proyecto al equipo que hace el trabajo. Es decir, dando poder de gestión y decisión al equipo que se remanga las mangas y hace una verdad el proyecto. En pocas palabras: Adiós jefes de proyecto.

Aquí inicia la polémica y debo ser lo más claro posible. No se trata de que no existan jefes y que nadie le reporte a nadie a nivel organizacional, etc. No se trata para nada de eso.

Se trata de romper con el esquema antiguo en el que existe un ser pensante, iluminado, llamado “jefe de proyecto” o cualquier nombre que se le quiera dar que asigna actividades y dicta cómo se deben hacer las cosas, él tiene centralizados todos los poderes de decisión. Ese esquema funciona en escenarios de menor complejidad y ambigüedad donde una sola persona está en todo y además funciona con un equipo “mudo” que sólo se dedica a escuchar y hacer. Todas las decisiones deben pasar por ese jefe, así que él debe ser omnipresente en el proyecto, estar copiado en todo, saberlo todo y prácticamente tomar las decisiones sobre todo. Lo irónico de esto es que muchas veces ese “jefe” no tiene idea del detalle y los desafíos más complejos y técnicos para hacer una verdad el proyecto, y no porque sea malo, simplemente porque en esta era la complejidad de las cosas que hacemos hace que no pueda saberlo todo. Es así de simple.

Agile lo que propone es antes que nada, conformar un equipo que está en capacidad de ser “auto-gestionado”. Es decir, debe conocer sobre su material (ojo uno de los principios ágiles es la excelencia técnica) y debe tener un mínimo nivel de madurez como para saber comunicarse, opinar, saber debatir, etc (y ojo que no de todos se espera esto, puedes tener un esquema de mentoring con un junior que está aprendiendo del resto), al menos una cantidad crítica de personas deben estar en capacidad de autogestionarse y ser muy conocedores de su materia.

Y ojo no sólo se trata de dar “voz” al equipo y que puedan opinar y pedirles que se levanten y propongan definiciones, cambios, etc. No, no se trata de dar “voz”, se trata de dar “poder”. El equipo tiene la última palabra respecto a la gestión, a la mecánica de trabajo y al diseño y definiciones acerca del cómo se hará lo que se pide de más arriba. Esa es la clave.

  • Con un coach que entrene al equipo y lo acompañe en su camino de madurez.

Esto es sumamente importante en Agile. El equipo es seguro conocedor de su rama (software, marketing, servicios, etc) pero es prácticamente un hecho que no todos van a tener claro cómo hacer Agile. El coach lo primero que hace es enseñar, lo segundo vela porque los principios y los elementos clave de la metodología que se esté usando se respeten y por último resuelve impedimentos de índole tanto soft (temas humanos) como hard (temas del trabajo, falta de materiales, recursos, etc).

  • Con alguien que está enfocado y full time definiendo “QUÉ” se debe hacer, ojo no “CÓMO” se debe hacer.

Algunas metodologías ágiles no lo exponen como un requisito. Pero para mi en todos los casos debe haber alguien que haga dos cosas:

– Esté en capacidad de ir desde 10000 pies de altura y tener claro tanto el propósito como la visión de lo que se está haciendo y poder luego aterrizar a 500 pies de altura y definir qué es lo siguiente qué se debe construir de manera que esté alineada con esa visión.

– Que tenga un foco absoluto en la generación máxima de valor considerando el costo que implica cada cosa. Es decir, con foco en valor y eficiencia.

Esta persona habla directamente con el equipo y los hace parte de la visión y el norte. Además les cuenta lo más a detalle posible lo que se sueña y aterriza con ellos en acciones específicas, marcando las necesidades próximas a cubrir. El equipo con esto inicia a tomar decisiones de diseño, construcción y hace una verdad lo que se pide.

  • Haciendo que absolutamente todo lo que pasa en el avance sea visible y de acceso público.

Al mostrar en las paredes o en pantallas lo más grandes posibles todo lo que pasa en el día a día. Agile consigue que el equipo haga frente a los problemas y los solucione lo antes posible. Si hace unos años en el esquema de gestión tradicional una persona podía estar 1 mes estancada sin resolver un problema que no le dejaba avanzar y le decía al jefe de proyecto que estaba en 90% de avance y saltaba al final cuando se tenía que ver funcionando las cosas. Ahora en Agile seguro habrá un post-it o una manera de ver “al día siguiente” que esa persona no pudo terminar su tarea, es más, el ambiente es tan relajado que la misma persona lo expone y pide ayuda, todos están enfocados en hacer que las cosas fluyan.

Estos para mi son puntos transversales a todas las metodologías y críticos al momento de hacer Agile.

Por último y para que puedan generarse una idea más concreta del foco y las diferencias entre las tres principales metodologías aquí les comparto una definición rápida de cada una y un cuadro comparativo.

Scrum

¿De qué trata?

Scrum sirve para conseguir el máximo valor con los recursos que tienes en un contexto de alta complejidad y alta ambigüedad. Es decir, sabes muy bien qué deseas conseguir (visión) pero no tienes ni idea de cómo lo vas a hacer. Por eso, necesitas caminar con una estrategia de ensayo y error. Equivocarte lo más rápido posible (para que no hayas avanzado mucho por el camino incorrecto) e ir tanteando el impacto de lo que vas haciendo directo con el que lo va a usar (le funciona? le gusta? lo usaría? etc).

Scrum lo que hace es partir el trabajo en espacios de 1 semana a 4 semanas en las que debes de entregar algo que funciona y puede ser utilizado por el usuario. Lo que busca es generar feedback de alto valor para saber si vas por el camino correcto.

Funciona muy bien en proyectos – en esfuerzos con un inicio y fin con un equipo enfocado en un alcance. No funciona muy bien en procesos, donde se tiene a un equipo enfocado en varios alcances, productos, servicios y donde los requerimientos llegan en cualquier momento.

¿Qué te pide?

3 roles – Product Owner, Scrum Master, Team

4 reuniones – Sprint Planning Meeting, Daily Meeting, Review Meeting, Retrospective Meeting

2 artefactos – Product Backlog, Sprint Backlog

Aquí les dejo un video qué te explica Scrum con Legos en menos de 5 minutos.

¿Lo complicado?

Conseguir un Product Owner con disponibilidad full time.

Conseguir usuarios que realmente puedan dar feedback a cada sprint. (recuerdo una vez que Jeff Sutherland me dijo que si no tenía usuarios reales que iban a probar el producto al final de cada sprint, mejor no hiciera Scrum).

Conseguir armar un equipo multifuncional.

Darle poder al equipo para decidir y autogestionarse.

Kanban

¿De qué trata?

Kanban utiliza el concepto de flujo o tráfico de trabajo. Imagina una autopista repleta de autos, todos van muy lento por el poco espacio (o ancho de banda) que existe entre ellos, a esto le llamamos tráfico en Perú o taco en Chile. Ahora imagina una autopista con una cantidad óptima de autos y bien distanciados entre ellos, seguro la velocidad será muy superior al primer escenario.

La idea es similar en Kanban. Se trata de limitar el trabajo en progreso de las personas. Muchas veces nos la pasamos aceptando cosas nuevas y nos demoramos en cerrar las que tenemos en curso. Pocos equipos son conscientes de cuántas cosas están teniendo en curso y cuán rápido las están cerrando.

Lo potente de Kanban es que define límites para el trabajo en progreso de TODAS las fases de un flujo de valor. Vamos a verlo con un ejemplo:

Supongamos tu trabajo es definir productos nuevos en una empresa de relojes. Recibes un brief con el concepto que se quiere crear y tu trabajo es diseñar el producto, materiales, componentes, etc. Luego que terminas con eso le pasas todos tus diseños a un colega que calcula el costo de lo que significaría hacer ese nuevo producto.

Imagina que tu puedes crear hasta 3 productos en paralelo y tu colega puede costear hasta 4 productos en paralelo. En el caso que no se utilice Kanban, apenas tu acabas con tu 3er producto se lo pasas a tu colega, te liberas (te quedaste con dos) y puedes coger uno más. Lo que haces realmente es encolar en tu colega ese producto que va a esperar mientras él termina con alguno de los 4 productos que está costeando en paralelo. En este esquema a ti no te importa mucho cuán atiborrado esté tu colega de trabajo, tu vas terminando y vas pasando, luego coges otro y empiezas con ese. Este es un sistema enfocado en empezar y no en terminar.

Kanban lo que te dice es “Deja de comenzar y empieza a terminar”.

Con Kanban el escenario sería otro. Lo primero es que se visualizaría el flujo (seguro en la pared o en alguna herramienta digital). Luego se definirían límites (3 para tu trabajo y 4 para el de tu colega).

Luego imagina que tu terminas con algo y se lo quieres pasar a tu colega para tu comenzar con otra cosa. Pero salta que tu colega ya está con 4 cosas en curso, la que tu le pasarías haría que sea una 5ta y se rompería el límite de trabajo en progreso. Debido a eso ese item se queda en tu sitio, obligándote a ayudar a tu colega a que acabe costeando uno de los productos que tiene en este momento, cuando él termine y se quede con 3. Recién ahí podrá tomar el tuyo y tu podrás tomar uno nuevo. Esa es toda la lógica de Kanban, limitar el trabajo en progreso de manera que la gente se enfoque más en terminar que en comenzar.

Kanban desde mi punto de vista funciona muy bien tanto en proyectos como en procesos. A diferencia de Scrum que sólo se debería utilizar en proyectos.

¿Qué te pide?

No hay roles. Sólo te pide visualizar tu flujo de trabajo, limitar el trabajo en progreso de cada fase y empezar a abrir la pista para que las cosas fluyan.

¿Lo complicado?

Limitar el trabajo en progreso implica decir NO a clientes o interesados. Por más que parezca que alguien está disponible para empezar con algo nuevo se debe decir no y hacer que esa persona se enfoque en cerrar algo que está en curso.

Lean Development

¿De qué trata?

Eliminar todo aquello que no agrega valor en todo el proceso o flujo. A todo eso Lean le llama desperdicio. Particularmente yo me enamoré de Lean cuando lo escuché explicado directamente de Mary y Tom Poppendieck allá por el 2008 (creadores de LSD – Lean Software Development – y autores de uno de los mejores libros escritos sobre el tema). Lean tiene que ver mucho con crear una cultura de mejora continua en el que la gente analice todo lo que hace desde un punto de vista de si agrega valor o no.

Por ejemplo, recuerdo muy bien cuando en una conversación con Mary me preguntó. “La fase de pruebas, donde se corrige todo lo que se hizo mal, agrega valor? es un desperdicio?”. Se que este tema despierta pasiones pero luego de entender mejor el concepto la conclusión es un contundente sí, el testing es un desperdicio, porque no genera nuevas funcionalidades o aporta valor directo al usuario. Mary fue muy tajante con esto.

Invertir una semana o dos meses haciendo pruebas es un desperdicio porque no genera valor real al producto, estás corrigiendo lo que pudiste hacer bien desde el principio. Eso en una cultura Lean hace que las personas estén muy preocupadas por agilizar lo más que se puede ese tiempo de pruebas. Mentes como esas generaron técnicas de automatización de pruebas unitarias, funcionales, etc.

Lo que debería tener toda nuestra atención es toda aquella actividad que genera valor. Es decir, la documentación, la gestión, todo aquello que al final del día no va a generar un beneficio al usuario debería ser llevado a su mínima expresión.

¿Qué te pide?

No hay roles. Pero te pide como mínimo un coach Lean y un espacio de entrenamiento en conceptos Lean.

En resumen (si estás en mobile mira la tabla en posición horizontal)

CriterioSCRUMKANBANLEAN DEVELOPMENT
Principios claveAutogestión y equipos multifuncionalesLimitar el trabajo en progresoEliminar todo aquello que no agrega valor
Condiciones favorables para su usoProyectos y una cultura innovadora con una visión clara. Flujo de proceso, mejora continua con requerimientos de similar tamañoFlujo de proceso donde exista una cultura de alta calidad
Roles que necesitaUna persona que se hace responsable full time del valor que genera el producto en el usuario (financiero, percepción, costos, etc)

Un equipo multifuncional con personas que pueden generar alto rendimiento.

Un facilitador encargado de hacer que el proceso fluya, levantar impedimentos y acompañar al equipo en su camino de madurez.

No hay roles.

Se puede empezar desde cualquier estadío.

No hay roles.
Principales retosDisponibilidad del Product Owner (Cliente).

Usuarios reales que prueben lo que se hace.

Equipo multifuncional y con el poder necesario.

Decir no al cliente cuando pida comenzar con algo que supera el Límite de trabajo en progreso.Mantener las reuniones en el tiempo de mejora continua, se necesita un líder o un impulso que sostenga lo suficiente los espacios hasta que formen parte del ADN del equipo.