“El plan no es nada, la
planificación lo es todo”. Eisenhower
 |
| Imagen cortesía de Vichaya Kiatying-Angs /
FreeDigitalPhotos.net |
Basado en hechos históricos
Natalia es gerente de
proyectos de una importante compañía proveedora de servicios de tecnología. Es
la encargada de la operación en uno de los clientes más grandes de la empresa:
un conglomerado de telefonía móvil. Hacia el final de esta mañana la llamó el
director de mercadeo de esa organización bastante alarmado:
- Natalia,
hablas con Juan Pérez de Móviles del Sur* - ¿tienes un momento?
- Hola Juan, ¿en
qué te puedo ayudar?
Lo que siguió fue toda una
perorata que inquietó a Natalia. El cliente le contó cómo durante la mañana se
enteró de la Promoción Rumbo al Mundial Brasil 2014 que su más encarnizado
competidor sacaría a la luz la noche de ese día. Pérez sabía que de no
responder efectiva y rápidamente no solo dejaría de ganar cientos o miles de
clientes, sino que perdería muchos otros, lo que podría golpear severamente sus
márgenes de ganancia durante el primer semestre del año. Para suerte de
Natalia, el señor Pérez había hecho su tarea, ya sabía que debía actualizar las
herramientas de software de mercadeo y ventas para soportar una promoción agresiva
que debería estar al aire en la TV y en las redes sociales dos horas antes que
la de su competidor.
Mientras Pérez hablaba,
Natalia revisaba rápidamente el proceso de control de cambio de la compañía y
concluyó que podría entregarle una propuesta de trabajo que incluyera el
impacto de la actualización del software en costo y presupuesto a su cliente pero
solo hasta el día siguiente. Era inaudito, mientras Juan Pérez estaba buscando
una respuesta ágil y eficiente que concluyera con un resultado de valor en las
próximas 8 horas, Natalia se enfrentaba a la disyuntiva de seguir un proceso
clásico de estimación a priori y
modificación del plan de trabajo, previo análisis de impacto y de costos, que
redundaría en una pérdida tanto para su compañía como para la de su cliente, o
simplemente responderle firme y positivamente que cumpliría la meta establecida
para las siguientes horas.
El Manifiesto por el Desarrollo Ágil de Software (aka: la solución del proveedor)
Por suerte para Natalia,
ella también había hecho su tarea. En los últimos tiempos había empezado un
proceso de transformación en sus equipos que incluía una forma de ver el mundo
de manera distinta a como lo venían haciendo en la compañía. Se trataba de todo
un ecosistema basado en una cadena de valores y principios que rompían con los
esquemas tradicionales de hacer software. Todo empezaba con el así llamado
Manifiesto por el Desarrollo Ágil de Software o, simplemente, Manifiesto Ágil,
el cual le daría la clave para ganar ese día:
Estamos descubriendo formas mejores de desarrollar software tanto
por nuestra propia experiencia como ayudando a terceros. A través de este
trabajo hemos aprendido a valorar:
Individuos e interacciones sobre procesos y herramientas
Software funcionando sobre documentación extensiva
Colaboración con el cliente sobre negociación contractual
Respuesta ante el cambio sobre seguir un plan
Esto es, aunque valoramos los elementos de la derecha,
valoramos más los de la izquierda.
El Manifiesto Ágil por el Desarrollo de Software. Fuente:
http://www.agilemanifesto.org/iso/es.
Este pedazo de esfuerzo
mental, fruto de la colaboración de 17 personajes reconocidos en la industria
del software en 2001, serviría a Natalia como pilar fundamental para encontrar
una solución de valor para su cliente. Los Valores y Principios Ágiles
enfatizan en la importancia de colaboración e interacción en el desarrollo de
software y, de otro lado, el trabajo creativo involucra comúnmente alguna forma
de colaboración y puede entenderse como una interacción entre un individuo y un
contexto sociocultural.
Los proyectos
tradicionales están plagados de equipos conducidos-por-gerentes, organizados en
una estructura jerárquica con múltiples capas de autoridad. Esta gerencia es
del estilo de “comando y control” y los roles se basan en tareas funcionales
que, en el caso del software, son los programadores, los diseñadores, los
analistas, etc. El trabajo se delega a los miembros del equipo por sus jefes. Las
prácticas en estos equipos incluyen copiosa documentación, especificaciones
previas y planeación detallada. Las líneas de comunicación son indirectas entre
las distintas capas de la jerarquía organizacional y el empoderamiento es algo
invisible para la mayoría de los participantes, lo mismo que el estado general
del proyecto.
 |
Imagen cortesía de Salvatore Vuono / FreeDigitalPhotos.net
|
El primero de los valores
“Individuos y sus interacciones”, le indicaba a Natalia que necesitaba un
equipo cooperativo, multi-funcional y auto-suficiente, experto, altamente
productivo y creativo que se comunicara con su cliente y trabajara con él el
resto de la tarde, no solo en la extracción de conocimiento típica de los
proyectos actuales, sino en todo el ciclo de producción que le permitiera a
Móviles del Sur poner en funcionamiento una solución automatizada que soportara
su ambicioso programa de retención y captura de clientes con motivo del evento
mundialista de los próximos meses. Recordó así uno de los Principios que
acompañaban a esos valores ágiles:
Principio Ágil # 1: Nuestra mayor prioridad es satisfacer al cliente mediante la entrega
temprana y continua de software con valor.
Natalia sabía que la
filosofía ágil tiene la habilidad de amplificar la productividad de los equipos
de software hasta una escala de gran magnitud, a través del empoderamiento de
las personas, fomentando un entorno orientado-al-equipo y enfocándose en la
transparencia del proyecto y en los resultados. Estos proyectos pasaron de ser
dirigidos-por-el-plan a estar enfocados en el producto, uno priorizado por y de
valor para el cliente. Estos equipos se identifican a sí mismos como una unidad
social dentro de la organización de la cual hacen parte y a quienes se les
confía la ejecución del trabajo y se les proporciona el entorno y el apoyo que
necesitan, para mantenerlos motivados, como invoca otro de los principios del
Manifiesto Ágil, y para aumentar su apego emocional a la empresa.
Si bien se trata de un
conjunto de Valores, el último de estos, pero no por eso menos importante, no
devalúa la planificación, en la práctica solo se adhiere al plan. La
planificación es valiosa en sí misma; y dado que el plan nos asiste en la tarea
de reconocer cuándo las cosas han cambiado, también nos ayuda a entender las
implicaciones del cambio, cómo tenemos que ajustarnos y cuál es el costo
probable. Lo importante es que, a medida que hacemos planes, entendamos que el
plan puede cambiar. La planificación es una actividad continua que incluye:
- Reuniones de planificación
de iteración
- Reuniones diarias
- Reuniones de revisión
- Retrospectivas
- Evaluación de riesgos
Planificación clásica versus planificación ágil y
un mito que se niega a desaparecer
 |
| Imagen cortesía de hin255 / FreeDigitalPhotos.net |
Cada una de esas
ceremonias sirve para no solo para planear sino también para inspeccionar el
estado del proyecto y crear mecanismos de adaptación en caso de ser necesario.
El grueso de los practicantes de la industria y quienes la miran desde los
tejados, cree que los equipos ágiles son desorganizados, informales, que no
documentan y sobre todo que no planean. Todo eso se debe en parte a la mala
lectura que le dan al mismísimo Manifiesto Ágil. Pero no es así. Contrario a lo
que ocurre en los modelos tradicionales de planificación, donde se planea al
comienzo, se elaboran planes de 2, 3 o más niveles, y se hace seguimiento a ese
plan durante el resto del proyecto, un seguimiento que raya en el acoso, los
equipos ágiles planean todos los días.
En parte eso se debe a que
los equipos ágiles saben que los cambios hacen parte inherente, son
constituyente primario del ADN, del ciclo de vida del software. Los cambios
pueden ocurrir en cualquier momento, desde las etapas iniciales del proyecto,
aun cuando apenas se están conociendo las necesidades del usuario, hasta las
fases tardías del proyecto, quizás cuando estamos a punto de salir a
producción. Si son bien manejados, los cambios brindan muchos beneficios a los
usuarios, el primero de ellos, ventaja competitiva. Los cambios son una
herramienta invaluable para crear productos inmejorables. Era precisamente lo
que necesitaba Juan Pérez ese día. Otro de los principios ágiles llevó a
Natalia a esa conclusión:
Principio Ágil # 2: Aceptamos que los requisitos cambien, incluso en etapas tardías del
desarrollo. Los procesos Ágiles aprovechan el cambio para
proporcionar ventaja competitiva al cliente.
En cambio, los enfoques
tradicionales de gerencia de proyectos presentan los cambios como un monstruo
con el que hay luchar a sangre y fuego. Los procedimientos rigurosos de control
de cambio, típicos de estos enfoques, causan la pérdida de oportunidad que los
clientes tienen para ganar más mercado y para crear mejores productos. En
general, a medida que el tiempo avanza, la habilidad de hacer cambios disminuye
y cuesta más. Esto es lo que enfrentan los procesos ágiles, aunque sin dejar de
planear. Los métodos ágiles promueven planes más livianos y de alto nivel a
largo plazo, mientras que atienden la elaboración de agendas bien detalladas a
corto plazo, las de la iteración actual, que solo tarda unos pocos días o muy
pocas semanas. En Scrum, por ejemplo, las iteraciones tardan máximo 4 semanas y
con frecuencia mucho menos que eso.
Al principio de los
proyectos ágiles se planean las entregas o salidas a producción tempranas,
beneficio primario que nos traen los procesos ágiles. Estas salidas a
producción pueden ser cada tres meses, pero hoy contamos con la tecnología y
plataformas lo suficientemente maduras como para hacer continuous delivery o entregas continuas. Amazon, por ejemplo, la
vendedora al detal más grande del mundo, sale a producción cada 11,6 segundos,
algo absolutamente asombroso si tenemos en cuenta la cantidad de clientes
recurrentes simultáneos que tiene su sitio Web cada segundo. Natalia sabía todo
eso, entonces no dudó que podía tener un producto funcionando para antes de las
8 de la noche de ese día, meta principal de su cliente.
Resultado final
Mientras hacia un
recorrido por los acontecimientos de la hora, Natalia convocó a un equipo
idóneo, uno que sabía capaz de elaborar un producto que generara resonancia no
solo en su cliente sino en sus usuarios, uno que haga que la gente experimente
distintas reacciones de gozo al usarlo, sin hablar de los ingresos en que
redundaría su uso. No se trataba solo de actualizar un pedazo de software
existente, sino de producir algo no ordinario que tuviera la capacidad de
atraer a una audiencia cada vez mayor. Otro de los principios ágiles fue el
último consejo que le dio al equipo antes de despedirlo hacia lo que
seguramente sería un éxito total:
Principio Ágil # 10: La simplicidad, o el arte de maximizar la cantidad de trabajo no
realizado, es esencial.
¿Quieres saber más?
Sobre otros mitos y leyendas relacionadas con los métodos ágiles puedes
leer:
Mitos, Monstruos, Leyendas Urbanas y
otros Desvaríos de Ágil y Scrum: http://goo.gl/PIfZpx
Sobre cultura ágil y transformación a ágil, estos 2 artículos:
Cultura ágil: ese oscuro objeto del deseo:
http://goo.gl/IuJIlY
Sí, usted está listo para implementar un
proyecto ágil: http://goo.gl/19Hcnz
.jpeg)
