El poder: cuando la autoridad se apodera de la ceremonia
El segundo modo de fracaso del teatro ágil: las distorsiones de autoridad que acaban con la honestidad. El «efecto trinquete de la velocidad», el «blanqueo de estimaciones» y el «acumulación de comentarios» son las tres formas en que un desequilibrio de poder hace que una ceremonia se vuelva en contra del equipo.
Toda ceremonia ágil parte de la base de que existe igualdad de condiciones. El poder surge cuando no es así.
El «Planning Poker» solo evita el efecto de anclaje si nadie en la mesa puede invalidar las cartas. Una retrospectiva solo es fiable si la honestidad no conlleva ningún coste. La «velocidad» solo es una previsión si nadie por encima del equipo la califica. Si se eliminan esas suposiciones (se añade un responsable que apruebe los ascensos, una métrica que se transmita a los niveles superiores, una estimación que se convierta en una promesa), la ceremonia no solo deja de dar los resultados esperados. Se invierte. Empieza a actuar en contra de las personas para las que fue concebida. En este capítulo se señalan las tres formas más evidentes en las que esto ocurre, ya que identificarlas es el primer paso para rechazarlas.
El trinquete de velocidad
Empecemos por el argumento más contundente de todos: la persona que inventó los «story points» se ha desmarcado de ellos. «Me gusta decir que quizá yo inventé los “story points”, y si lo hice, ahora lo lamento», escribió Ron Jeffries en 2019. Fue muy concreto: «Creo que comparar a los equipos en función de la calidad de sus estimaciones o de su velocidad resulta perjudicial». Cuando el propio inventor de una unidad le indica que dicha unidad se está utilizando para perjudicar a los equipos, la carga de la prueba recae sobre cualquiera que siga utilizándola como indicador de rendimiento.
El mecanismo de trinquete de velocidad es la forma en que se produce ese perjuicio. La velocidad está concebida como una autoevaluación interna del equipo: la media móvil de los puntos completados, que se utiliza para prever cuánto tiempo llevará completar el backlog. En el momento en que deja de ser un objetivo de productividad, se convierte en un trinquete: la cifra del último sprint es el mínimo de este sprint, y la única dirección en la que se permite que se mueva es al alza. Los equipos no son tontos, por lo que responden de la única forma que el incentivo les permite. Inflan las cifras. Una historia que era un 3 el trimestre pasado es un 5 este trimestre, la cifra sube y nada se entrega más rápido. Incluso Mike Cohn, la autoridad a favor de los puntos, reconoce este mecanismo: el más mínimo indicio de que se compararán las velocidades produce una inflación gradual y constante de los puntos.
La base más sólida y citable para mantener la «velocidad» dentro de su ámbito es DORA. Una década de investigación sobre los factores que predicen el rendimiento en la entrega de software ha dado lugar a cuatro métricas (frecuencia de implementación, tiempo de entrega, tasa de fallos en los cambios y tiempo de recuperación), y la «velocidad» se ha excluido deliberadamente de entre ellas, ya que los puntos de historia no son comparables entre equipos y miden el esfuerzo, no el valor entregado. Por lo tanto, la regla es sencilla y defendible: utilice la velocidad para realizar previsiones, pero nunca para evaluar. Si alguien ajeno al equipo pregunta «¿es buena su velocidad?», la solución se encuentra en la fase previa a la obtención de esa cifra. La respuesta sincera es: «¿Qué está intentando medir realmente?». Nuestro capítulo sobre velocidad muestra cómo mantener la honestidad al respecto, y la planificación de la velocidad y la capacidad explica cómo utilizarla para lo único para lo que sirve.
Blanqueo de presupuestos
La segunda distorsión es más sutil, ya que parece una forma de rendir cuentas. El blanqueo de estimaciones consiste en la conversión silenciosa de una estimación (una suposición, realizada con la mínima información de la que se dispondrá jamás) en un compromiso, para luego exigir al equipo que lo cumpla como si hubiera firmado un contrato. La suposición se presenta en la reunión de planificación; se establece un plazo; y, cuando este plazo se incumple, la culpa recae en el desarrollador por «no haber cumplido su estimación».
Los profesionales describen todo el ciclo de «blanqueo» sin que se les tenga que pedir: las estimaciones se convierten por arte de magia en compromisos, y si no se alcanza la cifra, la responsabilidad recae sobre usted. Las estimaciones se rechazan («eso no puede ser correcto, hágalo de nuevo») hasta que el equipo ofrece cualquier cifra que permita cumplir con la fecha, momento en el que la planificación se convierte en una farsa con una respuesta predeterminada. Existe incluso una reveladora asimetría en el lenguaje: si dice «esto llevará diez días», un responsable le presionará preguntando «¿está seguro de que no pueden ser nueve?»; si dice «esto son diez puntos», y por razones que nadie puede defender del todo, ese mismo instinto no se activa. Los puntos de historia se concibieron, en parte, como una armadura contra esa misma presión, y el «blanqueo de estimaciones» es la presión que vence a la armadura al convertir los puntos directamente de nuevo en una fecha.
La solución canónica es la de Mike Cohn, y es anterior a nuestro término: separar la estimación del compromiso. Una estimación es una distribución de probabilidad; un compromiso es una decisión que toma el equipo sobre lo que está seguro de poder entregar. Manténgalas separadas, de forma explícita. Prevea un rango y especifique los supuestos en los que se basa. Y esté atento al efecto acumulativo. Cuando el alcance, el tiempo y el coste se fijan por adelantado y el trabajo simplemente se divide en sprints de dos semanas, no se trata de agilidad con estimaciones, sino de un método en cascada disfrazado. Dave West, de Forrester, lo denominó «water-scrum-fall», y el «blanqueo de estimaciones» es su núcleo. Nuestro capítulo «Puntos de historia frente a horas» analiza por qué la conversión es la causa del fracaso, y no la solución.
Gestión de comentarios
La tercera distorsión es la más oscura, ya que convierte la ceremonia que parece más segura en un lastre. El «banco de comentarios» consiste en que los comentarios retrospectivos sinceros se acumulan y se utilizan discretamente en su contra más adelante: en una evaluación de rendimiento, en la fijación de una bonificación o en una conversación discreta sobre su «adecuación al puesto». La sesión retrospectiva se presenta como un espacio seguro para expresarse con franqueza. El «almacenamiento de comentarios» es el descubrimiento de que la franqueza tiene una fecha de liquidación.
Las anécdotas son concretas y duelen. Un ingeniero describió cómo sus comentarios en las retrospectivas resurgían en la evaluación anual como prueba de que «se queja demasiado». Otro explicó el mecanismo sin rodeos: la dirección acumula todas las quejas para sacarlas a relucir en la revisión anual de la bonificación. El efecto disuasorio ni siquiera requiere malicia. La persona encargada de aprobar los ascensos no tiene por qué decir ni una sola palabra en la sala. Su mera presencia basta para que las opiniones sinceras se vuelvan vagas y para enseñar a todos que lo más inteligente es aparentar satisfacción. Nuestro capítulo «Por qué fracasan las retrospectivas» aborda cómo diseñar la sesión para que la sinceridad deje de suponer un coste para la carrera profesional.
Es aquí donde la literatura sobre seguridad deja de ser meras generalidades. El trabajo de Amy Edmondson sobre la seguridad psicológica, así como el Proyecto Aristóteles de Google —que durante dos años estudió a 180 equipos—, reveló que la seguridad psicológica es el más sólido de los cinco factores identificados: aquel sobre el que se asientan los otros cuatro. Un equipo que ha comprendido que sus comentarios se guardan en el cajón carece, por definición, de seguridad psicológica, y la retrospectiva que pretenda lo contrario no es más que una farsa que conlleva un riesgo legal. La Guía de Scrum define la retrospectiva como el proceso en el que el equipo se evalúa a sí mismo. Entonces, ¿por qué está el responsable en la sala tomando notas?
No confíe en un héroe
Existe un modo de fallo en el propio remedio. Estas distorsiones suelen quedar ocultas porque alguien de alto rango (un responsable, un gestor de proyectos con carácter) protege personalmente al equipo: se niega a transmitir la «velocidad» a los niveles superiores, reformula las estimaciones como previsiones y mantiene el contenido de la retrospectiva dentro de la sala. Funciona, pero solo mientras esa persona permanezca en su puesto. Un escudo no es un sistema. Si la honestidad de sus ceremonias depende de la disposición de un solo directivo a absorber la presión, no dispone de ceremonias seguras. Dispone de una situación temporalmente benévola, y la farsa se reanuda el día que esa persona se marcha.
Esa es la diferencia entre el «poder» como modo de fracaso y el «poder» como algo fijo. El capítulo sobre la seguridad psicológica aborda cómo fomentar la franqueza sin que esta dependa de quién se encuentre en la sala, y la Directiva Principal trata sobre la norma que hace que esto se mantenga. Cuando la ceremonia formal acaba por no producir más que una imagen controlada, se ha llegado al vacío de seguimiento: el cuarto modo, y aquel en el que la acumulación de comentarios causa su daño más silencioso.
Preguntas frecuentes
¿Cómo puedo evitar que la dirección utilice la «velocidad» en contra de mi equipo?
Mantenga esta cifra en el ámbito del equipo. La velocidad es un dato de referencia para la previsión, no un indicador de rendimiento. El estudio DORA la excluye deliberadamente porque los puntos no son comparables entre equipos. Si un responsable ajeno al equipo le pregunta si su velocidad es buena, la respuesta honesta es devolverle la pregunta: ¿qué es lo que realmente está intentando medir? Informe de los resultados y de la entrega, no de los totales de puntos.
¿Se pueden utilizar los comentarios retrospectivos en mi contra en una evaluación de rendimiento?
Es algo que ocurre, y el temor es razonable. Los participantes relatan que las aportaciones sinceras realizadas en las sesiones retrospectivas resurgen meses después en forma de comentarios en los que se les acusa de quejarse en exceso. Eso es lo que se conoce como «acumulación de comentarios», y es la razón por la que existen el anonimato, la exclusión de los responsables y la «regla de Las Vegas». Una sesión de retroalimentación en la que la franqueza suponga un riesgo para la carrera profesional no es psicológicamente segura, y ninguna técnica de moderación puede solucionarlo. Hay que corregir la dinámica de poder, no la redacción.
¿Cómo puedo evitar que los plazos estimados se conviertan en plazos definitivos?
Separe la estimación del compromiso, de forma clara y deliberada. Una estimación es una probabilidad; un compromiso es una promesa; mezclar una cosa con la otra y luego exigir al equipo que la cumpla es lo que rompe la confianza. Prevea un margen, especifique los supuestos y nunca permita que una suposición realizada en una reunión de planificación se cite posteriormente como una fecha a la que el equipo se haya comprometido.
¿Debería mi jefe asistir a la retrospectiva o dirigir la reunión diaria?
Por lo general, no. La Guía de Scrum define la retrospectiva como un proceso en el que el equipo se evalúa a sí mismo, y la reunión diaria como un momento de coordinación entre los propios desarrolladores. La mera presencia de una figura de autoridad en la sala basta para coartar la sinceridad, sin que tenga que decir ni una sola palabra. La persona encargada de aprobar los ascensos es, por definición, una presencia intimidatoria. Comparta las medidas a tomar con los superiores, no los puestos.
Lecturas relacionadas
- El vacío del seguimiento: el punto de encuentro entre la retroalimentación acumulada y la impotencia.
- Representación: la ceremonia que usted lleva a cabo ante el público: el teatro que el Poder convierte en algo coercitivo.
- Velocidad: para qué sirve y cómo calcularla: utilice esta cifra para realizar previsiones, nunca para calificar.
- Puntos de historia frente a horas: por qué la conversión fomenta el «blanqueo» de estimaciones.
- Planificación del sprint (la ceremonia): en la que se pretende que la estimación sea una previsión de la que se hace responsable el equipo, y no un compromiso.
- Cómo crear un espacio psicológicamente seguro: una franqueza que no dependa de quién esté presente en la sala.
- Glosario de Agile Theatre: «blanqueo de estimaciones», «acumulación de comentarios» y «efecto trinquete de la velocidad», definiciones.