Fragilidad

Por Nicolás Paez, @inicopaez

Etiquetas: principios, mitos, profesionalismo

Introducción

Haberme acercado a las metodologías ágiles en 2003, permitió que pudiera experimentar en primera persona gran parte de su evolución a lo largo de todos estos años. Mi participación en diversos encuentros y conferencias, tanto académicas como industriales, sumada a mi trabajo como profesional independiente me ha permitido conocer muchos informáticos y ver de cerca la forma de trabajo de distintos equipos y organizaciones. Muchos argumentaban trabajar de una forma ágil pero bastaba con unos pocos minutos de charla para descubrir que más que ágil su forma de trabajo era frágil. En estas páginas quiero compartir algunas ideas, reflexiones y cuestionamientos surgidos a partir de diversas observaciones e interacciones que he tenido con individuos, equipos y organizaciones dentro del ámbito informático.

La popularidad

En los últimos 10 años los métodos ágiles han crecido exponencialmente en popularidad, traspasando incluso el dominio del desarrollo de software que fue donde tuvieron su origen. Los métodos ágiles surgieron en ciertos contextos particulares de la industria, luego se filtraron en la academia y desde hace un tiempo se están expandiendo en forma masiva llegando incluso a contextos que algunos podrían considerar "anti-ágiles". Este crecimiento de la “agilidad” también se evidencia en el incremento de la cantidad de publicaciones: libros, artículos de investigación, blogs, etc. Incluso han aparecido nuevos títulos para puestos de trabajo: en la actualidad es común encontrar anuncios en busca de Scrum Masters. En fin, en base a todo esto creo que la popularidad del “agilismo” es un hecho indiscutible.

Ahora bien, la popularidad en sí misma puede ser un arma de doble filo. Como suele ocurrir con toda moda que cobra popularidad, su demanda aumenta generando nuevas oportunidades de negocio. Este podría ser un aspecto positivo de la popularidad.

Es de esperar entonces que aparezca gente interesada en aprovechar esas oportunidades de negocio. El problema aparece cuando quienes quieren aprovechar la oportunidad ponen más foco en hacer el negocio que en satisfacer la oferta con calidad. Esto lleva a la aparición de consultores/coaches/instructores/empresas hablando sobre el tema de moda sin estar debidamente preparados. Esto, muchas veces, se traduce en una mala experiencia de los clientes que luego terminan diciendo frases del tipo "la agilidad no sirve" o “los consultores ágiles son chantas”. Este sería un aspecto negativo de la popularidad. En este sentido considero que esta popularidad negativa de la agilidad se debe en gran medida a la fragilidad.

Los fragilistas

Hace un tiempo me crucé en una reunión casual con una persona con quien trabajé brevemente unos años atrás. Recordaba su nombre pero no su apellido. Al día siguiente seguía intentando recordar su apellido así que decidí buscarlo en la web. Sabía sólo su nombre y sabía que lo tenía entre mis contactos de LinkedIn, así que comencé a recorrer mis contactos en dicha red. Curiosamente (o no tanto) varios de mis contactos tenían posiciones del tipo "Agile XYZ". Hubo dos contactos en particular, cuya posición indicaba “Agilista”, lo cual tras un segundo de reflexión me llevó a preguntarme ¿Qué sería ser Agilista? Instantáneamente pensé: un evangelista predica el evangelio, entonces ¿es agilista quien predica el agilismo? Suena razonable. Siguiendo con el paralelismo, el evangelio es un escrito bien concreto. ¿Cuál sería entonces el evangelio del agilismo? Creo que el Manifiesto ágil se ajusta bastante bien a ese rol. Pero si bien hasta aquí la analogía me parece bastante válida, hay un punto en el que no funciona: quienes predican el evangelio dan sustento a sus dichos, citando precisamente los evangelios. Sin embargo, he escuchado (o leído) a varios “agilistas” hablando sobre “agilismo” sin ningún tipo de sustento. En este sentido podría ser más conveniente llamar a esas personas “fragilistas” en lugar de agilistas.

Puede que en este momento el lector este desconfiando de mi, pero lo invito a que haga un experimento: la próxima vez que se encuentre con un "agilista" y lo escuchen enunciar alguna frase del tipo “el agilismo [...]”, pregúntele si puede citar alguna fuente para reforzar su afirmación.

¿Un fin, un medio o marketing?

En reiteradas ocasiones he escuchado gente diciendo frases del tipo: "pero XYZ no es ágil", “La empresa ha decidido ser ágil”, “hacerlo de esta forma es más ágil”. Este tipo de discursos parece sugerir que “ser ágil” es un fin. Muy posiblemente para alguna gente sea efectivamente así, pero sin duda hay algunas otras opciones.

Un caso que he visto en reiteradas ocasiones es el de gente más preocupada por decir que "es ágil" que por verdaderamente serlo. O sea, ven la agilidad como si fuera una herramienta de marketing. Estos casos los veo muy relacionados con la faceta negativa de la popularidad que mencioné previamente.

Otro caso bastante distinto es aquel con el cual yo me identifico. Yo soy ingeniero de Software, mi pasión es la resolución de problemas técnicos. Para mi, los métodos ágiles son un medio, no un fin. Un medio para resolver (o tal vez incluso evitar y/o mitigar) problemas. Creo que es en gran parte por esta visión que en general prefiero hablar de métodos ágiles que de agilidad. Si bien reconozco la existencia de "la agilidad" como movimiento, no me siento cómodo cuando me identifican como “agilista”. Yo me dedico a resolver problemas que generalmente incluyen la construcción de software y para cuya resolución suelo echar mano de diversas técnicas que se engloban dentro del mundo ágil. Sin embargo no soy fundamentalista y no creo que los métodos ágiles sean una bala de plata. Creo que como toda estrategia tiene contextos en los que suma y otros contextos en los que no. En este sentido el uso de métodos ágiles en contextos no apropiados para su uso termina generando fragilidad.

Ni para todo ni para todos

Lejos están los métodos ágiles de ser una bala de plata pero sin embargo veo (o mejor dicho leo) a diario gente empecinada en usar métodos ágiles en todo proyecto con el que tienen contacto sin quiera evaluar si la situación amerita su uso. Si se utiliza una herramienta en un contexto no propicio para su uso, puede que el uso de dicha herramienta termine provocando más problemas que soluciones (fragilidad).

Los métodos ágiles no son para todos los contextos. Hay ciertos prerrequisitos que debe cumplir el contexto para lograr un resultado exitoso utilizando métodos ágiles. Posiblemente uno de los más importantes sea el alto involucramiento del usuario. Otro requisito importante es la posibilidad de trabajar en forma iterativa. Hay algunos contextos donde el costo de iteración es muy alto lo cual imposibilita un flujo de trabajo iterativo.

Los métodos ágiles tampoco son para todas las personas. Estos métodos requieren de una comunicación muy fluida entre los técnicos y la gente de negocio. Pero he aquí una paradoja: gran parte de los que elegimos hacer una carrera técnica en computación lo hicimos con la ilusión/intención de interactuar con la computadora, no con gente. Recuerdo una situación que viví hace más de 10 años. Estábamos desarrollando un software a medida para un cliente e intentábamos trabajar de forma ágil. En una reunión de revisión un usuario nos hizo muchas observaciones sobre el comportamiento de una de las funcionalidades que que estábamos mostrando. Luego, en la reunión de retrospectiva tocamos este tema de la gran cantidad de comentarios que nos había hecho el usuario. Después de unos minutos de charla Ludovico, el desarrollador que había trabajado en la funcionalidad en cuestión, admitió que no había hablado en ningún momento con el usuario. Cuando le preguntamos porque no había hablado con el usuario Ludovico contestó: "He trabajado casi toda mi carrera en el área de sistemas de una empresa de ingeniería civil, donde los requerimientos me llegaban en un documento con un gran nivel de detalle. Sinceramente prefiero leer documentos detallados que hablar con el usuario".

Personalmente no me asombró la situación de Ludovico, pues en aquella época los planes de estudio de las carreras de computación/informática apenas si prestaban atención a las cuestiones de "trato/interacción humana". En mi caso particular creo que lo más cercano que tuve a temas humanos en toda mi carrera fue la materia “Recursos humanos”, cuyo nombre ya da una idea cuán poco humana es la visión que se pretende transmitir.

Claro que siempre es posible usar alguna práctica ágil "suelta" como retrospectivas o integración continua, pero el solo uso de algunas prácticas ágiles no me parece suficiente para decir que uso trabaja de manera ágil. Más que ágil sería frágil.

Scrum flácido

En 2010 Martin Fowler publicó un artículo titulado Scrum flácido en el cual definió esta "variante" de Scrum como:

1. Una organización quiere trabajar de forma ágil y decide para ello utilizar Scrum

2. Adopta las prácticas de Scrum y tal vez también sus principios

3. Al cabo de un tiempo el ritmo de avance del proyecto es aún más lento que antes debido a que su código apesta

Cabe destacar que, si bien la propuesta de Scrum tiene su foco en cuestiones de gestión, no deja de mencionar la importancia de la cuestiones técnicas. Pero a pesar de ello, creo que algunos practicantes lo pasan por alto.

En mi día a día he conocido varios equipos/organizaciones haciendo Scrum flácido, y es por esto que cuando otros equipos/organizaciones me convocan para que los ayude en su adopción de métodos ágiles, intento llevarlos por un camino más del tipo Extreme Programming, comenzando por las prácticas técnicas. Sin embargo, he podido avanzar muy poco con esta estrategia, ya que sin un orden básico en la forma de trabajo, cualquier práctica técnica que implica cierto cambio de hábitos, es abandonada a la brevedad en cuanto el negocio empieza a presionar con las fechas de entrega.

¿Entonces está bien arrancar por Scrum?¿No se corre el riesgo de caer un en Scrum flácido?¿De ser frágil en lugar de ágil? Puede que sí, puede que no, en todo caso el problema está en si solo adoptamos las prácticas de gestión de Scrum, o sea, creo que es necesario trabajar simultáneamente en las prácticas de gestión y en las prácticas técnicas. He hablado sobre esta situación con varios colegas y algunos me han sugerido que la raíz del problema no está en Scrum, sino en los coaches de Scrum, que muchas veces no tienen habilidades técnicas y que por ello dejan postergada la adopción de prácticas técnicas en los equipos con los que trabajan.

Para cerrar:

• Coaches de Scrum: no posterguen las prácticas técnicas

• Equipos: asegurense que su coach de Scrum tenga habilidades técnicas

El enfoque híbrido

Hace un tiempo con nuestro grupo de investigación sobre prácticas y procesos en la Universidad Nacional de Tres de Febrero, nos sumamos al proyecto Helena, liderado por un conjunto de investigadores alemanes. El nombre Helena surge de: Hybrid dEveLopmENt Approaches in software systems development . Este proyecto parte de la idea de que muchos equipos/organizaciones utilizan un enfoque híbrido en sus procesos de desarrollo, mezclando prácticas del mundo ágil con prácticas del mundo "no-ágil". Un ejemplo de esto podría ser un equipo que trabaja con un proceso waterfall y que al mismo tiempo hace retrospectivas.

Mi primer impresión cuando escuche sobre "el enfoque híbrido" fue: eso es ágil mal hecho. Con el correr de los días y luego de hablarlo con algunos colegas, no cambié de opinión, pero entendí que llamarlo “Enfoque híbrido” podría resultar mucho más amistoso y constructivo que llamarlo “agile mal hecho” (aunque posiblemente alguién podría llamarlo Waterfall mal hecho). Al mismo tiempo, creo que tiene valor entender las particularidades del enfoque híbrido para así detectar las posibles falencias y/o dificultades de los métodos de manual, que llevan a que los proyectos/equipos/organizaciones decidan inclinarse por un enfoque híbrido, que no se ajusta a la definición original del manual. Quién sabe, tal vez incluso pueda llegar a tener valor formalizar el enfoque híbrido y terminemos teniendo un cuerpo de conocimiento al respecto.

Conclusión

Sospecho que algunos lectores no llegarán a este punto pues soy consciente que las ideas compartidas en los párrafos anteriores pueden haber sonado desalentadoras, conflictivas, negativas. Incluso algún lector podría tildar dichas ideas como delirantes. Tal vez lo sean.

Pero para aquellos que llegaron hasta aquí, en primer lugar les agradezco por tomarse el tiempo de leer todo lo anterior. Puede que se estén preguntando cual fue mi objetivo al compartir estas ideas polémicas. La respuesta es simple: pensar, reflexionar y en última instancia llamar a la acción. Todos los cuestionamientos aquí planteados no son obra mía, sino que son el resultado de intercambios con diversos colegas y clientes.

Para cerrar espero que todos aquellos que tienen un rol de docentes, instructores, consultores, facilitadores tomen conciencia de estas percepciones distintas de la agilidad que por momento la hacen ver como fragilidad.