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

Valor de Negocio

Blog de Pablo Lischinsky

De qué hablamos cuando hablamos de Valor.

Uno de los factores que nos motivan a los seres humanos, luego de tener satisfechas nuestras necesidades básicas, es el valor que podemos aportar al mundo que nos rodea. Necesitamos que el resultado de nuestro trabajo tenga una retribución o reconocimiento. Además de eso, a muchos nos gustaría que ese trabajo genere valor. Es más: en muchas ocasiones, el trabajo que hacemos no tendría sentido si no aporta valor.

Antes de entrar de lleno a darle un enfoque más cercano a la agilidad o la entrega de valor desde un producto/servicio no sobra abordar el término desde las ciencias del comportamiento humano, que habla de cuatro ejes sobre los que los seres humanos contemplamos el valor: desde el dinero, el tiempo, el impacto y la perspectiva. Aparentemente, después de estudiar la valía que le damos a las cosas, esos cuatro caminos definen en…

Ver la entrada original 1.091 palabras más

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

¿Cuál es el siguiente paso después de Agile? Enterprise Agility

Captura de pantalla 2016-07-20 a las 7.01.44 p.m..png

El camino hacia la agilidad Empresarial. Tras 15 años de la firma del manifiesto ágil, Agile ha dejado de ser algo exclusivo para equipos de desarrollo para convertirse en un imperativo de negocio para compañías que desean mayor agilidad en la entrega de sus productos, competitividad de mercado y satisfacción de sus Clientes. A través de esta charla exploraremos la evolución de Ágil a través de los años, el enfoque de Agile hacia lograr la Agilidad empresarial y el rol de los Agile Coaches en este nuevo contexto.

El día de hoy tuve la fantástica oportunidad de participar en otro #DevHangout con los amigos de DevAcademy.la y la compañía de practicantes ágiles de la región. Muchas gracias por la invitación y las preguntas.

Dejo a continuación los enlaces a la presentación y al video para que puedan revisarlos y comentarlos:

Este es un tema que está despertando con cada vez más fuerza en las Comunidades de practicantes Ágiles; en las organizaciones y grupos de discusión relacionados. No significa que no se haya discutido antes sobre Business Agility o Enterprise Agility (de hecho son tópicos ya explorados de los cuales nos estamos empapando los agilistas); pero es importante comprender que Agile dejó de ser exclusivamente un tema para desarrolladores, construcción de productos o de áreas de TI. A medida que esta conciencia avanza, nos exige como practicantes y coaches comprender estos aspectos desde la perspectiva ágil para ayudar a los equipos y compañías para las cuales trabajamos.

Da mucho para conversar y escribir, pero dejémoslo para más adelante.

Muchas gracias sus comentarios.

Un abrazo!

Johnny

El problema con las estimaciones no son las estimaciones

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