¿Cómo reconocer el agilismo de verdad?

Llevo unos meses dándole vueltas a la idea de que el mundo del agilismo está perdiendo poco a poco el foco de lo que realmente es importante.

Estamos en un momento donde los métodos ágiles por fin han llegado a la gran empresa española y se habla de ello incluso en los comités de dirección.

Pero esto ha sucedido no tanto por méritos propios, sino en parte gracias a la publicidad que le han dado artículos de bancos que “han acabado con los jefes y los departamentos” o papers de grandes consultoras sobre “Tribus y Squads” que, solo llegan, a mi juicio, a rozar muy superficialmente lo que significa realmente es ser ágil.

Este tipo de contenidos, si bien son muy positivos para la propagación del agilismo, contribuyen también a que vaya perdiendo poco a poco su verdadera esencia.

Y estos artículos no son más que un pequeño ejemplo. Miro en las redes y veo muchas conversaciones sobre el nombre correcto de las cosas: por qué una demo es un concepto muy diferente a una review, por qué scrum es un framework y sin embargo SAFe es una librería, pero waterfall es una metodología, etc.

Veo también muchas conversaciones sobre antipatrones, donde algunos incluyen técnicas como el sprint 0, inception o el dual tracking.

Me encuentro con excesivos contenidos sobre lo importante que es diferenciar lo que está dentro de scrum y los añadidos “bastardos”, como la daily standup o el product burndown, que no están recogidos en la Scrum Guide.

Y no digo que estas conversaciones carezcan de importancia, pero creo que nos estamos quedando muy lejos del verdadero agilismo si solo hablamos de estas cosas.

Creo que si nos dejamos llevar por la “industria” que se ha montado alrededor del agilismo corremos el peligro de convertirnos en scrum zombies, que rinden culto a las prácticas superficiales, perdiendo la esencia del por qué y el para qué.

Dave Thomas hizo ya hace unos años una reflexión parecida en su espectacular charla “Agile is Dead”. Porque al final, si lo piensas ¿qué es el agilismo de verdad? Yo diría que se puede reconocer por estos 5 puntos:

  • Personas que actúan de acuerdo a los valores agile, por encima de las prácticas.
  • Trabajan en equipos pequeños, multidisciplinares y auto-organizados.
  • Entregan a menudo y obtienen feedback de usuarios reales.
  • Ponen foco en el valor de negocio, por encima de los entregables y el coste.
  • Y que experimentan todo lo posible con el producto y con el proceso.

Todo lo demás es secundario. No hacen falta tribus, ni la colección completa de certificaciones, ni dibujitos chulos que resumen reuniones, ni mesas de ping pong, ni post-its.

Bajo esta idea del agilismo, yo echo de menos más contenidos que hagan foco en los resultados que se han conseguido gracias al agilismo: cuánto ha ayudado a mejorar productos o a aumentar ingresos, lo que ha ayudado a empresas a superar a su competencia, lo que ha reducido el Time to market, cómo ha ayudado a la motivación de los empleados…

Echo de menos más historias como esta de Dropbox, donde sin necesidad de incidir en la rigurosidad del método, habla de los resultados de una aproximación iterativa e incremental en un entorno real.

Me encantaría ver más agile coach hablando de los productos de éxito que han ayudado a construir y de las compañías que han transformado. Sobre todo en este último punto los frameworks y las guías no dan respuesta a todas las situaciones que nos podemos encontrar, por eso las experiencias personales ganan aún más valor.

Mi compañera Cristina siempre incide en lo poco que se habla de los valores agile y de cómo se hacen tangibles en situaciones reales. Equipos que se ayudan y actúan como una unidad, donde las personas no tienen problema en ayudar en lo que haga falta si en ese sprint no hay tareas específicas para su rol. O equipos donde las personas actúan como compañeros y dejan su tarea para ayudar a solucionar un problema con una tarea más crítica para el objetivo en ese momento.

Quizá ahora que el agilismo está más o menos extendido, creo que es el momento de pasar al siguiente nivel en términos conversacionales. Es el momento de rendir cuentas y demostrar que todo esto sirve para obtener mejores resultados.

Cuando hablo de resultados me refiero a resultados de negocio, pero también a resultados de crecimiento personal del propio equipo. Y resultados no a cualquier precio, sino obtenidos con un ritmo sostenible de trabajo y siempre desde la honestidad, sin engañar a nadie.

Alguno puede verlo como una llamada del “lado oscuro de la fuerza”, pero yo lo veo como una evolución natural, que no pasa por dar la espalda al agilismo, ni tampoco por afirmar que ya hemos tocado techo y no hay nada que mejorar.

Ya tienes el carnet de conducir, ya llevas muchos kilómetros con el coche y empiezas a mirar los espejos y a cambiar de marcha de forma natural, casi conduces de forma instintiva. El propio proceso de conducir pasa a un plano secundario y te centras en desplazarte o en ir a lugares interesantes con el coche.

Esta es mi visión de lo que es la esencia del agilismo, pero estoy convencido de que la clave pasa por aceptar que no existe una definición única de lo que es «agilismo de verdad», y que solo aceptando eso podremos aprender y mejorar continuamente, desde una perspectiva de respeto a otras soluciones.

Foto de jiherranz

Mi rol es diseñar productos digitales y convertirlos en realidad. Siempre en busca de nuevos retos que mezclen diseño, tecnología y humanidades. He participado en varios procesos de transformación de grandes compañías españolas. Procuro siempre crear un marco de trabajo que permita a las personas mejorar y dar su mejor versión.

Ver toda la actividad de Jose Ignacio Herranz

4 comentarios

  1. Jordi Cabot dice:

    Sobre este tema, la reciente charla de Martin Fowler sobre los «falsos-ágiles» ( https://ingenieriadesoftware.es/desarrollo-agil-software-martin-fowler/ ) vale también la pena

  2. David dice:

    Gracias Jose por compartirlo,
    Estoy de acuerod contigo en muchos puntos. No obstante, quiero compartir contigo la importancia de usar las cosas por las que se crearon. Mucha gente usa la review para una DEMO, pero en Scrum cuando se pensé en Review el objetivo es diferente… Scrum se creó para responder a unas necesidades de desarrollo de producto, basandose en el manifiesto agil.
    Te pongo un ejemplo, muchos programadores de C (10 años en c) se apuntaron a programar en Java, lo que no pensaron es que el C es muy diferente a Java, y hicieron programas en C bajo el lenguaje Java. MAs adelante volvio a pasar lo mismo con Java y Scala, se olvidaron que Scala tenia un proposito y tiene ciertas normas y guias etc. Pues con Scrum pasa lo mismo.
    Luego sobre los valores, me encanta lo que comentas, pero, me resulta curioso cuando luego hay muchas empresas abusan de esos valores metiendo mas roles, como un delivery manager/ proxy/../etc. en Scrum, que su unico objetivo es controlar al equipo DT y asegurar que entreguen puntos de historia a lo loco. Por que es asi como funcionan muchas empresas. ¿Entonces lo estan haciendo mal o bien? meter roles bien, pero no seria el proposito inicial por el cual se creó ese elemento en este universo.

    De nuevo te doy las gracias por tu post, y de verdad que estoy contigo en muchos.

    Un saludo y muchas gracias.

    • Jose Ignacio Herranz dice:

      Gracias David,

      Completamente de acuerdo en que es importante entender el origen de las cosas para poder aplicar correctamente los principios y las prácticas, para así ir más allá de poner nombres ágiles a las cosas.

      Respecto al ejemplo que comentas de los roles, y específicamente el service delivery, yo no lo entiendo como un rol adicional dentro de un equipo scrum.

      Creo que sería impensable pensar en montar una compañía solo con los roles de equipo de desarrollo, product owner y scrum master. Por eso yo entiendo el rol de service delivery como una figura fuera de scrum, que se encarga de ayudar a montar los equipos de producto, ayudar en la resolución de conflictos e incluso mantener cierta coherencia en cuanto a excelencia técnica, valores, etc.

      En mi opinión, usar este rol para controlar al equipo o asegurar que entreguen puntos de historia iría en contra del concepto de auto-organización y en contra de los principios ágiles.

      Un saludo

Escribe un comentario