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

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.

imagen-3

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?

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.

600_455191617

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

1

¡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.

cuk4z7jw8aexejl

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.

culcyu6w8aeavbj

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:

balance-masa-maeda

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

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):

Agile 2016 - Talks Analytics (Laptop)

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 CleaningData 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:

  1. Entreprise Agile (27 charlas)
  2. Culture collaboration & Teams (24 charlas)
  3. 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í).
  4. Leadership (23 charlas)
  5. Project Program & Portfolio Management (21 charlas)
  6. 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

Agilistas: Empatía con el Management

2_5

En los procesos de transformación ágil en los que he podido participar, he visto que generalmente las personas en las que se acumula mayor presión generada por proceso -y quizás mayor frustración y “sufrimiento”- son aquellas que pertenecen a la capa media de gestión, el middle-management: gerentes, directores, coordinadores, líderes.

Veamos un par de escenarios. En un proceso de adopción bottom-up, Agile y métodos como Scrum empoderan a los equipos y les invita a desatar todo su talento y autonomía. Toman sus decisiones, definen acuerdos, fomenta el compromiso y el desarrollo de sus habilidades tanto técnicas como de trabajo en equipo. Normalmente, están muy motivados y entusiastas…aunque no se tenga toda la certeza de algunas cosas.

Desde una perspectiva top-down, los beneficios de la Agilidad hacen eco el staff Ejecutivo -Presidentes, Vicepresidentes y altos Directivos. Mejorar el Time-to-Market, incrementar la Calidad, procesos más eficientes, mayor satisfacción de los Clientes, alineamiento y visibilidad, flexibilidad; son cualidades deseables de un negocio saludable en vista de adaptarse, mejorar y crecer. Estos elementos coinciden con las expectativas de negocio y el lenguaje estratégico. Quizás con algo de escepticismo, pero el mensaje es muy bien recibido en este nivel.

De pronto, las personas del nivel medio de gestión se ven en una reunión en la que ya sea, por arriba o por abajo; el mensaje principal es: “Nos vamos hacia Agile!”. Al principio posiblemente no se tenga mucha conciencia de lo que esto significa: “Una metodología más, ¿no?”, pero no pasa mucho tiempo en evidenciarse que la propuesta hace cimbrar los cimientos en la forma de cómo se conciben el trabajo, los proyectos, la gestión; y los propios paradigmas respecto a la ingeniería y dinámicas de equipo; sin hablar de hábitos y de la cultura de la empresa.

Comienza entonces la tensión.

El sufrimiento en la capa intermedia

Enfocándome en los Gerentes de proyecto, al ser responsables por los resultados de la ejecución, sienten la presión de lograr las promesas de negocio sin contar con mucha certeza de cómo hacerlo en la nueva dinámica de trabajo. Y ven poco a poco como muchas de las funciones de las que se encargaban habitualmente se delegan a varios roles encarnados por otras personas (comúnmente): la gestión del alcance, monitorización y métricas, lineamientos de organización de equipos; etc.

Para empezar, en métodos como Scrum no existe de forma explícita el rol de Gerente de Proyectos, lo que hace pensar de que este rol -más no sus funciones-, es innecesario en entornos ágiles. No comparto, pero sí que hay consultores y coaches que así lo manifiestan. Lo mismo sucede con Arquitectos, Directores de Programa, Líderes funcionales, etc. Es claro, Scrum fue creado bajo una visión de trabajo creativo en equipo (no sólo de desarrollo de software), no estaba pensado para enfoques empresariales tradicionales.

Las destrezas y habilidades que hicieron grandes a estos gerentes ya no son requeridas de la forma como la venían desempeñando. La planificación a largo plazo y el levantamiento del detalle temprano no van más, adiós a la negociación del triángulo de acero como lo conocíamos, SRSs, documentos funcionales pesados, análisis y arquitecturas detalladas up-front quedan en el recuerdo. Técnicas, artefactos y métricas comunes (WBS, Gantts, CPI, SPI, etc.) son reemplazadas rápidamente con planes de Release, Burndown charts,  Velocidades, Story Maps, etc. Hay que re-aprender gestión de proyectos de software.

Los consultores y coaches comienzan a cuestionar su lenguaje, hábitos y estilos de liderazgo, “Ya no digas recursos, son personas” (comparto plenamente), algo tan arraigado en la cultura de gestión . Ya no se puede pedir al equipo que se queden hasta más tarde porque vamos atrasados, ahora el equipo decide, etc., etc.

La organización y el mismo Gerente comienzan a preguntarse sobre la relevancia del rol tal como se conocía, y definitivamente debe existir una transformación que tiene implicaciones a nivel funcional y por supuesto a nivel humano. Comienza entonces un estrés más profundo a nivel personal.

Empatía con el Management

¿Podría existir un milagro tan grande para nosotros, que el de mirar a través de los ojos de otros por un instante?

– Henry David Thoreau

Existe un cierto antagonismo entre una gran parte de agilistas y los roles de gestión. También me pasó. Recuerdo mis días de Scrum Developer y de Scrum Master que junto a los demás compañeros del equipo nos quejábamos de ellos y decíamos que deben desaparecer, “No Managers!”, nos auto-organizamos ya no son necesarios, no aportan valor, son dinosaurios, Holacracy y así por el estilo…todo mientras nos tomábamos una cerveza luego de la retro y andábamos en zandalias por todo el lugar. Sí, era divertido, era joven :)…pero les comento, que esto está alejado del propósito real de la Agilidad que es buscar mayor bienestar de las personas mientras entregan valor a través de su trabajo.

Yo no creo que los Gerentes sean malas personas. En verdad. No creo que digan “son recursos” porque vean a los equipos como baterías que se pueden reemplazar cuando se gasten (al menos los buenos Gerentes no lo ven así). Pienso que este lenguaje, mindset, hábitos y demás son producto de su formación y por supuesto de la organización, del sistema. Pienso que al igual que el resto, ellos quieren que el negocio mejore y que la empresa y los equipos crezcan. Se están enfrentando a una realidad que les desafía a re-aprender muchas cosas, crecer profesionalmente y mejorar personalmente…y es nuestra labor como coaches y agentes de cambio ayudarlos a encontrar su camino.

¿Qué se puede hacer? Aquí algunas sugerencias :

Ayúdelos a encontrar su lugar

Los roles y funciones se vuelven confusos en un proceso de adopción ágil, es un momento de transición. Como mencioné, Scrum no muestra de forma explícita un rol de gerencia, sin embargo hay compañías que mantienen el rol. Si existe, ayúdeles a comprender que el paradigma de gestión cambia profundamente con Agile, de Gerentes a Líderes de Servicio; las personas no se gestionan, el sistema se gestiona; ahora son habilitadores para que los equipos fluyan, preocuparse auténticamente en el bienestar de los equipos, entre otros.

Si este rol desaparece de la organización, ayúdelos a identificarse con los nuevos roles y hágale entender las destrezas y responsabilidades requeridas para ellos. Quizás le guste más el tema de ser Product Owner, o se enfoque más hacia el crecimiento del equipo y se convierta en Scrum Master; o sus equivalentes en escala (Product Manager/Chief Product Owner, Chief Scrum Master, etc.). Si usa otros frameworks, invítelos a revisar los roles y ofrezcan la guía necesaria donde con sus destrezas y mentalidad sean apropiados y se sientan a gusto.

Ayúdelos a prepararse

Haga charlas, hable sobre los valores y principios, métale Management 3.0 por los ojos, envíenles información, artículos, libros, hábleles de las certificaciones (muchos agilistas me matarán aquí por el tema de las certificaciones 🙂 ), motívelos a aprender. Ayude a comprender lo subyacente detrás de los métodos. Explíquele los artefactos y ayúdelos a dibujar tableros para sus actividades, a ellos también les gustaría embarcarse en la onda de pegar papelitos y lo demás, apóyelos.

Involúcrelos

Hágalos partícipes de las iniciativas de cambio durante la transformación ágil. Trabaje junto con ellos en alguna de ellas y luego pídales comprometerse ellos solos, o en equipo de directores, como sea. Conviértalos poco a poco en agentes de cambio y en parte del equipo de transformación. Si logra de a poco cambiar su mentalidad y comportamiento, serán faros y guías para propagar la cultura que se desea en la organización.

Evite el “ellos” vs “nosotros”

Intégrelos al trabajo del equipo, invítenlos a las ceremonias y que perciban la agilidad de la mano de los equipos….por supuesto, hable con los equipos para que tengan apertura necesaria y que sean bien recibidos. Discutan los tableros, argumenten de forma sana y genere la cercanía necesaria para hacerlos sentir “parte de”. Ya basta de “los ágiles” y los “no ágiles”.

Acompáñelos

Hágales coaching. Converse con ellos, haga sesiones One-to-One, lleven una bitácora de coaching, entregue consejos para que mejoren sus destrezas personales y habilidades blandas. Ayúdelos a mejorar como Líderes y como seres humanos.

Pensamientos finales

Como agilistas siempre estamos hablando de empatía: empatía con el usuario, UX, Design Thinking y más. Mi invitación es aplicar esta misma habilidad de “empatizar” -e incluso las mismas herramientas y técnicas que usamos en los equipos- con las personas en la mitad del sánduche (¿por qué no?: haga un Empathy Map, cree Personas). Los procesos de transformación ágil representan un cambio trascendental y muy profundo dentro de las empresas, con impacto a nivel organizacional, cultural y personal. Póngase en los zapatos del management, mire a través de sus ojos, sienta con su corazón. Esta capa es fundamental para el éxito de la transición, para obtener los beneficios esperados y para generar la cultura ágil que queremos ver en todas las organizaciones a las que visitamos.

Como dirían acá en Colombia: ¡Hágale mija! o ¡Hágale mijo! 🙂

Gracias por leer.

Johnny

¿Cambiar Comportamientos = Cambiar Cultura?

7029d8a64a79f01fdd34f471dfeadbc1

A medida que se avanza en los procesos de transformación hacia Agile en organizaciones de cualquier tamaño o giro de negocio, se hace cada vez más evidente que precisamente el obstáculo más fuerte al que se enfrenta el equipo de transformación y el proceso como tal, no tiene que ver tanto con el entendimiento del método o framework seleccionado, y más bien este posee aproximaciones hacia índoles humana y sistémica; el tema es cultural. Ya lo decían las encuestas: la habilidad de cambiar la cultura organizacional es la barrera más grande en la Adopción Ágil.

“A nivel de iniciativa ágil, los encuestados citaron a la cultura organizacional o una resistencia general al cambio como las barreras más grandes hacia una adopción ágil, seguido de no contar con el conjunto de habilidades correctas.”

– 9th Annual State of Agile Survey, VersionOne

De aquí que el verdadero desafío consiste en trabajar en influenciar -más que “cambiar”- la cultura organizacional vigente del grupo (equipo, área u organización). Por lo tanto, los miembros del equipo de transformación son Agentes de Cambio inherentemente, y es necesario enfocar iniciativas para lograr figurar una nueva cultura donde la Agilidad florezca en múltiples niveles; una cultura de transparencia, confianza, colaboración y preocupación auténtica por las personas. Y esto por cierto, no es nada fácil.

Y entonces te pones a leer, a comprender y aprender cómo hacerlo. Y en este aprendizaje me he encontrado con un pensamiento compartido por algunos excelentes coaches y amigos que dice: Comportamientos = Cultura. Cambiar comportamientos = cambiar Cultura. Suena coherente en verdad, pero tras mi experiencia y profundizando sobre el asunto, comienzan a aparecer mis conflictos. No creo que esto sea tan simple ni que funcione de esta forma, y pretendo explicarlo a continuación.

El comportamiento es sólo el aspecto visible de la Cultura

En varios procesos de adopción en compañías donde he tenido la oportunidad de participar, comienzan aplicando las reglas del método o framework seleccionado para traer agilidad. Algunos me dicen: “Sí, somos ágiles…aplicamos Scrum y todas las ceremonias y roles”. Entonces pienso, “Okay, veamos más de cerca.”  Al principio cada persona del equipo comienza a ejecutar su rol muy proactivamente, se levantan, responden sus preguntas, una buena ejecución y cumplimiento del método; pero se siguen percibiendo rastros del esquema de pensamiento y actitudes anteriores; ciertas disfunciones y algunas muy sutiles de detectar: el reporte al jefe (que ahora es Scrum Master o Product Owner), personas algo tímidas en comentar los problemas, justificaciones por el no cumplimiento del trabajo, mediciones de desempeño ahora de la forma ágil (Velocity u horas) pero con el tinte tradicional, ejecución mecánica de las ceremonias o prácticas sin la verdadera comprensión del beneficio, entre otras “reglas no escritas”.

Uno de los gráficos que uso con frecuencia para explicar qué entendemos como cultura es la siguiente pirámide basada en el enfoque de William Ouichi, -el mayor precursor de la Teoría Z-:

Agile como una Cultura

Es como un iceberg, lo único que vemos -los comportamientos- es sólo la punta; lo de abajo es más interesante. A pesar de la aparente buena ejecución del framework, los cimientos culturales anteriores se mantienen o se modificaron muy poco. Claro, quizás sólo sea el principio, pero no deja de ser una “agilidad cosmética”, poco profunda. Sin embargo, si se aleja y observa el conjunto, podría apreciar un comportamiento homogéneo en función de lo establecido.

Pensando detenidamente, considere que el comportamiento del grupo -algunas de las disfunciones descritas arriba- son el reflejo de la verdadera cultura imperante; es como el aire alrededor; difícil de señalar pero saben que está allí. Significa que la cultura está lejos de cambiar con sólo la ejecución de prácticas o reglas.

El comportamiento es un resultado

Son nuestras creencias, nuestra formación, nuestros modelos mentales, nuestras experiencias, la sociedad…y en sí, nuestro mindset los que dibujan nuestro comportamiento, y no al revés. Pero no es lo único, dentro del contexto organizacional la forma en cómo se llevan las cosas dentro de la organización, la naturaleza de las tareas, los flujos de información, la estructura y procesos influencian la forma en la que actuamos.

High Altitude Leadership

Cambiar Cultura es trabajar sobre el mindset: Incepción u Origen

Estaba en una de las primeras reuniones con el staff ejecutivo de una compañía para inducción sobre Agile y el framework en específico que seleccionamos. Entre los asistentes, unos de los VPs, el más fuerte de carácter y quien veía con mayor escepticismo el tema de Agile. Todos habían leído al respecto, pero el taller era más que necesario para profundizar.

Queríamos explicar el concepto del Costo de la Demora (Cost of Delay) y realizamos uno de aquellos ejercicios lúdicos con todos los presentes en la mesa, ya saben…comenzamos simulando el flujo tradicional y luego lo enfocamos como flujo de valor y tomamos los tiempos, las variaciones y todo lo demás…y este Ejecutivo tuvo un momento ¡A Ha!, se detuvo a explicarlo porque creo que sentía las ganas de exteriorizarlo y dijo algo como: “es increíble la cantidad de desperdicio que estamos generando”. Al siguiente día, reunió a su equipo de Managers y propuso cambios interesantes. Él comprendió que la forma con la que estaba acostumbrado a trabajar estaba lejos de ser eficiente y que su presión -en el buen sentido de sacar las cosas- estaba generando frustración en los equipos, y lo más importante; el impacto que esto tiene en la economía de la organización. Él cambió su comportamiento y argumentos.

“No es lo mismo conocer algo que comprender algo.”

Okay, ¿recuerdan a Leo Dicaprio en la película Inception / Origen? Acá pasó algo similar, la comprensión de la idea, de los principios detrás de la práctica generaron un nuevo comportamiento. No hubiera ocurrido lo mismo si sólo le decíamos al gerente que establezca WIP contraints en su tablero Kanban o que reduzca el tamaño de los lotes (por ejemplo). El cambio se generó de adentro y se externalizó en un nuevo comportamiento. Lo mismo a nivel de proyecto, hacemos una Inception como una actividad de entendimiento compartido, de identificar y comprender la problemática a resolver, de estar todos alineados, de que salgamos con la misma imagen en la mente de todos.

¿Cómo ser como Leo Dicarpio? Utilice herramientas: SAGAs, StoryTelling, experiencias lúdicas, practique con el ejemplo, module su lenguaje, haga inceptions.

Cambiar Cultura es trabajar sobre el sistema: el qué y el cómo

Una parte del cambio se genera a nivel individual, pero es necesario reconocer que mucho de la cultura en una organización se dibuja a partir del sistema de gestión existente. A grandes rasgos el sistema de gestión está formado por el cómo se hacen las cosas y qué cosas hay que realizar. Los procedimientos, las métricas, procesos de evaluaciones y recompensas, planes, organigramas, estructuras y otros, dibujan la cultura organizacional. No es de sorprenderse que cuando una persona llega a una compañía, poco a poco la cultura de la organización dibuja su comportamiento, la cultura se contagia.

organizational-culture-is-like-an-iceberg-e1422608195987

Para tomar un ejemplo, imagine a las personas de mesas de servicios o atención de tickets de una empresa de servicios a internet; si el esquema de medición está basado en cuántos ticktes pueden cerrar, la persona se enfocará en cerrar la mayor cantidad de tickets como medida de buen desempeño de su trabajo, entre más tickets cerrados y con el menor tiempo de vida es mejor; lo que hace perder el foco de que el verdadero servicio es entregar soluciones a los clientes. Me ha pasado centenares de veces con los proveedores de internet en Ecuador, te piden que llames y generes otro ticket para quejarte; y hablan muy rápido porque quieren despacharte rápido para tomar otro ticket. Observe, sólo la forma en la que se mide el “desempeño” de una persona, generará un comportamiento determinado en aquella persona.

“Culture is no more likely a target than the air we breathe. It is not something to target for change. Culture is an idea arising from experience. Our idea of the culture of a place or organization is a result of what we experience there. In this way, a company’s culture is a result of its management system.”

– David Mann, Creating a Lean Culture

Si realmente se desea crear una nueva cultura organizacional, es necesario cambiar el sistema de gestión. Por lo tanto el enfoque debe ser sistémico, evitar la optimización de una parte y pensar que lo más importantes es la interacción de las partes y cómo fluye la información a través del mismo.

Cambiar Cultura es duro, ésta se defiende

La cultura organizacional es un memeplex. Una linda y acertada analogía que plantea el gran FlowSensei (Bob Marshall). ¿Qué significa? Cada elemento de la cultura organizacional anteriormente mencionado es un meme (y no me estoy refiriendo a las imágenes con textos alusivos del Facebook). Un meme es una idea que se refuerza a sí misma. De los elementos de la cultura organizacional, la idea del correcto Liderazgo, de los roles y estructura existentes, políticas y demás…están allí porque se consideran respuestas correctas a varios problemas. Por ejemplo, he escuchado cosas como: “colocamos managers porque sino los developers no hacen su trabajo”, “generamos actas porque sabemos que no van a cumplir” y cosas similares. Cada argumento justifica su razón de existencia y se refuerza así mismo, generando nuevos paradigmas.

Organizational Culture is a Memeplex

Un memeplex es un sistema de memes que actúan en coordinación (cultura), y se comporta como un sistema inmune hacia elementos foráneos que pretenden cambiar la estabilidad del sistema. El sistema repele los cambios como una forma natural de defensa.

“La Cultura es el sistema inmune de la organización.” – Michael Watkins

Nuevamente, el enfoque es sistémico. Si el equipo de Agentes de cambio se enfoca en sólo un aspecto o sólo en desarrollo de software, la misma cultura se encargará de desayunarse sus iniciativas de cambio haciendo que todo el proceso se deteriore, minando la confianza de la organización y frustrando al equipo. Es vital trabajar con las capas de liderazgo.

Si la Cultura cambia se reflejará en nuevos comportamientos: de mindset a comportamientos, no al revés

Como los comportamientos son un resultado, a medida que el equipo de cambio trabaje sobre el mindset de las personas y sobre el sistema de gestión de la organización en múltiples niveles, los comportamientos cambiarán como consecuencia. Probablemente, cuando vea a los equipos podrá apreciar adherencia al método y cumplimiento de prácticas, pero si se acerca más apreciará que la dinámica del equipo, su lenguaje y comportamientos actúan en coherencia; incluso los equipos pueden cuestionar una práctica en particular y modificarla, porque comprenden los principios detrás, y esto puede que rompa la homogeneidad, pero está perfectamente bien; ya que todos están enfocados en la entrega de valor. Algunos harán StandUps diarias, y otros StandUps emergentes, algunos usarán, Scrum y otros Kanban; no hay problema siempre y cuando todos estén alineados al propósito del proyecto y la organización. El entendimiento e interiorización de valores y principios dibujan las prácticas y el comportamiento; que consecuentemente dibuja una cultura acorde.

Gracias por leer.

Johnny

Referencias

Evitando la seducción de la herramienta

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: