Se me pasan los minutos
uno, dos, tres
sé cuál es mi apuro
la cosa es.
Acelerar,
(acelerar, acelerar, acelerar)
oh, oh, oh, oh.
—Anahí van Zandwegue y Memo Méndez Guiú.

Nuestro cliente ya lo había mencionado en un par de ocasiones, pero no fue sino hasta esa junta que me resonó la petición expresa de ser “lo más ágiles posibles”. Hacía un instante, un colega había manifestado algo parecido en relación con otro contexto y así, sucesivamente, comencé a escuchar el término con la misma frecuencia con la que escucho que determinado proceso, objeto o estructura aspira a ser creativo, colaborativo, disruptivo o innovador, sólo por mencionar algunos conceptos recurrentes.

Para estar en posibilidades de responder a las expectativas del cliente, leí Agile for dummies, tomé un curso de Scrum1 y me sintonicé tanto como pude.

Hecha la tarea, concluí que el cliente quería las cosas rapidísimo (para ayer, como suele decirse). Sin embargo, vale la pena explorar la pregunta si más rápido siempre es mejor, y bajo qué criterios. En ese sentido, tratar de entender qué puede significar trabajar con lineamientos ágiles.

Ilustración: Jonathan Rosas

Lo que no fue, sí será

En 1994, el grupo automovilístico Chrysler deseaba mejorar su sistema para el pago de la nómina a sus casi 90,000 empleados, por lo que contrató a Payroll Systems. En representación de dicha compañía, el desarrollador Tom Hadfield asumió el reto de diseñar e implementar el Comprehensive Compensation System (C3).

Uno de los problemas que enfrentaron Tom y sus programadores fue que el cliente no le hacía caso. Sumado a esto, los equipos trabajaban sin coordinación y competían entre sí en lugar de colaborar.

Con estas desventajas a cuestas, Payroll necesitaba refuerzos.Martin Fowler se sumó para capacitar el equipo, Kent Beck para mejorar el desarrollo con su método de refactorización, más tarde se incorporaron Ron Jeffries, Chet Hendrickson, así como Don Wells, experto en desempeño de equipos. Este último no dejaba de preguntarse: ¿por qué si aquí tenemos a tantos cerebritos y se han invertido millones de dólares, no logramos terminar el C3?

Unos geeks llegaban, otros se iban, el representante de Chrysler que colaboraba con el equipo de desarrollo tuvo una crisis nerviosa en ese navío que avanzaba pero hacía agua; así pasaron los años y llegó 1999. Daimler-Benz compró Chrysler y el C3 se puso en pausa para ser cancelado de forma definitiva a principios del milenio.

El C3 había terminado su historia, pero no sus beneficios. Kent Beck había sistematizado todos sus aprendizajes en un método llamado Programación extrema (Extreme Programming, XP), el cual parte de las siguientes reglas operativas:

1. Los equipos de XP producen y entregan pequeñas versiones de código de manera temprana.
2. Los equipos usan un sistema común de nombres y descripciones.
3. Los equipos enfatizan en el código simple y orientado a objetos que cumplen con los requisitos (del cliente).
4. Los diseñadores escriben pruebas unitarias automatizadas por adelantado y las ejecutan durante todo el proyecto.
5. Los equipos con frecuencia revisan y editan el diseño general del código (refactorización).
6. Los programadores trabajan codo con codo, viendo y discutiendo continuamente el código del otro.
7. Todos los programadores tienen la propiedad colectiva del código y la capacidad de cambiarlo.
8. Los equipos integran el código y concentran a un repositorio cada pocas horas y en ningún caso lo retienen más de un día.
9. Los programadores trabajan sólo 40 horas por semana, no hay horas extras.
10. Un representante del cliente permanece en el sitio durante todo el proyecto de desarrollo.
11. Los programadores deben seguir un estándar de codificación común para que todo el código en el sistema parezca que fue escrito por un solo individuo.

Estos principios pegaron con tubo en la manera de desarrollar software y, con los años, se convirtieron en el canon de ésta y otras industrias.

Lo primero que este sistema pretende evitar es que los nervios del cliente colapsen por falta de información durante el desarrollo de un proyecto encomendado a un proveedor. Lo siguiente que busca evitar es que el staff a cargo del desarrollo reviente por rencillas internas, malentendidos (entre sí y/o con el cliente) o jornadas de trabajo extenuantes. Finalmente, persigue que el entregable satisfaga por completo los requerimientos del cliente, aun si éste pidió cambios en etapas tardías del proyecto.

En suma, XP es un modelo para alcanzar la felicidad de los involucrados o, como diría Mihály Csíkszentmihályi, para garantizar el flow tanto en el proceso como en el resultado final.

Un manifiesto para unirlos a todos

Tras el descalabro de Chrysler, los compadres se fueron a esquiar a Utah junto con otros colegas que habían hecho sus propias pesquisas y desarrollado sus propios caminos para producir software de manera efectiva. Al calor de la chimenea y con unas copitas encima, conversaron acerca de las molestias y hallazgos que compartían en común, acordando los principios de lo que hoy se conoce como el Manifiesto ágil para el desarrollo de programas informáticos y para la vida en general.

Quienes se tomen unos minutos para consultar el manifiesto, podrán apreciar que adapta algunos principios de XP y mantiene el espíritu de trabajar sin que el cliente y los desarrolladores se maten en el proceso. También contempla que los productos se entreguen en el menor tiempo posible, sin que ello vaya en detrimento de las personas ni de sus relaciones.

El manifiesto puede ser una inspiración para otras industrias y ha adquirido momentum en los últimos años, hecho confirmado por la popularidad que los cursos de Scrum, Kanban, Crystal Clear y otros métodos han adquirido en fechas recientes. Todo parece ser algarabía; entonces, ¿cuál es el problema?

¿Tú y yo qué somos?

El adjetivo “ágil” se ha sumado a la plétora de palabras que expresan los anhelos; si no de todas, sí de muchas organizaciones interesadas en mantenerse a la vanguardia en sus métodos para operar. Mi cliente está siendo, en realidad, un hombre de su tiempo.

El problema es que, como ocurre con frecuencia, mi cliente no ha leído el Manifiesto ágil completo.

Ser ágil implica moverse con soltura y rapidez, de acuerdo con la RAE. Pero serlo en los términos propuestos por el manifiesto, implica además privilegiar a las personas y sus vínculos por encima de los procesos; al entregable por sobre la documentación del proceso; la colaboración con el cliente sobre la negociación contractual; asimismo, la adaptación ante el cambio por encima del apego estricto a un plan. Significa darle espacio y autonomía a los equipos para que se organicen y tomen decisiones, a la par que establecer reglas y sistemas claros para intercambiar y compartir información: así que es mucho más que hacer y entregar lo más rápido que se pueda, ¿no es así?

En el compendio de tendenciasMind the Future, editado por Web for Interdisciplinary Research & Expertise, se incluye una pequeña colección de dilemas para acicatear a los equipos de trabajo. Hay una en particular que establece la oposición progreso vs. continuidad y al reverso se indica: “atrévete a ser lento”, con su correspondiente reflexión para abordar el dilema.

Tras releer los principios de XP y del manifiesto y después de haber practicado al menos dos métodos ágiles, concluyo que la idea es encontrar una manera efectiva de hacer las cosas (una forma asertiva de ser lento, digamos), antes que entregar el trabajo lo más rápido posible y al costo que sea.

En todo caso, valdrá la pena preguntarse al querer implementar este tipo de métodos: ¿realmente se busca adoptar un marco de productividad ágil o sólo lograr que colaboradores hagan las cosas tan rápido como sea posible?

 

Karla Paniagua
Coordinadora de estudios de futuros en CENTRO y CFO en Punk.


1 Método desarrollado en los ochenta por Hirotaka Takeguchi e Ikujiro Nonaka a mediado de los ochenta y retomado por Jeff Sutherland, John Scumniotales, y Jeff McKenna en los noventa.

Leer completo