Cómo entrenar a un PO dominante para que se suelte y permita que un equipo se autogestione

Si bien parece una pregunta psicológica y no se relaciona con las metodologías, no estoy de acuerdo en que sea un callejón sin salida y que no se pueda cambiar el comportamiento de las personas. Pero primero debe comprender las razones subyacentes de tal comportamiento, que podrían ser:

• No cree que los demás hagan un trabajo lo suficientemente bueno.
• Quiere hacer las cosas rápido y cree que mientras otros son capaces de hacer un buen trabajo, no serán lo suficientemente rápidos.
• Ella no quiere parecer (por ejemplo, a su jefe) inútil
• A ella le gusta mandar, la imagen y todo eso.

Una vez que comprenda lo que subyace a este comportamiento "dominante", puede intentar idear un plan para solucionarlo. Algunas soluciones que pueden funcionar para algunas personas:

• Pídale que dé más control a uno o dos de sus mejores empleados. Para que los riesgos (de fallar) sean bajos. Trabaje durante un par de meses en este modo y luego comience a expandirse. Si ella no cree que el resultado será de buena calidad, entonces cualquier falla puede ser un retroceso. Así que tómelo con calma, asegúrese de que el equipo sea realmente capaz.
• Trate de poner más trabajo en ella. Por ejemplo, hable con los superiores, tal vez puedan darle más proyectos. Esto resulta en cualquiera de 2:
  • Ella no tendrá suficiente tiempo para seguir tu progreso y por lo tanto te dará más control (tu victoria)
  • Simplemente trabajará más y tratará de seguir dominando, pero ahora que tiene más en su plato se volverá más irritable (usted pierde).
• Alguien del equipo puede estudiar una parte del dominio, hablar con los usuarios, las partes interesadas y convertirse en un mejor experto en esa parte que ella. Dicha persona será igual (o cercana) a ella durante las discusiones sobre esa funcionalidad en particular. De esta manera ella puede estar más ansiosa por confiarlo.

De todos modos, experimentaría. Creo que es crucial que el equipo comprenda muy bien el dominio para que este plan tenga éxito.

Pero también tendría cuidado de no sobrestimar al equipo. Sigues oyendo hablar de equipos autoorganizados/autogestionados como si fuera algo bueno y debiéramos esforzarnos por lograrlo. Pero la mayoría de los equipos (al menos por lo que he visto) inherentemente no son capaces de autoorganizarse. Y moverse en esta dirección puede ralentizar el proceso y, en consecuencia, alejar a las personas que son realmente capaces de hacer un buen trabajo (tal vez sea su PO).

TL;RD

No, no, no. Simplemente no."

La pregunta se basa en la suposición errónea de que puede forzar el cambio en otras personas (pista: no puede), y desea lo que parece ser una mala composición del equipo en el campo de maíz.

Por qué estás haciendo la pregunta equivocada

El propietario del producto con el que estoy trabajando acordó "probar estas cosas de autoorganización" en nuestro equipo Scrum.

Esta es una señal de alerta que le dice que una persona a la que ha descrito como "dominante" está dispuesta a aceptar la adopción ágil con la mano, o a complacer la solicitud sin comprometerse realmente con ninguno de los valores ágiles o de Scrum. Esta no es una base sólida para el cambio.

Usted está haciendo una pregunta que asume ab initio que existe una bala de plata que le permitirá cambiar a esta persona, que actualmente no es adecuada para ser miembro de un Equipo Scrum. El Product Owner es un miembro del equipo con responsabilidades específicas , no un dictador autoritario elegido de por vida. La Guía Scrum dice:

Dentro de un Equipo Scrum, no hay sub-equipos ni jerarquías. Es una unidad cohesiva de profesionales enfocados en un objetivo a la vez, la Meta del Producto... El Equipo Scrum está... estructurado y facultado por la organización para gestionar su propio trabajo.

Entonces, cualquier encuadre del problema que no comience allí está destinado a ser un espectáculo secundario de proporciones épicas, lleno de drama y lágrimas. Solo el propietario del producto puede cambiar su propio comportamiento y, para hacerlo, debe querer cambiar. Sin eso, es una pérdida de tiempo.

Las preguntas correctas

Las preguntas correctas son:

1. Si la organización quiere hacer Scrum, ¿por qué han asignado un Product Owner no ágil al rol?
2. Si el equipo quiere hacer Scrum, ¿por qué no están colaborando con el Product Owner en formas de ayudarse mutuamente sin abusar de las responsabilidades de los demás?
3. Si usted (presumiblemente como Scrum Master) quiere hacer Scrum, ¿por qué le pregunta a extraños en Internet cómo recopilar información específica del proyecto sobre las personalidades y los procesos de su equipo en lugar de preguntar a los miembros del Equipo Scrum?

No te hagas estas preguntas a ti mismo. Como Scrum Master, debe tener el compromiso, el enfoque, la apertura, el respeto y el coraje para hacer estas preguntas a todos los involucrados, tanto por separado como en conjunto. Este no es su problema para resolver; es un problema del Equipo Scrum, y dejarlo sin resolver lo convierte en un problema de la organización.

Qué hacer a continuación

El Product Owner tiene un rol claramente definido (pronunciado "responsabilidades" en la Guía Scrum 2020), y el Equipo Scrum debe trabajar en conjunto para desarrollar acuerdos de trabajo internos que respalden (pero no contrarresten) los requisitos del marco. Eso significa que el comportamiento "dominante" debe ser:

1. Abordado por todo el Equipo Scrum en la Retrospectiva del Sprint más cercana, si no impide el progreso dentro del Sprint actual.
2. Se usa como una razón para detener la línea y resolver el problema de forma colaborativa, si está arriesgando activamente el Sprint Goal actual.
3. Criado con la línea o la alta dirección, ya que son los responsables últimos de la composición del equipo y la gestión del personal.

Como Scrum Master, puede y debe entrenar a esta persona tanto como sea posible. Explique los roles/responsabilidades, ayúdelos a comprender los principios ágiles , la teoría de Scrum y los valores de Scrum lo mejor que pueda, e incluso déles algunas tareas de lectura sobre prácticas ágiles y estudios de casos si encuentra algo adecuado. Sin embargo...

Su trabajo es arbitrar el proceso

El Scrum Master no es solo un líder-servidor pasivo. La Guía Scrum 2020 lo ha dejado claro. Las responsabilidades de un Scrum Master incluyen:

El Scrum Master es responsable de establecer Scrum como se define en la Guía Scrum. Lo hacen ayudando a todos a comprender la teoría y la práctica de Scrum, tanto dentro del equipo Scrum como en la organización.

El Scrum Master es responsable de la efectividad del Scrum Team. Lo hacen al permitir que el Equipo Scrum mejore sus prácticas, dentro del marco Scrum.

Por lo tanto, si no responsabiliza al propietario del producto (y al resto del equipo Scrum) por colaborar de manera efectiva dentro del marco Scrum, entonces tampoco está desempeñando su función correctamente. Su trabajo es educarlos sobre el marco, ayudarlos a aplicar el marco a sus problemas y procesos, y aumentar la visibilidad de los problemas insuperables de composición del equipo para el liderazgo senior. De hecho, la Guía Scrum 2020 dice (énfasis mío):

El Scrum Master sirve a la organización de varias maneras, que incluyen:

• Liderar, capacitar y asesorar a la organización en su adopción de Scrum;
• Planificar y asesorar implementaciones de Scrum dentro de la organización;
• Ayudar a los empleados y partes interesadas [incluido el liderazgo] a comprender y promulgar un enfoque empírico para el trabajo complejo; y,
• Eliminación de barreras entre las partes interesadas y los Equipos Scrum .

El último es especialmente importante. Los problemas con la composición del equipo están (en muchas organizaciones) fuera del control del Equipo Scrum. Por lo tanto, los problemas que no se pueden resolver dentro del equipo a través de la autogestión y la colaboración deben hacerse visibles para la organización , y la responsabilidad de solucionar los problemas de composición del equipo o resolver los problemas de recursos humanos es, en última instancia, responsabilidad del liderazgo de la organización.

Como Scrum Master, debe tener el coraje y el compromiso de plantear estos problemas cuando sea necesario. Si el Equipo Scrum en su conjunto carece de las habilidades, el compromiso o la disposición para abordar los problemas de comunicación y proceso de frente, entonces Scrum brinda una guía clara sobre qué hacer: brindar transparencia y visibilidad del problema a la organización, y luego mantener la responsabilidad . los líderes de la organización son responsables de resolver las cosas que solo ellos están facultados para resolver.

Por todos los medios, trabaje con el propietario del producto y los desarrolladores para hacer visibles los problemas y guiar la colaboración donde sea posible, pero su trabajo no es morir en la colina de los conflictos interpersonales dentro del equipo. Explique el proceso, guíe al equipo en la aplicación del proceso y ayude al equipo a adaptar el proceso, pero al final, cada miembro del Equipo Scrum es totalmente responsable de su propia participación efectiva (o la falta de ella) en el proceso. No puedes obligarlos a hacerlo, o incluso hacer que quieran hacerlo.

Scrum no es una panacea. No puede convertir a las personas que no se autorrealizan en un equipo cohesivo y de alto rendimiento a través de la magia. Requiere compromiso y trabajo duro de todo el equipo, así como cierto nivel de impulso intrínseco de los miembros del equipo. Su trabajo principal en esta situación es determinar si se trata de una montaña o un grano de arena, y luego ayudar al equipo y a la organización a explorar el espacio de la solución hasta que todos estén de acuerdo en un experimento o plan de acción que sea lo mejor para el equipo en su conjunto. , el proyecto actual y la organización.

Tomando un enfoque diferente al de Barnaby, lo que sugeriría es enfocarse en lo que se necesita de ella, en lugar de lo que es problemático para ella. (O combine los dos enfoques).

Repase la Guía Scrum con todo el Equipo, poniendo énfasis en la sección sobre las responsabilidades de los roles. Luego, si/cuando comience a afirmar su presencia en el equipo (de una manera en la que obviamente no es una afirmación correcta), pídale que lo justifique.

"¿Puede explicar cómo se relaciona exactamente esto con usted que representa las necesidades del cliente?"

"No es así, pero aún debemos ser conscientes del impacto en el proyecto".

"Gracias, entonces lo tomaremos en consideración al tomar nuestra decisión. ¿Algo más?"

Lo que, por supuesto, también deja espacio para el caso cuando:

"¿Puede explicar cómo se relaciona exactamente esto con usted que representa las necesidades del cliente?"

"El cliente ha solicitado específicamente evitar el uso de widgets flexibles".

"...¿Por qué?"

"Tendré que verificar dos veces, pero creo que porque son incompatibles con sus servidores".

"Está bien, bueno, verifique dos veces, por favor, y mientras tanto, intentaremos pensar en otra cosa".

La clave será tener formas de resaltar el impacto de la microgestión del propietario del producto. Si no puede demostrar el impacto, hay poco para evitar que regresen a sus viejas costumbres.

Por ejemplo:

"Sally fue bloqueada hoy porque estaban esperando que el propietario del producto decidiera qué hacer a continuación. Si hubieran podido tomar esa decisión por sí mismos o en conjunto con el equipo, nos podrían haber ahorrado varias horas".

Como ya se mencionó, no puedes convencer a una personalidad dominante de que no sea dominante.

Tampoco estoy seguro de que ella vea el mundo como tú, que es:

Uno en el que ella dirige y gestiona el equipo, pero también se responsabiliza en gran medida de la producción y el mantenimiento o, alternativamente, podemos trabajar juntos para construir un equipo autoorganizado para asumir la propiedad y la responsabilidad .

Es decir, dado que ella está "microgestionando", es responsable de las consecuencias, pero si "se suelta", entonces el equipo es responsable.

Sospecho que puede estar haciendo una suposición.

Puede que se considere responsable de cualquier manera, o que no entienda por qué es responsable en cualquiera de los escenarios, eso también depende de su personalidad.

Una vez que aclare su weltanschauung sobre este tema, puede intentar mejorar la situación.

• Si ella se ve responsable "sin importar nada", entonces tienes que demostrarle que darle a tu equipo el margen de maniobra que necesita, producirá mejores resultados para ella.

• Si ella responsabiliza al equipo, entonces tienes un trabajo más difícil; tratando de persuadirla de que ella está a cargo, mientras gana algo de independencia. Estás en conflicto directo con toda su personalidad.

De acuerdo, voy a volver a agregar mi "respuesta rechazada" una vez más.

"Eres un proyecto de software. Bien por ti. Te organizas o te autoorganizas como quieras. Bien por ti".

"¡Tú no eres el propietario del producto!"

El propietario del producto es la interfaz más importante entre todo el proceso de desarrollo y la empresa que lo paga. Y, ¿me importaría mencionar que: "la empresa no sabe, entiende o no le importa?"

El rol del propietario del producto es mucho más que el de un mero "representante". El papel del propietario es verdaderamente el de Jano: "el dios de dos cabezas". Es un papel que con frecuencia es malinterpretado por "aquellos que yacen debajo", y no es un papel para ser envidiado. El dueño es quien te protege .

Por encima de su equipo, "el negocio" responsabilizará al propietario . Y, "el propietario" absorberá esa responsabilidad para que, a propósito, ninguno de ustedes tenga que hacerlo. Pero, la responsabilidad sigue ahí.