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:
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.
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.
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.
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.
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.
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!
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” 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.
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.
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! 🙂
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-:
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.
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.
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.
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.
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 Schminckerelacionados 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.
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 :).
A medida que SAFe, LeSS, DAD y otros frameworks ganan popularidad, aumenta también el debate acerca del «nivel de agilidad» y la adherencia hacia los principios ágiles de éstos. Decenas de posts circulan en la red y cada framework con sus adeptos. Pero antes de compartir mi opinión permítame contarle algo: soy un fan del Tenis; es mi deporte favorito. Lo practico desde chico, disfruto al jugar y en serio me esfuerzo para mejorar (porque en verdad me falta mucho 🙂 ).
Como todos los fans del tenis tengo varios jugadores favoritos, pero el mejor para mí, sin duda: Roger Federer. Rebosante de talento, dueño de un revés formidable y un estilo elegante. Fuerte concentración y su típica habilidad para leer al contrincante, adaptar su juego y ganar. Un maestro. La herramienta principal de un tenista es su raqueta. Cada tenista usa la marca y el modelo de su preferencia, la que considera que se adapta mejor a su juego. Evalúa el tamaño, peso, tensión, diseño, etc. La de Roger es Wilson, y hay muchas marcas en el mercado. Ahora pregunto:
¿Cuál es el nivel de «tenis-ibilidad» de su raqueta?
¿Qué tan «tenística» es la raqueta marca Wilson?.
¿Es la raqueta la que permite que Roger gane?
Sin la necesidad de ser conocedores del tenis, Usted estimada amiga o amigo lector estará de acuerdo conmigo en que no es la marca de la raqueta la que hace que Roger Federer gane. Es más, la raqueta es lo de menos. Les aseguro que si le damos una raqueta de otra marca a Roger, seguiría jugando brillantemente (aunque podría tomarle un tiempo adaptarse). Cuando en varios posts leo a las comunidades debatir sobre que SAFe no es ágil, que LeSS es súper ágil, que DAD es medio ágil y muchos otros comentarios; sólo leo discusiones sobre raquetas. Sí, pueden ser ejercicios mentales interesantes, de hecho he entablado varias discusiones desde el punto de vista conceptual; pero al final de cuentas NO IMPORTA.
En serio, Usted piensa que Roger Federer se reúne con Rafa Nadal y se ponen a discutir: «mira, el nivel de «tenis-ibilidad» de tu raqueta no es bueno porque le falta esto, entonces tú no eres tenístico». Vamos, claro que no. Son discusiones inútiles. Están discutiendo de herramientas. Puede ser entretenido y aboga a nuestro mindset de ingenieros, muy analíticos tratando de descifrar el punto y la coma; pero de frente al mundo real y a los resultados esperados de la organización, no aportan o muy poco.
Por favor, no dogmatismos
Lo peor que puede pasar es encerrarnos en enfoques puristas. «Pero mira, si el que vela por el Producto no se llama Product Owner, entonces eso no es Scrum», «Que si no hay iteraciones no es ágil». Personalmente critico a aquellos agilistas que desde sus oficinas súper bonitas y abiertas al estilo Google, con mesas de ping pong y en zandalias, van a otra organización donde ven la cosa diferente y dicen: «Ah, es que Ustedes no son ágiles porque no tienen StandUps y no son tan cool como nosotros». Hay una parte del Manifiesto Ágil de la que muchos agilistas se han olvidado:
Estamos descubriendo mejores formas de desarrollar software tanto por nuestra propia experiencia comoayudando a otros. – agilemanifesto.org
Ayudando a otros. Esas compañías «no ágiles» representan más del 90% de las compañías de desarrollo de software (al menos en Ecuador); son a aquellas a las que debemos ayudar. Es allá a dónde debemos llevar agilismo, ayudar a esas personas a mejorar su forma de trabajo, a construir mejor software y hacer una diferencia en la industria. Ahora, también podemos quedarnos en la comodidad del palco de comentaristas y discutir sobre raquetas todo el día. Seleccionar la mejor raqueta no es el propósito ¿Es Wilson mejor que Babolat? ¿Es Head más tenística que Prince? QUÉ IMPORTA!. El propósito no es adoptar una raqueta. El propósito no es adoptar un framework. El propósito es dar lo mejor en el juego siguiendo los principios del buen tenis. El propósito es ganar. No se trata simplemente de adoptar más prácticas XP, iteraciones y microservices por todos lados, ahora todos hacemos Scrum y ya somos ágiles. Llevamos las prácticas a la PMO, Marketing y otras áreas y listo, agilísimos!. No se trata simplemente de llevar agilismo más allá del área de TI (aunque esta sea una consecuencia); se trata de ir hacia la Agilidad Empresarial; desde mi punto de vista en dos sentidos: agilidad del negocio y nuevo mindset organizacional. Agilidad del negocio responde a aspectos:
Estamos mejoramos la Calidad de nuestros productos o servicios, de tal forma que con el menor re-trabajo estamos aumentando la satisfacción de nuestros Clientes y mejorando las ventas?.
Estamos mejorando nuestro Time to Market, de tal forma que entregamos valor al mercado y nuestros Clientes de forma temprana, lo que permite un ROI temprano y mejorar nuestro flujo de caja?.
Estamos mejorando nuestra Predictibilidad de tal forma que somos mejores en Venta y Delivery con menores tiempos de espera?
Estamos reduciendo desperdicios de tal forma que podemos re-enfocar nuestros recursos económicos en innovación u otras áreas de la compañía?
Nuevo mindset organizacional responde a:
Estamos mejoramos la Calidad de vida de nuestros colaboradores de tal forma que recomendarían a sus amigos a venir acá?
Estamos mejorando la Carrera profesional de nuestros colaboradores de tal forma que sienten que trabajan por un propósito y creciendo cada vez más?
Estamos mejorando la Calidad de nuestro Liderazgo de tal forma que fomentamos y habilitamos a nuestra gente a desatar su talento?
Estamos cuidando nuestros Valores y Cultura organizacional de tal forma que nos preocupamos en cuidarla y actuamos de forma coherente con los principios Lean y Agile?
Este es el propósito. Si Usted está pensando en transformar su compañía, prepárese para responder a estas preguntas (sobretodo las del primer bloque 🙂 ). Frente a los resultados el framework es irrelevante.Ganar el juego depende de ti.
La actitud y tu pensamiento son más importantes que cualquier metodología. – Masa Maeda
Imagine que va presenciar un partido de Roger y quiere saber si podría ganar el juego. Entonces Usted hace un análisis de los jugadores, revisa las estadísticas en las últimas temporadas, su desempeño en el tipo de cancha, los partidos recientes, lesiones, etc. ¿Usted podría predecir que Roger ganará el partido?. Difícil verdad. ¿Pero si está usando raquetas Wilson, eso debe servir? 😀 Para nada; ya vimos que la raqueta es lo de menos, no es relevante. No se trata del framework o herramienta que use.
En un partido de tenis hay decenas de factores por las que podría darse un resultado: las condiciones climatológicas, el estado de ánimo de los jugadores, el nivel de confianza, su entrenamiento, su comprensión del partido, el buen uso de la raqueta (sin importar la marca que haya seleccionado) y muchos más. Ahora; Usted desea adoptar, transformar o escalar ágil en su organización. ¿Su éxito depende del framework que use? Difícil saberlo. Dependerá de las innumerables de condiciones de su entorno. No es sencillo. Dependerá de su comprensión y entendimiento de los principios ágiles, del nivel de comprensión de su organización y los drivers de su negocio, del buen uso de las herramientas que seleccione (cualquiera de ellas), de su ánimo y del equipo de cambio que le acompaña, y del liderazgo y cultura de la compañía y muchos más. El éxito depende de Usted. El nivel de agilidad depende de Usted.
Si actualmente está evaluando frameworks para escalamiento de Ágil, le recomiendo no se estrese por encontrar el mejor de todos o el más ágil. Si le recomiendo leer casos de estudio y estar sintonizado a personas que lo estén usando desde la práctica, en las trincheras (nada de ejercicios conceptuales o puristas), hágales preguntas sobre las cosas que le pueden ayudar y obtenga sus propias conclusiones. Si no lo ha intentado aún, le invito también a jugar tenis. Y cuando vaya a elegir su raqueta, no se estrese mucho por escoger la mejor o la que posee mayor nivel de «tenis-ibilidad». Recuerde, ganar el partido depende de Usted; y quien mejor para inspirarse que el propio Roger:
Desde hace un poco más de 3 meses soy parte de una jornada de transformación ágil en una gran compañía de desarrollo de software en Ecuador. El proceso involucra a más 300 personas en 3 países y a todas las áreas de la compañía. Representa precisamente un proceso de transformación que toca el ADN mismo de la compañía en muchos sentidos (estructura, procesos, tecnología, diseño del software, cultura). Cuando me incorporé a apoyar, el proceso ya tenía unos 3 meses de haber iniciado. El consultor que lo lideraba usó el marco SAFe (Scaled Agile Framework) como la guía metodológica y de procesos a seguir. Había leído acerca de SAFe -cuando todavía no se llamaba así- hace un par de años atrás; el libro es muy grande, a veces me dolía la cabeza leerlo y por algún motivo lo dejé. Ahora, era el momento de retomarlo y empaparme profundamente sobre el tema.
Qué es SAFe?
Antes que seguir, quisiera dar una breve introducción acerca de SAFe, ya que es bastante nuevo sobretodo en el entorno ecuatoriano.
Scaled Agile Framework es un marco de trabajo que busca escalar los beneficios y principios de Agile y Lean hacia todos los niveles de una organización: equipos, programas y portafolio; a través de prácticas, roles y herramientas aplicadas para obtener entregas frecuentes de software de valor y calidad, maximizando el beneficio al negocio y permitiendo mayor agilidad organizacional. Es la promesa más grande y el propósito de SAFe.
Como yo soy muy visual, me gustó este video de Inbar Oren -uno de los SAFe Program Consultants estrellas, SAFe Coach y creador de videos oficiales del framework- que explica SAFe en 9 minutos y con dibujitos.
No tenía mucha certeza de por dónde comenzar a describir mis puntos: los que me parecen buenos primero o los no tanto; pero normalmente cuando doy feedback hacia alguna persona siempre comienzo resaltando sus aciertos y luego le describo los puntos de mejora; entonces hago lo mismo con SAFe. Siendo así, las cosas que me gustan son:
El Agile Release Train
Posiblemente una de las propuestas más interesantes de SAFe desde mi punto de vista. El Agile Release Train o ART es un mecanismo a nivel de programa para la entrega de valor en una cadencia definida y constante de un incremento de sistema. El término surge de la analogía de las salidas de los trenes de una estación, las mismas que se definen en rangos uniformes de tiempo y de constante consecución. Cada ART produce un incremento de sistema; donde se integran todas las historias o funcionalidad de todos los equipos que se terminaron y aceptaron por los Product Owners en una iteración. La cadencia definida es de dos semanas, de tal forma que hay una integración de un «Big Working Software» y una revisión con los stakeholders denominada «System Demo».
Algo muy interesante de SAFe, es que la definición de la salida al mercado de un número acumulado de features que corresponde a un tren específico es una decisión de negocio, algo que se denomina «Desarrollo en Cadencia. Entrega en Demanda». Esto habilita a la toma de decisiones por varios roles (Product Managers, Marketing, etc.) basados en costos de oportunidad, time-to-market adecuado, madurez o estabilidad de la versión, etc. Tiene todo el sentido del mundo para mí. En empresas como Spotify lo manejan de forma similar.
SAFe posee también una base filosófica fundamentada en el pensamiento Lean. He leído y escuchado a algunas personas sobre la «casita de SAFe», «la casita Lean», y esta casita es la siguiente:
Básicamente es la misma casa tomada del Toyota Production System. Okay, yo comprendo los pilares y el sentido del pensamiento Lean, lo que quería saber es cómo se expresa el mindset Lean y Kanban dentro de SAFe. A nivel de portafolio se aplica el pensamiento Kanban restringiendo el WIP basado en presupuesto, el mismo que es repartido entre varias cadenas de valor o value streams. Es decir, sólo se pueden trabajar en iniciativas que podamos pagar, «hasta donde nos de el presupuesto?». En la práctica, esto se expresa en el manejo de las épicas de negocio y arquitectura a través de un flujo Kanban; las épicas deben pasar por un funnel donde reciben aprobación por los miembros del Portafolio. Los dueños de la épica deben preparar y «vender» su épica justificando los beneficios para el negocio y para la compañía. Básicamente, de la misma forma en la que un emprendedor explica y vende su idea ante un grupo de inversionistas (o ante un estanque de tiburones, para el caso la analogía sirve).
A nivel de Programa, se aplica Kanban restringiendo al trabajo en base a la capacidad organizacional, traducida por la capacidad de los equipos con los que cuenta la compañía. Esto se traduce a: «cuántas features podemos hacer con la capacidad que tenemos?». Este mindset se expresa en el Release plan y el Roadmap de producto; cuando las líneas de potenciales releases son fijadas por la capacidad (con la cadencia de los ARTs es posible contar con fechas definidas y fijas) y en cada Release Planning se van ajustando para replanificar, repriorizar y ajustar nuestras entregas bajo criterios de negocio. Esto ya venía sucediendo en el entorno Ágil; así que hace mucho sentido para mí y es un aspecto que se mantiene y me gusta.
En general, en todo SAFe siempre se habla acerca de contar con una «vista económica», un término que viene de los principios del Desarrollo del Flujo de Productos, específicamente del libro de Don Reinersten, The Principles of the Product Development Flow; de donde SAFe ha tomado muchos conceptos de gestión de flujos aplicados al nivel de programa (algo que no me sorprende debido a que Don Reinersten hizo un foreword en el libro del cual nació SAFe). Tener una vista económica significa que debemos tomar en cuenta el «costo de la demora» de no sacar un producto o característica al mercado en cierto momento. La idea es, donde el costo sea más alto, eso se debe entregar primero. Para aquello se usa una fórmula denominada WSJF que permite priorizar épicas y features. En el entorno ágil ya veníamos usando algo similar de lo que denominamos el ROI de Agile: Business Value / Story Points. WSFJ es casi lo mismo, pero agrega otras variables en el numerador que brinda otras perspectivas al análisis. Lo bueno de esto, es que se discute otros aspectos válidos para el marketing, el cliente y operaciones; lo malo es que lleva más tiempo estimar y priorizar las épicas/features (más nivel de discusión, más Planning Poker, etc.).
Uno de mis «likes» favoritos. En la última versión de SAFe (la 3.0) se hace relevancia al rol de «champions» que abracen al Manifiesto Ágil y los principios Lean para apoyar al proceso de adopción y tener una jornada lo más satisfactoria. Estos líderes son clave en el entendimiento y aplicación de los principios y prácticas. En SAFe tienen su propio manifiesto con cuatro principios fundamentales:
Tener una vista sistémica: de todas las partes de la organización, el proceso y del flujo de desarrollo del producto;
Abrazar el Manifiesto Ágil: soportar los valores y principios ágiles;
Implementar/Optimizar el Flujo de Desarrollo de Productos: visualizar el trabajo, limitar el WIP, identificar cuellos de botella, ayudar a la mejora continua;
Desbloquear la motivación intrínseca de los trabajadores del conocimiento: ayudar a crear el ambiente y las condiciones para contar con personas auténticamente motivadas y fomentar el conocimiento.
Este último tiene una relevancia súper alta para mi forma de ver, es vital. Este es un plus en SAFe, me gusta mucho que se haya dado esta importancia a este grupo; algo que los agilistas ya conocíamos.
SAFe no nació tal como lo vemos ahora en su Big Picture, ha tenido varias versiones, la actual es la 3.0. SAFe ha venido de un proceso de adaptación y evolución desde los primeros blog posts de Dean Liffingwell hasta consolidarse en la figura que vemos. Gracias al feedback de varios consultores, las empresas que adoptan SAFe y la comunidad, el framework se ha ido adaptando y ajustando; agregando o eliminando elementos sobre la marcha. Pude hacer un tracking de la vida de SAFe en el tiempo y encontré versiones desde el 2008. La primera vez que lo vi no se llamaba SAFe y fue por la versión 2.0 allá por el 2011.
Otro gran plus de SAFe es su Big Picture; puedes ver SAFe en una hoja. Aceptémoslo, es de mucha ayuda. Además de que visualmente es agradable, el Big Picture es como una base de conocimiento interactiva en línea que permite navegar rápidamente sobre los conceptos y profundizar sobre algún tema. Creo que visito este sitio unas cinco veces al día cuando necesito reforzar alguna cosa o encontrar algo que se me escapa. Este Big Picture, junto con los otros recursos: presentaciones, videos, posters, referencias, frases, cursos; son elementos de marketing claves que posiblemente le han dado gran visibilidad a SAFe en los últimos años. Representan una estrategia inteligente de difusión y ventas.
Una de las razones por las que dejé de leer el libro, es que puedo encontrar el contenido más rápido y la información está actualizada (el libro básicamente describe la versión 2.0 y algo de la 2.5).
Yo imprimí el Big Picture y me sirve mucho para el análisis de los puntos de mejora el contexto de la adopción, me ayuda a identificar problemas y priorizar, como dije; soy muy visual.
Los 5 «No me gusta» de SAFe
Pues ahora, permítanme enumerar los aspectos que me generan mucho ruido y que desde la práctica veo que necesitan atención si se está pensando en la adopción de Agile con este framework.
1 día = 1 story point? Qué?
Cuando escuché por primera vez al consultor que decía esto yo dije en voz alta en medio de una reunión: «Qué?» y todo mundo en el salón me quedó mirando raro. Esto para los agislistas es cercano a la aberración. Estamos usando una medida de complejidad para medir tiempo? Es como usar kilogramos para medir distancia. Es impensable, ya que sabemos que no hay una relación directa entre los story points (unidades para evaluar complejidad) y el tiempo. Es decir, 5 story points pueden ser hechos en más o menos tiempo en función de capacidad del equipo: su destreza, conocimientos, experiencia, etc. No hace sentido para mí, así que me puse a leer mucho sobre el tema.
En SAFe existe la necesidad de «normalización». Normalizar significa contar con una medida estándar para poder realizar predicciones a nivel de programa y portafolio. Básicamente, SAFe prescribe usar esta relación de 1 día = 1 story point; si tenemos un equipo de 5 personas trabajando 8 días de un sprint de dos semanas (se resta dos días: 1 Sprint Planning y otro para Sprint Demo y Restrospectiva) tenemos que un equipo cumple 40 puntos por sprint (5 personas x 8 días => velocidad de 40 puntos por sprint). Para lograr eso, se le pide al equipo que imagine una tarea que pueda hacer en un día y a esa se le pone 1 punto (más o menos como los días ideales).
En la práctica, no funciona. Cuando Usted le pregunta al equipo que estime la historia, en sus mentes no están pensando en complejidad, sino automática existe una conversión a horas que luego traducen a puntos. Por ejemplo: «Yo me tardo haciendo esta tarea 16 horas, si 8 horas es un punto, entonces esta historia es 2 puntos»; y peor, como se está pensando en tiempo y no en complejidad se añaden colchones o buffers para evitar equivocarse en la estimación: «Yo me tardo haciendo esta tarea 16 horas, pero por si acaso digamos 3 días. Si 8 horas es un punto, entonces esta historia es 3 puntos». He visto este razonamiento en muchos equipos. Cuando se está comenzando con Agile es contraproducente, ya que brinda una manera sencilla de expresar el mindset tradicional pero con lenguaje ágil; haciendo que no ocurra un verdadero cambio. A la final, le está preguntando lo mismo que antes «cuánto te tardas en esto?» cuando el cambio es «qué tan complejo (complejidad inherente, accidental y tamaño) consideras esto?».
A nivel de programa también hay problemas. Con un estándar de 40 puntos, es relativamente sencillo hacer proyecciones y planificar features. Los cálculos son expresados en fórmulas con esta base, por ejemplo: «si tengo 1000 puntos y 2 equipos que me dan 80 puntos por sprint, entonces los estaré completando en aproximadamente 13 sprints», y otras fórmulas derivadas. Las fómulas no están mal, lo que está mal es considerar la premisa de que cada equipo produce 40 puntos. Es como decir que todos los equipos piensan igual, actúan igual, que son relojes perfectos que entregan siempre lo mismo sin considerar aspectos como el aprendizaje sobre la nueva tecnología, si hay personas nuevas en el equipo, si alguien sale de vacaciones, etc.
Sigo leyendo sobre el tema, pero aún no hace sentido para mí. Cuando se escala Agile es verdad que se necesita normalizar para ayudar al nivel de programa, área de ventas, etc.; pero en mi experiencia previa de adopciones Agile lo que hemos hecho es normalizar el concepto de complejidad a través de un backlog de referencia. Básicamente, creas un backlog con muchas historias tipo que representan varias labores que se generan dentro del contexto de la organización, las estimas con Planning Poker donde se involucran muchos roles (arquitectos, miembros de los equipos, DevOps, Testers, etc.). Con eso, los equipos tienen un punto de referencia para iniciar su estimación, toman la historia de 1 punto del backlog de referencia y contra ese comparan su backlog para ese sprint. Las estimaciones son ajustables cada cierto periodo. Las proyecciones a nivel de programa se realizan tomando en cuenta la velocidad histórica y se eligen escenarios: optimista, esperado, pesimista.
La iteración de Hardening es aquella que ocurre después de una iteración de desarrollo en la que integra y se prueba el desarrollo de todos los equipos con el fin de lograr un incremento del Sistema. Está a cargo de un nuevo equipo en SAFe llamado «System Team«. El producto de la etapa de hardening es un incremento de sistema que se presentará en la System Demo. Esta función era parte de lo que SAFe denominaba la iteración HIP: Hardening, Innovating and Planning; una iteración especial que habilita a los equipos a estabilizar su software y brinda tiempo para organizar hackathons u otras actividades para innovar. Desde la versión 3.0, se separó el concepto de Hardening y ahora SAFe provee una iteración especial IP:Innovating and Planning luego de varios sprints de desarrollo (normalmente después de 4 sprints) para habilitar la innovación en la organización.
En la etapa de Hardening, el equipo de System Team baja el código de todos los equipos en un ambiente separado, integra, genera un instalador de ser el caso y somete al software a pruebas end-to-end (carga, estrés, exploración, algunas UATs). Cuando hay problemas, se reportan bugs que se pasan a los equipos para que los resuelvan. Si el incremento pasa bien las pruebas y es aprobado por los Product Managers, se pasa este incremento a la etapa de Sustaining, entiéndase colocar en un ambiente de pre-producción o producción en el Cliente. De esta forma, SAFe provee una secuencialidad de fases como esta (Planning, Development, Hardening y Sustaining):
Esperen un minuto, esto es parecido a Waterfall no? son pequeñas cascaditas? Lo que se aprecia es que la etapa de Hardening es muy similar a la etapa de Verificación y la de Sustaining es muy parecida a la fase de Despliegue. Esto indica para mi un olor en el proceso, y un olor no tan agradable. La etapa de Hardening tiene buenas intenciones, estabilizar el software antes de colocar en el ambiente del Cliente. Pero en la práctica, tener un sprint de Hardening hace que se difieran acciones de calidad e integración a una etapa posterior, produciendo acumulación de bugs, dificultades en la integración, desafíos en el control de versiones, loops grandes de asignación y corrección de bugs y otros malestares que existen en un desarrollo de cáscada; recordemos. Hace que los equipos piensen: «hay una etapa de detección de bugs más adelante, así que ellos detectarán problemas.». Adicionalmente se refuerza el equipo de System Team con más Testers o personas de operaciones, volviendo al paradigma del desarrollo tradicional. Aspectos de hardening deben ser abordados dentro del mismo sprint de desarrollo y son responsabilidad del equipo. En cada sprint el equipo debe definir, desarrollar, probar, integrar y desplegar su código. El sprint de hardening tiende a ser usado en ambiente donde no existe automatización de pruebas o de integración continua como un nivel de contención. Esto hace que esta fase sea para detectar bugs y no para prevenir bugs, algo que va en contra del Agile Testing.
Una de las cosas que me generó una gran incógnita en la cabeza fue el tema de la ejecución de las retrospectivas a nivel de equipo. Participé en una retrospectiva y dentro de mi mente decía: «qué está pasando aquí?». Para realizar una retrospectiva a nivel de equipo (porque también hay una retrospectiva a nivel de programa) SAFe provee un artefacto que permite evaluar la «salud» del equipo y del sprint (SAFe ScrumXP Team Self-Assessment). Consiste en una hoja de cálculo con varias preguntas agrupadas en diferentes secciones. El voto se hace en una escala de 0 a 5 (donde cero es No cumple Nunca y 5 significa Cumple siempre), el Scrum Master lee una pregunta, recopila los votos de los miembros del equipo, saca el promedio, redondea y coloca el valor resultante en el excel. Al terminar con todas las preguntas, el Scrum Master guarda el archivo y automáticamente se dibuja un radar, lo muestra al equipo y luego se envía el archivo para su consolidación a nivel de programa. Al final de esa reunión todos salieron y yo me quedé sentado durante varios minutos tratando de entender lo que sucedió: en qué momento se habla sobre los problemas? cuándo el equipo se expresa? dónde están los post-its? y los action items?.
La retrospectivas -a mi forma de pensar- posiblemente sean la piedra angular del agilismo mismo. Parte importante de los valores y principios, el corazón de la mejora continua, la expresión de Hansei y Kaizen. El excel me pareció interesante, pero no debe ser el foco de la retrospectiva. Es el momento en el cual el equipo habla, se expresa, se siente escuchado, se discuten los problemas, se comparten risas, es un momento para reflexionar y proponer en equipo, es vital y no estoy de acuerdo que este momento sea opacado por un artefacto.
Imaginen lo siguiente: más de 50 personas en una sala de reuniones, en una reunión de 8 horas seguidas, con mucho calor, escuchando o tratando de escuchar a todo lo que se dice. Resultado: Cerebro frito. Así sentí mi cabeza luego de un Release Planning de ocho horas seguidas, y lo peor es que sólo era el día 1; al día siguiente sería lo mismo. Me preguntaba: un Release Planning de dos días, en serio?. SAFe provee una agenda de dos días para el Release Planning, en ella asisten varios roles: Product Managers, Product Owners, Release Managers, System Team, System Architects, los equipos, DevOps, etc. Debido a que se están planeando todas las features e historias de todos programas para el trabajo de todos los equipos del siguiente sprint, la duración de esta reunión es larga y con agenda definida. Quizás tenga sentido para la primera ocasión, pero aún así la reunión ya es pesada. A esto súmenle que no habían radiadores de información; básicamente todos leían o veíamos la herramienta digital mediante una proyección y se planificaba en la PC. Igual, la Sprint Demo, es una reunión que agrupa a todos los equipos al mismo tiempo para que todos muestren a los stakeholders (POs, Product Managers, Epic Owners, Marketing) su avance del sprint. En ese momento los POs aprobaban o rechazaban las historias y se pasaba al siguiente equipo. Ocho horas seguidas con 150 personas en la misma sala. Después de las dos primeras horas yo ya estaba divagando.
Agile, Scrum y los demás métodos ágiles en general sugieren una comunicación continua, clara, cara a cara. Reunirse para tener estas conversaciones entre los miembros del equipo, con los stakeholders, con el Cliente, etc.; es muy bueno, mucho feedback. Cuando hablamos de un equipo ágil y sus stakeholders, esto no es muy complicado, nos reunimos, conversamos, planificamos y seguimos. Pero cuando hablamos de 20 equipos, más de 100 Devs, 12 Scrum Masters, 12 POs, 5 PMs, 5 RMs, etc.; la cosa se complica y mucho. Desde mi punto de vista esto está lejos de la efectividad. Mucho tiempo de muchas personas todas sentadas viendo una proyección durante más de 8 horas, es algo que no clasifico como comunicación cara a cara. Esto no quiere decir que estoy en contra de las reuniones, todo lo contrario. Pero la reuniones en Agile son facilitadas, con artefactos visuales, muy ligeras pero bien enfocadas, con los interesados correctos. La idea es dosificar; hacer las Sprint Demos con cada equipo y su PO y crear otra reunión entre POs y PMs (algo parecido a Scrum de Scrum pero de Producto), un Release Planning efectivo con un Visual Story Map y los pocos interesados, reuniones de trabajo de los equipos de Producto y otros para llevar el trabajo de Features e historias listas al planning, entre otras. Después de una discusión sobre el uso de post-its y elementos visuales, creamos un Release Plan en la pared y la reunión de planificación se redujo a 4 horas.
Uno de los aspectos de SAFe que posiblemente sea parte de su creciente popularidad en la comunidad y empresas, es que su lenguaje y estructura están diseñados para el mundo empresarial. Hablar a la gente de las corporaciones y el management sobre portafolio y programas pero con un enfoque Agile y Lean es apropiado, hablar el mismo lenguaje ayuda a la comunicación y el apoyo del management es necesario para una proceso de adopción o transformación ágil. Muchos coaches recomiendan manejar el lenguaje apropiado para los niveles y grupos apropiados.
Lo malo de SAFe es que al ver su estructura rápidamente se presta a interpretación y se puede hacer una correlación con las jerarquías y posiciones existentes dentro de la compañía. Cómo se llama ahora al BA? PM, y el PM es el jefe de los POs; el Release Manager o RTE es el jefe de los Scrum Masters; a quién reporta el developer, al Development Manager? y así por el estilo. Incluso la discusión llega a nivel de áreas.
Las jerarquías existen en una organización y entre más grandes son las organizaciones, más grandes y sólidas las estructuras. Lo que me parece que hay que manejar es la percepción de que «tal rol es jefe de otro rol» o que un rol es una posición. Un rol pueden formarlo varias personas dentro de la organización, o quizás no; cada organización es diferente. Este es uno de los desafíos al que nos enfrentamos los consultores y coaches y hay que tener criterio para abordarlo.
Pensamientos finales
Un amigo agilista de Ecuador me preguntó hace poco tiempo: «y esta vaina de SAFe funciona o qué?». Es una pregunta algo capciosa y difícil de responder de forma de Sí o No; similar a si se preguntara qué funciona: Toyoya o Mazda? o una cuchara o un cuchillo?. SAFe es sólo un framework, una herramienta que provee un enfoque referencial sobre cómo llevar prácticas del entorno ágil hacia una organización. Mi respuesta es, depende de cómo la uses. Yo soy muy crítico sobre SAFe, hay que cosas que me generan mucho ruido (y que seguiré publicando); pero en este proceso de adopción estamos tratando de tomar lo mejor, adaptar al contexto y fomentar agilismo verdadero a través de conceptos, principios y prácticas.
El tema en discusión: comprender Agile como un conjunto de valores y principios más allá de un conjunto de prácticas; interpretar si Agile es una cultura o no.
El punto de Allen y Andrew: «Agile es un cultura, no un conjunto de prácticas»
Allen y Andrew explican en sus artículos que un gran grupo de consultores ágiles se enfocan rápidamente en la aplicación y socialización de prácticas o frameworks olvidando lo que en esencia se menciona en el Agile Manifesto. Agile es un conjunto de valores y principios, más que prácticas de desarrollo de software.
El punto del Tío Bob: «Agile es una cultura expresada a través de un conjunto de prácticas»
En respuesta, el Tío Bob explica que la verdadera corrupción de Agile es pensar que las prácticas están separadas de la cultura. Es a través de las prácticas que podemos reconocer una cultura y por lo tanto son inherentes a ella, nos identifican. En tal virtud, Agile es también un conjunto de prácticas.
Esperen un minuto, resolvamos esto primero: ¿Qué entendemos por cultura?
Okay, antes de comentar mi punto de vista al respecto deseo detenerme un momento a comprender lo que es cultura. Hay muchas definiciones (si no me creen vean esta discusión en LinkedIn). Para mí, cultura es como el par de lentes adquiridos a través de los cuales vemos y comprendemos el mundo. Es parte de nuestra memoria colectiva y de la comprensión de nosotros mismos. Cultura es algo que nos une.
Algo que me ha ayudado a comprender mejor lo que es cultura es el trabajo de William Ouchi quien llevó conceptos de antropología a la organización y básicamente define la cultura como una pirámide en cuya base se ubican las creencias y valores, más arriba los modelos mentales y por último el comportamiento:
Esta pirámide es como un iceberg, lo único que podemos percibir inicialmente es el comportamiento de las personas e intuir lo que hay por debajo.
Si hago una relación de Agile con el iceberg tendríamos algo así:
Para mí, Agile es una cultura basada en valores, guiada por principios y expresada en prácticas. La base del iceberg es lo que llamaríamos «Ser Agile», mientras que la parte visible es lo que consideraríamos «Hacer Agile».
Okay, una cultura posee ambos: valores y prácticas; cuál es el problema?
En los procesos de adopción de Agile muchos consultores comienzan profundizando las prácticas: «hagamos TDD, tengamos Dailys Standups, usemos Scrum», etc. El problema de comenzar por la parte superior del iceberg es que las prácticas se deterioran si no son practicadas teniendo una conciencia sobre el principio o valor que las sustenta. No hacemos TDD o Dailys porque decimos que somos ágiles, hacemos TDD porque construimos software de valor, de alta calidad, de forma colaborativa y con feedback temprano; es porque creemos en la transparencia y en el trabajo en equipo. Agile es más que pegar post-its en la pared y reunirse todos los días. Del otro lado, existe una alta probabilidad de que si te reúnes como equipo, trabajan colaborativamente, usas buenas técnicas de desarrollo de software, la calidad mejore y entregues mayor valor; pero normalmente no hay una correspondencia bidireccional entre el «ser» y el «hacer».
Mi punto: Agile es cultura, pero debe ser una cultura viva
Seguramente han visto muchas empresas con sus valores pintados en las paredes, o con grandes pósters diciendo: «somos ágiles, trabajamos en equipo, trabajamos con pasión, transparencia», etc; pero en el día a día pasa precisamente lo contrario: micromanagement, competencia, individualismo. De igual forma, me he encontrado con numerosos equipos teniendo «zombie standups» todos reunidos contando los minutos para terminar y sentarse nuevamente a trabajar, siguiendo la Liturgia Ágil (como le diría mi amigo Juame Cardona) de forma automática, sin ninguna reflexión acerca del valor de la práctica.
En ambos casos existe una brecha entre los valores y el comportamiento. Es una cultura vacía, una cultura zombie.
Una cultura viva es aquella en donde se respira, practica y vive lo que se predica. Es aquella en donde las prácticas reflejan el verdadero acuerdo del equipo, los valores con los cuales se comprometieron, el lente a través del cual miran todos. En una cultura viva existe una comunión auténtica entre valores y prácticas, de tal forma que las prácticas pueden cambiar o evolucionar en busca de respetar los valores; es muy difícil que las prácticas por sí solas modifiquen los valores core del individuo, equipo u organización; son sus valores core quienes modifican las prácticas.
Adoptar Agile implica un cambio profundamente humano
«Tu cultura se come a tu estrategia por desayuno». – Henrik Kniberg
Ya lo dicen las encuestas: «el principal obstáculo para adoptar Agile es la falta de habilidad de cambiar la cultura organizacional» (State of Agile, 8th Version One Survey). Tiene sentido, no podemos ayudar a una organización sin conocerla, sin conocer los drivers y los valores en la parte baja de la pirámide más allá del comportamiento visible. Es la razón por la que estoy convencido que un Agile Coach/Consultant debe ser un antropólogo organizacional y descubrir la pirámide de cada organización. En mi opinión, más allá de las prácticas o frameworks de moda para escalar Agile; el cambio es profundamente humano. A partir del primer valor del Agile Manifesto:
Individuos e interacciones sobre procesos y herramientas.
se derivaría algo como:
Valores y principios sobre frameworks y prácticas.
No quiere decir que las prácticas o los frameworks no sean necesarios, son herramientas muy útiles; pero sin una interiorización de los valores que representan, estas se diluirán con el tiempo perdiendo aquellos valores. Una cultura Agile es la comunión auténtica bidireccional entre «Ser Agile» y «Hacer Agile», comenzando por comprender «Ser Agile» para luego «Hacer Agile».
Hablar de felicidad o sentimientos, son posiblemente dos de los tópicos más subestimados, ignorados -y por supuesto- menos valorados dentro de la dinámica de los negocios y el entorno laboral. Dentro del ADN de los negocios y en las raíces mismas del management tradicional (el que heredamos de la época industrial) existe al parecer una noción de que los sentimientos de las personas que conforman una organización no son tan importantes como su productividad o su capacidad de ejecutar una tarea; al fin y al cabo se trata de recursos no!?, término que usan muchas empresas y gerentes para referirse a su equipo.
«Cómo es que cuando quiero un par de manos también me traen un cerebro.» – Henry Ford
Yo añadiría: y un corazón también!! (Bueno, en el sentido figurado más puro, ya que los sentimientos nacen en el cerebro, pero nos identificamos más fácilmente con el corazón 🙂 ).
A finales del siglo XX, se puso de moda en el mundo los negocios una palabra: motivación. Aparecieron muchas teorías y modelos. «Motivar a tu gente» se convirtió en el objetivo, al conocer que la productividad está estrechamente relacionada al estado de ánimo y compromiso de un empleado. Interesante.
Entonces, se crearon varios mecanismos para «fomentar» la motivación y aparecieron los bonos, promociones, regalos, etc. Era algo como: si alcanzas a lograr este valor en ventas, obtendrás un porcentaje de las ganancias; si llegas a un valor menor, entonces obtendrás un porcentaje menor; y así por el estilo. Después de esto, la gente de Ventas sale corriendo pisándose unos sobre otros a capturar más clientes. En la mayoría de los casos se pierde el foco; lo importante ya no es la calidad del producto o servicio, es simplemente vender más.
Pero, qué motiva realmente a una persona? Afortunadamente Dan Pink nos brinda luces maravillosas sobre el tema; y habla sobre la Motivación Intrínseca, compuesta básicamente de brindar a cada persona tres elementos esenciales: Autonomía, Maestría y Propósito. Jurgen Appelo en su trabajo sobre Management 3.0 lo extiende y habla sobre los Moving Motivators y los 10 Deseos Intrínsecos de cada persona (ChampFrogs). Muy bueno!.
En busca de la Felicidad
La felicidad es una elección consciente no una respuesta automática. – Mildred Barthel
La felicidad es para muchos un concepto abstracto. Hace algunos años cuando hablaba de felicidad con algunos compañeros de la oficina me decían: «Pero, es que no se puede hacer feliz a todos, es un error.» Me hizo cuestionarme mucho, y en cierto modo tenían razón; cada persona posee un conjunto diferente de valores, motivadores, expectativas y deseos; es lo que nos define como individuos y nos hace únicos, y de una forma maravillosa iguales también; todos tenemos aquello. Cada quien posee su concepto de felicidad.
Y entonces, cómo podemos sentirnos más felices en la oficina?
Desde hace un par de décadas, todos somos testigos del nacimiento de una nueva generación de empresas y alrededor de ellas un conjunto de principios, estructuras organizativas y técnicas llamativas que procuran mejorar colaboración, aumentar la creatividad y la satisfacción de las personas. Para muchos de nosotros ya no es raro ver una oficina al estilo Google y toda su filosofía por detrás; y es precisamente ese fundamento ideológico por donde se debe comenzar.
Definir una cultura organizacional basada en valores y principios que las personas quieran, sientan y se identifiquen con ellos; que sea un trabajo de todos; y que cada persona en la organización respete y quiera ser parte de esa identidad. Construir algo para un propósito más grande, y trabajar por el.
Ajustar constantemente el entorno para «habilitar» la felicidad en las personas. Por ejemplo, Zappos posee una persona en una posición llamada Chief Happiness Officer, encargada en todo momento de preocuparse de la felicidad de las personas de la compañía y entregar felicidad también. Medir la felicidad es posible, aquí hay una implementación muy ingeniosa de un Happiness Index usando bolas de tennis, me gusta mucho!. Hacer de la felicidad una parte importante y visible de su negocio y sus equipos, por ejemplo aplicando algo como el Happiness Profit, y preocuparse de hacer depósitos positivos a la cuenta de felicidad; tal vez aplicando técnica como la de Kudo Box.
Si bien es cierto, no hay recetas para la felicidad; y tal como reza el dicho, más que un destino, la felicidad es un camino a disfrutar. Si deseas ser feliz en tu trabajo, disfruta de el. Trabaja en algo que realmente te apasione, en el que sientas que aportas con tu talento y energía a un propósito que consideras grandioso, sublime, que puede cambiar al mundo. Busca tus motivadores a tu alrededor, busca la motivación en tu corazón. Sal, cambia al mundo y sé feliz en el camino, es tu elección!.
«La felicidad es cuando lo que piensas, lo que dices y lo que haces están en armonía.» – M. Gandhi
Seguramente, alguna vez nos hemos enfrentado a una entrevista laboral y con ella a una pregunta de rigor -adicional a cuál es tu aspiración salarial?, por supuesto-…cuál es tu experiencia??.
Cuál es tu experiencia con esta herramienta? o en este proceso? o haciendo tales actividades?. Incluso, en alguna ocasión me pedían que establezca un porcentaje a mi experiencia sobre ciertas cosas…por teléfono.
En fin, valoramos mucho la experiencia; y esto no es casualidad, es herencia. Pasaban aquellos tiempos de post-guerras donde las organizaciones representaban estabilidad y crecimiento económico. Las industrias proliferaron y dentro de estas organizaciones se tomaba mucho en cuenta aspectos de producción: números de piezas por unidad de tiempo, número de fallas por item y así por el estilo.
De esta forma, el trabajo manual y el conocimiento manejando herramientas para elaborar productos de forma más rápida y con calidad se valorizaron altamente. Un trabajador con buenas habilidades tenía preferencia y por ende era seleccionado para el puesto y promovido posteriormente.
Se me viene a la mente la escena de la Lista de Schindler donde se le toma el tiempo a un obrero para construir un picaporte (la escena aquí):
De alguna forma, esto evolucionó hacia labores no necesariamente industriales o de manufactura. Fue tan fuerte su influencia que la vemos y la hemos vivido en casi todas las empresas de casi todos los sectores (en algunos más fuerte que en otros). La importacia de la experiencia es parte del ADN de las organizaciones, tal como las conocemos.
Sin embargo, vivimos en un mundo diferente; rodeados de un entorno dinámico, de cambios constantes y de disrupciones tecnológicas que cambian la vida de las personas y organizaciones. En este ámbito plagado de incertidumbre les pregunto…qué valor tiene la experiencia?.
Tomemos en cuenta que hoy existen carreras que no existían sino hace 8 años o menos. Que existen nuevas plataformas tecnológicas que marcan tendencias y generan nuevos empleos que antes no imaginábamos, así como también una nueva especie de empresas al mando de geeks que salen de la nada y transforman al mundo.
Yo quiero ser un emprendedor (algún día cuando me arme de valor y deje mi trabajo
por perseguir mis sueños, falta poco); y como todos los emprededores de mi generación, queremos fundar una empresa innovadora, una empresa que marque la diferencia, que haga cosas diferentes, que deleite a los clientes. La pregunta que me surge es: contraríamos personas con mucha experiencia si no pensamos en hacer lo mismo??. Pienso que demasiada experiencia en algo puede matar la innovación (les invito a leer un gran artículo de José Miguel Bolívar).
Es mejor contratar a la persona correcta antes que a la experiencia correcta. Yo prefiero Mindsets sobre Skillsets.
Es verdad y es importante también, hay que tomar en cuenta la experiencia en nuestro propio campo, nuestras herramientas y nuestros procesos en el momento de contratación; pero no sobrevalorarlas. Existen otras competencias que tienen un alto valor: energía personal, capacidad de completitud de tareas, trabajo por resultados, transparencia y comunicación, capacidad de aprendizaje, habilidades sociales, la capacidad de ayudar al equipo a crecer…la capacidad de inspirar.
Invitar a un nuevo miembro a nuestra empresa o a nuestros equipos no debe verse únicamente desde el punto de vista financiero, como un obrero más a la fábrica. Las personas no son recursos. Incorporar a una nueva persona a la empresa tiene que ver más con una decisión estratégica; y es responsabilidad de la empresa ayudarle a crecer, a que aporte valor, a desatar todo su potencial.
Como en muchos aspectos de la vida, el balance es lo adecuado. Esto significa que, no estoy diciendo que todas las personas que durante años vienen haciendo una labor ya no son elegibles para aportar y generar innovación. Tampoco que mayor experiencia significa mayor edad. Lo que digo es que nuestra carrera siempre debe estar en un «beta permanente», investigando constantemente, aprendiendo, adaptándonos, dispuestos con estusiasmo a abrirnos hacia nuevos habilidades, destrezas, tecnologías, empresas….personas.
Si deseas construir un barco, no mandes a los hombres a recoger madera o distribuyas el trabajo. Mejor evoca en ellos el anhelo de la belleza y la inmensidad del mar. –
Johnny Ordóñez 
