Desde hace algunos años fuimos invadidos por una extraña y colorida energía que hoy llamamos agilismo, de tal suerte que hoy casi toda empresa de desarrollo de software y las áreas de TI de muchas empresas privadas son hipotéticamente “ágiles”, o dicen ser ágiles, o al menos están intentando serlo hace años. “Hace ya tres años lo estamos haciendo ágil en mi empresa”, dicen. O, “Nosotros ya comenzamos a ser ágiles porque usamos metodologías ágiles” (si como usar una metodología ágil te volviera automáticamente ágil). Pero, ¿realmente son esas empresas ágiles? ¿Entendemos de qué se trata el tan mencionado, anhelado, e impactante agilismo? ¿Por qué es tan intimidante no ser ágil?
Tenemos ya un mercado rebosante de consultores ágiles con tarjetas de presentación que los presentan como “coach”, “trainers”, “experts”, “scrum developers”, “scrum masters”, etc. A toda hora somos bombardeados por eventos sobre agilismo, cursos de scrum, cursos de scrum masters, cursos de product owners, cursos de management, y cursos de facilitación gráfica. Ya somos certificados en 4 o 5 “cosas” relacionadas de algún modo con agilismo. Y toda empresa que se respete y quiera ser competitiva deberá tener en alguna parte de su portafolio la palabra “ágil” ligada a la palabra “metodología”, y en particular, un alto predominio de la palabra “scrum”, (que ya es casi una marca). De hecho, hoy conseguimos scrum masters en “la calle”, como si sólo se tratara de etiquetar gerentes de proyectos, o como si simplemente se tratara de contratar personas que han asistido a eventos ágiles y les encanta el tema del agilismo. Para complicar las cosas, las empresas son expertas en redefinir analistas de negocios como “scrum product owners”, o como “scrum master”.
Además, ¿quién va a querer que digan por ahí que uno no es ágil?
Según los diccionarios de antónimos, no ser ágil significa ser “burocrático”, “incompetente”, “mediocre”, “incapaz”, “lento”, “lerdo”, “tardío” o “torpe”. (Mejor digo que soy ágil, y evito que piensen esas cosas “malucas” de mi, o de la empresa donde trabajo).
No es el propósito de este corto texto decirle qué es ser ágil: sobre ser ágil en procesos de desarrollo de software ya hay demasiada literatura (es sólo cuestión de buscar la correcta y no leer tanta basura disponible); el verdadero propósito es sugerir superficialmente “QUÉ NO ES” agilismo (muy a modo personal, y que caiga toda la responsabilidad sobre mí).
En 1918, un gran físico alemán recibió el premio Nobel de física. Ese físico del que casi todos hemos oído hablar desde el colegio o universidad, es Max Planck. Como gran científico y Nobel, fue invitado muchísimas veces a distintas partes de Alemania a dictar charlas sobre mecánica cuántica. El profesor Plank normalmente daba un discurso muy similar en todos los lugares académicos. Plank siempre era trasladado de un lugar a otro por su chofer que siempre lo llevaba a todas las conferencias y siempre se sentaba en primera fila. Una y otra vez, el chofer escuchaba con interés el tema de mecánica cuántica que el científico ofrecía (tema bastante complejo para los no físicos) .
Con el paso del tiempo, el chofer aprendió el discurso del científico de memoria, y de regreso a su casa comentó: “Debe ser muy aburrido dictar una y otra vez la misma conferencia, Profesor Plank. ¿Quiere que se lo dicte yo en Múnich? Usted me puede esperar sentado en primera fila como yo hago, y se pone mi sombrero de chofer. Eso nos dará a los dos algo de variedad para romper la monotonía”.
Planck disfrutó la idea. La noche de la conferencia, el conductor dictó una larga conferencia sobre mecánica cuántica frente a una distinguida audiencia. Más tarde, un profesor se levantó con una pregunta. El conductor respondió con cara de asombro: “Nunca me imaginé que alguien de esta avanzada ciudad como es Múnich haría una pregunta tan simple! Mi chofer se la contestará.” [Dobelli, 2013].
No voy a hacer comentarios sobre cómo esta anécdota puede aplicar al tema de agilismo en nuestra ciudad, en otras ciudades, o incluso en otros países. Cada cual saque sus conclusiones. Lo que sí voy a decir es lo que creo: usamos mucho conocimiento de chofer en agilismo, y eso puede afectar mucho nuestros procesos y productos.
A medida que nos movemos en el “mercado del agilismo”, vemos preconcepciones problemáticas de lo que es ser ágil, ya que si se quiere ser ágil, pues simplemente muchas veces escuchamos y aplicamos lo que se diga en el medio en eventos, paneles, blogs (como este texto que estás leyendo), cursos, y comentarios. Damos por sentada una “realidad ágil”, que no necesariamente apunta a la verdad. El problema es que los eventos, los cursos, y los blogs te dan herramientas útiles que mal usadas son inútiles y hasta contraproducentes. Tome como ejemplo el uso de scrum: hay proyectos en los que el uso de scrum es contraproducente, pero scrum casi siempre se usa para matizar el proyecto como ágil, o porque pensamos que scrum siempre es el marco adecuado porque es el que conocemos. Entonces, el error de pensamiento inductivo es: si un proyecto es Scrum, es un proyecto ágil.
La falacia radica en el hecho de no comprender de qué trata ser ágil. Ser ágil no es tener un proyecto montado en scrum con roles bien definidos. Ser ágil no se trata de tener tableros con post-its, ni evolucionar al uso de herramientas como Jira. Ser ágil no se trata de hacer retrospectivas. Ser ágil no se trata de hacer planeaciones cortas. Ser ágil no se trata de hacer sprints. Ser ágil no se trata de tallas de camiseta o de estimar con planning poker. Ser ágil no se trata de hacer reviews. Ser ágil no se trata de hacer ‘Dailies’. Tampoco se trata de hacer ‘user story maps’, ni de tener equipos autoorganizados o autogestionados o altamente motivados. Ser ágil no es tener equipos felices. Ser ágil tampoco se trata de que antes de comenzar un proyecto hagamos un impact mapping, o que definamos un product backlog, ni de que sepamos refinar una historia de usuario, o la sepamos escribir muy bien. Ser ágil no se trata de definir un sprint o un sprint backlog. Tampoco nos hace ágiles entender los requisitos, o ser hábiles en facilitación gráfica. Tampoco te hace ágil que en vez de escribir código y hacer una prueba, escriba primero la prueba y luego el código (TDD). De hecho, no te hace ágil escribir código muy mantenible que se pueda refactorizar fácilmente. Todo lo anterior lo puedo hacer en proyectos no ágiles.
No me lea mal: lo que pretende el párrafo anterior es decirle a algunos: “Hey, pssss”, pilas que primero debes entender qué es ser ágil antes de ponerte a ensillar un equipo ágil, ya que todo lo mencionado son sólo meras herramientas. Así hagas uso de ellas, no serás ágil.
Ser ágil es un tema de negocio y competitividad a través de la adaptabilidad.
Día a día los clientes definen sus hipótesis sobre el software que necesita su negocio para hacerlo más competitivo. Su negocio correrá sobre la base de software presumiblemente creado para hacer la empresa más apta para enfrentar el mercado: una excelente alineación a las metas de negocio, una adecuada priorización, planes de liberados con horizontes cercanos, y requisitos funcionales de corto alcance que permitan hacer validaciones tempranas de hipótesis de requisitos que faciliten abrazar el cambio para ser adaptables en un mundo altamente competitivo.
La necesidad de una entrega continua, sólo posible con iteraciones cortas con entregables de alto valor y calidad, usables y validables, es totalmente fundamental sobre la base de que no es posible tener una predictibilidad a largo plazo, pues la complejidad siempre va a estar presente haciendo de las suyas, modificando todos los planes, y haciendo el proyecto inmanejable. “Predictability has a devious sister named Complexity” [Jurgen 2011].
Toda esta adaptabilidad lograda por medio de la entrega continua con valor, no es posible sin una estrecha colaboración entre todos los involucrados, y es aquí donde fallan muchas herramientas, y otras se vuelven ganadoras. En colaboración, por ejemplo, el trabajo estrecho con altos niveles de confianza entre las partes, alcanzada sobre la base de valores de la credibilidad como la integridad, intención, capacidad y resultados: [Covey 2006 ], se vuelve fundamental. La herramienta que uses es meramente un medio, y debe ser seleccionada sobre la necesidad para solucionar problemas concretos, y no sobre la aplicación de una literatura.
La mejora continua por otro lado, se logra sobre la base de frecuentemente entender el pasado y redefinir el futuro, para lo cual hay que dar espacio a la reflexión para perseguir la adaptabilidad adecuada de los procesos.
Concluyo diciendo, que no podemos seguir cayendo en las mismas disfunciones procedurales una y otra vez, sólo por el hecho de que no tenemos muchas veces un sano entendimiento del verdadero propósito de ser ágiles. Puedes seguir usando scrum y puedes seguir haciendo producto con buena calidad; puedes tener equipos autoorganizados felices y motivados, y puedes usar todas las herramientas que te sugieren los eventos y los libros. Pero no serás ágil hasta no entregar software de alta calidad evolucionando de forma frecuente ante el día a día de las necesidades de mi negocio.
Agilismo no es entregar un producto de alta calidad al final del proyecto hecho con scrum o con cualquier otra guía, porque puede que ya sea demasiado tarde para el negocio. El reto es lograr la entrega continua de alta calidad con retroalimentación del negocio sobre la validación de hipótesis, y con alto valor para la competitividad de mi negocio, y un mínimo desperdicio. Cuando estés a ese nivel, podrás decir “soy ágil” o “somos ágiles”. Mientras tanto, sigue tu camino de aprendizaje por la senda adecuada mi pequeño shaolin, porque para lograrlo, se necesita mucho pelo para la moña.
“No puedes depender de tus ojos cuando tu imaginación está fuera de foco”
-Mark Twain-
Bibliografía:
[Mayer 2014], Bertrand Mayer, Agile! the Good, the Hype and the Ugly, 2014[Dobelly 2013], Rolf Dobelli, The Art Of Thinking Clearly, 2013
[Jurgen 2011], Jurgen Appelo, Management 3.0, 2011
[COVEY 2006], Sthepen M. R. Covey, The Speed of Trust
