De Retrospectivas y de Ratones

O de cómo los Agilistas le ponemos el cascabel al gato

La falta de atención a las acciones de mejoramiento es una de las razones principales por las cuales muchas personas, equipos y organizaciones no ven valor en las retrospectivas*; es uno de los motivos por los cuales en una tras otra de estas ceremonias dejamos entrever el mismo comportamiento apático y hasta errático, es la causa por la cual nos sentimos grandemente desmotivados cuando de regresiones ágiles se trata.

Las acciones de mejoramiento que surgen a raíz de una retrospectiva o de cualquier otro evento durante el sprint no se ejecutan los fines de semana a las 3 de la tarde o el jueves a las 10 de la noche antes de finalizar el sprint actual; tampoco se realizan solo por mencionarlas, como si la lista de acciones se tratara de un pozo de los deseos que el Hada de las Retrospectivas hace realidad cada dos semanas o menos.

Cada una de esas acciones toma tiempo, se trata de un esfuerzo serio para el que quizás no estamos preparados pero que debemos llevar a cabo si queremos mejorar como personas, como equipo, como organización.

Hay diferentes categorías de mejoramiento:

A nivel personal

A nivel de equipo

A nivel de liderazgo

A nivel de organización

Conocer el impacto que tendrá la acción de mejoramiento nos ayuda a saber a dónde ir, qué puertas tocar en la organización, cómo tenemos que proceder.

En ocasiones, las acciones de mejoramiento no se implementan o el objetivo no se alcanza en un solo sprint. Lo importante es que al final de cada iteración haya avances o hayamos logrado metas intermedias. Volveré con esto más adelante en una de mis recomendaciones a continuación.

Recomendaciones

Podemos proponer o establecer un time-box para ejecutar estas acciones de mejoramiento. Es decir, un lapso de tiempo máximo durante el sprint, así como lo hacemos con la planificación, el refinamiento o la misma retrospectiva. Ese tiempo dependerá de si la acción de mejora será ejecutada una sola persona, varias o todo el equipo; también, si depende de alguien más en la organización o de otra área de la misma. En este último caso, alguien del equipo Scrum, no tiene que ser solo el Scrum Master, debería encargarse de gestionar la realización de esas acciones. Lo importante es que en la siguiente retrospectiva mostremos avance medible y verificable de la tarea.

No tratemos de mejorar solo lo que hemos hecho mal o lo que no estamos haciendo. También se puede seguir mejorando lo que estamos haciendo bien o muy bien. ¡No hay límites!

En ese mismo sentido, no abordemos solo los problemas que enfrentamos durante el sprint, analicemos también lo que hemos hecho bien y por qué, para seguir haciéndolo, para convertirlo en algo común y corriente en nuestro trabajo, recordable y repetible.

No convirtamos la retrospectiva en una sesión de autoflagelación. El “mea culpa” por humildad o por sacrificio no funciona. Si esto se repite es porque no estamos creando escenarios seguros para fallar y aprender y entonces allí hay una acción de mejoramiento que realizar.

No dejemos todo en manos de la Organización. En principio, las acciones de mejoramiento son nuestra responsabilidad. Si más adelante, después de implementarlas, logramos que la organización se beneficie con ellas, bienvenidas. Las tareas que se salgan de nuestras manos o de nuestro control, ya sea por presupuesto, por tiempo o por complejidad o por cualquier otra razón, entreguémoslas a ojos cerrados. El Scrum Master o el Dueño de Producto nos pueden servir de puente con el resto de la organización para que estas se implementen en algún momento. En cualquier caso, no dejemos que estás bloqueen nuestro trabajo.

Aunque el mejoramiento no es el foco principal de lo que hacemos, tampoco debería ser lo más complejo, lo que más estrese el esfuerzo de las personas o del equipo. Concentrémonos en acciones pequeñas pero de alto impacto, o realicemos su implementación gradualmente. Por ejemplo, si queremos mejorar nuestra puntualidad porque estamos llegando tarde, no intentemos lograrlo del todo en un sprint o menos. Más, si esa no es nuestra cultura. En cambio, hagámoslo incrementalmente. ¿Qué tal 5 minutos la primera semana o el primer sprint? ¿Lo logramos? Bueno, ahora otros 10 minutos. ¿Meta alcanzada? Ahora sí, últimos 15 minutos. ¿Ya estamos llegando a tiempo? Sigámoslo haciendo de esta manera para siempre, motivados, con energía, ¡con la mente en el juego!

Toyota Kata viene a mi mente, pero hablaremos de ello en otra ocasión. Sin embargo, y a propósito de esto, las acciones de mejoramiento no tienen por qué ser una lista plana, a veces sin voluntad, sin vida. Pensemos en experimentos. Propongamos hipótesis. Hagámoslo divertido. Después de todo, esto debe ser lo “fácil” de nuestro trabajo. Lo otro, lo verdaderamente esencial, el desarrollo del producto/servicio en medio de la incertidumbre y hasta del caos, eso sí que debe estresarnos. Busquemos en la realización de estos experimentos, en la prueba de estas hipótesis, ese descanso que nuestra mente necesita para lograr ese otro objetivo cardinal que nos ocupa.

¿Y qué sucede, qué hacemos cuando la implementación de una acción de mejoramiento nos está causando problemas? ¿Desechamos esa mejora? No. Cambiamos la estrategia, solicitamos ayuda, ¡está bien pedir ayuda!

Trabajemos en equipo: el todo es mayor que la suma de las partes y es una de las razones por las cuales, los equipos Ágiles, como los gatos, siempre caemos de pie.

Finalmente, no esperemos al término del sprint para revisar y conocer si nuestras acciones de mejoramiento se han implementado o están en camino. Seamos proactivos: ¿en qué vamos? ¿Cómo podemos ayudar? ¿Hay algo que pueda hacer para que logremos este objetivo? Son algunas de las preguntas que nos podemos hacer como equipo, quizás durante la Reunión Diaria o en cualquier otro momento del día, mientras estiramos las piernas o nos tomamos un café. O simplemente digamos, “¡hoy es un buen día para mejorar!”

Siempre recomiendo realizar una retrospectiva al final de la iteración, a no ser que alguien mencione que está muy ocupado. ¡En cuyo caso, recomiendo hacer una segunda a mitad del sprint!

Y tú, ¿qué estás haciendo para mejorar? Déjamelo saber en el foro.

-----

*Adenda

Siempre recomiendo a los Scrum Masters que acompaño o a cualquier miembro del equipo que recuerde durante las primeras de cambio la Directiva Primaria de las Retrospectivas, sobre todo las primeras veces que se realiza un ritual de esta naturaleza, cuando el equipo es nuevo o cuando detectamos en los asistentes cierto temor a participar activamente de las mismas. Puedes descargarla de:

http://www.gazafatonarioit.com/2017/05/directiva-primaria-de-las-retrospectivas.html

Ahora bien, para saber más de retrospectivas, puedes leer este artículo de mi gran amigo Leonardo Agudelo, http://www.twitter.com/sweepnoise, que publicamos en la página de la Comunidad Ágiles Colombia:

Buenas retrospectivas = equipos en mejoramiento constante

Y luego te recomiendo ampliamente las Lecciones Aprendidas de mi otro gran amigo Jorge Abad, http://twitter.com/jorge_abad, con quien he tenido la oportunidad de hablar extensamente sobre el asunto mientras ayudamos a terceros a implementar todas estas formas mejores de hacer las cosas:

[Agenda Scrum] Pasos para Realizar la Retrospectiva

Empezar una Retrospectiva y la Directiva Principal de las Retrospectivas Ágiles

Scrum Master: Cómo Continuar la Mejora Continua de tu Equipo

Tip de Scrum: La calificación del Product Owner al finalizar el Sprint

No esperar hasta la retrospectiva para mejorar

Y un recurso indispensable para realizar retrospectivas fantásticas, es Retromat, de Corinna Baldauf, una suerte de elementos en los cuales inspirarnos y con los cuales podemos planear nuestras próximas retrospectivas, y cuya traducción al español hace ya algunos años fue conducida por Thomas Wallet, quien se define a sí mismo como un enfermo de las retrospectivas, acompañado de Pedro Serrano y un grupo de entusiastas de la Comunidad Ágil Latinoamericana:

https://plans-for-retrospectives.com/es/

Créditos de la portada: Designed by Peoplecreations / Freepik

Del triángulo de hierro al triángulo ágil extendido

Las empresas en período de transformación organizacional se enfrentan a la dicotomía de seguir paradas sobre el triángulo de hierro en lo que se refiere a planificación y gestión de proyectos de software o moverse a una zona que en principio se les parece más al Triángulo de las Bermudas que al área de confort por donde han transitado durante las últimas décadas.

De lo más valioso que hemos aprendido en el desarrollo de software es que muchas de las prácticas y técnicas usadas desde aquella histórica reunión del Comité Científico de la OTAN en 1968 en la ciudad de Garmisch, Alemania y que diera inicio a la Ingeniería de Software como profesión, fueron tomadas a manera de préstamo de otras áreas de la ingeniería y de otras ciencias aplicadas.

Algunas de esas prácticas influyeron directamente en la forma de realizar estimaciones y de planificar proyectos de software. Específicamente, hemos aprendido que no podemos estimar ni planificar proyectos de software como lo hacen en proyectos de la industria de la construcción… ¡a no ser que vayamos  a usar piezas de Lego® para construir ciudades!

Afortunadamente ya sabemos con certeza que la ingeniería de software tiene su propia personalidad. Se trata de un sello que la hace única y que hace que sus practicantes se distingan del resto de profesionales de la ingeniería y de otros cuerpos de conocimiento. Por ejemplo, en su libro Agile Project Management, Jim Highsmith[1] sugirió que si aplicamos el enfoque Ágil al Triángulo de hierro encontraríamos los siguientes vértices:

• Valor, para el usuario en términos de un producto que se pueda distribuir y cuyo uso genere beneficios para la organización.
• Calidad, para entregar continuamente valor al usuario en términos de un producto confiable y adaptativo.
• Restricciones, los ya tradicionales alcance, tiempo y costo, en donde, si movemos uno, usualmente el primero, se mueven los otros dos.

Como dice el mismo Highsmith [2], las restricciones siguen siendo parámetros importantes de un proyecto pero no constituyen el objetivo del mismo. En cambio, el Valor y la Calidad establecen la meta del proyecto y las restricciones mencionadas se ajustan a medida que el proyecto incrementa el valor para el usuario. En particular, El tiempo podría seguir siendo una restricción fija pero entonces el alcance debería ajustarse para entregar el valor más alto posible dadas las restricciones impuestas.

Como nos gusta lo visual, esta otra versión del triángulo ágil de Highsmith nos llega más:

Más allá de este enfoque de planificación y de gestión de proyectos (ágiles), quienes ya hemos trasegado algunos años por los vericuetos, subido a los riscos y caminado por los valles complejos del desarrollo ágil de software, sabemos que todo momento es una oportunidad de mejorar: de mejorar como personas y como profesionales, de mejorar los procesos y las técnicas, de mejorar la calidad de los productos y de incrementar el valor que estos entregan a nuestros usuarios. ¡Es la mejora continua!

Ahora bien, la mejora continua junto al valor y a la calidad forma otro vértice del triángulo, el del resultado. A los agilistas no nos interesa simplemente crear un producto, por más disruptivo o benéfico que este sea. Nos interesa pensar en lo que viene, en lo que llevará al cliente al próximo nivel de optimización, satisfacción y felicidad.

Pero lo más importante en todo proyecto, en todo proceso de innovación o mejoramiento, en todo plan que tenga como propósito el diseño y la construcción de productos (de software), son las personas: la comunicación cara a cara entre ellas, la motivación de todos los individuos que intervienen en el proyecto, la atención continua a la excelencia técnica, la autogestión del equipo y la confianza que la organización deposite en ellas se constituyen en las bases del éxito de cualquier iniciativa que requiera generar nuevos productos o servicios.

Las cosas así, podríamos entonces encontrarnos con esta nueva versión del triángulo ágil:

Referencias:

[1] Highsmith es uno de los 17 firmantes del Manifiesto Ágil

[2] Beyond Scope, Schedule, and Cost: Measuring Agile Performance

Libro: ‘La práctica de inteligencia de negocios: guías para lograr proyectos exitosos’

“El escritor escribe su libro para explicarse a sí mismo lo que no se puede explicar.”

[Gabriel García Márquez, escritor colombiano]

Siempre me da mucho placer realizar este tipo de anuncios. Conozco a Mauricio hace casi dos décadas y hemos tenido la oportunidad de trabajar juntos en distintos proyectos, incluyendo algunos de Inteligencia de Negocios, y de compartir más allá de la práctica profesional. Sé de su pasión por la lectura, por los hechos de la Historia y conozco también del esfuerzo monumental que es escribir y más si se trata de un libro como este. Por eso sé que para Mauro escribir este volumen se convirtió en una osadía, pero finalmente está aquí, el fruto de muchísimas horas de desvelo y estudio.

En el libro, Mauro nos embarca en una lectura amena que inicia con los conceptos generales de la práctica de la Inteligencia de Negocios, pasando por el propósito y los elementos de la práctica, los métodos y las herramientas usadas, lo que él llama ‘la hoja de ruta de un proyecto de Inteligencia de Negocios’ y dedica capítulos enteros a temas vitales como las pruebas y la calidad del producto, el despliegue, gestión de cambios y actividades posteriores a la implantación, hasta llegar a la infraestructura requerida en los proyectos de inteligencia de negocios.

De todo esto, el capítulo VI es mi favorito, porque habla de las personas y de la relación cliente – proveedor, asunto natural cuando se trata de una organización orientada a los servicios de tecnología de la información. Mauro habla de los roles principales a tener en cuenta cuando se trata de tener éxito en los proyectos y en particular dedica una sección a los roles típicos en las organizaciones con iniciativas de Inteligencia de Negocios.

Y a través de todo el texto, Mauro también aborda el tema de cómo se implementan todos estos elementos con métodos y prácticas ágiles como Scrum. De tal suerte que este es un compendio sensato de lo que cualquier interesado, persona u organización, debe tener en cuenta al momento de llevar a cabo proyectos de Inteligencia de Negocios.

Contraportada de 'La práctica de inteligencia de negocios' de Mauricio Cotes

Una de mis partes favoritas en todo el libro tiene que ver con el uso de las metodologías. El pensamiento de Mauro no se circunscribe a un método en particular, permitiendo la elección al lector. Eso es excelente, porque no entra y no promueve  o siembra elementos dogmáticos en el texto, es una apertura sistémica.

De hecho, su ‘conclusión en relación con el uso de las metodologías’ es algo que no solo es aplicable a proyectos de Inteligencia de Negocios. Mauro nos dice:

 “Finalmente, es ideal que el proveedor tenga la posibilidad de configurar la metodología de manera tradicional o ágil dependiendo de las condiciones, premisas y la negociación hecha con el cliente. El cuerpo metodológico seleccionado debe ser configurable, debe estar documentado, los practicantes deben aprehenderlo y ser conscientes del propósito de cada uno de los elementos que lo constituyen.

Los practicantes de los roles encargados de la contratación y negociación deben tener en cuenta las premisas mencionadas y ofrecer la modalidad apropiada de trabajo según el caso.”

En definitiva, en ‘La práctica de inteligencia de negocios’, Mauro saca a relucir sus veinte años de experiencia en el tema. Es un libro escrito desde la pragmática del autor, con el suficiente soporte teórico, pero sobre todo, con la idiosincrasia nuestra, la del trópico, con la visión de nuestra economía y de nuestra forma de hacer proyectos, lo que lo convierte en un documento valioso para cualquier estudiante y profesional y para cualquier organización que piense en serio acerca de la práctica de la inteligencia de negocios.

Es un trabajo minucioso, que te ha costado encorvarte durante muchísimas y largas horas, pero finalmente tú y todos nosotros tenemos la mejor recompensa: un sumario de todo tu fogueo en el asunto. ¡Enhorabuena, Mauro, felicidades por este gran logro!

¿Quieres conseguir el libro?

Escríbanle un mensaje electrónico a Mauro a la dirección: rmcotes@hotmail.com. Él les dará más detalles de cómo obtenerlo.

Ecos del SEPG Latino América 2014

Manizales, en los alrededores de la sede de la SEPG LA

Para quienes no están familiarizados, SEPG es la serie de conferencias premier en gestión de procesos de software y sistemas. Cada conferencia brinda desarrollo profesional en mejoramiento de procesos a través de sesiones técnicas enfocadas en tecnologías como CMMI, People CMM, PSP, TSP, Agile, ISO y Six Sigma; también aborda los enfoques para implementar alta madurez, técnicas efectivas de adquisición, desarrollo y entrega de servicios, entre otros temas de relevancia para la industria.

En Latinoamérica este año la edición de la conferencia, SEPG LA, se llevó a cabo en Manizales, en un ambiente natural, rodeado de montañas y termales de aguas que provienen directamente de las entrañas de la tierra, nos reunimos 2 o 3 centenares de personas que llegamos de latitudes tan diversas como España, USA, Chile, México y Colombia. Como era de esperarse, el programa de la Conferencia se combinó con un ambiente de networking entre los asistentes, condición sine qua non el evento no hubiese colmado las expectativas de quienes acudimos a la cita.

El Programa

Cuando me enteré que el llamado de artículos incluía entre sus temas principales la combinación de disciplina con métodos ágiles pensé que era una forma peyorativa de nombrar los métodos y prácticas con enfoque ágil. Eso me motivó a participar. Involucrado como he estado en los últimos años con la agilidad y lo que yo llamo la Cultura Ágil, liderando el proceso de transformación de una compañía con un alto nivel de madurez, he aprendido que los dos ecosistemas, el de procesos prescriptivos tipo CMMI, y el de procesos generativos tipo Scrum, se pueden “aprovechar” uno del otro. Con ello en mente, preparé mi ponencia “Ágil es algo que eres, CMMI es algo que usas”, pero eso es algo a lo que llegaré más adelante.

• El resto del programa incluía temas como:
• Competitividad y supervivencia en un mercado globalizado (Visión estratégica del sector TI)
• Mejora de procesos en entornos diversos (pequeños, pymes y grandes empresas)
• Alcanzando y trabajando en entornos de alta madurez
• Mejorando la capacidad de la prestación de servicios TI
• Industrializando la producción de Software
• Retos en las arquitecturas y nuevos modelos de negocio TI (Arquitectura Empresarial, Cloud, Big Data, Movilidad, Seguridad, entre otros), y
• Marca y normatividad sectorial de Software

El plato estaba servido, mi artículo había sido aceptado en la Conferencia, así es que viajamos a Manizales en compañía de algunos colegas y amigos de la industria. Al ver la fascinación que representaban las cordilleras colombianas, mientras repasaba lo que había escrito para la ponencia sobre lo que significa ser ágil, recordé a uno grande de la industria, Steve Jobs, diciendo que ese precisamente había sido uno de sus mantras – foco y simplicidad.

Tenía razón Jobs, lo simple puede ser más difícil que lo complejo. Tienes que trabajar duro para lograr que tus pensamientos sean limpios y poder alcanzar así la simplicidad. Pero vale la pena, porque una vez allí, puedes mover montañas. En ágil, la simplicidad el arte de maximizar el trabajo no realizado, es esencial. O así lo invoca el Manifiesto Ágil.

El Evento

El Ministro TIC de Colombia, Dr. Diego Molano Vega

El inicio del evento supuso un acto protocolario algo extenso para mi gusto – qué le vamos a hacer, ¡tenía que decirlo! –, que incluyó al Ministro de las TIC en Colombia, Dr. Diego Molano, y al alcalde de Manizales, con presentaciones bastante enérgicas, lo mismo que a la Dra. Elena Schaeidt Ayarza, Directora de Desarrollo Corporativo e Internacional de TECNALIA y al Dr. Albeiro Cuesta Mesa, Director de Políticas y Desarrollo TI hablando sobre cómo se está transformando la industria TI en Colombia.

A continuación, el Dr. Kirk Botula, CEO del CMMI Institute, rama recién desprendida del SEI, nos habló de cómo hacer para que la industria de TI latinoamericana trabaje mejor. En su presentación, el Dr. Botula hablaba de como la misión del CMMI Institute era hacer que el mundo trabaje mejor, hacer que el mundo del trabajo, funcione mejor. La razón por la que la gente adopta CMMI, decía Botula, o de preocuparse por esos marcos de trabajo o las evaluaciones CMMI o el entrenamiento en esas áreas, es debido a los buenos resultados que todo eso lleva a las organizaciones e instituciones que lo usan.

Pero el Dr. Botula también le abrió las puertas a la filosofía ágil. Afirmó que con técnicas ágiles ganamos el 5% más de velocidad que con CMMI y 2% más que con TSP, aunque dijo también que los costos de desarrollo son los mismos. ¿Qué si ágil es la dirección correcta? No, según Botula todavía no, pero igual pensé que el haberlo mencionado ya era un hito.

Al día siguiente, la contraparte de Botula, el Dr. Paul Nielsen, CEO del SEI, habló de la calidad del software y de su impacto en la ciberseguridad. Mostró datos nada nuevos para quienes estamos involucrados en el tema: que el 70% de los defectos del software se introducen en las primeras etapas del desarrollo y que solo se encuentran el 3,5% de los errores en esas mismas etapas (requisitos, diseño, arquitectura y diseño de componentes). El mensaje de Nielsen es que sigamos adoptando un enfoque centrado en la arquitectura, nada que no hayamos estado haciendo hará ya una década y media con la guía de procesos como el Unified Process.

Además hubo una mesa redonda moderada por la Viceministra de TI de Colombia, la señora María Isabel Mejía, con un panel compuesto por los directores de los clusters de empresas de TI en Colombia, como Lina Taborda, Directora de Intersoftware, y María Victoria Gara, Directora de CaribeTIC, entre otras personas. El panel versó sobre la oferta y la demanda de las TIC en Colombia en el que se dijo que necesitamos más talento calificado, más programas específicos de desarrollo de las TIC para las regiones, etcétera.

La Viceministra de TI, María Isabel Mejía

A propósito de la Viceministra, tuve la oportunidad de almorzar con ella y con Lina Taborda de Intersoftware (por invitación de esta última). El objetivo inicial era presentarle las VII Jornadas Latinoamericanas de Metodologías Ágiles que serán en octubre en la ciudad de Medellín y de cuyo equipo organizador hago parte, pero el almuerzo se extendió gratamente y tuvimos la oportunidad de hablar largamente de métodos y prácticas ágiles y de la presentación que yo haría un par de horas más tarde sobre la cultura ágil, al cierre del evento.

Las Conferencias

El resto de ponencias transcurrieron en un ambiente ponderado. Algunas de buena calidad, otras no tanto o, al menos, esas fueron las notan predominantes durante los 2 días del evento. La lista de conferencias la encuentran en:

http://www.sepgla.com.co/programa/

Y finalmente, al cierre, mi presentación, “Ágil es algo que eres, CMMI es algo que usas”. Pero antes de ir a ese punto específico, quisiera hacer mención de una de las conferencias, no porque las demás no lo merezcan, sino porque no hay espacio para mucho más. Me llamó la atención el tema que presentó Luz Adriana Sepúlveda sobre los significados acerca del proceso de implementación de un modelo de mejoramiento de procesos.

Luz Adriana nos habló de los resultados obtenidos durante una investigación que condujo. Algunos de sus planteamientos vienen de Deming y de Crosby, entre otros. Dejó asomar lemas como el de Tomas Gilb que señalan que el personal que no está motivado no avanza, ofrece resistencia y niega el cambio. Algunos datos interesantes como que más de la mitad de 100 esfuerzos de transformación corporativa no sobrevivieron el arranque inicial, o así se desprende de un estudio de John Kotter de Harvard. Sepúlveda nos mostró algunas de las causas de todo esto:

• Falta de compromiso de la Alta Dirección
• Falta de continuidad por no contar con estructura de soporte
• No tomar en cuenta las limitantes que pueden afectar el proceso.
• Cambio en los sistemas sin cambio en el operador (no existe cambio en la manera de pensar)

Sobre su estudio, Luz Adriana enfatiza en los factores motivantes de rechazo a un Sistema de Gestión de Calidad:

• Miedo a lo desconocido
• Resistencia a experimentar
• Aumento /Disminución de las responsabilidades laborales
• Falta de información – Desinformación
• Amenazas al pago y otros beneficios
• Factores históricos
• Amenazas al estatus
• Miedo al fracaso
• Temor a no poder aprender las nuevas destrezas requeridas

Y señala algunos elementos que contrarrestan esas aprehensiones:

• Sensibilización/Capacitación/Información
• Participación en el proceso
• Construcción colectiva del sistema
• Experiencia adquirida
• Acompañamiento por parte de los líderes
• Planeación del proceso
• Conceder tiempo al personal para participar activamente en el sistema.

Los dejo con los datos de Luz Adriana por si quieren contactarla. 

Ágil es algo que eres, CMMI es algo que usas

Algunos momentos de mi conferencia. Foto de María Clara López.

En este SEPG LA Se habló mucho de calidad, pero no se habló de las personas. Y mucho menos de sus interacciones. Pensé entonces que el enfoque de mi discurso era precisamente el que quería. Mi asunto principal era que los métodos ágiles no tienen por qué entrar en conflicto con otros modelos o enfoques de construcción de software, no es la idea de ser ágil o, al menos, no está en el flujo de un proceso de transformación a ágil echar tierra a las prácticas existentes en una organización. Los líderes de los procesos actuales deberían trabajar en conjunto con los nuevos líderes para que estos últimos obtengan los beneficios de ambos universos y aprovechar esa sinergia para mejorar dramáticamente el rendimiento del negocio.

Para apoyar este concepto, expliqué que los modelos como CMMI, PMI e ISO nos dan una idea de cuales procesos son necesarios para mantener una organización madura y disciplinada, capaz de predecir y mejorar el desempeño de la organización misma y de los proyectos. Entre tanto, las técnicas ágiles proporcionan guías para un manejo eficiente de los proyectos de una manera que permite alta flexibilidad y adaptabilidad. Al mezclar los dos enfoques, la filosofía ágil asegura que los procesos se implementen eficientemente a la vez que aceptan los cambios; y los modelos tradicionales aseguran que se consideren todos los procesos relevantes.

Pero de inmediato fui al centro de mi exposición: una de las grandes diferencias, radicales por demás, entre los métodos tradicionales y los ágiles es que estos últimos son generativos, no prescriptivos. Los procesos necesitan evolucionar según las necesidades, no prescritos con anticipación. Un enfoque prescriptivo genera procesos complejos y complicados, mientras que un enfoque generativo comienza con un conjunto de procesos simples y adiciona otros a medida que se requieren.

La filosofía ágil reconoce que los procesos de software más efectivos no pueden definirse por adelantado; es un proceso continuo. Los métodos tradicionales se enfocan en definir y reforzar procesos y gastan muy poco tiempo en identificar y entregar lo que los usuarios necesitan. Aunque su propósito es mejorar la consistencia y la calidad, esto muchas veces se consigue a expensas de la productividad y la entrega. El enfoque tradicional de procesos tipo CMMI también usa herramientas monolíticas y pesadas que causan construcciones frágiles y traspasos inefectivos entre desarrollo, pruebas, despliegue y operaciones.

A esta altura de mi coloquio, la suerte estaba echada. Decir eso en una Conferencia dedicada a adorar a los procesos y a modelos tipo CMMI podría tomarse como sacrilegio. Lo que siguió fue enfatizar en lo que significa ser ágil: específicamente, la interiorización y la práctica de los Valores y Principios del Manifiesto Ágil, nada de lo que no haya hablado en algunos de mis artículos citados más abajo en las referencias.

Pero contrario a mi desazón, la reacción de mis oyentes fue bastante positiva. Era el final del evento, todos estábamos cansados, pero muchos quisieron ir más allá y tuve la oportunidad de compartir experiencias luego de mi charla con muchos de los presentes. La misión, la mía, estaba cumplida: sembrar una semilla, una llama que motive a los colegas a mirar en otra dirección. Por supuesto que dije que ágil no era la solución, pero sí una muy buena alternativa, una que nos está permitiendo volver a amar la profesión, volver a querer que sea lunes en el trabajo, para seguir innovando con cada interacción.

Referencias

Las diapositivas de la conferencia la pueden descargar de:

https://drive.google.com/file/d/0B5SNac-eZKMMLUtHWk1kZ2ZQRWs/edit?usp=sharing