So far we have analyzed GameStudioX's transformation from the outside: its goals, its contradictions, the signals that don't show up in the books…
But this week we change perspective: you are inside.
🕹 Imagine you are part of the GameStudioX team. You take part in dailies that go nowhere, and there is a lot of frustration on the team because, despite the retrospectives and the kanban board, there is no real improvement. And those who question decisions get punished. Communication between departments is still scarce. And nobody seems willing to talk about what isn't working.
Still, "we are being agile," says the director.
🔍 Are we really being agile? Are we improving anything, or are we just using new language for old habits?
- How would you know when the time has come to change course? What objective indicators could help you argue for it without seeming to oppose change?
- How would you approach this conversation from within? How would you open the dialogue constructively, without falling into complaining or confrontation?
Comments (5)
Log in to your Scrum Manager area to comment
Jorge Sánchez López ★★★
23 Jul 2025 06:40Absolutely not! GameStudioX's description is a classic example of a "zombie" or superficial Agile transformation. They are using ceremonies (dailies, retrospectives) and tools (Kanban) without understanding or applying Agile's fundamental principles and values. The signs are clear:
Useless dailies and frustration: These indicate a lack of purpose, engagement, and probably poor facilitation.
No real improvement: The goal of Agile is continuous improvement. If there is no change despite the retrospectives, it means the root causes aren't being addressed or the action items aren't being tracked effectively.
Punishment for questioning: This destroys psychological safety, a fundamental pillar of high-performing teams and of Agile. Without it, there is no transparency, learning, or innovation.
Poor interdepartmental communication: A symptom of organizational silos and a lack of end-to-end vision of value, which contradicts collaboration and joint value delivery.
Avoiding problems: Related to the lack of psychological safety. If nobody wants to talk about what isn't working, problems become entrenched and improvement becomes impossible.
"We're being agile" from the director: This phrase is the icing on the cake. It shows a lack of deep understanding of what it means to be agile. "Doing Agile" (applying practices) is being confused with "being Agile" (adopting a mindset and values).
They are simply using new language for old habits. It is a cosmetic transformation that, in the long run, will generate more frustration, demotivation, and probably an even greater rejection of future change initiatives.
How do you know it's time to change course?
The moment to change course is not an intuition; it is a tangible reality at GameStudioX. However, to argue for it objectively without seeming to oppose change (but rather seeking real improvement), I suggest the following objective indicators:
Flow metrics (if they exist and are reliable):
Lead Time / Cycle Time stagnant or increasing: If the time it takes for an idea to become delivered value does not decrease (or even increases), the "agility" is not generating efficiency.
Low or decreasing throughput: The number of completed value items per unit of time. If it's low, the team is not being productive.
High Work In Progress (WIP): If there are many things half-finished, it indicates poor flow management, bottlenecks, and overload.
Rising defects / rework: A clear indicator of poor quality and that problems are not being resolved.
Retrospective data (if recorded):
No improvement actions implemented or tracked: If retrospectives generate actions that are never carried out or whose impact is never verified, they are useless.
Repetition of the same problems: If retrospectives keep addressing the same problems without resolving them, it's a sign of stagnation.
Low participation or engagement in retrospectives: People stop participating if they perceive no usefulness.
Team climate or satisfaction surveys (if they can be proposed):
Low team satisfaction: Questions about the atmosphere, collaboration, purpose, psychological safety, etc.
High levels of frustration or burnout: This can be measured with specific questions about stress and workload.
Value delivery:
Recurring negative feedback from users/stakeholders: If what is delivered doesn't meet expectations or doesn't add value.
Lack of frequent or predictable deliveries: If "Agile" is not resulting in more and better deliveries.
To present this, avoid "you're doing it wrong" and focus on the impact on the business and the team. For example: "I've noticed that our lead time has increased over the past few months, which could be affecting our ability to respond to the market. I also see that in our retrospectives we keep discussing the same impediments without seeing sustained improvement. I'm concerned that this is creating frustration in the team and affecting our ability to innovate."
How would you approach this conversation from within?
Raising this conversation from within requires tact, empathy, and a clear strategy, avoiding complaints and confrontation. My approach would be:
Find allies: Identify colleagues on the team (or even in other departments) who share your concern. A collective message is more powerful and less threatening than an individual one.
Small experiments and "show, don't just tell": Rather than big debates, propose small, concrete improvements in your own team that demonstrate the value of agile principles. For example:
Improve your team's dailies: If they aren't useful, offer to facilitate and experiment with a format focused on impediments and the plan for the day. Show how an effective daily can save time and align the team.
Foster impediment resolution in your team: Instead of just listing impediments, spend time looking for solutions or proactively escalating blockers.
Propose a simplified "Value Stream Mapping" exercise: At the team level or between two nearby teams, to visualize where time and value are lost. Don't call it that if it sounds threatening; simply "map our process."
Frame the problem in terms of the director's business goals and objectives: If the director says "we're being agile," it's because they believe Agile will bring benefits. Connect current problems with the absence of those benefits. For example:
"Director, I've been thinking about how we can speed up our deliveries and reduce errors, which I know are priorities for you. I've noticed that X (e.g., lead time) is affecting our ability to do this."
"I'm concerned that the team's frustration with the lack of real improvement could affect our ability to retain talent and our long-term productivity."
Use data (the objective indicators): In a one-on-one conversation or a relevant meeting, present the data neutrally and solution-oriented. "We've seen the rework percentage rise by X% over the last two quarters, which is consuming valuable hours we could dedicate to new features."
Open questions and genuine curiosity: Instead of accusations, ask questions that invite reflection:
"What do you think is preventing us from seeing real improvement, despite using Kanban and retrospectives?"
"How could we make our dailies help us resolve impediments more, rather than just reporting?"
"How could we ensure that retrospective actions are really implemented and help us move forward?"
Focus on learning and continuous improvement, not on failure: The message should be: "We are at a point where we can learn and adjust to become more effective in our agile transformation."
What similar experiences have you had?
I have seen many scenarios similar to GameStudioX, both as an external consultant and as an internal team member. Often, what is called an "agile transformation" is actually the implementation of practices without a change in mindset. Companies invest in tools and training but don't address culture, hierarchy, psychological safety, or reward systems.
I learned several key lessons about how (not) to initiate change when the transformation seems to be running on autopilot:
Don't start change with direct confrontation: Early in my career, I fell into the trap of pointing out mistakes or lack of agility directly, which created immediate resistance. People (especially leaders) get defensive when they feel their work or decisions are being questioned. It is much more effective to plant seeds of doubt, ask questions that lead to reflection, and propose small experiments.
The power of "early adopters" and "pilot teams": When a change is running on autopilot and there is no willingness to listen, identifying a team or leader who is sensitive to the problems and working with them to demonstrate the value of a different approach can be transformative. If that team starts getting better results, it becomes an internal success story.
Focus on business results, not "Agile purity": Directors don't care whether you use Scrum, Kanban, or Scrumban. They care about results: faster deliveries, higher quality, happier clients, cost reduction, more motivated employees. Align your arguments with those business objectives.
Resistance is not always bad faith: Often, resistance comes from fear (of losing power, of not knowing how to do it, of failure) or from misunderstanding. Address that fear with empathy and education, offering support and solutions, not just criticism.
The importance of patience and persistence: Cultural transformations are slow. A single attempt is usually not enough. It is an iterative process of planting, nurturing, measuring, and adapting.
Celebrate small wins: When you achieve a small advance (a more effective daily, a resolved impediment, an improving metric), celebrate it and communicate it. This builds momentum and shows that change is possible.
If you use persuasion, data, small experiments, and empathy, rather than confrontation or complaints.
Your goal is to help GameStudioX truly "be" agile, not just "do" agile.
¡Absolutamente no! La descripción de GameStudioX es un ejemplo clásico de una transformación "zombie" o superficial del Agile. Se están utilizando ceremonias (dailies, retrospectivas) y herramientas (Kanban) sin comprender ni aplicar los principios y valores fundamentales de Agile. Las señales son claras:
Dailies inútiles y frustración: Indican falta de propósito, engagement y probablemente una mala facilitación.
Ausencia de mejora real: El objetivo de Agile es la mejora continua. Si a pesar de las retrospectivas no hay cambio, significa que no se están abordando las causas raíz o que no hay un seguimiento efectivo de las acciones.
Castigo por cuestionar: Esto aniquila la seguridad psicológica, un pilar fundamental de los equipos de alto rendimiento y del Agile. Sin ella, no hay transparencia, aprendizaje ni innovación.
Comunicación interdepartamental deficiente: Un síntoma de silos organizacionales y falta de visión de valor end-to-end, contradiciendo la colaboración y la entrega de valor conjunta.
Evitar problemas: Relacionado con la falta de seguridad psicológica. Si nadie quiere hablar de lo que no funciona, los problemas se enquistan y la mejora es imposible.
"Estamos siendo ágiles" del director: Esta frase es la guinda del pastel. Demuestra una falta de comprensión profunda de lo que significa ser ágil. Se confunde "hacer Agile" (aplicar prácticas) con "ser Agile" (adoptar una mentalidad y valores).
Están simplemente usando un lenguaje nuevo para viejos hábitos. Es una transformación cosmética que, a la larga, generará más frustración, desmotivación y probablemente un rechazo aún mayor hacia futuras iniciativas de cambio.
¿Cómo saber que ha llegado el momento de cambiar el rumbo?
El momento de cambiar el rumbo no es una intuición, es una realidad palpable en GameStudioX. No obstante, para argumentarlo de forma objetiva sin parecer que te opones al cambio (sino que buscas la mejora real), te sugiero los siguientes indicadores objetivos:
Métricas de flujo (si existen y son fiables):
Lead Time / Cycle Time estancado o en aumento: Si el tiempo que tarda una idea en convertirse en valor entregado no disminuye (o incluso aumenta), la "agilidad" no está generando eficiencia.
Throughput bajo o decreciente: La cantidad de elementos de valor completados por unidad de tiempo. Si es baja, el equipo no está siendo productivo.
Work In Progress (WIP) alto: Si hay muchas cosas a medio hacer, indica una mala gestión del flujo, cuellos de botella y sobrecarga.
Defectos / Retrabajo en aumento: Un indicador claro de falta de calidad y de que los problemas no se están resolviendo.
Datos de las retrospectivas (si se registran):
Ausencia de acciones de mejora implementadas o seguimiento: Si las retrospectivas generan acciones que nunca se llevan a cabo o no se verifica su impacto, son inútiles.
Repetición de los mismos problemas: Si las retrospectivas abordan una y otra vez los mismos problemas sin resolverlos, es una señal de estancamiento.
Baja participación o compromiso en retrospectivas: La gente deja de participar si percibe que no hay utilidad.
Encuestas de clima o satisfacción de equipo (si se pueden proponer):
Baja satisfacción del equipo: Preguntas sobre el ambiente, la colaboración, el propósito, la seguridad psicológica, etc.
Alto nivel de frustración o burnout: Puede medirse con preguntas específicas sobre el estrés y la carga de trabajo.
Entregas de valor:
Feedback negativo recurrente de usuarios/stakeholders: Si lo que se entrega no cumple expectativas o no aporta valor.
Falta de entregas frecuentes o predecibles: Si el "Agile" no está resultando en más y mejores entregas.
Para presentarlo, evita el "tú estás mal" y enfócate en el impacto en el negocio y en el equipo. Por ejemplo: "He notado que nuestro lead time ha aumentado en los últimos meses, lo que podría estar afectando nuestra capacidad de respuesta al mercado. También observo que en las retrospectivas seguimos discutiendo los mismos impedimentos sin ver una mejora sostenida. Me preocupa que esto genere frustración en el equipo y afecte nuestra capacidad de innovar."
¿Cómo abordarías esta conversación desde dentro?
Abordar esta conversación desde dentro requiere sutileza, empatía y una estrategia clara, evitando la queja y el enfrentamiento. Mi enfoque sería:
Encuentra aliados: Identifica a compañeros del equipo (o incluso de otros departamentos) que compartan tu preocupación. Un mensaje colectivo es más potente y menos amenazante que uno individual.
Pequeños experimentos y "mostrar, no solo decir": En lugar de grandes debates, propone pequeñas mejoras concretas en tu propio equipo que demuestren el valor de los principios ágiles. Por ejemplo:
Mejora las dailies de tu equipo: Si no sirven, proponte como facilitador para experimentar con un formato más enfocado en impedimentos y plan del día. Demuestra cómo una daily efectiva puede ahorrar tiempo y alinear al equipo.
Fomenta la resolución de impedimentos en tu equipo: En lugar de solo listarlos, dedica tiempo a buscar soluciones o a escalar los bloqueos de manera proactiva.
Propón un ejercicio de "Value Stream Mapping" simplificado: En un nivel de equipo o entre dos equipos cercanos, para visualizar dónde se pierde tiempo y valor. No lo llames así si suena amenazante, simplemente "mapear nuestro proceso".
Fragmenta el problema en términos de negocio/objetivos del director: Si el director dice "estamos siendo ágiles", es porque cree que Agile traerá beneficios. Conecta los problemas actuales con la falta de esos beneficios. Por ejemplo:
"Director, he estado pensando en cómo podemos acelerar nuestras entregas y reducir los errores, que sé que son prioridades para ti. He notado que X (ej. el Lead Time) está afectando nuestra capacidad de hacer esto."
"Me preocupa que la frustración del equipo por la falta de mejora real pueda afectar nuestra capacidad de retener talento y nuestra productividad a largo plazo."
Usa datos (los indicadores objetivos): En una conversación uno a uno o en una reunión relevante, presenta los datos de forma neutral y orientada a la solución. "Hemos visto que el porcentaje de retrabajo ha aumentado un X% en los últimos dos trimestres, lo que está consumiendo horas valiosas que podríamos dedicar a nuevas funcionalidades."
Preguntas abiertas y curiosidad genuina: En lugar de acusaciones, haz preguntas que inviten a la reflexión:
"¿Qué crees que nos está impidiendo ver una mejora real, a pesar de usar Kanban y retrospectivas?"
"¿Cómo podríamos hacer para que nuestras dailies nos ayuden más a resolver impedimentos en lugar de solo reportar?"
"¿Cómo podríamos asegurar que las acciones de las retrospectivas realmente se implementen y nos ayuden a avanzar?"
Enfócate en el aprendizaje y la mejora continua, no en el fallo: El mensaje debe ser: "Estamos en un punto donde podemos aprender y ajustar para ser más efectivos en nuestra transformación ágil."
¿Qué experiencias similares has vivido tú?
He vivido múltiples escenarios similares a GameStudioX, tanto como consultor externo como miembro de equipo interno. A menudo, lo que se denomina "transformación ágil" es en realidad una implementación de prácticas sin un cambio de mentalidad. Las empresas invierten en herramientas y formación, pero no abordan la cultura, la jerarquía, la seguridad psicológica o los sistemas de recompensa.
Aprendí varias lecciones clave sobre cómo (no) iniciar un cambio cuando la transformación parece ir en piloto automático:
No iniciar el cambio desde la confrontación directa: Al principio de mi carrera, caí en la trampa de señalar directamente los errores o la falta de agilidad, lo cual generaba una resistencia instantánea. Las personas (especialmente los líderes) se ponen a la defensiva cuando sienten que se cuestiona su trabajo o sus decisiones. Es mucho más efectivo sembrar dudas, hacer preguntas que lleven a la reflexión y proponer pequeños experimentos.
El poder de los "early adopters" y los "equipos de prueba": Cuando un cambio va en piloto automático y no hay voluntad de escuchar, identificar a un equipo o un líder "sensible" a los problemas y trabajar con ellos para demostrar el valor de un enfoque diferente puede ser transformador. Si ese equipo empieza a tener mejores resultados, se convierte en un caso de éxito interno.
Enfocarse en los resultados del negocio, no en la "pureza Agile": A los directores no les importa si usas Scrum, Kanban o Scrumban. Les importan los resultados: entregas más rápidas, mayor calidad, clientes más felices, reducción de costes, empleados más motivados. Alinea tus argumentos con esos objetivos de negocio.
La resistencia no siempre es mala fe: A menudo, la resistencia surge del miedo (a perder poder, a no saber cómo hacerlo, al fracaso) o de la incomprensión. Aborda ese miedo con empatía y educación, ofreciendo soporte y soluciones, no solo críticas.
La importancia de la paciencia y la persistencia: Las transformaciones culturales son lentas. Un solo intento no suele ser suficiente. Es un proceso iterativo de sembrar, cuidar, medir y adaptar.
Celebrar las pequeñas victorias: Cuando logres un pequeño avance (un daily más efectivo, un impedimento resuelto, una métrica que mejora), celébralo y comunícalo. Esto genera impulso y demuestra que el cambio es posible.
Si estas utilizando la persuasión, los datos, los pequeños experimentos y la empatía, en lugar de la confrontación o la queja.
Tu objetivo es ayudar a GameStudioX a "ser" ágil de verdad, no solo "hacer" ágil.
Automatic translation · View original
Marta Berné ★★
24 Jul 2025 12:44Interesting, I have a few questions:
You mention that the Daily Scrums are frustrating and pointless. How do you demonstrate this claim to a senior executive? In an environment like the one in the example, it is hard to criticize anything.
To what extent do you think everything you propose could be addressed in a culture like the one in the example?
How feasible would it be to keep some agile practices even if the mindset isn't there? Perhaps, given the context, the change in mindset won't be so easy (maybe it will never happen).
Being realistic, could we apply everything you propose? Or would we need to simplify things?
Interesante, tengo algunas preguntas:
Mencionas que las dailies son frustrantes y sin propósito. ¿Cómo demuestras a un alto cargo esta afirmación? En un entorno como el del ejemplo, es difícil hacer críticas.
¿Hasta qué punto crees que se podría abordar todo lo que propones en una cultura como la del ejemplo?
¿Cómo de viable podría ser mantener algunas prácticas ágiles aunque la mentalidad no lo sea? Quizás dado el contexto, el cambio de mentalidad no va a ser tan sencillo (quizás nunca se dé).
Siendo realistas, ¿podríamos aplicar todo lo que propones? ¿O habría que simplificar las cosas?
Automatic translation · View original
Jorge Sánchez López ★★★
24 Jul 2025 18:31Hi, Marta! I'm glad you find it interesting and that you have such relevant questions. They are exactly the challenges found in this kind of environment. I'll answer based on my experience mentoring in these situations, which has been tested and has produced good results.
Let's break them down:
1. How do you show a senior executive that Dailies are frustrating and pointless in an environment like this?
This is one of the hardest parts, because direct criticism can be counterproductive. The key is to turn the subjective complaint into an objective business or efficiency problem.
Here are some ideas:
Observation and time tracking:
"Time is money": You can start by discreetly tracking (or proposing an experiment) how much time is spent on the Daily Scrum and how much of that time is actually productive. For example: "Our Daily Scrum lasts 20 minutes, but only 5 minutes are spent identifying impediments or coordinating the day's work. The rest is a status report that's already in the tool."
Impact on flow: Connect the inefficiency of the Daily Scrum with the team's lead time or cycle time. "If our Daily Scrums were more effective at unblocking work, we could reduce the time it takes to deliver X feature by 10%."
Anonymous surveys (if the culture allows it, even on a small scale):
Even if it's not a formal survey, you could propose a quick anonymous check-in during the Sprint Retrospective about how useful the Daily Scrum is (e.g., "On a scale of 1 to 5, how much does the Daily Scrum help you plan your day and resolve blockers?"). If the results are consistently low, you have data.
Demonstration with a "pilot team":
If you have the chance to influence a small team, propose a different experimental Daily Scrum for one week, focused solely on impediments and the plan for the day. At the end of the week, compare the results (e.g., "During this experimental week, we resolved X impediments in the Daily Scrum that would have taken longer before"). Show the value instead of just talking about frustration.
Impact-focused language, not complaints:
Instead of saying "the Daily Scrum is a waste of time," say: "I've noticed that in our Daily Scrums we're not identifying and resolving blockers as quickly as we could, which slows our progress on X project." Or: "We could free up X hours a week for the team if we optimized the Daily Scrum to be more results-driven."
Focus on the "why": If the Daily Scrum doesn't have a clear purpose for the team, it won't work. Propose redefining the "why" of the Daily Scrum with the team first, and then with the senior executive.
2. How far do you think everything you propose could be addressed in a culture like the one in the example?
Being very realistic, you can't address everything at once, and probably not everything can be fully addressed. A culture that punishes questioning faces a huge barrier to change.
My approach is based on "small wins" and "contagion":
Priority number one: Psychological safety (even on a small scale). If there isn't a minimum level of safety to speak up, nothing else will work. This is built by example: you modeling vulnerability, acknowledging mistakes, and encouraging questions. Start with your closest circle.
Focus on what's within your control: You can't change the director's mindset overnight. But you can influence your direct team.
Improve your team's Daily Scrum.
Improve your team's Sprint Retrospective, focusing on concrete, measurable actions the team can actually implement.
Foster communication and collaboration within your team and with the teams you interact with most.
Demonstrate value: If your team starts improving its metrics (even on a small scale), becomes more motivated, and delivers faster, that will be noticed. Success is the best argument.
Patience and persistence: Cultural transformations take years, not months. There will be setbacks. What matters is not giving up and continuing to look for those small opportunities.
3. How viable is it to maintain some agile practices when the mindset isn't there?
It is viable to maintain some practices, but with limited results and the risk of "agile theater."
"Doing Agile" vs. "Being Agile": What GameStudioX is doing is "doing Agile." They have the ceremonies and the tools. This can produce some superficial improvement (e.g., greater visibility of the work on the Kanban board), but without the underlying mindset (collaboration, inspection and adaptation, psychological safety, focus on value), the benefits will be minimal and the frustration high.
Risks:
Burnout: The team gets frustrated because they are "doing" Agile but don't see the benefits.
Cynicism: People start to believe Agile is just another fad that doesn't work.
Lack of adaptation: Without a continuous improvement mindset, practices become rigid and don't adapt to real needs.
Hiding problems: Without psychological safety, metrics can be manipulated and problems can be hidden.
In a context like this, practices turn into empty rituals. They may give the director a false sense of progress, but they won't solve the underlying problems. You could maintain them, yes, but always look for opportunities to inject a bit of the underlying mindset.
4. Being realistic, could we apply everything you propose? Or would we need to simplify things?
Definitely, things need to be simplified and prioritized. You can't apply everything at once, not even in a healthier environment. At GameStudioX, less is more.
My recommendation would be:
Priority 1: Create a safe space (however small). Start with your team. Encourage people to talk about problems without fear of retaliation within that micro-environment. If you achieve a team where people feel safe to speak up, you already have a foundation.
Priority 2: Focus on 1-2 key problems for the team.
Is the Daily Scrum the most frustrating? Start there. Propose an experiment to make it more effective.
Are retrospectives not useful? Focus on making them produce a concrete, measurable action the team can carry out and whose impact can be seen.
Is interdepartmental communication a bottleneck? Find a key person in another department and propose a short weekly sync on a specific topic.
Measure the impact: However small the change, try to measure its impact. "This week, did our Daily Scrum help us resolve X impediment that would have blocked us last week?"
Celebrate small wins: When something works, however small, celebrate it with the team and, if possible, share it discreetly upward. "We've achieved this, and it has helped us improve X."
My recommendation, based on my experience, is not to attempt a revolution. Pursue gradual evolution. Be a "mole" for change, working from within, planting seeds and demonstrating value with tangible results, even if they're small. Patience, resilience, and the ability to influence without confrontation will be your best tools.
Some of us call it being a Change Agent, but what matters is the rest
¡Hola, Marta! Me alegra que te parezca interesante y que tengas estas preguntas tan pertinentes. Son precisamente los desafíos que se encuentran en este tipo de entornos, te voy a responder basada en mi experiencia en mentorías de este tipo contrastadas que han proporcionado buenos resultados.
Vamos a desgranarlas:
1. ¿Cómo demuestras a un alto cargo que los dailies son frustrantes y sin propósito en un entorno así?
Esta es una de las partes más difíciles, porque la crítica directa puede ser contraproducente. La clave es transformar la queja subjetiva en un problema objetivo de negocio o eficiencia.
Aquí te dejo algunas ideas:
Observación y registro de tiempo:
"El tiempo es dinero": Puedes empezar por registrar discretamente (o proponer un experimento) cuánto tiempo se dedica a la daily y cuánto de ese tiempo es realmente productivo. Por ejemplo: "Nuestra daily dura 20 minutos, pero solo 5 minutos se dedican a identificar impedimentos o a coordinar el trabajo del día. El resto es un reporte de estado que ya está en la herramienta."
Impacto en el flujo: Conecta la ineficiencia de la daily con el lead time o el cycle time del equipo. "Si nuestras dailies fueran más efectivas para desatascar el trabajo, podríamos reducir el tiempo que tardamos en entregar X funcionalidad en un 10%."
Encuestas anónimas (si la cultura lo permite, aunque sea a pequeña escala):
Incluso si no es una encuesta formal, podrías proponer un "check-in" anónimo rápido en la retrospectiva sobre la utilidad de la daily (ej. "Del 1 al 5, ¿cuánto te ayuda la daily a planificar tu día y resolver bloqueos?"). Si los resultados son consistentemente bajos, tienes un dato.
Demostración con un "equipo piloto":
Si tienes la oportunidad de influir en un equipo pequeño, propón una daily experimental diferente durante una semana. Enfocada solo en impedimentos y plan del día. Al final de la semana, compara los resultados (ej. "En esta semana experimental, resolvimos X impedimentos en la daily que antes habrían tardado más"). Muestra el valor, no solo hables de la frustración.
Lenguaje de impacto, no de queja:
En lugar de decir "la daily es una pérdida de tiempo", di: "He notado que en nuestras dailies no estamos logrando identificar y resolver los bloqueos tan rápido como podríamos, lo que ralentiza nuestro progreso en X proyecto." O "Podríamos liberar X horas a la semana del equipo si optimizamos la daily para que sea más resolutiva."
Enfócate en el "para qué": Si la daily no tiene un propósito claro para el equipo, no servirá. Propón redefinir el "para qué" de la daily con el equipo y luego con el alto cargo.
2. ¿Hasta qué punto crees que se podría abordar todo lo que propones en una cultura como la del ejemplo?
Siendo muy realista, no se puede abordar todo de golpe, y probablemente no todo se podrá abordar por completo. Una cultura donde se castiga el cuestionamiento tiene una barrera enorme para el cambio.
Mi propuesta se basa en un enfoque de "pequeñas victorias" y "contagio":
Prioridad número uno: Seguridad psicológica (aunque sea a pequeña escala). Si no hay un mínimo de seguridad para hablar, nada más funcionará. Esto se construye con el ejemplo: tú mismo/a modelando la vulnerabilidad, reconociendo errores, fomentando preguntas. Empieza por tu círculo más cercano.
Enfoque en lo que está bajo tu control: No puedes cambiar la mentalidad del director de la noche a la mañana. Pero sí puedes influir en tu equipo directo.
Mejora la daily de tu equipo.
Mejora la retrospectiva de tu equipo, enfocándola en acciones concretas y medibles que el equipo sí pueda implementar.
Fomenta la comunicación y colaboración dentro de tu equipo y con los equipos con los que más interactúas.
Demostrar el valor: Si tu equipo empieza a mejorar sus métricas (aunque sea a pequeña escala), a estar más motivado, a entregar más rápido, eso se notará. El éxito es el mejor argumento.
Paciencia y persistencia: Las transformaciones culturales llevan años, no meses. Habrá retrocesos. Lo importante es no rendirse y seguir buscando esas pequeñas oportunidades.
3. ¿Cómo de viable podría ser mantener algunas prácticas ágiles aunque la mentalidad no lo sea?
Es viable mantener algunas prácticas, pero con resultados limitados y el riesgo de "teatro ágil".
"Hacer Agile" vs. "Ser Agile": Lo que GameStudioX está haciendo es "hacer Agile". Tienen las ceremonias y las herramientas. Esto puede generar alguna mejora superficial (ej. una mayor visibilidad del trabajo en el Kanban), pero sin la mentalidad subyacente (colaboración, inspección y adaptación, seguridad psicológica, enfoque en el valor), los beneficios serán mínimos y la frustración alta.
Riesgos:
Desgaste y burnout: El equipo se frustra porque "hacen" Agile pero no ven los beneficios.
Cinismo: La gente empieza a creer que Agile es solo una moda más que no funciona.
Falta de adaptación: Sin la mentalidad de mejora continua, las prácticas se vuelven rígidas y no se adaptan a las necesidades reales.
Ocultamiento de problemas: Si no hay seguridad psicológica, las métricas pueden maquillarse y los problemas ocultarse.
En un contexto así, las prácticas se convierten en rituales vacíos. Pueden dar una falsa sensación de progreso al director, pero no resolverán los problemas de fondo. Podrías mantenerlas, sí, pero siempre buscando la oportunidad de inyectar un poco de la mentalidad subyacente.
4. Siendo realistas, ¿podríamos aplicar todo lo que propones? ¿O habría que simplificar las cosas?
Definitivamente, hay que simplificar las cosas y priorizar. No se puede aplicar todo de golpe, ni siquiera en un entorno más sano. En GameStudioX, menos es más.
Mi recomendación sería:
Prioridad 1: Crear un espacio seguro (por pequeño que sea). Empieza por tu equipo. Fomenta que se hable de los problemas sin miedo a represalias dentro de ese micro-entorno. Si logras un equipo donde la gente se siente segura para hablar, ya tienes una base.
Prioridad 2: Enfocarse en 1-2 problemas clave del equipo.
¿La daily es lo más frustrante? Empieza por ahí. Propón un experimento para hacerla más efectiva.
¿Las retrospectivas no sirven? Enfócate en que generen una acción concreta y medible que el equipo pueda llevar a cabo y que se vea su impacto.
¿La comunicación interdepartamental es un cuello de botella? Busca una persona clave en otro departamento y propón una mini-sincronización semanal para un tema específico.
Medir el impacto: Por pequeño que sea el cambio, intenta medir su impacto. "¿Esta semana, nuestra daily nos ayudó a resolver X impedimento que la semana pasada nos habría bloqueado?"
Celebrar las pequeñas victorias: Cuando algo funcione, por pequeño que sea, celébralo con el equipo y, si es posible, compártelo discretamente hacia arriba. "Hemos logrado esto, y nos ha ayudado a mejorar X."
Mi recomendación basada en mi experiencia es que no intentes una revolución. Busca la evolución gradual. Sé un "topo" del cambio, trabajando desde dentro, sembrando semillas y demostrando el valor con resultados tangibles, aunque sean pequeños. La paciencia, la resiliencia y la capacidad de influir sin confrontar serán tus mejores herramientas.
Algunos lo llamamos Agente del Cambio, pero bueno lo importante
Automatic translation · View original
Marta Berné ★★
25 Jul 2025 10:00Interesting! In your experience, have you ever found yourself in a situation similar to the example we propose?
Thanks for sharing!
¡Interesante! ¿En tu experiencia te has visto alguna vez en una situación similar a la del ejemplo que proponemos?
¡Gracias por compartir!
Automatic translation · View original
Jorge Sánchez López ★★★
25 Jul 2025 10:25Yes, of course, several times. As I indicated, I have answered based on my own experiences. Moreover, these answers are based on a kind of manual of lessons learned or guide of experiences, which I prefer and which I keep as a diary of situations and lived experiences, and I answered based on a summary.
I empathized a lot with the case, since it is quite realistic, as I mentioned.
Thank you for posing situations and debate so that we can share our opinions!
Si claro varias veces, como he indicado lo he contestado en base a mis experiencias, es más estas respuestas estan basadas en una especie de manual de lecciones aprendidas o guía de experiencias que me gusta mas que voy tomando como diario de situaciones y experiencias vividas, y en base a un resumen he contestado.
Empaticé mucho con el caso ya que es bastante realista como he comentado.
¡Gracias a tí por poner situaciones y debate para que podamos opinar!
Automatic translation · View original