Una forma de pensar llamada “Agilidad”

Cada vez que se empieza a construir una idea, una iniciativa, un proyecto, se plantea el cómo se va a abordar, -asumiendo a este punto que el propósito está claro, que se empezó por el why como explica Simon Sinek-. Sin importar el tamaño de la iniciativa siempre se divide en partes más pequeñas para ejecutarla, partes que se asignan a equipos de personas. Para el cómo no se tiene un equipo gigante trabajando juntos para hacer algo gigante, sino la suma de equipos pequeños haciendo partes pequeñas coordinando y colaborando entre sí, es la decisión humana de colaborar en búsqueda de un objetivo común. Robert C. Martin en su libro Clean Agile dice: “Las grandes cosas no se hacen por equipos grandes, las grandes cosas se hacen por la colaboración de muchos equipos pequeños que hacen muchas cosas pequeñas”. Así se enmarca una idea, una mentalidad.

La idea antes de ser bautizada

A través del tiempo se ha tenido la necesidad de colaborar en equipos pequeños para alcanzar un objetivo común, en distintos campos, es algo que se ha venido resolviendo día a día, cada equipo pequeño debe coordinar su trabajo para hacerlo bien y a tiempo, sincronizado con el objetivo. Desde hace muchos años y para múltiples disciplinas, se ha tenido la mentalidad de colaboración y trabajo en equipo para hacer entregas de valor y como resultado lograr grandes cosas, se han construido pirámides, coliseos, murallas, ciudades y muchas otras cosas más.

Dentro de esta mentalidad siempre ha existido la idea de mejora, para que esos equipos pequeños alcancen su objetivo, que tengan lineamientos, calidad y que lo hagan mejor, eficientemente, a gusto, en menor tiempo, menor costo, etc. En los procesos de manufactura y en los de construcción de Software, se ha desarrollado la idea de mejoramiento para esa mentalidad de colaboración, trabajo en equipo, organización del trabajo, desde mucho tiempo antes que fuera bautizada como “Agilidad”, y desde allí surgieron grandes aportes para enriquecer esta forma de pensar.

En los años 50s el Toyota Production System TPS, precursor de Lean, mostraba una idea de reducir el desperdicio, una clara inclinación a la calidad y a la estandarización de los procesos. Tahichi Ohno uno de los fundadores del TPS decía “No hay mejoramiento sin estándares. El inicio de toda mejora es saber exactamente dónde está usted”, enfatizando en la mejora continua de personas y procesos. Para los años 80s, Takeuchi y Nonaka en The New Product Development Game, ya hablaban de trabajo en equipo, colaborativo e introducían la palabra Scrum como un símil a la formación que adopta un equipo de rugby, cómo tener sinergia de equipo para alcanzar un objetivo común a través de la autoorganización.

Las ideas de Tahichi Ohno, Takeuchi y Nonaka, inspiraron prácticas para otros autores en la disciplina de construcción de Software. En 1995 Ken Schwaber y Jeff Sutherland formalizaban la práctica que llamaron Scrum, ya se unían temas de trabajo colaborativo y trabajo en iteraciones, para entregas tempranas de valor. En 1996 Kent Beck tiene una aproximación de eXtreme Programming XP, a mi gusto una de las mejores prácticas ágiles de construcción de Software, donde muestra el flujo de trabajo en iteraciones, entrelazado con prácticas, técnicas, haciendo hincapié en la calidad y el concepto de entrega continua. En los 90s otros autores también exploraban prácticas y técnicas para mejorar el desarrollo de Software, como Feature-Driven Development, Dynamic System Development Method DSDM, Crystal Orange de Alistair Cockburn, Model Driven de Steve Mellor y otros, acá cito sólo algunos autores, referentes del manifiesto ágil. Antes del manifiesto, estas prácticas ya hablaban del enfoque en las personas, iteraciones, entrega, etc., siempre con un matiz de mejoramiento continuo.

El bautizo a una idea por la comunidad del Software

Dejando egos a un lado, en 2001, 17 representantes de las principales prácticas de desarrollo y construcción de Software se reúnen por un objetivo común: plantear alternativas al actual desarrollo de Software con procesos y documentación muy pesados. De esa reunión emerge un manifiesto con 4 valores y doce principios como una mejor forma de desarrollar Software. Como era una alternativa a lo tradicional, rígido y pesado, los autores acuñaron la palabra “ágil”, es así como de esta reunión y orientado totalmente al desarrollo de Software, es bautizada ésta idea y forma de pensar como “Agilidad”.

Los cuatro valores que describen esta mentalidad orientada al desarrollo de Software, están en el manifiesto expresando que, aunque se valoran los elementos de la derecha, se valoran aún más los de la izquierda:

• 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

Valores simples que enmarcaron un movimiento dentro de la comunidad del desarrollo de Software e hicieron que se mejoraran y estandarizaran los procesos tal como indicaba Tahichi Ohno en los 50s, con trabajo colaborativo, interacción con personas como Takeuchi y Nonaka sugerían, es un reflejo de una idea de mejora, de una mentalidad que ha existido en varios ámbitos desde mucho antes de ser bautizada en el 2001. Es el resultado de la experiencia vivida por cada uno de éstos 17 expertos, unida para crear una mejor forma de trabajar.

Con el paso del tiempo han surgido otras expresiones para plasmar esta idea bautizada Agilidad, como el Corazón de la Agilidad o la Agilidad Moderna, las que detallo en mi artículo Cómo alinear las perspectivas de la agilidad a su propósito, y cómo al tratarse de una mentalidad, se puede usar en otras áreas distintas al desarrollo de Software.

Mantener una idea simple

Les quiero hablar ahora desde un principio que permite transmitir las ideas sin mayor complejidad, se trata del Principio KISS acrónimo de "keep it simple, stupid" o "keep it stupid simple", es un principio de diseño que establece que la mayoría de sistemas funcionan mejor si se mantienen simples en vez de complejos, la simplicidad es mantenida como un objetivo clave. Me he regido por ese principio como coach y me ha funcionado para transmitir distintos tipos de ideas de manera práctica y sencilla, -me quedo con la traducción para "keep it stupid simple", la encuentro más amigable-.

Empiezo desde la aproximación de 2001 en el manifiesto ágil para explicar esta mentalidad por dos razones principalmente: la primera porque fueron quienes bautizaron la idea y mentalidad como “Agilidad”, la segunda porque fueron personas experimentadas en su campo (construcción de Software), que concluyeron apoyados en sus vivencias y prácticas, todos referentes del área del Software, que están respaldados por grandes resultados y casos de éxito.

Manifiesto KISS 💋

Si le aplicara el principio KISS al manifiesto, un acercamiento de manera generalizada y simple puede ser el siguiente:

El manifiesto nos invita a enmarcar la mentalidad en tres dimensiones: personas, en dos aspectos, interacciones y colaboración con los involucrados, entrega de valor, que enmarcado en desarrollo de Software, únicamente puede ser Software funcionando y abrazar el cambio, dejar la rigidez para actuar rápido y acertadamente al mejor siguiente paso del producto.

El manifiesto enmarca una idea, una mentalidad, no es una metodología, no son los pasos a seguir, no es el cómo, eso viene luego con las prácticas; se trata es del ser.

Lo que le podría faltar de manera explícita al manifiesto de 2001 son los temas de calidad que se expresan claramente desde los 50s en TPS, luego en Lean, y que en XP son explícitos y apalancados en diferentes técnicas que permitan alcanzarlos.

Una aproximación general para “Agilidad” 💋

Dado que abrazar el cambio es un tema de comportamiento humano, se podría unir a la dimensión de personas, impulsando la mentalidad de interacciones, colaboración y cambio. Una aproximación que permita incluir los temas de calidad podría ser:

Enmarcando Agilidad de nuevo en tres dimensiones: Personas, el desarrollo de todas las personas involucradas, para trabajo colaborativo a través de interacciones, manejo del cambio, organización, coordinación, con el uso de prácticas que permitan hacerlo, acompañado de métricas y mejora continua (kaizen) para el equipo. Una dimensión transversal que aplica para cualquier área o campo, siempre hay que buscar desarrollar a las personas. Entrega de valor:  El propósito de lo que hacemos, llegar a un resultado, cumplir una meta, expresada en una entrega continua de valor. De igual forma que la dimensión anterior aplica en cualquier campo, pues siempre se está buscando alcanzar un objetivo a través de resultados medibles, usando herramientas de análisis de datos y de métricas del producto. La tercera dimensión es la calidad y mejores prácticas de lo que estemos haciendo/construyendo. Esta dimensión es particular del segmento donde nos encontremos, debe incluir estándares, mejores prácticas, lineamientos de calidad, seguridad, etc. (ya sea manufactura, desarrollo de Software, construcción o lo que sea que estemos haciendo).

En términos sencillos la mentalidad es:

• Desarrolla a las personas
• Entrega continuamente valor
• Trabaja con calidad y las mejores prácticas

Haciendo Software

Si nos dedicamos a hacer Software, ¿por qué no seguir a los referentes? Si en nuestro trabajo hacemos Software como apoyo al negocio o si es el Software el negocio en sí, la mejor manera de hacerlo es acudir a las mejores prácticas y temas de calidad.

Uno de los referentes en este punto es sin duda Robert C. Martin, con Clean Code y recientemente Clean Agile, nos entrega pautas para hacer las cosas bien en cada parte del ciclo, en la planeación, pruebas, despliegue, temas de calidad de código, patrones y cómo se integran con el marco de trabajo que se use. Otra referencia como lo dije antes es Ron Jeffries, Kent Beck y Ward Cunningham fundadores de eXtreme Programming XP, inicialmente puede parecer complejo, pero al adentrarse se observa que es muy completo y une diversas técnicas para asegurar la calidad, como TDD, entrega continua y otros. Daniel Terhorst-North propone BDD a partir de TDD. Martin Fowler nos ha mostrado diversos patrones de arquitectura, también técnicas y prácticas, por ejemplo, Refactoring no como algo negativo sino como mejoramiento continuo y Feature Toggles para entregar características de forma rápida y segura.

He nombrado solo unos cuantos autores, en su mayoría firmantes del manifiesto ágil de desarrollo de Software, pero si se explora se encuentran muchos más que nos muestran cómo hacer Software bien diseñado, de mejor calidad, flexible, escalable, con técnicas que apoyen la entrega temprana de valor.

Para terminar

Lo primero que trato de hacer en mis equipos de trabajo es separar el ser del hacer, dejar muy en claro la mentalidad y las ideas por un lado y las prácticas por otro. La respuesta a la pregunta ¿qué es agilidad? es simple, es una manera de pensar, es la descripción de un comportamiento, es el ser. Sin importar qué nos dediquemos a hacer, si la decisión es hacerlo bajo la mentalidad de Agilidad, debemos recordar: desarrollar a las personas, entregar continuamente valor y trabajar con calidad y las mejores prácticas de nuestro campo, hoy contamos con la información y las herramientas para conseguir hacer las cosas de la mejor manera.

Espero que esta visión de Agilidad, sirva como apoyo para entender y transmitir esta mentalidad a las personas de sus organizaciones, como un punto principal de cambio. Gracias por tomarse el tiempo para leer, todo su feedback es siempre bienvenido, comparto desde mi experiencia para que co-creemos y juntos construyamos mejores formas de trabajar.

Referencias

• Manifesto for Agile Software Development
• eXtreme Programming
• Kiss Principle