El Zen del Scrum Master: Self-Mastery

marzo 22, 2018marzo 22, 2018 / Johnny Ordóñez / 2 comentarios

dongzhi-419028

He notado que cuando se habla del rol del Scrum Master, siempre se lo expresa «hacia fuera», es decir; la descripción de aquellas responsabilidades que tiene hacia el equipo o la organización. Esto es importante sin duda, pero a mí me gusta también explorar este rol «hacia dentro»; y cuando lo hago uso una analogía -tomada de la representación del yin y el yang– a la que he denominado el Zen del Scrum Master.

El yin-yang es una representación taoísta muy conocida que se refiere a la «dualidad» existente en todo lo que habita en este universo. El círculo yin-yang es familiar (quizás unos de los conceptos orientales más difundidos). El yin corresponde a la mitad del lado izquierdo de la esfera, de color negro; representa la pasividad, la absorción, la tierra, la oscuridad, lo nocturno. Por su parte, el yang pertenece al lado derecho de la esfera, de color blanco y representa el principio activo, luminoso y diurno. No puede haber yin sin yang, o yang sin yin…y hay un poco de yang en yin, y un poco de yin en yang.

En el Zen del Scrum Master, el yin es el «self» o el «yo». Hace referencia al dominio del individuo, a la maestría personal; esto es: el conocimiento de ti mismo, el dominio y uso de tus emociones, al dominio de tu ego, el desarrollo de la escucha empática, a la consciencia y dominio de tus palabras…y como todo esto te ayuda a crecer como individuo y como Scrum Master.

5f136e918828b0934d4ca0cdc479ac6e-zen-meditation-concentration-camps

Exploración y conocimiento del «Yo»

El yang hace referencia al «mastery» o «dominio de la técnica». Esto es acerca al desarrollo de habilidades para crear espacios donde los equipos se habiliten a tomar sus propias decisiones para aprender y mejorar. Es sobre el dominio de técnicas para la introspección, ideación y solución, es sobre ayudar a elevar el nivel de consciencia de los equipos; y por supuesto- es sobre el dominio del método Scrum o otros métodos ágiles, técnicas de facilitación, retrospectivas, mentoring y guiar al equipo para ayudarlos a crecer.

Expresar a través de la técnica

Posiblemente lo siguiente sea una parte menos conocido en el yin-yang. En el yin-yang no existen sólo dos fuerzas, existen tres: el yin, el yang y el Tao…la fuerza que los une, la fuerza conciliadora, que no se ve pero allí está.

Taller de Scrum Masters que facilité en BBVA Colombia, 2017

En esta pequeña analogía, en el Zen del Scrum Master hay el«self», la«mastery» y el «Self-Mastery».

Ser Scrum Master (SM) es vivir en un ejercicio continuo de «auto-maestría» (Self-Mastery). Que si bien, hay un principio sobre el dominio de la técnica de Scrum y ágil, hay un principio sobre el dominio del ser, de las emociones, de la maestría personal.

Hay un poco de «Yo» en mi «Técnica», y un poco de «Técnica» en el dominio de mi «Yo»…y ninguno de ellos viven solos.

Posiblemente todo esto suene algo «esotérico» o «romántico» para la mayoría de agilistas, pero por experiencia en carne viva puedo compartir: ser un Scrum Master o Agile Coach es un camino de trabajo constante en uno mismo, de crecimiento personal que toca fibras íntimas, que replantea; y también de «expresar a través de la práctica», del dominio de la técnica. Un Scrum Master o Coach comparte y expresa lo que se lleva por dentro; y esto sin duda ayuda a crecer en el rol y ayudar a sus equipos. No subestimen el Zen del Scrum Master.

Gracias por leer.

El autodominio es un desafío para cada individuo. Sólo nosotros podemos controlar nuestros apetitos y pasiones. El autodominio no puede ser comprado con dinero o fama. Es la prueba definitiva de nuestro carácter. Requiere descender por los profundos valles de nuestras vidas y escalar nuestro propio Everest.

– James E. Faust

Shu Ha Ri: la historia del samurái y sus tres hijos

marzo 19, 2018febrero 22, 2021 / Johnny Ordóñez / 6 comentarios

«Shu Ha Ri» es uno de los conceptos más populares en el mundo ágil y es utilizado comúnmente como analogía para describir las etapas de madurez en el dominio de una técnica o maestría sobre algo.

Photo credit: Jim Barry

La interpretación más utilizada que he visto es: «Seguir la regla, adaptar la regla, romper la regla». En alguna ocasión, leí una interpretación de Ri como: «Ser o convertirse en la regla». Esta me gustó más. Todas estas variaciones son muy utilizadas en actividades de trainning, mentoring, coaching, comunidades, artículos, modelos de evaluación de equipos y roles ágiles, y otras aplicaciones. Me atrevería a decir, que es conocido por todo agilista.

Sin embargo, -y con todo respeto- pienso que estas interpretaciones pueden ser simplificaciones que limitan la comprensión de la esencia y el obtener el beneficio del significado trascendente.

Para explicarme un poco mejor, permítanme compartir con Ustedes cómo aprendí el concepto del Shu Ha Ri; gracias a la historia que me contó un gran amigo y mentor japonés. Esta historia le fue contada por su abuelo cuando era muy joven y me la narró de la siguiente forma:

«En la época del Japón feudal, había una vez una familia de un samurái con sus tres hijos. Este samurái fue requerido para una misión que tardaría siete años. La noche antes de partir, durante la cena; el samurái pidió a sus hijos que en su ausencia nunca dejaran de practicar el arte de la espada y de honrar el código del guerrero. Los tres hijos asintieron y juraron ante su padre. Siete años después, el samurái estuvo de regreso. Esa noche, durante la cena; el samurái preguntó a sus hijos si habían honrado el juramento que hicieron ante él al momento de su partida. Todos asintieron y afirmaron haber honrado la promesa.

Antes de dormir, el samurái pensó: «¿de qué forma puedo darme cuenta que en verdad han practicado y cumplido su promesa?». Ideó una prueba que pondría en marcha en la mañana siguiente. Amaneció, y muy temprano el samurái preparó la prueba. Colocó una cubeta de madera con agua en el filo superior de la shoji (puerta deslizante japonesa), y él se sentó dentro de la habitación.

Entonces llamó a su hijo menor, quien esperaba junto a sus hermanos fuera de la casa, con sus espadas en la cintura. Al abrir la puerta, la cubeta cayó a toda velocidad. Golpeó la cabeza del hijo menor, pero antes de que cayera al piso…este sacó la espada y la dividió en dos con mucha destreza. El samurái hizo una reverencia ante su hijo. Luego, armó nuevamente la trampa y llamó a su segundo hijo. Al abrir la puerta, la cubeta cayó a toda velocidad, el segundo hijo se da cuenta, la esquiva…y antes de que cayera el suelo…desenvaina la espada y parte la cubeta en dos. El samurái hizo una reverencia ante su hijo. Finalmente, arma la trampa y llama a su hijo mayor. Al abrir la puerta, la cubeta cae a velocidad; el hijo mayor se da cuenta…y levanta su mano para sostenerla en el aire sin que cayera ni una gota de agua. El samurái hizo una reverencia ante su hijo.»

– «Y eso es Johnny: Shu, Ha y Ri»…terminaba la historia mi amigo. Hasta aquí, estaba algo atónito…tratando de descifrar la moraleja. No era claro para mí, de qué forma esta historia se conjugaba con la concepción de Shu Ha Ri que tenía en ese entonces. Al ver mi cara de confusión, mi amigo me dice:

– ¿Qué piensas? ¿te gustó la historia?.

– «Me encantó!», le respondí, «…pero no logro comprender aún.»; y posteriormente me hizo una reflexión que hasta hoy, considero uno de los mejores regalos de que me han realizado.

«Shu Ha Ri» no se trata únicamente del dominio de la técnica. Se trata de la consciencia de tu entorno y el manejo de tu energía. En el nivel más alto de maestría, cabe la búsqueda de la más pequeña acción que genera el máximo impacto posible utilizando el mínimo de energía, sin romper la armonía con tu entorno. Acción sin acción, estar presente, ser consciente…más allá de la destreza de la técnica.

En la historia, todos eran diestros en el uso de la espada; más, la diferencia entre el hijo menor y el hijo mayor, es que este último sabía cuando usar la espada…y lo más importante, cuando no usarla. Me decía también, que hay variaciones de la misma historia pero con la temática de la ceremonia del té, escritura japonesa y otras artes; y múltiples enseñanzas alrededor, por ejemplo: el orden en el que el samurái llama a sus hijos, hace referencia a que llegar a un nivel de consciencia más profundo toma tiempo, y entre más viejo mejor usas tu energía…que es difícil identificar a una persona en nivel Ri, y que por lo contrario de lo que se pensaría, a mayor nivel de maestría, más quieto, más callado y más humilde se vuelve la persona.

Gratamente asombrado y todavía con mi cabeza dando vueltas, le agradecí a mi amigo. Esta reflexión sigue conmigo en cada paso de mi vida y mi carrera; y espero sinceramente que les ayude en su proceso de crecimiento personal y el de sus equipos.

Gracias por leer.

How To Create The ‘Tree Of Teams’ That Influenced The Culture Of An Entire Bank

diciembre 18, 2016diciembre 18, 2016 / Johnny Ordóñez / Deja un comentario

imagen-1

One of the most important challenges on agile transformations is influencing the current culture. Culture is more than making ceremonies, creating new roles and putting Kanban Boards full with Post-It’s. Although it’s absolutely true that visible artifacts show cultural expression, values and principles, however I believe that talking and showing values on a more active way is a much healthier way to initiate a change.

This blog post by my friend Johnny will show you how a small group of Scrum Masters came up with an awesome idea to radiate values and principles on an artful way. The following tutorial will show how they implemented the Tree of Teams in a one of the biggest banks in South America. Read how you can do it too!

Where did the idea come from?

We are working with four scrum teams as a part of an agile transformation initiative within an international bank in Latin-America. Each team developed their own identity, expressed on their boards and walls inside the teams´ spaces. Each team is doing several individual initiatives in order to improve motivation, ceremonies and some other processes.

However, at one point we felt that we needed to show the achievements of the teams without following the traditional metrics and charts. All Scrum Masters met to discuss and proposed ideas on how to do this. We talked from drawing a forest with stars and flowers until creating a solar system. Finally, we came to the consensus of drawing a tree after the premise that these four Scrum teams are the seed of the bank’s transformation.

What is the Tree of Teams?

We began to build the Tree based on several important basic pillars: the teams, their values & principles, achievements and ideas for changing the culture.

Here you can see the result (after a lot of Colombian coffee and “empanadas”), divided into the 5 mentioned pillars:

1. Teams in the center: The Heart

We located the agile teams in the center of the tree because they are the driving engine to generate fruits. The image shows the names of the four Agile teams that we consider as the drivers for the change management:

imagen-2

2. Roots

Roots are the pillars that support the culture we want to create. They are represented by four roots that the teams use to “radiate” and transform culture:

– Defining goals and objectives

– Showing achievements and value delivery

– Demanding a secure environment in order to grow and innovate

– Delegating actions and responsibility to viralize Culture.

3. Branches

Each branch represents a value that we are trying to interiorize:

Humility to accept and give feedback, generosity to share our knowledge to help growing others.

Respect for the people and their ideas without overlapping out personal positions.

Honesty to say things with truth, transparency in order to generate an environment of trust.

imagen-4

You cannot create a great culture without having values that everyone shares.

4. Fruits and Flowers

Fruits and flowers are commitments and achievements of the teams. Fruits are green and they represent a commitment between the teams and the business. A commitment could be a software product, an MVP or a cultural change initiative (normally they have an established deadline, for instance: for the next three months).

When a commitment is released (placed on the market or “On Hands of our customers”) this flourish with a blue star where we put the corresponding release date.

imagen-5

In this way, everything with a blue star is a value delivered to the organization, our customers or teams.

5. Ideas

We have represented the section of ideas as a watering can that is nourishing the tree. Here, any person in the organization (regardless of its role) can propose some idea to improve the culture, products, processes, practices with the only condition that it must be an item that serves people, customers, teams or stakeholders.

imagen-6

What is happening now? After three months since we draw the tree, we observed some new behaviors from the teams and managers:

Individuals and interactions

Many people came to ask with surprised faces when they saw our drawing. Any member of the agile teams could explain it to managers, business people or stakeholders but most important is that people are getting connected and are starting to talk about the relevance of our work to the organization. Now we recognize that the teams feel more empowered and committed.

imagen-7

Celebrating accomplishments, reinforcing commitments

There is a special atmosphere when a fruit “flourish” and one member (who received help by his/her mates) put a blue star on the tree. “We achieved a new goal” – It’s a wonderful moment for all.

Radiating the values and principles in an artful way

Showing team achievements in a different and collective way was our primary goal. However, we realized that this format surpassed our expectations and became a beautiful experiment that is changing mental models and the way of how to show progresses beyond a Burn-Down chart. This tree is an expression of the new culture that we are drawing and extending every day.

imagen-8

It’s the tree of all of us

This idea was born by the collaborative work of all Scrum Masters and Agile Teams. The strong desire to improve and transform our organizational culture is a breeding ground for agility.

We invite you to practice and adapt the idea with your teams. Run the experiment. Improve it and share your experience with us.

Remember: Be the change that you wish to see in the world. Thanks for reading!

Authors:

This Blog Post was written by Ana Zuried Salinas Parra, Elmer Yesid Fajardo Rodriguez, Yassef Briceño García and Johnny Ordóñez. I saw their work on LinkedIn and ask them if they would be open to make make their work transparent for the Agile Community. They agreed immediately and I’m happy to see these people thriving in Agile.

What’s your opinion on the “Tree of Teams”? Do you have further questions? Unsure on how to implement the idea? Don’t hesitate to drop your comments or questions below. The authors are open to answer all your questions!

Transformación ágil: ¿qué significa realmente?

diciembre 9, 2016diciembre 10, 2016 / Johnny Ordóñez / 6 comentarios

dk_butterfly_lifecycle_rev05_affmr0

“Transformación ágil” es el juego de palabras que más he escuchado o leído en este año. Sólo una evidencia más de la tendencia en la que se ha convertido la Agilidad gracias al impetuoso deseo de un número creciente de compañías de “incorporar Agile” dentro de sus operaciones.

captura-de-pantalla-2016-11-26-a-las-8-19-52-p-m

Sin embargo, cuando escucho a un ejecutivo o a un Agile coach: “Tenemos que ir hacia una transformación ágil..”, siento que se subestima el verdadero alcance e implicaciones de esta proposición.

De oruga a mariposa: no es un cambio, es una transformación radical

Muchos reconocidos agilistas usan esta metáfora “de oruga a mariposa” para ilustrar un proceso de transformación y muestran imágenes donde se observan los pasos a través de los cuales una oruga se convierte en un animal radicalmente diferente. Pero estamos observando el proceso desde afuera, como espectadores.

¿Qué sucede en realidad dentro del capullo? Pues básicamente la oruga se digiere a sí misma. Destruye sus tejidos a través de sustancias que genera consumiendo sus órganos y más del 90% de estructura actual, dejando solamente una parte de su “esencia” que soportará el nuevo cuerpo que viene después.

Durante el proceso, un cierto grupo de células se mantiene a partir del cual se crearán nuevas clases más especializadas a través de las cuales se formarán la nueva estructura, nuevos órganos y nuevas funciones (ojos, antenas, alas, etc.). Este proceso es más que un cambio estético hacia una hermosa mariposa, es casi como generar desde cero un animal completamente diferente desapareciendo su originador. Es radical, destructivo y creativo a la vez, toma tiempo y necesita las condiciones necesarias para llevarse a cabo.

¿Qué implica la transformación ágil para las empresas?

Una transformación ágil va más allá que adoptar prácticas técnicas, marcos de trabajo como Scrum o del ámbito de TI. Desde mi perspectiva también deben revisarse aspectos como:

Estructura y diseño organizacional: debe revisarse y rediseñarse el OBS (Organizational Breakdown Structure), revisión de los niveles jerárquicos y de las áreas.

Gestión del Talento y Cultura (antigua área de RRHH): los procesos de contratación (Hiring), Aprendizaje organizacional (adquisición y difusión de conocimiento), esquemas de incentivación, planes de carrera, motivación, infraestructura y adecuación física.

Trabajo con proveedores: modelos de contratación, esquemas de facturación y modelos de colaboración.

La dinámica con las áreas centrales: deben revisarse las dinámicas de interacción con las áreas de Marketing, Legal, Financiera, Riesgos, Medios y comunicación.

Estrategia y alineamiento: las dinámicas y frecuencias de las planificaciones estratégicas deben dirigirse hacia un paradigma de planificación adaptativo, de corto plazo y de cambio de rumbo; mecanismos de priorización y uso de la capacidad organizacional (presupuestaria y de conocimiento).

Liderazgo: es vital repensar seria y profundamente sobre el estilo de liderazgo y las personas que lo ejercen. Puede implicar la remoción de personas en diferentes niveles; la formación y el acompañamiento son intensos (al menos al inicio); es necesaria mayor diversidad.

Relacionamiento con el cliente y el mercado: diseñar nuevas formas de acercarnos a los clientes y escucharlos, fortalecer los círculos de feedback, modelos de relación y colaboración con StartUps, entre otros.

No es lo mismo “transformación ágil” que “optimización ágil”

La incorporación de prácticas ágiles y una mayor interiorización de los principios -independiente del framework usado- producen mejoras que paulatinamente se hacen visibles (no siempre los beneficios de la agilidad son percibidos inmediatamente). Menor “Tiempo de Espera” (Lead Time), más entregas, mayor calidad, menos desperdicio.

Todo esto es muy bueno, pero en realidad no es transformación. Si la compañía no se ha re-estructurado en buena medida en las dimensiones antes mencionadas considerando convertirse en otro tipo de animal tomando en cuenta pilares como los propuestos por Luis Mulato (5 Guías para Organizaciones Ágiles); habrán sido buenos cambios más no transformación. Si yo visito una compañía dentro de un año o dos y observo -por ejemplo- los mismos métodos de contratación, los mismos esquemas jerárquicos o el mismo estilo de liderazgo; en realidad no habrán cambiado mucho.

5 guías para las organizaciones ágiles por Luis Mulato

Conservar la esencia

«Organisational transformation needs to be crowdsourced, change needs to be rolled up.»

– Gary Hamel

Al igual que la oruga, que conserva una parte de sí misma y trasciende durante la transformación, la empresa debe dibujar y preservar su esencia. Los valores, la visión, los principios de una organización ágil. Con esto en mente, la agilidad será una buena forma de avanzar por el camino. Es desafiante, en ocasiones atemorizante, conlleva tiempo. Perseverancia, coherencia y acción son las bases para la transformación.

Gracias por leer y por su feedback.

Johnny

Referencias

https://www.scientificamerican.com/article/caterpillar-butterfly-metamorphosis-explainer/

http://www.flightofthebutterflies.com/life-cycle/

http://www.forbes.com/sites/stevedenning/2016/11/27/gary-hamel-can-big-firms-be-agile/#10a7cdf714f6

Balance organizacional: más allá de la conciencia de Equipo

octubre 17, 2016octubre 17, 2016 / Johnny Ordóñez / Deja un comentario

¡Ya una semana y un poco más desde el Ágiles 2016! Esta fue una ocasión muy especial y gratificante para mí…sí algo cansada también; pero una experiencia muy satisfactoria al reunirnos nuevamente con los viejos amigos, hacer otros nuevos y juntarnos para compartir y aprender de lo que nos gusta: Agilidad, sobre ayudar a mejorar la vida de personas y organizaciones.

Al mismo tiempo muy complacido y sorprendido del nivel de los agilistas de la región. Observé y participé de muy buenas charlas, vi muchos reportes de experiencia y me enriquecí del aprendizaje compartido de los practicantes ágiles a partir de su experiencia de probar cosas en sus equipos y organizaciones; de seguir creciendo en agilidad. Esto fue muy bueno.

Mientras conversaba con varias personas y lanzaba algunas preguntas, pude constatar la madurez en la aplicación de prácticas ágiles a nivel de equipo y de proyecto: la aplicación de mejores técnicas para el tratamiento de backlogs, mejores retrospectivas, un enfoque más amplio del rol de Scrum Masters, Product Owners y Agile Coaches, patrones y técnicas para formar equipos ágiles y mejorar su auto-organización, contratos ágiles, sobre cómo mejorar el aprendizaje y demás. Esto fue muy chévere, sin embargo pude notar que la mayoría de argumentos fueron dados bajo una perspectiva de equipo.

Lori Leitgeb en Ágiles 2016 – Keynote speaker

Durante su Keynote, Lori Leitgeb hablaba de casos donde el equipo lograba ser tan auto-organizado, tan cohesionado y casi tan independiente que paulatinamente perdían el foco o no contaban con la claridad suficiente del impacto de lo que construían sobre el negocio y sobre la compañía a la cual pertenecían y de cómo soportaban la visión. Las decisiones que tomaban los equipos que mencionaba estaban enmarcadas dentro del contexto de ¿cómo podemos ser mejores equipos?, ¿cómo mejoramos técnicamente?, ¿cómo aplicar mejores prácticas? Y así por el estilo.

Resumen de la charla ketnote de Lori Leitgeb en Ágiles 2016 – Facilitación gráfica gracias a Ana Betancur

Las organizaciones no son exactamente una democracia

Algo que hay que reconocer es, que hasta que lleguen enfoques como «Holacracy», «Sociocracy», organizaciones Líquidas y «Teals» a nuestras geografías; la mayoría de las organizaciones que conocemos y en las que participamos no son una democracia (sin embargo, felizmente existen notables excepciones en Latinoamérica). Comúnmente, el equipo no puede decidir sobre qué línea de negocio trabajará la compañía, qué mercados abordarán o qué sueldos van a ganar. Sí, no es que me guste mucho…no obstante es una realidad (y como agilistas trabajamos para lograr mejores matices).

De aquí que es necesario para equipos y los practicantes ágiles tomar conciencia que somos parte de un ecosistema, que estamos circunscritos dentro un entorno empresarial y social, y que hay vida más allá del código: gerencias, sistemas de gestión, estrategias de mercado, impacto de negocio, proveedores, inversionistas y demás; y que cada elemento de este gran sistema interactúa con muchos otros y afectan al comportamiento del todo. Los equipos -ágiles o no- no son islas dentro de la organización.

Menos ruedas de entrenamiento, más balance

Uno de los conceptos claves detrás de #ModernAgile (y que me enamora sinceramente) es: el de encontrar un balance. Una linda analogía de Joshua Kerievsky para ilustrar que más allá de las prácticas o marcos de trabajo, la Agilidad requiere balance para florecer. Y desde mi punto de vista, este balance debe lograrse en múltiples niveles: desde un nivel personal, de equipo, de departamento o grupo, de organización y de sociedad.

Balance organizacional

captura-de-pantalla-2016-10-17-a-las-12-55-18-p-m

Durante mi charla en el evento, utilicé una metáfora del «ecualizador» de los aparatos electrónicos de música para ilustrar el concepto de balance organizacional. Y si bien no existe configuración perfecta, cada organización debe encontrar la apropiada «ecualización» para el ritmo que desea tocar. Cada «slider» afecta al sonido que se produce. Si cada slider fuera una etapa del flujo del valor o un área de la organización, el trabajar para subir ese único slider no necesariamente produce el mejor efecto a la organización. Desde un punto de vista sistémico, se estaría sub-optimizando el sistema. Imagine, que se lleva Agile y mejores prácticas al área de desarrollo y estamos creando mejor software y a un buen ritmo; y las subsiguientes etapas o antes de colocar a producción -por ejemplo: Certificación, Seguridad, Riesgos, Legal- no trabajan al mismo ritmo: ¿cuántas de aquellas historias de usuario están en producción generando valor o retroalimentación? ¿Qué tan ágiles somos en realidad?

Imagine que lleva Agile a TI o a las áreas de Delivery, pero áreas como Talento Humano, Proveedores, no están sintonizadas al ritmo que desea tocar la organización o que exige el mercado; en realidad no es una organización ágil por más prácticas ágiles que incorporemos.

Mientras Lori hablaba, vino a mi mente una imagen que se quedó grabada y que alguna vez viera de una presentación de Masa Maeda de su modelo Serious LeAP, estas piedras que representan el balance organizacional:

Prosperidad tomado del modelo Seriuos LeAP de Masa Maeda

Valor para los Clientes o el mercado, valor para las personas dentro de la organización y valor para la empresa o negocio; la idea es encontrar la armonía entre estos tres elementos, balance. Coincidentemente, un esquema muy similar al presentado por Lori en su charla para la toma de decisiones dentro de su compañía.

Balance integral

Lo único que podría añadir a esto, es que no hay que olvidar que somos parte y que afectamos a la sociedad en su conjunto: la comunidad humana, el ecosistema, la ecología y cómo hacemos de este un mejor planeta para todos.

Pensamientos finales

Lo bonito de la palabra balance es que no implica que uno de los elementos es más importante que otro. Lo que quiere decir que las prácticas ágiles a nivel de equipo son importantes y necesarias; y que los valores y principios del manifiesto deben vivirse e interiorizarse; todo esto sin olvidar las otras perspectivas. Pienso que si tenemos más conciencia de este ecosistema actuaremos de mejor forma y con mayor claridad en nuestro propósito de ayudar a las personas y organizaciones que acompañamos.

Gracias por leer, un abrazo.

Johnny

Referencias y lectura posterior

Agile 2016 – Atlanta: algunas estadísticas

julio 31, 2016julio 31, 2016 / Johnny Ordóñez / Deja un comentario

Agile 2016 - Portada

Un evento Agile 20XX de la AgileAlliance es considerado algo así como un «mundial de fútbol» para los que estamos sumergidos en el mundo de la agilidad. Los más reconocidos exponentes, coaches, autores, gurús, practicantes y una comunidad mundial; se reúnen para compartir y aprender de Agilidad y todas sus expresiones.

A la distancia, estuve siguiendo de cerca el Agile 2016; a través de las redes y de las cuentas personales de varios amigos quienes tuvieron la oportunidad de asistir. Me llamaba mucho la atención sobre el contenido intelectual del evento; las charlas, los temas, las tendencias y demás. Cada día me ingresaba al programa del evento a intentar capturar las presentaciones (algunas veces con suerte, otras no) ó navegando el hashtag #Agile2016 para revisar las fotos y hallazgos de las charlas que habían transcurrido durante el día. Las charlas que más me llamaron la atención las estaba registrando en un excel para poder verlas más adelante.

Al final del evento me preguntaba: «Y bueno, ¿de qué se habló más?, ¿qué tracks fueron más populares?, ¿cuáles fueron los tracks con más charlas?, ¿qué charlas se dieron en un track determinado? ¿cómo puedo consolidar todo y accederlo fácilmente?». A pesar de que toda la información está en Sched (la aplicación donde se plasma el programa completo); no podía consolidar fácilmente…y se me ocurrió crear una visualización para aquello a partir del excel que estaba llenando (copiando una a una cada charla del sitio web):

Antes que nada déjenme comentarles que no soy un profesional diseñador de dashboards, visualizaciones o Tableau, así que disculpas a los que sí saben de estas cosas 🙂

Mis hallazgos

277 charlas aproximadamente: muy buena producción

Es mejor decir alrededor de 277 charlas, porque las Lightning Talks no se muestran individualmente (fueron agrupadas en dos espacios durante los días del evento); y porque siento que hay charlas repetidas; algunas que tienen casi el mismo nombre, pero al final hay algo que las diferencia; por ejemplo:

Unlocking Innovation in Product Discovery – Deuxième Partie (Dion Stewart)

Unlocking Innovation in Product Discovery – Première Partie (Dion Stewart)

Misma charla, mismo autor; pero una sesión diferente, incluso en días diferentes (quizás haga falta una revisión Data Cleaning o Data Quality). Independiente de esto, más de 270 es una excelente producción que reafirma que Agile 2016 es el evento más grande del planeta.

«Enterprise Agile» fue el tópico más conversado en Agile 2016

En función del número de charlas, los cinco categorías más habladas fueron:

Entreprise Agile (27 charlas)
Culture collaboration & Teams (24 charlas)
Experience Report (23 charlas) (aunque ésta es un formato de charla más que una temática; dentro de esta categoría en realidad hay mucho de Enterprise Agile, Culture collaboration & Teams, Project Program & Portfolio Management y Working with Customers, aunque no fueron clasificadas así).
Leadership (23 charlas)
Project Program & Portfolio Management (21 charlas)
Coaching & Mentoring (20 charlas)

Y me voy a permitir incluir Coaching & Mentoring, ya que si separamos las charlas del track Experience Reports (por lo comentado anteriormente), pues es el siguiente en relevancia.

Enterprise Agile es el tópico más conversado en Agile 2016, algo que en verdad me esperaba. Indica una fuerte tendencia hacia abordar problemáticas reales de grandes empresas con Agilidad.

Tras los temas empresariales, los temas técnicos fueron los más populares

Casi en un empate tenemos:

Development Practices & Craftsmanship (19 charlas)
DevOps (18 charlas)

Interesante, hace uno y dos años atrás el escenario era al contrario, se hablaba mucho de aspectos y prácticas técnicas de ingeniería; más no tanto de temas empresariales. Refleja un cambio en la tendencia de la Comunidad.

«Learning», un tema que se consolida

El tópico Learning (18 charlas) está enfocado a explorar conceptos y prácticas con el propósito de mejorar el aprendizaje a nivel individual, equipos y organización. Me llamó mucho la atención la inclusión de temas relacionados a: Neurología, dinámica del cerebro, mindset, aspectos de comportamiento, dinámica social e incluso sobre el humor. Y esto me encanta en verdad. Me indica que existe una conciencia creciente en los agilistas de comprender estas dinámicas humanas para lograr cambios sostenibles más allá del método.

Testing & Quality, Working with Customers, UX y Government: empate técnico

Un 40% de charlas dentro del track Testing & Quality exploraban el tema desde una perspectiva técnica (automatización, pruebas de exploración, pruebas de APIs, y así por el estilo). Junto con las charlas de DevOps y Development Practices & Craftsmanship; hacen relevante el contenido técnico dentro del evento. Según este dato, un aproximado de 8 charlas (de 277) enfocadas a presentar Calidad en un sentido amplio más allá del aspecto técnico; bajo para mi gusto.

Junto con Working with Customers (temas de Product Ownership, Product Management y prácticas de colaboración con Cliente), UX y Government; están en el tercer puesto en cuanto a contenido. Sin embargo, me llama mucho la atención de un crecimiento de charlas relacionadas a la aplicación de agilidad en empresas de Gobierno, lo que demuestra una penetración interesante en un sector muy complicado; es difícil pero se puede.

Se habló muy poco sobre el Futuro de Agile

El track The Future of Agile Software Development (IEEE Software) sólo con 5 charlas, intentaba explorar las tendencias sobre Agile en el Desarrollo de software y en general. Pienso que quizás el nombre del track estuvo muy ceñido a desarrollo de software lo que pudo ocasionar que hubieran pocas charlas que se pudieran encajar en el track; debido a que Agile es más grande que desarrollo de software y más si hablamos sobre el futuro. Me hubiese gustado ver más conversación y contenido sobre el tema. No hay que perder la vista de cómo va la industria.

Un evento balanceado

Aunque existió una mayoría numérica de charlas en ciertos tracks que hacen que hayan sido los más discutidos, en realidad fue un evento bastante balanceado en contenido, temáticas y estilos de charlas. Un mérito del equipo organizador y por supuesto de la comunidad participante.

Saque sus propios hallazgos

Obviamente, los hallazgos comentados arriba son mi apreciación personal. Cuando estaba diseñando estas vistas lo vi como algo de mi uso para poder comprender lo sucedido en el evento y resolver mis propias inquietudes personales, sin embargo; espero en realidad que le sea de utilidad para hacer su análisis y localizar el contenido con mayor facilidad. Espero hacer lo mismo para Ágiles 2016…veamos cómo nos va!

Espero me comparta sus apreciaciones con respecto al evento. Gracias por leer y sus comentarios.

Un abrazo!

Johnny

El problema con las estimaciones no son las estimaciones

junio 15, 2016junio 17, 2016 / Johnny Ordóñez / 6 comentarios

Captura de pantalla 2016-06-15 a las 6.35.01 p.m.

“La propia palabra ‘estimación’ deja en claro que no calculamos un valor exacto, determinístico. De hecho, toda estimación tiene supuestos, y estos supuestos suman incertidumbres.” – Carlos Fontela, Estimaciones y Estadística, CyS Ingeniería de Software (2007)

Hola! Por favor permítame expresar mi opinión con respecto al tema de las estimaciones, y #NoEstimaciones. El problema con las estimaciones no son las estimaciones. Las estimaciones son sólo eso, aproximaciones sobre la magnitud de algo. No son valores determinísticos que buscan exactitud sobre el sujeto de la estimación. Bajo este contexto, no existen «estimaciones equivocadas».

El problema con las estimaciones (Estimates) -sobre todo en el ámbito del desarrollo de software- es que se usan como fechas de finalización de los proyectos (deadlines), sobre las cuales se asocian costos y se asignan equipos para lograr cumplir un alcance que por naturaleza es variable, en un entorno complejo completamente alterable en función de los cientos de factores que provienen de la misma naturaleza del desarrollo de software y de la naturaleza de lo que queremos construir. Complejidad.

Sin embargo, el proceso de estimación (Estimating) desde mi punto de vista es útil. Y aquí hago una pequeña pausa para resaltar la diferencia entre Estimating (la dinámica de estimación) y Estimates (los valores resultantes de la dinámica de estimación). Quizás tengamos un problema en castellano, ya que ambas tienden a traducirse como lo mismo: «estimación» o «estimaciones».

Desde mi punto de vista, el proceso de estimación es un ejercicio de entendimiento compartido durante el cual los participantes descubren y discuten aspectos que les permite comprender en mayor medida los desafíos de la construcción de lo que estén estimando. Por ejemplo -muy popular dentro del contexto Scrum-, cuando Usted observa a los equipos en una dinámica de Planning Poker, lo valioso es la discusión que se genera frente a la percepción de la complejidad de la cosa a construir y no por el número en sí mismo. Las estimaciones (estimates) pueden ser útiles o no, más el proceso de estimación es valioso.

“Una buena estimación es aquella que provee una visión de la realidad del proyecto suficientemente clara como para permitir a un equipo decidir correctamente cómo controlar el proyecto de modo tal de cumplir sus objetivos”. – Steve McConnell, Software Estimation: Demystifying the Black Art

Las estimaciones (Estimates) pueden ser expresadas en la unidad que el equipo acuerde: pueden ser horas, pueden ser puntos de historia o pueden ser bananas. Más adelante veremos cuántas bananas nos comimos en una unidad de tiempo. Son simplemente etiquetas de equipo que nos facilitan el proceso mental de comprender qué significa una banana.

El verdadero problema es enfrentar la necesidad de «predictibilidad»

Imagine que Usted llega a la cola en una oficina de su banco (a veces es necesario ir allí hasta que tengamos una banca totalmente digital). Entonces Usted llega a la cola y puede apreciar que hay varias personas antes que Usted. En ese momento le llama su esposa y le pregunta: «¿En qué tiempo te desocupas? Mira que tenemos que ir a donde mi mamá.»; Usted responde: «Okay amor, en esto momento no puedo hablar porque estoy en el Banco, pero ya te escribo por Whatsapp o algo.»

Cuelga y se dice a así mismo: «Vamos; soy ingeniero, trabajo en proyectos, también sé algo de ágil…esto no debería ser un reto para mí…» y comienza. Recordará sus años de Teoría de Colas y dirá: «Ley de Little!!…claro». El tiempo promedio de espera en la cola es igual al número promedio de personas en la cola dividido para el tiempo promedio de atención. Ya está! Cuenta: hay 20 personas antes que Usted, toma el tiempo desde que una persona llega a la caja hasta que sale (digamos 3 minutos) y listo, matemática simple: 20 personas + Usted (21 personas) / (1 persona cada 3 minutos) = 63 minutos, aproximadamente.

Pero espere, antes de que escriba a su esposa por la respuesta recuerde algo; el señor Little decía antes: «En un sistema estable el tiempo promedio de espera es….blah, blah.». Un sistema estable, ¿qué significa? Serían 63 minutos si todas las personas realizarían el mismo tipo de transacción exactamente, y que la persona en la caja se demore exactamente ese tiempo de atención por cada transacción sin cansarse. Además, pasan cosas: «se fue el sistema!» (muy típico al menos en mi país), es el descanso de la persona en la caja, lo reemplaza otra persona que está aprendiendo a usar el sistema, una persona se cuela por la parte de adelante, se va la energía eléctrica, habilitan una nueva caja, etcétera.

En otras palabras: Variabilidad. Variabilidad interna y externa al sistema. Estos y otros posibles cientos de factores que influyen en el comportamiento general del sistema. Con los equipos ágiles es muy similar, la diferencia es que estos factores pueden ser muchos pero en verdad muchos más.

Imagine que el siguiente gráfico representa la Velocidad de un equipo ágil en el tiempo:

Captura de pantalla 2016-06-15 a las 6.14.54 p.m.

Fíjese que en los primeros sprints la distancia entre su mejor velocidad histórica (la línea superior del rango) y su peor velocidad histórica (la línea inferior del rango) es más ancha; y a medida que el equipo corre sprints, esta distancia tiende a estrecharse. Esto es gracias a varios motivos, pero obviemos eso por ahora. Estamos tranquilos allí en la oficina y nos hacen la pregunta típica: ¿y en cuánto tiempo estará la feature X si trabajamos con el Equipo 1? Vale, hagamos el ejercicio de proyección:

Captura de pantalla 2016-06-15 a las 6.23.03 p.m.

En función de su desempeño histórico, podemos deducir un rango de fechas en el que equipo puede entregar la feature: entre la fecha X y Z; y podemos contemplar escenarios: en un mejor escenario la fecha X, en un escenario esperado la fecha Y, y en un escenario pesimista la fecha Z. El rango de fechas será más grande mientras más temprano en el tiempo tome su desempeño para proyectar (más alta es la varianza). Entre más estrecho el rango, la probabilidad de entrega es mejor.

Pero no se olvide, complejidad y variabilidad: ¿este equipo conoce el dominio y las tecnologías de implementación?, ¿ha trabajado antes sobre esto?, te comento que la mitad del equipo se va de vacaciones por esa época, etcétera. Variabilidad externa e interna. No hay ciencia exacta.

Entonces, ¿qué le decimos a la esposa?: «Amor, ve avanzando…allá te veo.» 🙂

¿Quiere ser predecible? Reduzca la variabilidad

Hay que reconocerlo: no se puede ser predecible en contextos complejos y sujetos a variabilidad como el desarrollo de software; entre más complejo el sistema y más elementos que añadan variabilidad menos preciso seremos. Es la realidad.

Si queremos lograr un mejor nivel de predictibilidad debemos trabajar sobre la variabilidad. La variabilidad interna (al alcance del equipo):

Reducir el batch size (reduzca el tamaño de los ítems de trabajo o Historias)
Revise el tamaño de la cola (ítems en el backlog)
Clasifique el trabajo (tipos de ítems de trabajo)
Establezca restricciones WIP (en cuántos ítems podemos trabajar en función de nuestra capacidad)
Enfocarse en generar flujo
Identificar cuellos de botella y supeditar el flujo a las restricciones
Equipo cohesionado trabajando junto durante un tiempo, no lo desarme
Otros.

La variabilidad externa (más difícil y a veces fuera del alcance del equipo):

Evitar distracciones organizacionales
Evitar multi-tasking o trabajar en varios proyectos al mismo tiempo
Contar con ceremonias de sincronización y alineamiento
Mucho feedback con Clientes y Stakeholders, entre otros.

Y nada, las cosas pasan…no se puede contener todo y no sabemos lo que sucederá hasta que pasa.

Con respecto a #NoEstimates

#NoEstimates es una perspectiva -y movimiento- que se enfoca en medir la entrega real de valor, por sobre obtener «medidas» a piori para saber cuánto trabajo se puede realizar y en qué tiempo. Es decir, en lugar de ponernos a obtener estas medidas (estimates), mejor hagamos el trabajo, entreguemos y luego sabremos realmente cuánto hicimos. En este contexto, las estimaciones (estimates) son desperdicio («waste» desde el punto de vista Lean). De acuerdo, como mencioné: el número en sí mismo no es lo importante; más no así el proceso de estimación. Para #NoEstimates tanto el proceso y el resultados son desperdicio; yo simplemente discrepo con respecto al proceso. El proceso de estimación -independientemente del número obtenido- puede ser valioso para los equipos.

Pensamientos finales

A modo de resumen:

Las estimaciones (Estimates) pueden ser útiles, pero es mucho más útil contar con la información histórica de entrega real.
El proceso de estimación es un proceso de entendimiento compartido, ayuda a comprender la magnitud del problema, identificar riesgos y llegar a consensos.
El problema no son las estimaciones, es problema es enfrentar la necesidad de predictibilidad.
Los sistemas complejos poseen variabilidad, a mayor variabilidad peor predictibilidad. Nunca será 100% predecible, abrace la variabilidad.
Si desea ser predecible -en la medida de lo que eso signifique- entienda y trabaje con la variabilidad interna y externa.
#NoEstimates en un enfoque hacia medir el valor real logrado en lugar de obtener cosas medidas a priori, no podría estar más de acuerdo.
Nunca deje esperando a su esposa…o a su suegra 🙂

Gracias por leer y por sus comentarios.

Johnny

Referencias

Evitando la seducción de la herramienta

marzo 5, 2016marzo 5, 2016 / Johnny Ordóñez / 6 comentarios

seduction-2

Durante mi charla en Ágiles 2015 presenté una lámina para ilustrar un par de conceptos interesantes tomados del libro High Altitude Leadership de Chris Warner and Don Schmincke relacionados al cambio organizacional y a los desafíos de los Líderes de Cambio. De entre ocho peligros a los que se enfrentan los líderes en busca de sobrevivir a la escalada de la montaña, quiero enfocarme en este post en el peligro #3: la Seducción de la Herramienta.

La imagen a continuación -que es mi representación del entendimiento de estos conceptos del libro- muestra de forma sencilla los aspectos que afectan al comportamiento organizacional y su influencia en la cultura, básicamente es otra forma de representar la dinámica de la cultura organizacional.

High Altitude Leadership

Conocemos que nuestro sistema de creencias influencia nuestro comportamiento: nuestra conciencia de identidad, el cúmulo de valores y principios inculcados en nuestra infancia, lo aprendido de nuestros padres y la sociedad. Pero no es lo único que afecta el comportamiento. Dentro del contexto organizacional, el «Qué» –representado como la estructura o jerarquía actual, el enfoque de planificación, establecimiento de objetivos, la definición métricas y su objeto de medición– más el «Cómo» –que son los procesos, políticas y mecanismos actuales de a través la organización ejecuta– influencian fuertemente y dibujan un comportamiento. Ambos definen la forma de cómo viaja la información y cómo se interpreta.

Lo que se espera es que a través de este comportamiento se generen resultados, y que estos sean cada vez mejores para el bienestar de la organización (y su supervivencia). Entre el comportamiento y los resultados normalmente se usan herramientas que sirven de «habilitantes» (enablers) que brindan soporte durante la ejecución y al posterior cumplimiento de objetivos.

¿Qué es la Seducción de la herramienta?

«Las herramientas ofrecen esperanza, y hacen sentir a las personas que tienen la respuesta correcta. Pero hay problemas cuando los empleados usan las herramientas como muletillas para tener respuestas seguras. Ambos, escaladores muertos y compañías en banca rota fueron encontraron agarrando grandes herramientas.»

– Chris Warner and Don Schmincke, High Altitude Leadership

Es ser seducido por la ilusión de que la herramienta produce resultados en lugar que las personas. Es pensar que la herramienta en sí misma es la solución; es cuando la herramienta nos deslumbra, nos impresiona, nos «enamoramos» de ella. El problema radica en que fácilmente se puede perder la perspectiva y dejar de pensar en el propósito, la problemática y el contexto general. En muchos situaciones, sobre todo en grandes organizaciones, se tiende a pensar que entre más cara o sofisticada o completa parezca ser la herramienta ésta es mejor.

Esto normalmente sucede cuando las últimas herramientas para el cambio organizacional, desarrollo de liderazgo, mejora de procesos, métodos de gestión -y por supuesto, frameworks para la adopción de Agile a nivel empresarial- distraen nuestra atención de los aspectos vitales. En lo relacionado a Enterprise Agile, no se trata de la adopción de un framework específico, sino de lograr la agilidad del Negocio (y un poco más allá).

Algunas evidencias de que esto está sucediendo en la organización incluyen:

Equipos trabajando para la herramienta en lugar de la herramienta trabajando para los equipos;
Contar con mucha información nueva e interesante pero irrelevante;
Síndrome del «Consultor de la Semana» (uno más experto que otro en la herramienta);
Nuevas ideas pero sin la capacidad de producir resultados;
Muchas reuniones inútiles;
El cumplimiento de tareas se confunden con resultados.

«En montañismo, la seducción de las herramientas ponen en peligro a los escaladores cada vez que se visten con la mejor ropa y últimos equipos, pero que aplican comportamiento y técnicas equivocadas para el desafío. En su exceso de confianza (o novatada), terminan perdidos durante días en una pendiente devastada por una tormenta, mientras que los escaladores experimentados están en el campamento base tomando cerveza y viendo el clima. Del mismo modo, el peligro de un ‘desfile de expertos’ empaquetando y vendiendo las últimas herramientas pueden distraer a los equipos.»

– Chris Warner and Don Schmincke, High Altitude Leadership

La herramienta adecuada para el problema adecuado

«Un tonto con una herramienta sigue siendo un tonto.»

-Grady Booch

Por supuesto, las herramientas son importantes; pero deben poder usarse inteligentemente y mucho de esto radica en identificar el problema correcto. Imagine que le pido pintar un paisaje en una hoja de tamaño A4; se podría usar lápices o crayones o acuarela y pincel (mi hija es una profesional en esto). Imagine ahora que le pido pintar un paisaje en una pared de 25mX8m, si bien es cierto que podría usar pinceles o todo lo anterior, pero puede ser más efectivo usar una brocha o un rodillo o un soplete, o los tres; y esto no significaría que un rodillo es mejor que un pincel; cada una es útil en el contexto apropiado.

Lo mismo ocurre con los frameworks para escalamiento de Agile (LeSS, DAD, SAFe, Nexus, Scrum, etc.). Cada uno ofrece mecanismos interesantes que son más útiles para ciertos contextos, y muy probablemente pueda usar elementos de más de uno. El punto clave del asunto es identificar cuál es más adecuada para el contexto actual y cómo puede aportar efectivamente al cumplimiento del propósito: Agilidad Empresarial. Scaling Agile no es igual a Enterprise Agile. Enterprise Agile responde a buscar Agilidad en el Negocio, Agilidad Organizacional y Cultura Ágil viva. Por lo que la adopción de frameworks son simplemente formas de apalancar a los equipos en la consecución de este propósito, de lograr pintar la pared.

¿Cómo evitar la Seducción de la Herramienta?

«De la misma forma que la música proviene del músico y no del instrumento; Agilidad proviene de las personas y no de los frameworks.”

-Johnny Ordóñez

Algo que me gusta del libro es que provee «tips de supervivencia» para evitar estos peligros. Para este caso: enfocarse en el comportamiento y en la adaptación; esto es centrarse en la generación de resultados desde una perspectiva de comportamiento. Enfocar el propósito, identificar problemáticas y contextos, la toma de decisiones apropiadas en base a hechos, generación de acciones coherentes.

No importa cuando se invierta en libros, entrenamientos, certificaciones, reuniones, etc.; todo es una pérdida si los equipos no adaptan su mindset, comportamientos y acciones consecuentemente. Si bien, el entrenamiento en las herramientas conlleva a su mejor uso, la clave es no perder de vista que el propósito es escalar la montaña, no sólo saber a hacer nudos. Así como los Líderes de Gran Altitud, los Agile Coaches deben tenerlo presente; sea fuerte y no se deje seducir :).

Gracias por leer.

Johnny

Referencias:

Escalando el Índice de Felicidad

febrero 10, 2016febrero 10, 2016 / Johnny Ordóñez / 6 comentarios

Medir la felicidad es algo complicado. La felicidad es algo abstracto e íntimamente ligado al aspecto personal, es difícil establecer un valor determinístico que permita concluir «qué tan feliz» se siente alguien. La felicidad es una elección consciente más que una respuesta automática. Sin embargo, dentro de las técnicas aplicadas por los equipos ágiles, existen interesantes herramientas para obtener información relacionada al estado anímico de los equipos y su satisfacción en el contexto laboral. En este sentido, el Índice de Felicidad se concibe como una medida organizacional de la percepción de satisfacción y motivación de los equipos ágiles.

¿Por qué medir la Felicidad?

«El Compromiso de los empleados es un imperativo de negocio; este es el eje fundamental entre la estrategia y los resultados de negocio.»

– Trends in Global Employee Engagement, 2013

1. Agile es acerca de personas

La Agilidad proviene de las personas, no de los frameworks (Scrum, SAFe o cualquiera). La Agilidad vive en los equipos y florece gracias a un entorno de confianza, transparencia y colaboración auténtica. El impacto de la motivación y la satisfacción de los empleados se ha venido estudiando con atención desde hace un tiempo. A continuación algunas cifras al respecto recopiladas por compañías como Gallup y otras:

Cifras sobre la Motivación en el trabajo

Cifras sobre el Impacto de la Felicidad en el Negocio.

La Felicidad es un asunto serio. Preocuparse por la motivación y el bienestar de las personas es un reflejo de la mentalidad ágil, de un nuevo estilo de gestión, de una práctica saludable y recomendable para Líderes de Servicio, Coaches, Managers, área de Talento Humano y otros.

2. Permite medir promesas de Adopción

En un proceso de transformación ágil en el que participé utilizando SAFe como framework referencial, uno de los desafíos al que nos enfrentamos fue el de cómo medir la «Promesa SAFe» expresada en el siguiente gráfico:

Resultados de Negocio de SAFe – SAFe Foundations

SAFe ha podido obtener estos datos de sus varios casos de estudio documentados. Con relación al engagement de los empleados, sus cifras están alrededor del 10% de incremento. Las preguntas fueron: ¿y cómo lo midieron? ¿y cómo lo medimos nosotros?. El Happiness Index resultó una herramienta útil para este contexto. (Para los otros aspectos, espero publicar pronto algo que puede servir; tema de otro post.)

3. Información que permite enfocar acciones de mejora sobre los equipos

Información valiosa que le permite a Scrum Masters, Coaches y Managers; enfocar acciones sobre aquellos equipos que necesitan mayor atención y protección. Sirve para indagar sobre las causas de su estado anímico, conversar, identificar problemas y actuar en busca de mejorar el bienestar de los equipos.

Se me ocurren otras razones, pero quizás estas sean las más importantes.

Mecanismos para medir la Felicidad

He leído de varios; desde el uso de aplicaciones en nube, encuestas de Google Docs y hasta el conteo de pelotas de tenis; todas muy interesantes.

Algunos mecanismos para medir la Felicidad

Más que las herramientas, siempre me ha gustado que este tipo de actividades sean muy lúdicas y divertidas; entonces me gustan más herramientas empleadas en Retrospectivas. Dos de las que más me gustaron fueron el Happiness Profit de mi gran amigo Hiroshi Hiromoto y la variación del Happiness Radar de mi otro amigo Paulo Caroli de su libro Fun Retrospectives.

Happines Profit y Happiness Radar – Técnicas para Retrospectivas

Debido a la información relacionada a varios aspectos, el Happiness Radar fue la elección que tomamos junto al equipo de Scrum Masters. Lo personalizamos y aplicamos en cada retrospectiva para los equipos.

El Happiness Radar de la Retrospectiva de un Equipo

Equipos en Retrospectiva – Happiness Radar

Escalando el Índice de la Felicidad

1. Recopilación de la Información

Nos pusimos a trabajar y ensayamos nuestro primer sprint con la nueva técnica. Luego de la recopilación en la herramienta física, cada Scrum Master la pasaba a un excel que diseñamos para este propósito, un archivo por equipo.

Archivo de Registro del Radar de la Felicidad por Equipo

Cada archivo era subido a un repositorio de donde una macro en Excel leía la información y la consolidaba en un archivo que unificaba la información de todos los equipos. La periodicidad de medición fue de cada sprint (cada dos semanas). Teníamos que establecer un nivel de automatización para que el proceso sea repetible y que no se constituya una tarea que demande demasiado tiempo, volví a programar en macros después de muchos años 🙂

2. La fórmula

El Happiness Radar es un mecanismo de conteo, es decir simplemente cuenta la personas con un estado anímico sobre un aspecto particular. La idea fue obtener un indicador que represente de la mejor forma la sensación de todo el equipo. Entonces, me basé en la fórmula del Net Promoter Score, usada comúnmente para medir la satisfacción de Clientes sobre un servicio o producto.

Fórmula del Índice de la Felicidad

La escala es un rango de entre -1 a 1, cuyos valores representan: +1: Equipo Feliz, 0: Equipo Neutral, -1: Equipo Triste. Luego se podría profundizar los aspectos y su valoración.

3. Visualización y Publicación

Quería que estaba herramienta fuera vista y discutida a nivel Ejecutivo y compartida por toda la organización, entonces figuraba en mi mente la mejor forma de presentar esta información, que fuera dinámica, muy visual y al estilo de dashboard o Balance Scored Card y en lo posible vía web. Excel no me iba a ayudar mucho por lo que recordé esta fantástica herramienta (con versiones gratuitas) para la elaboración de vistas y análisis de datos: Tableau nos salvó; así que me puse a «monear» (término ecuatoriano que significa explorar algo sin tener la certeza de lo que realmente estás haciendo, hacer monadas).

La herramienta debería contestar varias preguntas:

¿Cuál es el nivel de motivación general de la compañía?
¿Cuál es el equipo más “feliz” o motivado?
¿Cuál es el equipo más triste?
¿Con qué aspecto están más descontentos?
¿Cuál es la tendencia de la felicidad en el tiempo?
¿Qué equipo o equipos necesitan mayor atención?

De esta forma, el diseño de vistas debería responder de forma rápida estas cuestiones. Luego de mucho café y varios tutoriales en línea, logré crear algo como esto:

Happiness Index Dashboard

Puede explorarlo en línea en este link.

4. El proceso resumido

A modo de referencia, el resumen del proceso en la siguiente imagen:

Proceso de Consolidación y Publicación del Índice de la Felicidad

Analizando la Información

1. ¿Mayor Felicidad = Mayor productividad?

Al principio la iniciativa de medir la felicidad fue vista como algo muy romántico, muy abstracto. Obviamente no era muy común escuchar de esto y no se había intentando algo similar antes. Si bien es cierto, se tenía en mente como algo que permitía medir la «Promesa SAFe», el staff Ejecutivo no veía mucho valor…hasta que resaltamos lo que decían los estudios: «Un empleado feliz es más 31% productivo». Recuerdan las cifras de arriba. Veía como empezaba a brillar una luz en los ojos de algunas personas.

Nuestra hipótesis fue: «A mayor felicidad mayor productividad». Aunque productividad es un concepto que se presta a discusión, sobre todo hablando de Agilidad (quizás un término del siglo XX como bien lo dijera Ángel Medinilla) el reto ahora es expresar desempeño en términos de agilidad. Como eran equipos Scrum, la respuesta fue muy obvia: «Velocidad» (otro concepto discutible, pero se escapa a este post). Al inicio no me gustaba usar la Velocidad, pensaba en que se prestaría a comparación entre equipos, y más significativamente uno de los motivos fue que no hay homologación entre los puntos o velocidades de los equipos, es decir, cada equipo tiene su propia definición de qué es un punto y sus velocidades no son comparables. Una de las formas de lograr una comparación más homogénea fue utilizar la Velocidad promedio de todos los equipos.

De esta forma, contrastamos Felicidad vs. Velocidad. Recuerdo que moría de ansiedad por ver los datos, en verdad esperaba que se cumpliera la hipótesis. Pero, oh sorpresa!…no fue así. Encontramos que podíamos tener equipos tristes con mayor desempeño, y equipos felices con una entrega inferior. ¿Por qué? Me rompía la cabeza tratando de encontrar explicación. Investigué y me encontré con el trabajo del Dr. Charles Kerns, PhD por el 2008 y que despejó mi mente.

Lo más interesante fue la siguiente matriz:

Matriz de Felicidad vs Desempeño – Dr. Charles Kerns, PhD

Cada cuadrante corresponde a un grupo que poseen sus propias características y lo más interesante, el autor propone acciones de mejora específicas para ayudar a los equipos en cualquiera de las categorías. Esto fue revelador para mí. Lo discutimos con los Scrum Masters y podíamos enfocar acciones de mejora más claras con los equipos. Compartimos los hallazgos con los managers y los invitamos a generar acciones en conjunto. Estábamos muy felices! La herramienta sirvió en ayudar al crecimiento y bienestar de los equipos. Esto destapó la creatividad de los Scrum Masters, surgieron nuevas técnicas de retrospectivas, más actividades lúdicas, campañas y actividades interesantes para lograr mayor motivación. Gracias equipo! (a Katty, Andrés, José Manuel, Polo, Luis, Ana María, Stephanie y Ximena).

Pensamientos finales

Aprendí mucho de implementar esta herramienta. Espero que este post le brinde la guía y motivación para emprender una iniciativa similar en su compañía, y que por favor me comente cómo le fue. Obviamente, fórmulas, visualización y demás pueden mejorarse; pero más allá de eso, mi mensaje final es que considere el aspecto de la Felicidad como algo importante, y realzar su enfoque hacia cuidar y cultivar le bienestar en sus equipos y su organización.

«Las empresas a menudo se olvidan de la cultura, y en última instancia, sufren por ello porque no se puede entregar un buen servicio con empleados infelices.”

– Tony Hsieh, CEO de Zappos

Gracias por leer.

Referencias

La evolución de SAFe (en imágenes)

enero 21, 2016enero 21, 2016 / Johnny Ordóñez / Deja un comentario

Uno de los aspectos de SAFe que más me gustan es su naturaleza evolutiva. A través del feedback de empresas, consultores, comunidades y practicantes en general, el framework ha ido creciendo, adaptándose, mejorando; hasta consolidarse en la versión actual SAFe 4.0 for Lean Software and Systems Engineering.

Esto es bastante bueno, ya que Agile se trata de eso, adaptación continua en base al aprendizaje. Si bien es cierto, SAFe no es la bala de plata para todos los escenarios ni todas las compañías, a mi forma de ver SAFe brinda un robusto conjunto de valores, principios, patrones y prácticas para llevar agilidad a nivel empresarial, más allá del área de TI y del desarrollo de software. Es un gran inicio hacia buscar la Agilidad empresarial, y tal como lo mencionara Henrik Kniberg; SAFe es un framework en modo Shu.

He podido hacer un tracking de la vida de SAFe en el tiempo y encontré versiones de varios Big Pictures desde el 2008 y de la época en la que SAFe todavía no se llamaba SAFe; desde los antiguos posts de Dean Leafingwell hasta la versión actual:

El pase de diapositivas requiere JavaScript.

¿Qué es lo nuevo en SAFe 4.0?

El nuevo Big Picture de SAFe trae -además de un diseño más sobrio a través de un matizado de grises- novedades interesantes para el escalamiento de Agile. A continuación comento las cosas que más me llamaron la atención:

El nivel de Value Stream

Diferencias entre SAFe 4.0 en 3 niveles y SAFe 4.0 en 4 niveles

Posiblemente lo que más resalta a la vista es la posibilidad de expandir a SAFe de 3 a 4 niveles. Esto tiene una connotación importante, SAFe 4.0 en 3 niveles está diseñado para Value Streams donde el número de personas puede llegar hasta cien; SAFe 4.0 en 4 niveles puede albergar a Value Streams por encima de cien personas y habilita la coordinación entre varios Value Streams de diferente naturaleza, donde no todos están destinados necesariamente a desarrollar software; sino también hardware, firmware, trabajo con proveedores, entre otros.

El Nivel de Value Stream – SAFe 4.0

Este nivel es muy interesante, incluye un enfoque hacia pensar en Soluciones (Solution Intent y Solution Context), nuevo roles, un framework económico para la gobernabilidad, un trío interesante (Value Stream Engineer, Solution Architect y Solution Management), Arquitectura Ágil a nivel de Value Stream, entre otros. Este nivel fue heredado y adaptado desde SAFe for LSE.

Realce de los Fundamentos, Valores y Principios

Esta característica me encanta. En la base de la Big Picture y sobre el costado izquierdo, se hace énfasis en los Fundamentos, mindset y principios, y adicionalmente en el esquema de implementación de SAFe propuesto por los autores. El verdadero camino hacia la transformación ágil empresarial viene de la comprensión e interiorización de los valores y principios más que de la ejecución de las prácticas. SAFe es coherente con los principios ágiles y Lean; los principios del Flujo de Desarrollo de Productos de Don Reinertsen (Second Generation Lean Product Development) y patrones exitosos de transformación ágil como Comunidades de Prácticas y Líderes de Cambio (o coalición de Cambio).

Secciones de SAFe 4.0 enfocado a Valores, principios y prácticas

Por lo tanto, hacer un realce sobre estos elementos invita al lector a profundizar sobre las bases de SAFe más allá de lo detallado en el Big Picture; teniendo en cuenta que su comprensión permitirá adaptar el framework a su contexto y obtener los beneficios esperados.

Kanban en el nivel de Equipos

Heredado también de SAFe for LSE. SAFe brinda flexibilidad a los equipos ágiles de seleccionar el método que mejor se adapte a su contexto y a la naturaleza de su trabajo (entrega iterativa o flujo continuo de valor), y esto es correcto, pues no todo tiene que ser Scrum necesariamente. Sin embargo, los equipos Kanban (sobre todo aquellos enfocados en el desarrollo de productos) pueden tener la necesidad de integrarse a la cadencia a nivel de programa; significa que hay consideraciones a tener en cuenta para logrartrabajar en armonía con los equipos que no son Kanban.

Nivel de Equipos en SAFe 4.0

Hay varios artículos de los SAFe practitioners acerca de la implementación de Kanban dentro de SAFe que vale la pena revisar. Personalmente, he visto muy interesantes los webinars de Allan Shalloway donde habla sobre SAFe Kanban y LeanBan.

Nuevos tipos de ítems en los backlogs

SAFe propone un nuevo modelo para la gestión de requerimientos, incorporando en los backlogs de los distintos niveles nuevos tipos de ítems. En el nivel de portafolio existe el Enabler Epic, que de la versión 3.0 se lo conocía como Architectural Epic. A nivel de Value Stream existen el Capability y Enabler. A nivel de Programa, Enabler (antes Technical Feature). A continuación un resumen del nuevo modelo:

Modelo de Requerimientos de SAFe 4.0

CapEx y OpEx

Esto sí que es interesante. SAFe trae a la mesa la discusión sobre la Capitalización de la inversión que realiza la organización en las iniciativas que buscan lograr los objetivos estratégicos. De esta forma, en la asignación del presupuesto a los Value Streams, SAFe invita al Program-Portfolio Management Team, Epics Owners y Value Stream Managers a pensar en la distribución de los gastos operativos y del propósito de inversión en varios rubros: I+D, software para Venta, software de uso interno, etc. Algo que me ha parecido muy interesante y que deseo ahondar es la discusión sobre la Capitalización de Puntos de Historia de Usuario.

A continuación coloco algunos links donde encontrarán más información junto con mi invitación a revisar más sobre SAFe.

Manténganse ágiles mis amigos. Gracias por leer.

Johnny