El poder: cuando la autoridad se apodera de la ceremonia

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. Elimine esas suposiciones —añada 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— y la ceremonia no solo dejará de dar los resultados esperados. Se invertirá. Empezará 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 puede que haya inventado los puntos de historia y, si lo hice, ahora lo lamento», escribió Ron Jeffries en 2019; y, concretamente, «creo que comparar a los equipos en función de la calidad de sus estimaciones o de su velocidad resulta perjudicial». Cuando el propio creador 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 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» 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» no figura deliberadamente 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 más allá de la cifra: la respuesta honesta es «¿qué es lo que realmente está intentando medir?». Nuestro capítulo sobre velocidad muestra cómo mantenerla honesta, y 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, y a continuación 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 sobre el desarrollador por «no haber cumplido su estimación».

Los profesionales describen todo el ciclo de «blanqueo» sin que se les tenga que preguntar: 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 «story points» 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 caso de acumulación: 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» desglosa 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 «acumulación de comentarios» consiste en que los comentarios retrospectivos sinceros 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 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 vencimiento.

Las anécdotas son concretas y duelen. Un ingeniero describió cómo los comentarios negativos de antaño 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 que aprueba los ascensos no tiene por qué decir ni una 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 fingir satisfacción. Nuestro capítulo «Por qué fracasan las retrospectivas» aborda el diseño de la sesión para que la honestidad 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 importante 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 un 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 inherente a la solución. Estas distorsiones suelen quedar ocultas porque alguien de alto rango —un jefe de equipo, 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: tiene una que es 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 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 apariencias controladas, 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; la investigación de 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á tratando de medir? Informe sobre los resultados y la entrega, no sobre el recuento total de puntos.

¿Se pueden utilizar los comentarios retrospectivos en mi contra en una evaluación de rendimiento?

Esto 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 comentarios en los que se les acusa de quejarse demasiado. A esto se le denomina «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 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 explícita 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?

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 ya supone, por defecto, 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 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 este dato para realizar previsiones, nunca para calificar.
• Puntos de historia frente a horas — por qué la conversión favorece 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 el equipo es responsable, 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 — Definiciones de «blanqueo de estimaciones», «acumulación de comentarios» y «trinquete de velocidad».