El Fin de la Agilidad (XII)

(Puedes escuchar la banda sonora de este artículo en este enlace)

“A good drummer listens as much as he plays."
— Proverbio Indio

Como les conté antes, en la segunda mitad de los noventa, con mis amigos volvimos a ensayar como grupo musical. En esa época yo invertí en una batería y compraba cada cierto tiempo algún ejemplar de la revista Modern Drummer. A diferencia de hoy, en que encuentras en YouTube miles de tutoriales, en esa época recurrías a material escrito para aprender nuevas técnicas o mejorar como músico aficionado.

Fue en uno de esas ediciones que leí una entrevista a Neil Peart, el baterista de Rush, quien contaba como había vuelto a estudiar con el maestro Freddie Gruber. 

La historia de Gubber es azarosa, pudo haber sido uno de los grandes bateristas del jazz, pero su adicción a la heroína lo alejó del camino del éxito. Con la ayuda de sus amigos, entre ellos el gran Buddy Rich, Freddie pudo recuperarse y encontrar su verdadera vocación en la enseñanza.

Grubber enseñaba todos los aspectos de tocar la batería, pero su verdadero regalo, en palabras de Neil Peart, su discípulo más famoso, era *“un entendimiento sin paralelos de la ‘danza’ física involucrada al tocar el instrumento, la relación ergonómica entre el baterista y la batería” *(tomen nota de esto porque es importante).

A fines de 2015, como relaté en la parte 11, estábamos en crisis. Ese mismo año, en la StartechConf, presenté una charla que titulé “El viaje del agente de cambio”, donde reflexioné sobre mi intento por cambiar como persona y hacer cambios en mi organización. Pero había pecado de soberbia al tratar de llevar el cambio con pura voluntad y sin involucrar demasiado a mis colegas y a mis principales colaboradores. En cierta medida lo que contaba en esa charla era cierto sólo en teoría, no había sido efectivo. Así que debía hacerme cargo de la crisis y debía cambiar.

Empezar a hacerme cargo de las cosas que tanto Miguel, Carolina y  Elizabeth me habían dicho una y otra vez. Asumir, con humildad, que me faltaba mucho por aprender.

Así que, tal como lo hizo Neil Peart, quien siendo el mejor baterista del mundo fue a aprender para mejorar su técnica, yo también partí a estudiar.

Desaprender para aprender

“If the future's looking dark,
We're the ones who have to shine.
If there's no one in control,
We're the ones who draw the line.
Though we live in trying times,
We're the ones who have to try.
And we know that time has wings,
So we're the ones who have to fly."
― Neil Peart

Coincidió, porque no nos pusimos de acuerdo, que mis dos lugartenientes decidieron hacer lo mismo, y lo interesante es que estudiamos temas complementarios. Carolina decidió formarse como Coach Organizacional, y Elizabeth estudiar un diploma en Gestión de Calidad de Software.

Por mi parte decidí cerrar un ciclo personal. Cuando yo estaba en la universidad mi plan era salir con el título de ingeniero y magister. Pero no había completado ni uno ni el otro. Mil cosas pasaron en mi vida que hicieron que pospusiera mis estudios y así, sin darme cuenta, habían pasado más de veinte años. Esto no significó nunca cuestionamientos de mi capacidad laboral al buscar empleo. A fines de los ochenta y al inicio de los noventa muchos ingenieros en computación entramos a la industria en esta situación, nuestras habilidades eran requeridas y las ofertas laborales eran buenas.

Decidí que estudiaría el Magister en Tecnologías de Información de mi alma mater, la Universidad de Chile. Un programa que se ofrece para los profesionales de la industria. Mis hijos mayores ya dejaban la universidad, así que podía invertir en mi formación personal. También recibí algo de apoyo de mi empleador en esto, así que tenía sólo que poner de mi parte para sacar adelante estos estudios. 

Recuerdo que, cuando se cumplieron los 40 años de la fundación del departamento de computación de la Universidad de Chile, me invitaron a un cóctel en la facultad. Esa noche hablé con varios amigos y conocidos que eran académicos, o enseñaban en este u otros programas de extensión y educación continua. Fue en un momento que uno de ellos, quien me hizo clases después, me preguntó que ¿para qué hacía esto? Después de todo ya contaba con todos los conocimientos que se impartían en el programa. Pero yo quería cerrar el ciclo, y tener al menos un título y además enseñarles a mis hijos que todo debe cerrarse y terminarse como corresponde, aunque tome tiempo.

Al hacer los trámites de inscripción al programa de magister descubrí que mi universidad era generosa con sus ex alumnos y les permitía completar sus estudios, los que en mi caso, para ingeniería civil, era un ramo de ultimo semestre y la memoria, así que aproveché la oportunidad. dos año estudié para sacar mi carrera de ingeniero y el grado de magister.

El programa de la Universidad de Chile requiere tomar un par de diplomas e invertir una cantidad de horas para preparar la tesis. Pero yo aproveché el vuelo e  inscribí tres diplomas: “Gestión de Proyectos Informáticos”, “Ingeniería de Software” y “Ciencia e Ingeniería de Datos”, este último el más difícil, pero en dónde aprendí muchas cosas nuevas para mí.

Recomponiendo al equipo

En 2016 tomé algunos cursos de liderazgo y negociación. Fue ahí que fui reflexionando en la forma en que me relacionaba con mi equipo. También en ese tiempo hicimos diagnósticos de lo que nos había pasado y decidimos trabajar en mejorar la moral del equipo.

Sufrimos otro par de bajas, Natalia y José, que habían trabajado en un duro proyecto a fines de 2015 y principios de 2016. Ellos realmente habían caido en el burnout, uno de los males de nuestro tiempo. 

Empezamos a traer nueva y más gente para incorporar al equipo, fue ahí que llegaron Gerardo y Fabián. También llegaron miembros extranjeros a nuestro equipo, como Pedro y Johan. El fenómeno de la inmigración empezaba a aparecer en nuestro país en esa época, así que aparte de la diversidad de género que tratábamos de mantener, había que hacerse cargo de la diversidad cultural que implica incorporar gente de diversas nacionalidades.

Los cambios más importante ocurrieron en el área de Elizabeth. Con la partida de Gustavo y Contardo (ver parte 11), ese equipo corría el riesgo de colapsar. Hicimos muchos cambios y logramos mejorar la productividad de ese grupo a pesar de tanto cambio.

Una de las primeras cosas que hicimos fue hablar con Gabriel Ovalle, quien en ese entonces era jefe de sistemas, hicimos un análisis de todas las incidencias que generaban solicitudes desde el área de procesos que se traducían en labores de explotación de datos, lo que consumía mucho tiempo del equipo. Descubrimos que habían muchas solicitudes tenían un origen histórico, los usuarios las hacían porque hubo un tiempo en que no existían funcionalidades en los sistemas para resolver esos problemas, pero la verdad es que ya se habían resuelto, el problema era que no sabían que existían o al haber rotación de personal se perdía el conocimiento. Corregimos eso, capacitamos, desarrollamos algunas funcionalidades nuevas, o corregimos errores. Redujimos varios incidentes también automatizando algunas tareas. Y dejamos un montón de labores de explotación de datos en el equipo de DBAs que dependían de Gabriel.

Pusimos énfasis en la integración continua, fue ahí que Jonathan Peña y Lillo, quien era analista de calidad hasta ese momento, tomó la posta del trabajo que había empezado Gustavo e implantó definitivamente un proceso de integración continua para que nuestros desarrolladores dejaran de entregar piezas binarias para instalar. Ahora por fin teníamos un ciclo en que las piezas a entregar a producción se generaban de manera automática a partir del repositorio de código fuente.

Recuerdo el día en que me mostraron el primer pipeline de integración continua implantado en Bamboo. Realmente me emocioné, lo que había visto en Borland en 1998, y en Boston en 2011, por fin estaba tomando forma en mi área. Me sentí orgulloso de ellos.

A fines de 2015 se había incorporado Claudio Araya, como ingeniero de sistemas, a cargo de mantener la infraestructura de nuestros ambientes de desarrollo y calidad. Pero además de sus capacidades técnicas, lo que buscábamos en ese tiempo, era gente con ganas de aprender, con una actitud positiva, gente alegre que cambiara la moral del equipo, que lo empujara hacía arriba. En ese sentido Claudio es y sigue siendo, un pilar importante de mantener la actitud del equipo. Uno de los líderes positivos de mi unidad.

En 2016 también apareció el programa “Mujeres Programadoras”, de la fundación Kodea. Le dimos la oportunidad de realizar práctica con nuestro equipo a dos de las alumnas del proceso, Natalia y Camila. Finalmente decidimos incorporar a Camila Donoso al equipo de QA. Ella fue una de las pionera en un cambio importante que hicimos al proceso de control de calidad: incorporar la programación y así fue que empezamos a crear pruebas automatizadas, usando Selenium y Python en nuestro proceso. Pero se incorporaron otras técnicas que permitieron cambiar el estilo de hacer las pruebas. Gradualmente el equipo de Elizabeth empezaba a incorporar DevOps a nuestra organización.

Ritmo y Rito

“Rhythm is the soul of life. The whole universe revolves in rhythm. Every thing and every human action revolves in rhythm.”
–― Baba Tunji

Fue en la clase de ingeniería de software que conocí a Daniel Perovich, quien después se convertiría en mi profesor guía de tesis. Recuerdo que su clase de introducción al curso escribió dos palabras en la pizarra:

Ritmo y Rito

Con esas dos palabras se podía resumir todas la metodologías de desarrollo de software, y en particular las llamadas metodologías ágiles.

¿Y quién es el encargado de esas dos cosas en una banda de rock?

El jefe de proyecto, por ejemplo, es como toda la sección rítmica de una banda de rock, encargado de llevar el ritmo, pero de que se ejecuten los ritos que solicita el proceso de desarrollo de software. Y así.

La metáfora creo que se explica por sí misma. Pero yo no era consciente de esto, no había eso esa distinción hasta esa tarde en que asistía a esta clase. Yo creía que sabía de ingeniería de software, pero se me escapaba algo tan esencial. 

Al estudiar, al analizar las cosas, al darnos el tiempo de disectarlas y extraerles los detalles, es que podemos entender de verdad lo que está ocurriendo y podemos integrarlas a nuestro ser.

Ritmo y Rito, y qué mejor ejemplo que SCRUM para reflejar esto.

Procesos ágiles

“When Mr. Ludwig invented the bass-drum pedal, that's what made the drum set possible.”
-― Neil Peart

No soy gran fan de Scrum, pero es una excelente manera de introducir agilidad en un ambiente estructurado, con mucha norma, con obligaciones normativas, donde tus procesos son auditados. Además funciona como esas rueditas que se le ponen a las bicicletas para que los niños aprendan a andar en estas.

Scrum permite formar el hábito de la entrega continua, del time box, que fija el tiempo, y aprendes a controlar el alcance de lo entregado. Permite introducir algunos términos de agilidad. Incluso Spotify, que es vista como uno de los principales referentes del uso de las metodologías ágiles, partió con Scrum.

En la segunda mitad de  2017 fue cuando empezamos a adoptar Scrum oficialmente en algunos equipos. Hasta antes de ese cambio teníamos un proceso que más o menos podíamos describir como iterativo incremental.

Pero más que el proceso, lo que ocurría es que teníamos un grave problema con la calidad y la entrega.

Calidad

“I don't think there's such a thing as a 'best' drummer”
― Mike Portnoy

Esta viñeta cómica de Geek & Poke refleja mucho lo que ocurre con la calidad en el proceso de desarrollo de software:

Una vez literalmente nos pidieron hacer esto con un proyecto. El proveedor se quejaba de que nuestro equipo detectaba muchos bugs.

Y efectivamente ocurre. También ocurre que pareciera que el proceso de control de calidad no parara nunca. Fue entonces en que cambiamos el switch.

Tradicionalmente ocurre que el proceso de desarrollo involucra una etapa que llamaremos construcción, seguida de una etapa de control de calidad. Y ahí empieza la iteración, la que puede llegar a ser infinita.

nuestro caso intentamos con una métrica que medía la cantidad de iteraciones entre desarrollo y QA en cada entrega.

Esencialmente nuestro proceso era así:

Eran muchas iteraciones entre desarrollo y QA, y los proyectos se alargaban hasta que cortábamos y tomábamos la decisión de pasar a producción. Eso,  por supuesto, debía cambiar.

La clave es dejar de pensar en dos unidades independientes. El equipo de desarrollo y control de calidad deben trabajar juntos. Además había que aclarar que la calidad no es responsabilidad del área de QA, la calidad es una preocupación de todo el equipo.

Definimos que todos eran desarrolladores, ya no habría distinción si programaban o ejecutaban pruebas. Además les pedimos a nuestros tester que escribieran pruebas automatizadas, así que también estaban desarrollando literalmente. Para mi ya no hay distinción entre esos roles, todos son devs.

Otro elemento importante fue definir las métricas adecuadas. La más obvia, la cantidad de defectos que pasamos a producción. Empezamos a medir cuanto porcentaje de defectos incorporábamos en cada paso a producción. Es doloroso medir esto, pero importante. Una medida estándar en DevOps es la tasa de falla en cada cambio, cuentas cuantos fallos tuviste al realizar un cambio en el sistema. Otra medida también es medir cuantos defectos introduces contra la cantidad de funcionalidad que agregas en cada paso a producción. En la primera teníamos una medida de 16%, en la segunda estábamos sobre el 30%. La primera medida no es mala, la segunda sí lo es. Pero vas obteniendo una mejor visión cuando la complementas con otras métricas interesantes. 

Ahora, gracias a Scrum los ciclos de entrega eran fijos, 2, 3 o 4 semanas. Sabíamos la cantidad de nuevas funcionalidades, mejoras y correciones que se implementarían en cada ciclo. Eso falicitó la implantación de dos métricas esenciales para mejorar.

La primera de estas métricas es la Eliminación Efectiva de Defectos. La definición clásica, descrita en el libro de Pressman de ingeniería de software (quinta edición), la define de la siguiente forma:

EED = E / (E+D) 

En esta ecuación el valor  E corresponde a la cantidad de defectos encontrados en una entrega anterior, y D son los defectos encontrados en la entrega actual. Lo ideal es que este valor sea 1, pues significa que estás eliminando todos los defectos. Nosotros manejamos una formula modificada de la presentada por Pressman (una métrica más exigente de hecho). Pero se puede partir con este simple cálculo para ir midiendo la mejora en la calidad del trabajo. 

El problema era que nuestros valores de EED eran cercanos a 0.5. Nuestra manera de medir el EED nos entrega más información la que nos permitió deducir que lo que ocurría es que estábamos ingresando tantos defectos como los que eliminábamos en cada iteración. Otra forma de verlo es que pasas el 50% del tiempo corrigiendo errores previos.

Otra métrica complementa es la que llamamos Valor Entregado (VE). Un ratio similar al EED que nos permite ver cuánto de lo que pasamos a producción son funcionalidades nuevas y mejoras, por sobre la corrección de defectos.

Aunque puedan parecer muy crudas, estas simples métricas nos permitieron mejorar. Crecimos, mejoramos, y cambiamos la forma de hacer las cosas. Estábamos incorporando la agilidad a nuestra manera. Y nos fue bien. Revertimos los resultados de las encuestas de clima laboral, incluso estuvimos entre los mejor evaluados, y sostuvimos esos resultados en el tiempo. El espíritu del equipo cambió. 

Nuestro viaje de transformación

“It´s nice when somebody says that you're their 'favorite' drummer”  –― Mike Portnoy

Todo es lo contamos a la comunidad ágil de nuestro país,  en un Meetup que organizamos. Una presentación que elaboramos a partir del esqueleto de mi presentación de 2015, “el viaje del agente de cambio”.

La gran diferencia es que ahora era mucho más real, y comprometía la visión de mi equipo, ya no era mi visión egoísta, era una mirada mas integradora y sincera. Pero lo mejor que esta historia fue presentada por mis principales colaboradoras, Carolina y Elizabeth, sin las cuales no podría haber logrado ningún cambio. 

Ese Meetup fue especial. Todo fue organizado y atendido por todo el equipo, y marcó un hito importante para nosotros, salíamos al exterior a contar nuestra experiencia y éramos escuchados con interés y respeto.

Todo esto quedó registrado en un video que grabó Miguel González, y que les dejaré acá para que lo vean, ahí se describen mejor los cambios que realizamos, nuestras experiencias, dolores, y aprendizajes. 

Con esto ya nos estamos acercando al final de esta serie. El fin de una época se acercaba pero no lo sospechábamos, venían cambios y desafíos mayores, pero estábamos mejor preparados para afrontarlos, aún teníamos problemas, no menores, que resolver. Pero habíamos cambiado y eso es bueno.

Notas:

El video está en este enlace: https://www.youtube.com/watch?v=i0GpxfyZjr4&feature=youtu.be

La primera parte de esta serie se encuentra en este enlace.