Mis notas sobre el Corazón de la Agilidad

 

Fuente: https://heartofagile.com/heart-of-agile-plus-teaching-denmark-sept-2020/

“La Agilidad se ha vuelto excesivamente decorada. El remedio es simple: colabora, entrega, reflexiona, mejora”. -Alistair Cockburn.

En el mundo de los negocios, existen muchos enfoques diferentes que las organizaciones utilizan para funcionar de manera más eficiente. Una de esas líneas de trabajo es la agilidad. Ágil es un enfoque colaborativo que ha demostrado producir mejores resultados. He estado escribiendo mucho sobre agilidad durante la última década, incluida la cultura ágil, prácticas ágiles y más. Y como muchos otros entusiastas ágiles, he sufrido la sobredecoración que ha tenido esta forma de hacer las cosas todo este tiempo.

Por eso cuando conocí el Corazón de la Agilidad para recuperar la sencillez de Ágil reconociendo que se puede expresar en cuatro palabras: colabora, entrega, reflexiona y mejora, he hecho todo lo que ha estado a mi alcance para seguir el camino trazado por Alistair Cockburn, quien fue uno de los iniciadores del movimiento ágil hace más de dos décadas. Desde entonces, he tenido la oportunidad no solo de colaborar de cerca con diferentes miembros de la Comunidad Heart of Agile en Latinoamérica, sino también de poner en práctica esta forma de sentir la agilidad en equipos y organizaciones.

Lo que sigue son algunas notas de mi sentir en todo este trasegar por el camino de la agilidad. Estas son mis notas sobre el Corazón Ágil.

¿Qué es el Corazón de la Agilidad? La versión de Lucho.

El Corazón de la Agilidad es una forma de vida que simplifica la práctica ágil en cuatro imperativos críticos que amplifican su eficacia. Estos imperativos son colabora estrechamente con los demás, entrega pequeñas pruebas inicialmente, reflexiona periódicamente y mejora la dirección de tus ideas. Al seguir estas pautas, podrás entregar valor pronto y con frecuencia... con tu equipo.

El corazón ágil es la creencia de que la colaboración es clave para producir los mejores resultados. Esto significa que todos los miembros de una organización deben trabajar juntos en estrecha colaboración para generar y desarrollar ideas. Además, es importante comunicarse con frecuencia para suavizar las transiciones. Al trabajar juntos y comunicarse recurrentemente, los miembros del equipo pueden aprender unos de otros y generar resultados extraordinarios.

Hay varias razones por las que la colaboración es tan importante en el mundo de los negocios. Primero, al colaborar estrechamente con otros, puedes generar mejores ideas. Además, al comunicarte con frecuencia, puedes evitar posibles problemas y asegurarte de que todos estén en sintonía. Además, al reflexionar periódicamente, puedes pensar en lo que has aprendido y cómo puedes mejorar en el futuro. Finalmente, al mejorar la dirección de tus ideas y su implementación técnica, puedes lograr metas más ambiciosas.

Sobre Colabora

Fuente: https://heartofagile.com/heart-of-agile-plus-teaching-denmark-sept-2020/

Uno de los aspectos más importantes de Ágil es la colaboración. Para generar y desarrollar mejores ideas, es esencial que colabores estrechamente con los demás. Esto se puede hacer a través de sesiones de intercambio de ideas, reuniones de equipo o incluso conversaciones informales.

El corazón ágil es un enfoque radicalmente más simple que ayuda a los equipos a lograr resultados sobresalientes centrándose en practicar y promover una cultura de confianza y colaboración. Los miembros de equipos más exitosos están abiertos a las opiniones de los demás y están dispuestos a compartir las propias. Mantienen una comunicación efectiva para garantizar que todos estén en la misma página. Es con una comunicación efectiva, abierta y basada en evidencias que logramos dos cosas importantes: que los receptores del mensaje lo entiendan y que todos entiendan lo mismo.

Una parte clave de esto es crear una cultura de servicio en la que todos se concentren en satisfacer las necesidades de los demás. Esto se puede lograr a través de un liderazgo de servicio y equipos autogestionados. Al trabajar juntos y reconocer la importancia de cada miembro del equipo, es posible crear una cultura de confianza y colaboración. Esto, a su vez, conduce a equipos más exitosos que pueden lograr más de lo que podrían por sí mismos.

En resumen, colaborar se trata de reconocer que el todo es mayor que la suma de sus partes. Cuando trabajamos juntos, podemos lograr más de lo que podríamos alcanzar en solitario.

Sobre Entrega

Fuente: https://heartofagile.com/heart-of-agile-plus-teaching-denmark-sept-2020/

Otro elemento clave de Ágil es la entrega. Es importante entregar pequeñas pruebas inicialmente para aprender cómo funciona realmente el mundo. A medida que aprendes más y obtienes una mejor comprensión de la situación, puedes acelerar tus entregas en consecuencia. La entrega ágil tiene que ver con la entrega de valor de forma constante, eficiente y con la mayor calidad posible, mientras se mantienen dentro de las limitaciones típicas de presupuesto y tiempo.

En primer lugar, esto ayuda a los equipos a comprender la complejidad del problema que intentan resolver y a encontrar la mejor manera de generar valor. Y en segundo lugar, aprenden a predecir e influir en los resultados. Esto les facilita generar ingresos mientras continúan aprendiendo y mejorando iterativamente su producto.

Con el enfoque del corazón ágil, los equipos van desde desarrollar y mantener un conjunto mínimo de características que cumplan con la Definición de Terminado hasta entregar un producto fantástico que influencie la vida de sus consumidores, incluso hasta el punto de cambiar su estilo de vida.

Sobre Reflexiona

Fuente: https://heartofagile.com/heart-of-agile-plus-teaching-denmark-sept-2020/

Si deseas formar parte de un equipo ágil excepcional que ofrezca resultados sobresalientes, reflexiona y asegúrate de que la reflexión sea una parte clave de tu proceso organizacional. Reflexionando periódicamente, podemos aprender de nuestros errores y aciertos. Esto nos permite adaptar constantemente nuestros planes y estrategias para que se ajusten mejor a nuestras necesidades. El enfoque del corazón ágil es una forma mucho más sencilla de hacer las cosas y lograr nuestros objetivos. Al Reflexionar, podemos hacer una pausa y comprobar los datos y nuestras emociones. Esto nos asegura de que estamos tomando las mejores decisiones en función de la información disponible. Inspeccionar y adaptarse es vital para el éxito de cualquier equipo ágil.

Sin la reflexión, corremos el riesgo de quedarnos atrapados en métodos y procesos obsoletos que ya no funcionen para nosotros. Aprender de la experiencia es lo que nos permite crecer y mejorar como personas y como equipo. El corazón ágil fomenta este proceso de aprendizaje al exigirnos que reflexionemos sobre nuestro trabajo con regularidad para ver realmente qué funciona y qué no. Solo entonces podremos hacer los cambios necesarios para convertirnos en profesionales ágiles más efectivos.

El Corazón de la Agilidad se trata de simplificar la mentalidad y las prácticas ágiles para que sean más accesibles y fáciles de implementar.

Sobre Mejora

Fuente: https://heartofagile.com/heart-of-agile-plus-teaching-denmark-sept-2020/

Finalmente, es imperativo que te esfuerces continuamente por mejorar la dirección de tus ideas, su implementación técnica y tus procesos internos. Esto se puede hacer aprovechando las oportunidades de aprendizaje, buscando retroalimentación de otros y experimentando con enfoques novedosos. Al mejorar constantemente, puedes hacer que tus equipos y tu organización sean sostenibles en el tiempo y salir adelante incluso en tiempos adversos.

La mejora también es un proceso continuo. A medida que crecemos y nos desarrollamos como individuos, debemos seguir mejorando la forma en que trabajamos. Esto implica no solo aprender nuevas habilidades, sino también mejorar nuestras interacciones con los demás y usar las herramientas de una manera más efectiva. Al aprovechar la mejora, podemos ayudar a mejorar la forma en que el pensamiento ágil funciona para todos.

El cambio es una parte necesaria en la agilidad. Para tener éxito, los equipos deben estar constantemente experimentando y probando cosas nuevas. Sin embargo, esto no significa que deban hacer cambios grandes y radicales cada pocos meses. En su lugar, los equipos deben centrarse en realizar pequeños cambios que puedan mejorar el ecosistema ágil en general. Esto incluye mejorar el desarrollo de sus habilidades, limitar los cambios que hacen y mejorar sus formas de comunicarse y las técnicas para realizar experimentos y probar hipótesis. Con esto en su lugar, los equipos pueden adaptarse mejor a los cambios en el futuro.

Notas finales y un llamado a la acción

El manifiesto ágil ha ayudado a organizaciones de todo el mundo a producir mejores resultados durante dos décadas. Con sus valores y principios, apareció toda una nueva forma de trabajar, junto con marcos, prácticas e instrumentos que aumentan la productividad y la calidad de lo que hacemos. El enfoque del Corazón Ágil simplifica este complejo conjunto de prácticas en cuatro imperativos esenciales: colabora, entregar, reflexiona y mejora. Estos cuatro pilares te ayudarán a ti y a tu equipo a generar mejores ideas, transiciones fluidas, ampliar las entregas y mejorar los procesos internos. Al mantener el Corazón de la Agilidad en el centro de tu trabajo, tú y tu equipo pueden producir mejores resultados, juntos.

Entonces, cuando sientas la necesidad de adoptar y comprender la esencia de las prácticas ágiles, o de encontrar tu propia forma de ser "ágil", siempre ten en cuenta el Corazón Ágil.

¿Está latiendo tu Corazón de la Agilidad? Déjamelo saber en el foro.

El lenguaje y la transformación organizacional

Escucha el audio de este artículo aquí:

Muchas personas no creen que la terminología o el vocabulario usado importe. Pero el lenguaje se refleja directamente en los modelos mentales que hacemos de las cosas. Y los modelos son una representación de la realidad que nos rodea. Así que los modelos ayudan o soportan la construcción o elaboración de esas realidades a nuestro alrededor y de los escenarios en los que vivimos.

En los procesos de cambio o de transformación, es importante modificar no solo nuestros comportamientos sino también el vocabulario que usemos. Así la alta dirección y todos en la organización no se sentirán ansiosos pensando que nada está cambiando. Veamos un ejemplo:

De pensar en proyectos a pensar en productos

Imagen de Nattanan Kanchanaprat en Pixabay

No se trata solo de un cambio en la terminología, sino también en la forma cómo vemos e interpretamos el mundo. Se trata de la forma en que percibimos y pensamos sobre las cosas: los proyectos inician con buenas ideas, de esas que dan ganas de volver una realidad. Pero las formas de gestión tradicional de proyectos los han catapultado como “exitosos” si el plan inicial de alcance, tiempo y costo del proyecto estuvo cerca o muy cerca de los números al final del mismo: se trata del así llamado Triángulo de Hierro del management vetusto.

En principio, esto no tiene nada de malo. Son las prácticas de gestión que han predominado durante décadas en las organizaciones, aunque a muchas de estas les ha costado más de un dolor de cabeza. Pensemos en que el 88% de las compañías que el siglo pasado estaban en la lista de las 500 más grandes de Estados Unidos (Fortune 500), en 2017 habían desaparecido de la lista o de la faz de la tierra para siempre o simplemente se habían convertido en un pequeño departamento dentro de una corporación mucho más grande que las absorbió. Más sobre esto en:

http://www.aei.org/publication/fortune-500-firms-1955-v-2017-only-12-remain-thanks-to-the-creative-destruction-that-fuels-economic-prosperity/

O si no pregúntale a Nokia. Cien mil empleados, una infraestructura considerable y millones en activos y por la que Microsoft pagó incluso menos que por Skype, otra compañía muchísimo más pequeña, con apenas algunos cientos de empleados. ¿Cómo es posible que la empresa cuyas ventas de celulares se encuentran en la cima de todos los listados de ventas y que se cuentan por cientos de millones de unidades, se haya convertido en unos pocos escritorios dentro del gigante del software y luego desaparecido para siempre?

Bueno, si tú o tu empresa siguen pensando en términos de proyectos y menos en términos de productos y valor, tu destino puede cambiar rápidamente. Y más en los actuales escenarios de altísima incertidumbre y volatilidad e igualmente o más complejos y ambiguos que los de hace apenas algunos años. Es por ello que queremos reemplazar conceptos (vocabulario) como el “triángulo de hierro” de los proyectos por el triángulo ágil o por mi versión extendida que puedes encontrar en:

http://www.gazafatonarioit.com/2016/04/del-triangulo-de-hierro-al-triangulo.html

O por los conceptos mencionados de producto y de valor. El objetivo de toda organización, y el paradigma al cual se enfrentan hoy por hoy, es entregar productos o servicios de valor para sus consumidores. Productos que generen retorno de la inversión, disminuyan los costos, ganar más clientes, eliminen desperdicios en los procesos y, en fin, todo lo que signifique generar valor para la empresa.

Hoy es preferible pensar en términos del mínimo producto viable (MVP), incluso es mejor pensar en términos de experimentos y de sus conceptos subyacentes. Es lo que te permitirá cambiar la forma de hacer las cosas porque tus modelos mentales serán diferentes y, por ende, la realidad que te rodea, la realidad que construyes basado en esos modelos. Esta forma de pensar, ágil por demás, conduce a generar menos desperdicio, a mayor creatividad y a más entregas y de mejor calidad.

Sobre técnicas para encontrar el MVP y, en general, sobre la creación de productos, puedes consultar en:

http://www.gazafatonarioit.com/2016/08/inceptions-con-jorge-abad.html

Y sobre productos y su contexto, puedes leer en:

http://www.gazafatonarioit.com/2019/12/el-contexto-de-tu-producto-importa-aqui.html

De pensar en trabajo en equipo a trabajo colaborativo

Imagen de Gerd Altmann en Pixabay

Ya desde los mismos conceptos, el primero de ellos no da señales de que ese trabajo se haga efectivamente de manera colaborativa. Es posible tener un “equipo” de especialistas, como ha ocurrido históricamente, donde cada miembro elige o se le asignan tareas por hacer de acuerdo con sus habilidades específicas. Pero eso no tiene nada de colaborativo, no exige mucha comunicación entre uno y otro integrante del equipo y quizás requiera de poca o ninguna interacción entre unos y otros.

El verdadero trabajo colaborativo va más allá. Implica interacción constante, poner de manifiesto la inteligencia y las habilidades de cada persona para un bien mayor, el del equipo y el de la organización. Requiere de confianza entre las personas, de mucha comunicación, ojalá cara a cara, del establecimiento y práctica de valores como la apertura y el respeto, incluso el coraje. Requiere de mucha proactividad y de sentido de pertenencia y de familia. Bajo este paradigma no hay espacio para individualidades, el responsable de una tarea y de todas las tareas es el equipo en pleno, ningún miembro del mismo es dueño del resultado, solo el equipo.

Esta forma colaborativa de hacer las cosas hace posible la experimentación y la falla, requiere del liderazgo de todos los participantes en el equipo, rompe barreras, elimina silos, promueve recompensas a todo el grupo, no solo a unos pocos individuos, maximiza las habilidades de escucha y, en general, de comunicación, comportamientos que, a la postre, traerán como consecuencia un cambio en la cultura de la empresa, una transformación organizacional.

Estos cambios se van generando de manera natural, orgánicamente. Primero como un reflejo en nuestras mentes y en las mentes de los comprometidos con el cambio, más adelante, si lo sabemos promover, el cambio empieza a ocurrir en los demás interesados y, a partir de allí, en el resto de la organización. Finalmente esos cambios son el reflejo de nuestra forma de pensar, la que conseguimos encontrando nuevos conceptos y formas de ver e interpretar el mundo, un nuevo lenguaje que impacte positivamente nuestro modo de pensar.

Otros cambios necesarios en tu vocabulario

Estos apenas fueron un par de ejemplos sobre cómo el lenguaje impacta nuestro pensamiento y nuestra forma de actuar. Pero, en la práctica, quizás nos topemos con aspectos de la cultura organizacional, de la forma de trabajar de las personas y los equipos y de los paradigmas de gestión y de ejecución de tareas para los que no tengamos un vocabulario común o simplemente no hallemos una forma de verbalizarlo. Es allí donde es importante lo acentuado que tengamos una u otra forma de interpretación de los escenarios que enfrentemos y del contexto que tengamos de las cosas.

Con todo esto en mente, te invito a cambiar tu léxico:

·       De trabajo por habilidades o especialidades, aislado, a trabajo colaborativo, en red.

·       De una entrega final de producto a entregas tempranas y frecuentes de valor.

·       De analizar los resultados al final de un gran ciclo de trabajo (proyecto), a reflexionar sobre el estado de las cosas repetidamente: inspección y adaptación.

·       De tratar de mejorar todo y de una sola vez, a realizar mejoras graduales y pequeñas pero continuas.

·       De planificar una sola vez y ejecutar el plan, a realizar planes periódicos, quizás tanto como todos los días.

·       De pensar solo en tener éxito, a pensar en experimentar y fallar para aprender

·       De fomentar el trabajo de expertos en distintas áreas a promover el aprendizaje continuo de las personas para que adquieran habilidades T o Pi (especialistas generalistas)

·       De gastar tiempo estimando las actividades del equipo a ordenar los elementos del producto y empezar a crearlo de inmediato

·       De hacer multitarea a tener foco en una sola tarea a la vez, tanto individualmente como en equipo

Y de pensar que hay una palabra, una expresión verbal o escrita para todo, a tener presente que hay aspectos del universo que no somos capaces de modelar porque no hay forma de representarlos y allí es donde nuestras emociones y nuestro sentido común juegan un papel importante: es el fundamento o la esencia por el cual estamos aquí y la razón por la cual queremos cambiar para mejorar.

Al hacerlo, seguramente notarás un cambio en la realidad circundante. Por ahora, cuéntame en el foro qué otros cambios estás promoviendo en tu equipo y en tu organización.

Puedes ver y descargar la presentación aquí:

Dueño de Producto, usted ha sido invitado a la Retrospectiva

El Dueño de Producto, ¡ese ilustre olvidado!

Me preguntan por interno si este personaje debe asistir a la ceremonia de inspección y adaptación. Es una buena pregunta, teniendo en cuenta que hay quienes recomiendan que no sea así o que la participación del Dueño de Producto es opcional en la Retrospectiva.

No hay ninguna buena razón por la cual el Dueño de Producto no deba estar en la retrospectiva. Desde la misma guía de Scrum ya sus autores sugieren que debería participar:

"La Retrospectiva de Sprint es una oportunidad para el Equipo Scrum de inspeccionarse a sí mismo y de crear un plan de mejoras que sean abordadas durante el siguiente Sprint".

Y ya sabemos que el Equipo Scrum se compone de Scrum Master + Desarrolladores + Dueño de Producto.

Pero más allá de esto, no concibo cómo, sin la participación del Dueño de Producto en esta reunión, sea posible que el equipo en pleno se inspeccione a sí mismo para luego crear un plan de mejoras que nunca estará completo sin la intervención de este actor. Por ejemplo, ¿cómo mejorar la comunicación con el entorno del negocio? El resto del equipo no podría definir la mejor estrategia para lograrlo en ausencia del Dueño de Producto.

Algunos dirán que se define la estrategia en la reunión y luego se la comunican al Dueño de Producto, eso simplemente extendería la retrospectiva, con el riesgo de que él "tumbe" las acciones a realizar por cualquier motivo válido.

• ¿Y qué pasa si hay problemas con la salud del backlog? 
• Problemas con la definición de los criterios de aceptación de las historias de usuario.
• ¿El equipo conoce cómo los usuarios realmente usan el producto?
• Problemas con la aceptación del incremento sprint tras sprint.
• ¿El equipo conoce la visión completa del producto, la estrategia de implementación y cómo lo quieren los usuarios?
• ¿Y qué ocurre si el Dueño de Producto no está el tiempo suficiente con el equipo para responder sus preguntas y clarificar las características del producto? O para proporcionar retroalimentación efectiva.

En fin, muchas son las razones para que el Dueño de Producto sí esté en la reunión. Estas que mencioné son solo algunas. En breve, el Dueño de Producto es protagonista principal en esta ceremonia.

Ahora bien, se me ocurren algunas malas razones por las cuales no debería asistir. Las mencionaré brevemente y estableceré alguna razón sólida para no tenerlas en cuenta:

Lo aburrimos con minucias técnicas. Una retrospectiva no es para profundizar en los detalles de lo puramente técnico.

El equipo de desarrollo y el Scrum Master son de un proveedor y el Dueño de Producto es del Cliente. Entonces dónde queda la confianza y, por consiguiente, la transparencia. Si estamos pensando así, todavía nos hace falta mucho de la Cultura Ágil y de liderazgo. En cualquier caso, esta práctica reduciría mucho la transparencia, necesaria a todas luces en un entorno ágil.

No tiene tiempo. ¡Este es, precisamente, un tema a abordar con él en la retrospectiva!

Así lo hemos hecho aquí y nos funciona. Esta es interesante. ¿Y qué tal si lo hacemos de la otra forma (que si asista) y vemos la diferencia? ¿Mejoramos o empeoramos? Seguramente será lo primero.

Esta última es la típica cuestión que se enmarca en el empirismo, es decir, aprendemos de la experiencia, como todo en Scrum. Algo que se resume también en eso de "usar o hacer lo que te funciona". Sin embargo, las razones que expuse al principio y muchas otras precisamente nos han enseñado los beneficios de la presencia del Dueño de Producto en la ceremonia.

Entre otras, pero todas absolutamente son "malas" razones.

En definitiva, el Dueño de Producto sí debería (sí debe) asistir a las retrospectivas, así que adelante. Si como Scrum Master te sugieren que el Dueño de Producto no debe estar en la reunión, te enfrentas a una sintomatología que te indica que falta algo de la base, los valores y principios ágiles, la forma cómo racionalizamos, el fondo de la cultura ágil, más que del mismo Scrum y otras prácticas.

---

¿Y tú, invitas al Dueño de Producto a tus retrospectivas? Déjamelo saber en la sección de comentarios más abajo.

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

“No puedes guiar el viento, pero puedes cambiar la dirección de tus velas”

Sobre el cambio a ágil, temores infundados y penas frívolas

“Las masas humanas más peligrosas son aquellas en cuyas venas ha sido inyectado el veneno del miedo... del miedo al cambio.”

[Octavio Paz (1914-1998) Poeta y ensayista mexicano]

Todavía me encuentro con muchas personas que creen que ‘saltar al ecosistema ágil’ es como en las películas donde después de un ataque al gobierno, a veces por parte de alienígenas, a veces por parte de un gobierno enemigo, se dan a la búsqueda de los jóvenes y niños ‘genios’ de las universidades para que les resuelvan el misterio o le decodifiquen el mensaje cósmico. Lo bueno de esas historias es que siempre hay alguien que lo logra, a veces solo, a veces en compañía de alguien que para lograrlo viola un sinnúmero de leyes y comete muchos delitos en simultáneo. Otros son más facilistas y quieren usar la máquina del tiempo para ir al momento justo antes de que los modelos y enfoques tradicionales salieran a la luz pública y borrarlos de la historia. ¡Eso ya no es posible! Al menos no con una máquina.

Lo bueno de Ágil es que no tenemos que ser súperdotados para practicarlo ni para ser exitosos. Es más una cuestión de disciplina, de ganas, un deseo inacabable de ser feliz (o de volver a serlo) en el trabajo y de juntarse con las personas adecuadas. También es cuestión de pensar un poco, de entender cuáles son los problemas mayores de las organizaciones y de las personas cuando intentan dar el salto a una nueva forma de ver e interpretar el mundo. Hay dolores superficiales, pero también hay enfermedades crónicas cuyos síntomas no son tan evidentes; para completar el cuadro clínico, hay penas que traspasan lo físico y se quedan en lo puramente espiritual, son difíciles de detectar y mucho más de erradicar, de sanar.

Conocer los miedos no solo de los interesados sino también de los patrocinadores, de quienes toman las decisiones, por ejemplo, es un buen comienzo. He encontrado que muchos de ellos/ellas temen no alcanzar el éxito en el proyecto de transformación y quienes no, imaginan o sospechan que pueden perder su lugar en la organización una vez se dé el cambio, asunto que está bastante alejado de la realidad a no ser que la persona no se adapte al nuevo entorno. En este último caso, tendríamos que preguntarnos si en realidad ya estamos en el punto que queremos.

Quizás entonces el entrenamiento y el soporte no ha sido el adecuado. A veces nos quedamos en las áreas de tecnología, cuando ‘Ágil’ es un asunto de toda la organización. El papel del Scrum Master es fundamental en este aspecto y no nos digamos mentiras (al menos no entre nosotros), los buenos Scrum Masters, los verdaderamente buenos, son difíciles de encontrar: ellas o ellos necesitan tener lo que llamamos comúnmente ‘don de gentes’ y también habilidades en lo ágil y también conocimiento técnico y todo esto junto es muy difícil de encontrar en una sola persona.

Algunas otras dificultades ya son ‘clásicas’: cambiar de un enfoque de ‘comando y control’ tradicional a un enfoque de autoorganización, al mejor estilo Scrum, es una tarea espinosa por no decir algo indecible. Este es un aspecto que impacta a los mandos medios de una compañía, por ejemplo, a la habitual oficina de proyectos o PMO que llaman en algunos entornos. Es precisamente en esta oficina donde comienza el cuestionamiento de lo que puede ser y no es: ¿entonces qué hago con todos los gerentes de proyecto que tengo? He escuchado decir. Encontrar una justificación válida para esto es arduo, imposible dirán algunos. Pero en general, todas las personas tienden a sentir miedo, por aquello de los equipos multifuncionales, donde el poder de la especialización de una persona se pierde. En este mismo orden de ideas, abandonar la falsa seguridad que dan los planes a mediano y, sobre todo, a largo plazo, que nunca han funcionado, en pro de planes a corto plazo, es algo que enciende las alarmas de más personas en la organización de las que quisiéramos contar. Miedo al cambio, natural por demás, es el tema de fondo.

Algunos otros obstáculos que he encontrado:

• Conseguir que las áreas del negocio y la alta dirección se involucren efectivamente
• Lograr la confianza y la autonomía que requieren los equipos ágiles y, sobre todo, el equipo de transformación
• Qué hacer con la jerarquía existente en las organizaciones donde el escalafón de las personas es algo ‘valioso’, es una pregunta que deberíamos responder al iniciar el cambio
• Crear, preparar y promover un equipo ‘colonizador’ o mejor aún, un equipo ‘conquistador’, punta de lanza, que se atreva a hacer las cosas, a ir más allá de donde nadie en la compañía ha llegado. Este es un asunto vital.
• Desaprender los hábitos del desarrollo en cascada, del comando y control, del esperar a que me digan qué hacer, del llenar documentos por llenar y todos esos aspectos que aborda el manifiesto ágil en toda su extensión. Sobre este asunto, los invito a leer: ‘Respuesta al cambio sobre seguir al plan: no planearás’, aquí mismo en este Gazafatonario.
• No intentar cambiar a las personas que no quieren cambiar. La naturaleza humana evade el cambio o se resiste a este cuando alguien intenta cambiarla. Cuando la dejan en paz, cambia por sí misma… ¡si quiere!
• Finalmente, pero no menos importante, cambiar la cultura de la compañía, en ágil todo es acerca de la cultura. Pero sobre esto pueden leer mi artículo: ‘Cultura ágil: ese oscuro objeto del deseo’, aquí mismo en mi Gazafatonario.
• Más allá de todo, recordar que ser ágil significa reemplazar la predictibilidad falsa por la eficiencia.

Cambia... Hay un gran chance de que el nuevo día sea radiante.

Certificar un proveedor como Ágil o de la 'Agile Certified Provider Alliance'

“Generalmente ganamos la confianza de aquéllos en quienes ponemos la nuestra.” [Tito Livio]

Hace algunos días, nuestro amigo y colega Jorge Abad decía en un mensaje a la Comunidad de Ágiles Latinoamérica:

“Me hacen esta pregunta desde una empresa del estado que realiza grandes contrataciones de proveedores: ¿Existe una lista de chequeo estándar para validar si una empresa es ágil y usa las prácticas de ingeniería adecuadas para ágil?”

Al margen de que sea o no una empresa del estado, la pregunta tiene su truco. En cualquier caso, esta fue mi respuesta a Jorge:

Watts Humphrey, el padre de CMMI, decía que certificarse CMMI 5 significaba que tu siguiente proyecto iba a ser exitoso. Él no decía nada de los demás proyectos. Es natural, la organización recién certificada “respiraba” CMMI, calidad, procesos, productividad y motivación, algunos de los elementos clave para el éxito de los proyectos.

¿Pero y los demás proyectos, los que siguen a continuación de ese?

Igual sucede con Ágil. Aun si el cliente visita al proveedor potencial, este último le puede demostrar a aquel (¡a no ser que sea una visita sorpresa!), que es Ágil.

¿Pero y los demás proyectos? [Acá entre nos, no existe ninguna posibilidad de que una lista de chequeo sirva para probar que un proveedor es ágil. Existen listas como esta de Henrik Kniberg (http://goo.gl/QnQUN), una herramienta para evaluar una implementación de Scrum, tratar de encontrar algo más allá es una utopía.]

Quienes hemos navegado por los vericuetos, a veces inescrutables, de las certificaciones de todo tipo, que nos proclaman como los poseedores del vasto poder del conocimiento y la experiencia, sabemos que eso no es suficiente y que, en muchos casos, eso no garantiza el éxito. Sobre todo, en nuestras economías tercermundistas, con nuestra idiosincrasia, con nuestra forma de ver el universo.

¿Qué vale entonces?

¡La confianza!

Aun una entidad del gobierno, debe dar el salto y modificar su “modus vivendi” (Sí, lo sé, no es fácil –pero igual, aun una entidad del gobierno debe saber que “ser ágil no es solo cosa de sus proveedores”, la organización también debe transformarse), para que pueda ser capaz de hacer pilotos, evaluar los resultados y luego sí, ajustar con el probable proveedor o desecharlo de una vez por todas y para siempre, condenarlo a 100 años de soledad, esa fatídica maldición de los que no tienen una segunda oportunidad sobre la tierra.

Incluso quizás unos cuantos sprints no serán suficientes. Más aun, ¿cómo comprobar al final de varios proyectos si tu proveedor es ágil? ¿Acaso es posible probar que parte del equipo no es ágil (el equipo de desarrollo –del Proveedor) y parte sí (acaso el Dueño de Producto y quizás el Scrum Master –del Cliente)?

Estaba reflexionando con toda esta perorata y mi conclusión es que no es posible, al menos no tiene mucho sentido que este cliente del estado, o cualquier otra empresa privada o de gobierno, evalúe si un proveedor es ágil.

Quizás el proveedor sí es ágil, pero cuando se junte con el cliente deje de serlo.

Quizás no lo es, pero cuando se junte con el cliente aprenda a serlo.

Quizás sí lo es y cuando se junte con el cliente, siga siéndolo.

En fin, las posibilidades son variadas.

¡Estamos de vuelta en la Confianza! Martín Alaimo, dice en su libro “Equipos #MásProductivos”, citando a su vez a Gorerg Simmel, que “La confianza es una hipótesis sobre la conducta futura del otro” y más adelante él mismo dice: “La confianza que inspiro en otros sobre mí, la construyo y la sostengo a través de mis acciones.”

Algunos miembros de la Comunidad le respondieron a Abad que era una cuestión de “feeling”. Yo, por ejemplo, tuve varias novias (2 al menos) antes de quedarme con quien es mi esposa, no era la más bonita pero sí la que más confianza me generó. Y eso, mi estimado Jorge, no se consigue con una lista de chequeo ni con una visita a casa de los padres de la novia. ¿Quién sabe? Quizás mañana me divorcie.