Hay algo que siempre me provoca mucha curiosidad al trabajar en Agile. Y esto viene ya desde hace años. Primero, por si caíste acá medio sin saber exactamente qué es Agile en lo que refiere a desarrollo de software, déjame que te cuente qué se supone que es:

Agile, en el contexto del desarrollo de software, es un enfoque de trabajo basado en iteraciones cortas, colaboración constante y adaptación continua al cambio, cuyo objetivo principal es entregar valor al usuario lo antes posible.

En lugar de planificar todo un proyecto por adelantado (como en el modelo tradicional Waterfall), Agile propone dividir el trabajo en pequeños incrementos funcionales llamados sprints o iteraciones, donde cada uno produce un producto parcialmente funcional y potencialmente entregable.

Principios clave de Agile

Basados en el Manifiesto Ágil (2001), que establece cuatro valores fundamentales y doce principios:

Valores principales

1. Individuos e interacciones por sobre procesos y herramientas.

2. Software funcionando por sobre documentación extensa.

3. Colaboración con el cliente por sobre negociación de contratos.

4. Respuesta ante el cambio por sobre seguir un plan.

Principios esenciales

• Entregar software funcional de manera temprana y continua (si, a costa de salud mental y deuda técnica, pero se suele cumplir)

• Aceptar los cambios, incluso en etapas tardías del desarrollo (permitime reirme: JAJAJAJAJA)

• Fomentar la colaboración diaria entre negocio y desarrollo (Se suele cumplir)

• Construir proyectos en torno a personas motivadas y de confianza (Hablame de motivación cuando no hay tiempo para hacer las cosas bien)

• Mantener un ritmo de trabajo sostenible (pero...los stakeholders quieren que entreguemos el producto AYER!)

• Buscar la excelencia técnica y el diseño simple (se suele cumplir)

• Reflexionar regularmente sobre cómo mejorar y ajustar el proceso (se cumple. Muchas veces no se hace nada al respecto)

En la práctica

Agile no es un método único, sino una filosofía que da origen a varios marcos de trabajo (frameworks) como:

• Scrum (el más popular, basado en sprints, roles y ceremonias)

• Kanban (flujo continuo de trabajo visual)

• Extreme Programming (XP) (énfasis en buenas prácticas técnicas)

• Lean Software Development (minimizar desperdicio y maximizar valor)

Todo esto suena bastante bien en la teoría, e incluso en la práctica, pero... he observado un pequeño inconveniente cuando se implementa en contextos corporativos.

Presupuesto mata Agile

La necesidad de planificar gastos y presupuesto según entregables mata la idea de Agile. Especialmente el punto de "aceptar los cambios, incluso en etapas tardías". Te explico por qué me da esa sensación. Ojo, esto aplica a empresas grandes. Onda...bancos, entidades del gobierno. Siento que en Startups se suele aplicar un toque mejor.

¿Querés probar este punto? Andá a decirle a tus stakeholders que lo que prometiste para Marzo va a ser entregado en Noviembre porque hacen falta varios cambios técnicos para implementarlo bien.

Vos sabés que, nos guste o no, hay un año fiscal. Ese año fiscal viene acompañado de objetivos para las empresas. Sea en ganancias, gastos, etc. Ahora...cuando se planifican los cuartos de ese año fiscal, se intenta definir qué cosas se van a entregar para que los dioses del presupuesto sonrían a los equipos y sigan tirándoles plata para seguir trabajando.

El problema de esto es que los dioses del presupuesto se ponen codiciosos y demandan, lógicamente para ellos porque entienden de gastos y ganancias solamente, un plan estructurado y definido a nivel de detalle para el que Agile NO sirve.

Entonces qué pasa... terminamos con un montón de items que si o si se tienen que entregar por cuarto. En el medio, como ya sabemos los que trabajamos en software, ocurren mil sorpresas. Desafíos a nivel técnico que no se habían tenido en cuenta, bugs, desastres en producción, soporte, etc. Todo eso obviamente demanda tiempo, tiempo que hay que sacar de los items que habían sido prometido a los demandantes dioses.

El resultado termina siendo una suerte de práctica que yo llamo "Salmón" más que Agile. ¿Por qué Salmón? Porque se siente como que vas todo el tiempo contracorriente de una cascada (Waterfall).

Esto concluye en que, en el mejor de los casos, se llegan con los deadlines pero a las apuradas, sin asegurar la calidad que se debería haber asegurado, cosa que, creeme, siempre vuelve en forma de incidentes en producción o deuda técnica.

En el peor de los casos no se llega con los tiempos, la gente termina re quemada, la confianza en entrega de los dioses del presupuesto disminuye y la plata...deja de fluir. Y ahí es cuando las cosas verdaderamente malas pasan: Despidos, reducción de personal, redundancias, etc.

En fin, quería escribirles sobre esto porque lo tenía en el tintero hace un tiempo. Justo tenía unos mates conmigo y dije "a ver qué opina la comunidad de ésto".

En tu proyecto...¿ves alguno de estos anti patrones? ¿Sentís que hacen Agile bien?

¡Me interesa leer tu opinión!