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 todos están en 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 evalúa. 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 «efecto trinquete» de la 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 mecanismo de 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 hacia arriba. 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, pero 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» en su ámbito es DORA. Una década de investigación sobre los factores que predicen el rendimiento en la entrega de software dio como resultado cuatro métricas clave (frecuencia de implementación, tiempo de entrega, tasa de fallos en los cambios y tiempo de recuperación), y la «velocidad» no figura entre ellas; 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 antes de llegar a esa cifra. La respuesta sincera es: «¿Qué está intentando medir realmente?». Nuestro capítulo sobre la velocidad muestra cómo mantenerla sincera, y la planificación de la velocidad y la capacidad muestra cómo utilizarla para lo único para lo que sirve.
Blanqueo de presupuestos
La segunda distorsión es más sutil, ya que aparenta ser una cuestión de responsabilidad. 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 fija un plazo; y, cuando se incumple dicho plazo, la culpa recae sobre 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 estar bien, hágalo de nuevo») hasta que el equipo da la cifra que sea necesaria para que se cumpla el plazo, 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 precisamente esa 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 sobre «puntos de historia frente a horas» desglosa por qué la conversión es la causa del fallo, y no la solución.
Banca de retroalimentación
La tercera distorsión es la más grave, ya que convierte lo que parece ser una ceremonia inofensiva en un riesgo. El «acumulado de comentarios» se produce cuando las opiniones retrospectivas sinceras se van acumulando y, más adelante, se utilizan discretamente en su contra: en una evaluación de rendimiento, en la fijación de una bonificación o en una conversación discreta sobre su «adecuación». La reunión retrospectiva se presenta como un espacio seguro para expresarse con franqueza. El «acumulado de comentarios» es el descubrimiento de que la franqueza tiene una fecha de vencimiento.
Las anécdotas son concretas y duelen. Un ingeniero describió cómo sus comentarios negativos resurgían en una 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. Este 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 aportaciones 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 de modo 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 y el Proyecto Aristóteles de Google —dos años de estudio de 180 equipos— revelaron 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 archivan carece, por definición, de seguridad psicológica, y la retrospectiva que pretende 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 responsable 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 en que esa persona se marcha.
Esa es la diferencia entre el «poder» como modo de fracaso y el «poder» como algo inmutable. El capítulo sobre la seguridad psicológica aborda cómo fomentar una franqueza que no 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 apariencias controladas, se ha llegado al vacío de seguimiento: el cuarto modo, y aquel en el que el «almacenamiento 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. No forma parte de las métricas de entrega de DORA y, de todos modos, 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á tratando de medir? Informe de los resultados y de la entrega, no del recuento total 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 informan de que los comentarios sinceros de las sesiones retrospectivas resurgen meses después en forma de una observación en la que se les acusa de quejarse demasiado. 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 supone un riesgo para la carrera profesional no es psicológicamente segura, y ninguna técnica de moderación puede solucionarlo. Hay que corregir la estructura 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 ambas cosas y luego exigir al equipo que las 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 de Standups?
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: donde confluyen la retroalimentación acumulada y la impotencia.
- Representación: la ceremonia que usted escenifica para el público; el teatro que el poder convierte en algo coercitivo.
- Velocidad: para qué sirve y cómo calcularla: utilice este dato 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 considera que una estimación es, ante todo, una previsión de la que es responsable el equipo, y no un compromiso.
- Cómo crear un espacio psicológicamente seguro: una franqueza que no dependa de quién se encuentre en la sala.
- Glosario de «Agile Theatre»: «blanqueo de estimaciones», «acumulación de comentarios» y «trinquete de velocidad», definiciones.