[18/03/2021] Agile debería ser una noticia de ayer. En realidad, es una noticia de hace una década. El Manifiesto Agile apareció hace casi 20 años y, a diferencia de Atenea, que surgió completamente crecida y acorazada de la cabeza de Zeus, muchos de nosotros habíamos practicado o fomentado técnicas agile mucho antes de que el manifiesto las hiciera oficiales.
Y, sin embargo, algunos intrépidos resistentes han conseguido mantener a agile -que tiene grandes tasas de éxito y satisfacción empresarial- a raya. Si está entre ellos y se siente presionado para "volverse agile”, es hora de dejar de sentirse como un dinosaurio que espera el impacto del asteroide. A continuación, siete probadas formas de tomar la ofensiva y evitar que agile ocurra en su organización de TI sin que se gane la reputación de ser el que entorpece el progreso de su empresa.
Denomínelo agile. Hágalo casual
Cuando lance su próximo proyecto, insista en que el director del proyecto lo dirija de "forma agile”, y que todos los miembros del equipo piensen cada mañana en lo que pueden hacer ese día para hacer avanzar el proyecto en la dirección que crean conveniente.
¿Pruebas? Cuando el equipo esté listo para probar una función, comunique al propietario del producto que necesitará que el personal de la empresa trabaje en la función mañana. Si no están disponibles mañana, no pasa nada. Solo significa que esa función tendrá que pasar al siguiente sprint.
Y si el propietario del producto se queja de que el proyecto no se ajusta a los plazos, bueno, esta es la parte bonita: simplemente explíquele que los "proyectos agile” no tienen plazos.
Al fin y al cabo, agile significa "sin plan”, ¿no es así?
Ignore la arquitectura
No pierda el tiempo al principio del proyecto definiendo la arquitectura de la aplicación. Si agile significa que los requisitos evolucionan continuamente, ¿no debería evolucionar también la arquitectura de la aplicación?
Así que no limite la creatividad de los desarrolladores insistiendo en la conformidad con un montón de principios abstractos. En lugar de eso, dé a sus desarrolladores la posibilidad de hacerlo. Deje que desarrollen como quieran, estructurando sus módulos e interfaces como quieran. Y si diferentes módulos de distintos desarrolladores no se conectan y funcionan juntos, o distintos desarrolladores escriben código que depende de diferentes bibliotecas, no se preocupe. Para eso está la refactorización.
Si diferentes desarrolladores quieren desarrollar en lenguajes distintos, bueno, para eso están los contenedores, ¿no?
La respuesta es Scrum. ¿Cuál era la pregunta?
Agile no es una metodología. Es una familia de metodologías, cada una de ellas adecuada para un tipo de proyecto diferente. Scrum ha surgido como la más popular, no porque sea la "mejor práctica”, sino más bien porque es la variante agile más rígidamente estructurada, lo que la hace más cercana que cualquier otra a la zona de confort de un proyecto tipo cascada.
Scrum es poco adecuado para las implementaciones de software comercial (COTS) y software como servicio (SaaS), que constituyen la mayoría de los proyectos que emprende TI. Una variante agile diferente, el conference room pilot (CRP), o su pariente cercano, el acceptance test driven development (ATTD), son mejores alternativas.
¿Pero quién ha oído hablar de ellas? Con toda probabilidad, nadie que importe. Incluso sus oponentes políticos más fuertes no lo criticarán por elegir la variante agile más popular, y eso si saben que hay otras variantes agile para elegir.
Así que cuando las cosas vayan mal con su implementación COTS basada en Scrum, no será porque debería haberlo sabido. Bueno, en realidad sí lo será, pero puede alegar que el proyecto fracasó porque agile nunca fue una buena idea en primer lugar, y puede insinuar con seguridad que cualquiera que argumente lo contrario solo está siendo quisquilloso para protegerse.
Jugar a los saltos: de Cascada a SAFe de un tirón
El encanto -y mayor fortaleza- de agile es su simplicidad. Su mayor debilidad es que no escala tan bien.
Las empresas inteligentes mantienen ágil a agile -tanto que amplían los principios agile para abarcar, no solo la implementación del software, sino todos los cambios de la empresa. Desde esta perspectiva, los planes estratégicos a gran escala son intrínsecamente de naturaleza tipo cascada y fracasan por las mismas razones que fracasan los proyectos del tipo cascada de TI: son lineales, con muchas interdependencias y potenciales puntos únicos de falla; y se basan en supuestos sobre el futuro que cambiarán al menos dos veces para cuando ese momento llegue.
Pero nada de eso importa. El trabajo del CIO no es hacer que el negocio sea más agile, sino apoyar la estrategia empresarial, independientemente de que tenga alguna posibilidad de funcionar. Y como lo agile no se adapta a los planes del tamaño que tiene un programa estratégico, el departamento de TI debe adoptar una metodología que parezca agile pero que escale como si fuera de cascada.
Bienvenidos a SAFe, el llamado Scaled Agile Framework (el origen de la "e” es un misterio sin resolver). Mientras que lo agile tiene éxito por su simplicidad metodológica, SAFe es terriblemente complicado, tiene tantas partes móviles, puntos potenciales de fracaso y suposiciones sobre el futuro como la metodología de cascada, con el añadido de que no es conocida.
Entienda, SAFe no es intrínsecamente malo, sino que requiere profesionales experimentados y bastante infraestructura de programa.
Si SAFe es lo que su empresa necesita, SAFe es lo que hará el departamento de TI, saltando el abismo de Cascada a SAFe de un solo brinco, sin importar los riesgos.
El programa fracasará, pero sus manos estarán limpias. Ya se le advirtió que lo agile no escala.
Insista en que sus socios de desarrollo utilicen agile. Insista también en que acepten ofertas de precio fijo
Por supuesto que tienen que usar agile. Es mejor, ¿no? Y, además, le está enseñando a todos los directivos de la empresa a trabajar con TI de una forma agile.
Y, por supuesto, las ofertas de los proveedores deben tener un precio fijo. Es la única manera de lograr que sigan siendo honestos. De lo contrario, tendrían un "incentivo perverso” para saltarse el presupuesto y el calendario del proyecto.
Y si un proveedor tiene la temeridad de señalar que comenzar con un rango fijo y cambiarlo solo a través de un rígido gobierno de control de cambios es la antítesis de lo agile, es bueno que usted haya aprendido lo difícil que sería trabajar con ese proveedor antes de firmar una lista de tareas.
Agile en el extranjero
En teoría, los planificadores de la empresa establecen objetivos de ingresos, costos, riesgos y consecución de la misión empresarial. En la práctica, en la mayoría de las empresas, los proyectos aprobados para su ejecución real son los que reducen los costos.
¿Qué mejor lugar para empezar que las tarifas que se pagan por las horas de los desarrolladores?
Cuando contrate a un socio de desarrollo, asegúrese de que la mayoría de los miembros de su equipo viven y trabajan a 11 zonas horarias de distancia.
Sí, el principio agile número seis hace hincapié en la importancia de las conversaciones cara a cara, entre los desarrolladores y entre éstos y los usuarios de la empresa. No, los desarrolladores en el extranjero no participarán en ellas.
No pasa nada. Ignórelo. Es solo teoría. Si hay que elegir entre ahorrar dinero y principios abstractos, los que ahorran dinero son los que necesitamos por aquí.
Y cuando el "equipo” agile entrega módulos que dan en el blanco equivocado también está bien. Esos módulos habrán costado mucho menos y el departamento de TI siempre puede recurrir a la explicación de que "el negocio” no tenía claros sus requerimientos.
El hecho de que los requerimientos no estuvieran claros debido a la escasa comunicación cara a cara no se le ocurrirá a nadie que importe.
Que el proceso sea lo más importante
Sí, sí, sí, todos sabemos que el Manifiesto Agile premia a "... los individuos y las interacciones por encima de los procesos y las herramientas”.
Pero si hay algo que los gerentes han aprendido en las últimas décadas es que el éxito en los negocios depende de instituir procesos repetibles bien definidos. El éxito no proviene de las relaciones, ni de la colaboración de los empleados para encontrar juntos las mejores soluciones.
No, el éxito proviene de que los empleados sigan los procesos, paso a paso, tal y como lo prescriben los diagramas.
Y como todo diseñador de procesos sabe, un buen proceso no deja nada al azar. Depende de usted asegurarse de que su proceso agile, al igual que todos los demás buenos procesos, describa cómo fluye de un punto al otro, en donde cada punto de decisión es descrito como una rama del proceso mientras todos los implicados convierten sus inputs en outputs que se convierten en los inputs del siguiente trabajador.
Si se añade suficiente complejidad al flujo del proceso agile, el departamento de TI acabará ampliando el alcance de la política encargada de hacer cumplir el proceso de gestión de proyectos de la EPMO, de tal forma que terminen vigilando a sus agile coaches, del mismo modo en que han mantenido a raya a sus gerentes de proyectos de cascada todo el tiempo.
Solución: Siga con el programa
Si las siete estrategias descritas aquí le parecen poco atractivas, tiene una alternativa más.
Puede rendirse a lo inevitable.
Podría reconocer que agile funciona mejor que Cascada y darle una oportunidad.
Dolerá, pero piénselo así: la operación de prótesis de rodilla también duele.
Pero en ambos casos, a largo plazo, evitarla duele más que hacerla.
Bob Lewis, CIO
Autor de 12 libros y más de 1.600 artículos, Lewis es uno de los asesores y comentaristas más respetados del sector de las TI. Ha ocupado una amplia variedad de puestos ejecutivos, de gestión y de personal en tecnología de la información, fabricación, desarrollo de productos y planificación empresarial... fue un profesional antes de convertirse en autor y asesor, una de las fuentes de su reputación de proporcionar una mezcla única de visión y pragmatismo.
En 2001, Lewis fundó IT Catalysts, una consultoría especializada en el cambio empresarial, la eficacia organizativa de las TI y la integración de las TI con el negocio. En la actualidad, trabaja como consultor senior en una importante empresa internacional de consultoría y servicios.