# THINK en retrospectivas: cómo criticar sin romper al equipo > Descubre cómo dar feedback en retrospectivas ágiles sin dañar al equipo, usando THINK para comunicar críticas útiles, claras y respetuosas. - URL canónica: https://www.martagonzalez.dev/blog/think-en-retrospectivas-como-criticar-sin-romper-al-equipo/ - Fecha de publicación: 2026-01-03T20:51:25 - Última actualización: 2026-05-26T13:32:06 --- [![Imagen del artículo](https://martagonzalez.dev/wp/wp-content/uploads/2026/01/think-en-retrospectivas-1024x683.avif)](https://martagonzalez.dev/wp/wp-content/uploads/2026/01/think-en-retrospectivas.avif) Hay un momento delicado en casi cualquier equipo de desarrollo: la retrospectiva. Ese espacio que, en teoría, debería ayudaros a mejorar el proceso… y que, en la práctica, a veces se convierte en una sesión de quejas , un “a ver quién la suelta más gorda” , o un mini-juicio con sonrisas tensas. Y es una pena, porque una retro bien llevada es una de las herramientas más potentes de gestión de proyectos en entornos Agile (y también fuera de Agile): reduce fricción, acelera aprendizaje y mejora la entrega. Pero para que funcione, hay una condición imprescindible: poder hablar de lo que no va bien sin destrozar la seguridad psicológica del equipo . Aquí entra THINK , un filtro práctico para convertir crítica en mejora: decir lo necesario sin ser destructivos, y ser honestos sin sonar crueles. En este artículo vamos a llevarlo a un terreno más técnico y avanzado, con ejemplos aplicados a retrospectivas , desarrollo web , herramientas de comunicación , y además vamos a comparar un eje que suele pasarse por alto: tiempo de decisión vs. carga cognitiva . ## Por qué las retrospectivas se rompen (y por qué no es “culpa del equipo”) Una retrospectiva se rompe cuando el equipo aprende que “hablar tiene coste”. Ese coste puede ser: - Coste emocional: “Si digo lo que pienso, quedo como conflictiva”. - Coste social: “Si señalo un problema, alguien se lo toma personal”. - Coste político: “Si menciono dependencias externas, se interpreta como ataque”. - Coste operativo: “Hablamos mucho, decidimos poco, y nada cambia”. Cuando eso ocurre, la retro se convierte en teatro: comentarios genéricos, problemas sin nombres (“la comunicación”), y acciones tan blanditas que no mueven nada (“mejorar coordinación”). La buena noticia: esto se puede diseñar. Igual que diseñáis un sistema para evitar regresiones , podéis diseñar una dinámica para evitar regresiones relacionales . ## Qué es THINK y por qué funciona para criticar sin dañar THINK es un acrónimo clásico usado como filtro antes de hablar. Hay variaciones, pero una de las más útiles para retrospectivas es: - T — True (Verdadero): ¿Está basado en hechos observables? - H — Helpful (Útil): ¿Ayuda a mejorar, o solo descarga? - I — Inspiring (Inspirador): ¿Abre posibilidades, o solo hunde? - N — Necessary (Necesario): ¿Es el momento y lugar adecuados? - K — Kind (Amable): ¿Cuida la forma sin diluir el fondo? No significa “endulzar la realidad”. Significa hacerla procesable . En equipos, lo que mata no es el feedback; lo que mata es el feedback difuso, personal, tardío o humillante . Y aquí viene el punto clave: THINK no es solo un filtro individual; es una herramienta de comunicación que podéis convertir en norma de equipo. ## THINK aplicado a retrospectivas, paso a paso ### Antes de la retro: prepara el terreno para hablar con verdad La mayoría de retros fallan antes de empezar . Porque llegan cargadas de contexto, tensiones y prisa. Checklist previo (10 minutos): - Define objetivo único : “Mejorar el flujo de PRs” > “Hablar de cómo fue el sprint”. - Acota el alcance: “Últimas 2 semanas” o “incidentes desde el release X”. - Decide el formato: presencial, remoto, híbrido. - Prepara el tablero con columnas claras (ej.: Hechos / Impacto / Hipótesis / Acción ). #### — Microdiseño: reduce carga cognitiva desde el tablero Si el tablero tiene 8 columnas, 12 preguntas y 4 dinámicas, lo que haces es subir la carga cognitiva . El equipo se agota decidiendo “dónde va cada cosa” en vez de pensar “qué mejora hacemos”. Una estructura que funciona muy bien para retros técnicas es: - Hecho observado (qué pasó) - Impacto (qué costó) - Causa probable (hipótesis) - Acción (qué cambiaremos) Sencillo, pero brutalmente efectivo. ### Durante la retro: cómo usar THINK cuando la conversación se calienta Aquí es donde THINK se vuelve útil de verdad: cuando aparece el típico comentario que podría incendiar la sala. #### T — True: del juicio al dato observable En desarrollo web, es fácil caer en frases como: - “Siempre entregamos tarde.” - “QA nos frena.” - “Diseño manda cosas a última hora.” Eso suena a verdad… pero no es verificable. Cambiadlo por observables : - “En los últimos 3 sprints, 6 de 10 tickets se movieron a ‘Done’ el último día.” - “Esta semana hubo 9 re-aperturas por casos no cubiertos en los criterios.” - “Los cambios de UI llegaron después del inicio del sprint en 4 historias.” Regla práctica: si no lo puedes medir o describir sin adjetivos, todavía no es True . #### H — Helpful: ¿mejora algo o solo me desahogo? Desahogarse es humano, pero una retrospectiva no debería ser solo una válvula. Transformación rápida: - “Esto es un desastre” → “¿Qué parte exacta del flujo nos está fallando?” - “Nadie revisa PRs” → “¿Qué bloquea las revisiones: tiempo, claridad, ownership?” Útil = accionable . Si no puedes imaginar una acción concreta al final, probablemente falta enfoque. #### I — Inspiring: abre alternativas, no sentencia “Inspiring” no es motivación cursi. Es dejar espacio a opciones . - “Nunca vamos a mejorar esto” cierra la puerta. - “Probemos una regla durante 2 semanas” abre experimentación. Una retro madura se parece más a un laboratorio que a un tribunal. #### N — Necessary: elige qué batalla sí merece tiempo Aquí entra de lleno tu comparación pedida: tiempo de decisión vs. carga cognitiva . - Si metéis demasiados temas , crece la carga cognitiva y caen la calidad y la energía. - Si intentáis decidirlo todo, sube el tiempo de decisión y baja la ejecución. Optimización recomendada: - Elegid 1 problema principal + 1 secundario (máximo). - Definid 1 acción por problema (máximo 2–3 acciones en total). - Convertid el resto en “parking lot” con responsable para triage. Esto reduce el coste mental y aumenta la probabilidad de cambio real. #### K — Kind: firmeza sin humillar “Kind” no es “ser blandito”. Es no atacar identidad. - “Eres desorganizado” = identidad - “En esta historia faltaba definición de criterios” = comportamiento/proceso Frase puente útil: - “Lo digo por el proceso, no por la persona.” - “Voy a describir hechos para que podamos mejorarlo juntas.” ## Plantillas de frases THINK para retros (listas para usar) Estas frases suenan naturales, mantienen tono profesional y bajan tensión: - Para aterrizar en hechos: “¿Podemos describir un ejemplo concreto de esta semana?” - Para volver a utilidad: “¿Qué cambio pequeño tendría más impacto en esto?” - Para evitar el ataque personal: “Hablemos del sistema: ¿qué en el proceso hace fácil que esto pase?” - Para limitar alcance (Necessary): “Esto es importante, pero hoy no llegamos. ¿Lo aparcamos con un responsable?” - Para mantener amabilidad sin perder claridad: “Lo voy a decir directo porque nos afecta: necesitamos un criterio de ‘Done’ más explícito.” ## Ejemplos técnicos: THINK en escenarios típicos de desarrollo web ### Caso 1: PRs eternas y revisiones que se atascan Crítica que rompe: “Nadie revisa PRs, así no se puede.” THINK aplicado: - True: “Hay PRs con más de 3 días sin review.” - Helpful: “Eso retrasa integración y genera conflictos.” - Inspiring: “Podemos probar rotación de ‘reviewer de guardia’.” - Necessary: “Lo decidimos hoy porque afecta cada sprint.” - Kind: “No es por culpar; es un cuello de botella del sistema.” Acción concreta (diseño de interacción del proceso): - Etiqueta needs-review - SLA interno: primera revisión en 24h laborables - “Reviewer on duty” diario (15 min) - PR template con checklist (reduce carga cognitiva del revisor) ### Caso 2: Tickets ambiguos, cambios tarde y fricción con diseño Crítica que rompe: “Diseño siempre cambia todo al final.” THINK aplicado: - True: “Recibimos 4 cambios de UI tras empezar el sprint.” - Helpful: “Eso aumenta retrabajo y sube el riesgo del release.” - Inspiring: “Probemos ‘Design freeze’ 48h antes + canal de excepciones.” - Necessary: “Si no lo acotamos, repetiremos el patrón.” - Kind: “Entiendo la presión por iterar, buscamos una forma sostenible.” Acción concreta: - Definir “punto de no retorno” visual por sprint - Figma checklist: estados, empty states, responsive, tokens - Reunión corta de handoff (15 min) con preguntas tipo THINK ### Caso 3: Bugs repetidos y discusión eterna sobre QA Crítica que rompe: “QA nos frena y encima se le escapan bugs.” THINK aplicado: - True: “Reabrimos 9 issues por criterios no definidos.” - Helpful: “Eso crea desgaste y retrasa entrega.” - Inspiring: “Si definimos criterios + casos de prueba desde el inicio, bajan reopens.” - Necessary: “Necesitamos una regla de sprint para esto.” - Kind: “Esto es de proceso compartido, no de ‘quién falla’.” Acción concreta: - “Definition of Ready” con criterios mínimos - Casos de prueba escritos en el ticket - Pairing puntual Dev+QA en historias críticas ## Cómo facilitar retrospectivas con THINK (sin sonar a policía del lenguaje) Si la facilitación se siente como “corregir a la gente”, vais a generar resistencia. Mejor: integrad THINK como diseño de la dinámica . ### Dinámica recomendada (60 minutos) - 5 min — Contexto y objetivo: 1 frase clara. - 10 min — Hechos (silencio): cada persona escribe observables. - 10 min — Agrupar + votar: dot voting (máximo 2 puntos por persona). - 20 min — Profundizar en 1 tema: Hecho → Impacto → Hipótesis . - 10 min — Acción: 1 acción, owner, fecha, métrica. - 5 min — Cierre amable: “¿Qué nos llevamos de útil?” Resultado: menos tiempo de decisión inútil, menos carga cognitiva, más foco. ## Herramientas de comunicación que ayudan (sobre todo en remoto) Para retros remotas o híbridas, el formato importa muchísimo. Algunas ideas que suelen funcionar: - Tableros con entrada anónima (reduce miedo a hablar). - Temporizador visible (evita debates infinitos). - Dot voting limitado (obliga a priorizar). - Plantillas con campos obligatorios: Hecho / Impacto / Acción . - Registro de acciones con seguimiento en la herramienta de gestión (Jira, Linear, Notion, etc.). No es “poner herramientas por poner”: es diseñar un sistema que haga fácil hablar bien . ## Preguntas frecuentes (FAQs) ### 1) ¿THINK sirve si el equipo tiene conflicto fuerte o está muy quemado? Sí, pero con matiz: THINK no sustituye una conversación difícil, la hace posible . Si el conflicto es intenso, empezad por True y Necessary : hechos y alcance. Y reducid la retro a un objetivo pequeño con una sola acción. Cuando hay burnout, menos es más. ### 2) ¿Qué hago si alguien usa la retro para atacar o ironizar? Cortadlo rápido y con calma. Una frase útil: “Voy a pedir que lo reformulemos en hechos e impacto.” Si se repite, estableced una norma explícita: “No hablamos de personas, hablamos de comportamientos y sistema”. Eso protege al equipo sin humillar a nadie. ### 3) ¿Cómo mido si las retrospectivas están funcionando de verdad? Medid señales simples: - % de acciones completadas antes de la siguiente retro - número de reopens / bugs repetidos (si era el foco) - tiempo medio de PR review (si era el foco) - mini-encuesta de 1 pregunta: “¿La retro nos ayudó?” (1–5) Si no hay cambio observable, estáis haciendo conversación, no mejora. ## Criticar con cuidado es una forma de respeto En equipos de trabajo en equipo real, la crítica no desaparece: se transforma. Se vuelve más precisa, más útil y menos dañina. Y eso es madurez. Aplicar THINK en retrospectivas no es “hablar bonito”. Es algo más serio: bajar el ruido para que el equipo pueda pensar . Cuando filtráis por verdad, utilidad, inspiración, necesidad y amabilidad, estáis defendiendo dos cosas a la vez: los resultados del proyecto y la salud del grupo. Y al final, esa es la clave que mucha gente subestima en desarrollo web : no gana el equipo que “hace más”, sino el que decide mejor con menos fricción mental . Menos carga cognitiva, menos tiempo de decisión improductivo, más acciones pequeñas que se cumplen. Eso no es suavidad: es eficiencia humana.