Cuando un Scrum Master comienza un nuevo trabajo, generalmente dos cosas son ciertas: todos quieren que comience su trabajo de inmediato y nadie está seguro de qué trabajo debe hacer. La gerencia a menudo espera que se apresure en el proceso y comience a resolver los problemas que se han estado acumulando durante algún tiempo. Quieren que el equipo del Scrum Master se desempeñe de inmediato, pero solo tienen expectativas vagas de cuál debería ser el rol.
La combinación de urgencia y ambigüedad en estos primeros días puede llevar a un Scrum Master a cometer muchos errores. Veamos algunos de los errores más comunes que cometen los Scrum Masters en un nuevo rol, equipo de proyecto u organización. Explicaré cuál es la mejor manera de dirigir su tiempo y energía para optimizar el desempeño de su equipo como un servidor-líder eficaz y agente de cambio.
Errores comunes de Scrum Master
He trabajado con Scrum durante más de una década, tanto como entrenador Agile como Scrum master. Durante ese tiempo, he notado varios patrones y he identificado errores comunes que cometen los Scrum Masters. Aquí hay cuatro que veo con más frecuencia:
1. Centrarse demasiado en las ceremonias
La parte más obvia de su trabajo como Scrum Master es facilitar las ceremonias, por lo que puede parecer lógico comenzar por configurar, programar, ejecutar y hacer un seguimiento de estos eventos. Aparentemente, a partir de ahí, podría establecerse en otros aspectos fácilmente definidos de su función: optimizar la herramienta de gestión de proyectos , crear tableros, abrir tareas, registrarse después de su finalización, ayudar al equipo a comprender las técnicas correctas de acumulación, etc.
Si bien esto puede parecer una forma segura de comenzar, centrarse únicamente en las ceremonias y las tareas diarias durante sus primeros días en el trabajo corre el riesgo de tergiversar los deberes del Scrum Master como principalmente administrativos. Ante una guía limitada, los miembros del equipo seguirán siendo los mismos, solo interactuando con el Scrum Master para mover sus tareas a través de las etapas del flujo de trabajo, agregar comentarios y notas para el propietario del producto o resolver impedimentos. Más bien, desde el primer día, piense en cómo actuar como un agente de cambio , no como un administrador del statu quo. Los eventos y las ceremonias son importantes, pero no excluyen sus responsabilidades menos visibles, como alinear la dinámica del equipo con la cultura de la empresa o establecer objetivos a largo plazo.
2. Asumir que la gerencia conoce los problemas reales
Como Scrum Master, es posible que lo contraten, al menos en parte, para solucionar problemas de procesos en un equipo en particular. Pero recuerde lanzar una red más amplia cuando busque soluciones: los problemas pueden surgir dentro del equipo, pero también pueden provenir de la falta de soporte adecuado, una mala alineación entre el negocio y TI, bajos niveles de empoderamiento, equipos mal formados o falta de tutoría y aprendiendo.
Hay muchas herramientas que pueden ayudarlo a identificar áreas problemáticas, incluido el marco de valores competitivos , AgilityHealth Radar y Path to Agility . Pero podría comenzar de manera aún más simple, hablando con su equipo, otros departamentos y la gerencia. Utilice esta hoja de trabajo descargable con una serie de preguntas que debe hacer para ayudar a identificar dónde se han presentado las dificultades del proceso.
La información que recopile le permitirá preparar un plan de acción para mejorar, generando procesos más efectivos que abordarán más fácilmente las inquietudes de la gerencia. La gerencia puede tener varias ideas sobre cuáles son los problemas de nivel superior, pero por lo general se preocupan más por los productos y el crecimiento de la empresa que por el proceso diario de desarrollo. Si las soluciones que identifica son amplias y profundas, y crean valor concreto , la gerencia estará contenta con ellas.
3. Nunca desviarse de la guía Scrum
Es comprensible y aconsejable esperar hasta que pueda seguir las reglas de Scrum antes de intentar romperlas. Un modelo popular de romperlos “de forma segura” se basa en el concepto de arte marcial japonés de ShuHaRi .
En Shu, los equipos siguen las reglas y prácticas principales para obtener los mejores resultados. Una vez que pueden aplicarlos de manera consistente y predecible, ingresan a Ha, profundizando en los valores y principios ágiles. Al saber por qué existen las reglas, aprenden de los demás e integran ese aprendizaje en su práctica. Finalmente, en Ri, tienen un conjunto de conocimientos que pueden utilizar para adaptar las reglas a necesidades y contextos específicos.
ShuHaRi es útil porque ilustra un camino claro para convertirse en un equipo Agile maduro. Sin embargo, es un error asumir que su equipo está al comienzo de su viaje, en Shu. ¿Qué pasa si el equipo ya conoce las reglas y las ha estado aplicando con éxito durante algún tiempo? ¿Qué pasa si el problema no está en el cumplimiento de las reglas sino en áreas como el intercambio de conocimientos, el aprendizaje, la observación o la reflexión? Para tales equipos, si comienza centrándose en las reglas, sus esfuerzos pueden ser contraproducentes, o su equipo puede descartarlo como alguien que simplemente hace las cosas según las reglas. Tenga paciencia y asegúrese de que sus opiniones estén respaldadas por datos , y nunca responda preguntas con “Porque la Guía Scrum lo dice”.
4. Tratar a todos los equipos por igual
Es posible que lo asignen a un nuevo equipo que se formó especialmente para usted. O puede unirse a un equipo existente que ha trabajado juntos durante meses, o incluso años, y tiene su propia forma de hacer las cosas. He trabajado con ambos tipos de equipos y descubrí que aplicar un enfoque único para todos no funciona.
En un equipo nuevo, es probable que te reciban con interés y amabilidad. La fase de configuración probablemente será engañosamente fácil: su equipo será entusiasta (e idealista), y escuchará muchos eslóganes como “Queremos cambios” y “Queremos mejoras”. Pero a medida que pasa el tiempo, es probable que aumente la resistencia: los miembros del equipo se quejarán de la falta de tiempo para el desarrollo, demasiados eventos, no tener forma de T , confusión en los roles o falta de capacidad para dividir historias . Debe estar preparado para responder muchas preguntas mientras guía a su equipo a través de los valores y principios. Al explicar los eventos, artefactos y roles de Scrum, no olvide que el empirismo y la confianza son vitales para que prosperen los equipos de Scrum. Conozca dónde están los miembros de su equipo y sea lo suficientemente flexible como para reunirse con ellos allí.
Con un equipo existente, es posible que ingrese a un entorno en el que los malos hábitos no son evidentes de inmediato. Querrás escuchar más y hablar menos, observando lo que hace cada miembro del equipo y cómo lo hace. Puede comenzar con una evaluación de Team Radar para comprender qué les falta y dónde están los puntos débiles.
Crear un Team Radar es más simple de lo que parece. Comience identificando ocho áreas que el equipo necesita discutir o evaluar. Dibuje ocho ejes que surjan de un punto medio (como se muestra en la ilustración), etiquete cada eje con una de las áreas de discusión y haga que los miembros del equipo evalúen colectivamente su desempeño en una escala numerada para cada eje. Cuando todos los números estén trazados, conecte los puntos entre los ejes y haga una lluvia de ideas sobre soluciones prácticas para las tres áreas con puntajes más bajos.
Una vez que haya identificado las áreas problemáticas por sus puntajes, comience a trabajar en las que tienen el enfoque principal y una implementación más sencilla para crear victorias rápidas dentro del equipo. Los problemas importantes pueden ser mayores: los eventos son tediosos, no se implementan mejoras, el crecimiento no es visible, las cosas no cambian, la calidad es baja o la entrega se retrasa. Si el equipo esperaba que la implementación de Scrum resolvería todos sus problemas y no lo ha hecho, tendrá que profundizar más para comprender la cultura, la actitud, el nivel de apoyo y la seguridad psicológica de la empresa.
Continua con la parte dos de este artículo aquí
Referencia:
https://www.toptal.com/project-managers/scrum-master/common-scrum-master-mistakes
Pingback: Conseguiste el trabajo como Scrum Master ¿Y ahora que? Parte 2 - Agile CoEx