Get best of the week

Antipatterns de retrospectiva en el equipo Agile. Parte 1

Recientemente calculé que en el transcurso de varios años como Scrum Master, pasé más de 100 retrospectivas en equipos ágiles. Quiero hablar sobre la importancia de la retrospectiva y cómo refleja la situación en el equipo y afecta su desarrollo, en este artículo.



Algunas palabras sobre mi. Desde 2015, me he centrado en crear equipos ágiles felices y efectivos en empresas internacionales. Además, disfruto haciendo entrenamiento interno. Además del trabajo principal con el equipo, enseño Scrum Masters en la escuela y realizo capacitaciones en las áreas de pruebas Agile / Scrum / Agile. 

Desde el comienzo de mi carrera como Scrum Master, tuve la suerte de trabajar directamente con 10 equipos muy diferentes e interesantes. Cada uno de ellos se desarrolló a su propio ritmo y, sin embargo, tenían algo en común: la calidad de las retrospectivas influyó enormemente en la efectividad general del equipo. Al mismo tiempo, noté que, en cualquier equipo, la retrospectiva tarde o temprano deja de funcionar. Algo sucede y esta herramienta de inspección y adaptación más popular se descompone, es decir deja de ayudar al equipo a adaptarse y mejorar.

Sistematicé mis observaciones y me gustaría compartir los 5 antipatrones principales que conocí en mis equipos. 

Dentro de cada antipatrón, quiero discutir:

  • signos y causas de un determinado comportamiento;
  • qué hacer Scrum al maestro y al equipo para corregir la situación.

En la primera parte del artículo hablaré sobre tres antipatrones. En la segunda parte, compartiré observaciones sobre otros dos antipatrones, así como mis recomendaciones: qué pueden hacer los Scrum Masters y los equipos de manera proactiva, es decir. de antemano, incluso antes de que aparezca el comportamiento descrito en el artículo, para que la retrospectiva continúe funcionando y sea una herramienta efectiva para las mejoras en el equipo.
 

Antipatrón No. 1 "Todo está bien con nosotros"




El equipo tiene una retrospectiva, pero lo considera una formalidad. El antipatrón se manifiesta en el hecho de que el equipo, en principio, decide no llevar a cabo una retrospectiva (sin problemas, todo está bien, ¿por qué reunirse?). Pero en mi práctica, este caso fue extremadamente raro y el rechazo de la retrospectiva fue dictado por otras razones. Escribiré un artículo separado sobre ellos más tarde. Mientras tanto, volvamos a cómo reconocer este antipatrón.

Signos y razones:

el equipo se reúne, abre la plantilla de actividad estándar en retrospectiva (enojado / triste / contento o comenzar / parar / continuar), anota los principales momentos positivos de la iteración y después de 20-30 minutos diverge sin discutir problemas y el plan de mejora en el equipo. El equipo evita hablar sobre problemas o convence al Scrum del Maestro y al otro de que simplemente no hay ningún lugar para mejorar.
¿Cuál podría ser la razón de este comportamiento?

  • Los chicos pueden creer sinceramente que todo está bien con ellos: entregan el producto, el propietario del producto está satisfecho, ¿qué más se necesita?
  • Este es un equipo súper armonioso que ha estado trabajando juntos durante mucho tiempo y no puede imaginar cómo puede ser aún mejor, porque todos en la empresa son iguales a ellos.
  • Conocí a equipos cuyos miembros creían que todos los problemas existentes que estaban en la zona de control o influencia del equipo ya habían sido reparados, y el equipo todavía no tenía nada que ver con otros problemas, cuál era el punto de perder el tiempo y discutirlos nuevamente. Para tales problemas, incluso obtuve un término: "corporativo dado".

Qué hacer:

en esta historia, para mí mucho depende de cuánto yo, como Scrum Master, creo que todo está bien en el equipo, o tengo dudas al respecto.

Si tiene la sensación de que todo va muy bien en el equipo, puede proceder de la siguiente manera:

- Para ofrecer al equipo en retrospectiva una pregunta compleja que sale de la zona de confort. Por ejemplo, "lo que nosotros, como equipo, podemos llegar a ofrecer 10 veces más funcionalidades que ahora, al mismo tiempo". O "¿cómo puede alejarse por completo de la ejecución manual de la regresión?" Para algunos de mis equipos, la segunda pregunta sonaba aún más inadecuada que la primera.

Es probable que la primera reacción a esta pregunta sea un estupor y una sorpresa, pero el siguiente paso puede ser una lluvia de ideas interesante, una mirada al sistema en su conjunto e ideas interesantes para optimizar todo el proceso de entrega de valor.

- Aproveche la oportunidad para que los miembros del equipo se conozcan aún mejor y estimulen el trabajo en equipo a través de los juegos. No me detendré en el tema de los juegos, solo puedo decir que hay actividades maravillosas para trabajar con los valores de Scrum, enfocarse en un objetivo común, generar confianza en un equipo. Hay muchos formatos de juegos descritos en código abierto. Sobre los que realicé, comparto en mi blog profesional Scrum Masters.

Por supuesto, los juegos no deben ser reemplazados por retrospectivas, pero pueden convertirse en un "respiro" para el equipo, una oportunidad para cambiar el contexto de trabajo y ver la efectividad del trabajo en equipo.

Y sin embargo, ¿qué hacer Scrum to the Master, si no hay esta confianza interna de que todo está bien? Para este caso, tengo dos ideas.

El primero es expandir el contexto retrospectivo para el equipo, es decir. ampliar el ángulo de visión sobre la situación en el equipo. Por ejemplo, esto se puede lograr agregando nuevos participantes a la retrospectiva. Vi muchos equipos que realizaron retrospectivas sin la participación del propietario del producto debido a varias circunstancias (él no quería, históricamente, una barrera del idioma). Para tales equipos, se realizará una retrospectiva con la participación del propietario del producto de una manera completamente nueva. La misma idea puede realizarse invitando a miembros de otros equipos relacionados que están adelante o después del equipo en la cadena de suministro de valor. Un detalle importante: todo esto debe hacerse con el consentimiento del equipo; el invitado invitado como sorpresa probablemente traerá dolor y desconfianza al Scrum Master, en lugar de ayudar a establecer una retrospectiva.

La segunda idea es ofrecer Scrum al Maestro o a uno de los miembros del equipo para recopilar datos que nunca antes habían recopilado. Tengo un maravilloso ejemplo en mi experiencia al analizar las estadísticas recopiladas sobre la cantidad de defectos encontrados dentro del sprint (es decir, la tendencia de esta métrica en los últimos 4 sprints) llevó al equipo a discusiones muy productivas sobre cómo mejorar la calidad de las pruebas entre los desarrolladores y cómo organizar una interacción cercana de las pruebas y desarrollo dentro del sprint. A menudo sucede que, en general, el equipo se las arregla bien tanto en sus sentimientos como en los comentarios del exterior, pero todavía hay muchos puntos para mejorar, solo necesita llamar la atención del equipo sobre ellos.

Antipatrón No. 2 "Noah, nos quejamos, no hay plan"




La historia es que el equipo llega fácilmente a la retrospectiva para quejarse, resentirse, llorar, quejarse, pero no hay un plan para trabajar con problemas, como un plan de mejora, como resultado de la retrospectiva. Más precisamente, el equipo tiene un plan, se ha elaborado un conjunto de acciones, hay responsables, pero este plan no ayuda al equipo a mejorar realmente, no ayuda a establecer experimentos y probar hipótesis para aumentar la eficiencia del trabajo o mejorar la calidad del producto. Este plan es más bien una formalidad, un plan por el bien del plan.

Señales:

  • El equipo discute enérgicamente lo que está sucediendo en el equipo, pero no hay tiempo suficiente para planificarlo, y diverge hasta la próxima, en el mejor de los casos, con una lista de lo que planean trabajar en algún momento posterior. La cuestión de quién, cuándo y cómo funcionará exactamente permanece abierta.
  • , , , , : , - , .
  • , , 80-90% – , , , . , , . , ( , , ) , .

Veamos cómo puede trabajar con estas situaciones.

Qué hacer:

comencemos en orden. Para que el plan de mejora aparezca en el equipo, en primer lugar, es necesario que la agenda retrospectiva (es decir, todas sus fases: registro, recopilación de ideas, análisis de ideas, desarrollo de un plan de mejora, finalización y retroalimentación) sea transparente para el equipo y haya tiempo para elaborando un plan para acciones futuras. Tuve casos en los que no tuvimos tiempo para elaborar un plan de acción en profundidad y luego designé una sesión separada para completar la retrospectiva y formular un plan. Creo que es mejor expandir el tiempo asignado para la retrospectiva que terminarlo a tiempo, pero salir sin resultados.

Si hay problemas en el equipo para adaptarse al tiempo programado de la reunión, existe un enfoque para establecer varios temporizadores, por ejemplo, para 15, 8 y 5 minutos. Desde el principio, el equipo sabe que la discusión debe terminar al final del tercer temporizador y está más centrado en la negociación. En general, las técnicas de facilitación, la organización del trabajo en grupos pequeños y un tiempo fijo para las discusiones y las fases individuales del trabajo retrospectivo se hacen maravillas y ayudan a conducir al desarrollo de soluciones incluso para grupos con dinámicas complejas.

Entonces, ¿qué debe hacer Scrum al Maestro si el equipo trae problemas de organización en retrospectiva y evita problemas reales? Hay varias herramientas que, en mi experiencia, han ayudado:

  • – – , , , , « , ».
  • , (, ). , . , , .
  • , , , , , . . , , - .
  • , , , , . , !

№3 « , »




El nombre habla por sí mismo: se diseñó un plan para el equipo, pero no se realizan acciones o experimentos inventados.

Señales: Las

señales de antipatrón son bastante obvias: en la próxima retrospectiva, el equipo no tiene nada que compartir como resultado de la implementación de acciones o acuerdos previamente pensados. Todos, por supuesto, tienen buenas razones: no tuvo tiempo, sus manos no llegaron, estaba ocupado en asuntos más importantes, se olvidó. Pero como resultado del progreso en términos de mejoras y experimentos, no.

Hablando de este antipatrón, quiero hacer hincapié en las "llamadas perturbadoras" en la etapa de compilación del plan, que en mi práctica a menudo eran señales de que las acciones del plan no se llevarán a cabo:

  • action items (.. ) «, , ». , , .
  • , , . , , « unit ». , , , « », « », , . «, , » .
  • , : «, , , wiki , », « / , , », «, 3 , , , », « , , , »

¿Qué estoy haciendo en una situación en la que aparecen planes en mi equipo que están escritos pero no realizados? Recuerdo que si las personas no hacen algo, puede haber las siguientes razones:

1. No entiendo
2. No puedo
3. No puedo
4. No quiero

Este pensamiento me ayuda mucho a detenerme y pensar si es posible excluir opciones "No entiendo, no puedo, no sé cómo", antes de comenzar a trabajar en el campo "No quiero" y lidiar con la motivación de la persona, por qué está en el equipo y cuáles son sus objetivos.

¿Qué hacer?

Veamos qué se puede hacer exactamente, según cuál sea el motivo de la inacción.

Razón 1: un miembro del equipo que acordó asumir algún elemento de acción realmente no entendió lo que se esperaba de él.

  • , .
  • , , , , .
  • , , , - . 

Razón 2: un miembro del equipo y estaría encantado de cumplir con el elemento de acción que asumió, pero físicamente no puede hacer esto, porque ocupado con otras tareas y no tiene tiempo para esto en el sprint.
 
Scrum Master puede agregar la actividad más importante del plan desde la retrospectiva hasta el retraso del sprint (después de acordar esto con el propietario del producto en el retro o posterior), evaluarlo, observar quién lo hará, hacer transparente a todos que el equipo pasará tiempo en esto. 

Razón 3: un miembro del equipo nuevamente estaría contento de cumplir con lo que se inscribió, porque realmente está interesado e importante (por ejemplo, elegir el marco más adecuado para las pruebas de estrés), pero nunca ha tenido ningún negocio con esto antes y nunca puede averiguar por dónde empezar. Aquí es donde termina, ya que puede ser desagradable explicarle al equipo por qué realizó esta actividad si no sabe cómo.

Scrum Master puede consultar con alguien que esté listo para realizar la actividad bajo el plan retro, si tenía que hacer algo como esto antes. Si no, seguramente hay alguien en el equipo con más experiencia en este asunto que podría ayudar. Y si todo el equipo no tiene experiencia en el campo, el Scrum Master puede asumir la tarea de buscar expertos en otros equipos o en la comunidad.

Tengo una práctica de bonificación más, que realmente ayuda al equipo a cumplir el plan: colgar las actividades del plan en un lugar destacado para el equipo. Idealmente, cada miembro del equipo que realizó algún tipo de actividad le quitó una pegatina con este TO DO para colgarlo en un lugar destacado del escritorio y no olvidarlo. Dicen que si la meta está frente a los ojos, una persona consciente e inconscientemente va hacia ella. Este enfoque me gusta mucho más que recordarle regularmente al equipo que se acerca retro y que vale la pena refrescarse en la memoria de cuál fue el plan la última vez.

Entonces, compartí mis pensamientos sobre los primeros tres antipatrones de retrospectiva en los equipos ágiles que conocí en mi práctica, y hay dos antipatrones más, no menos interesantes y no menos comunes.

Estaré encantado de escuchar sus historias y observaciones sobre retrospectivas que funcionan y que no. Cuéntanos qué técnicas y técnicas tienes para construir retrospectivas efectivas. ¿Adivina de qué dos antipatrones pienso contar en la secuela?
 

More articles:


All Articles