Como su nombre lo indica, esta es una continuación de una serie de artículos sobre roles en scrum ( parte 1 y parte 2 ). Hoy consideraremos el siguiente rol: scrum master . Paradójicamente, el éxito de scrum depende en gran medida del scrum master. Por lo tanto, quiero recurrir al poder de la imaginación nuevamente y dar una metáfora ( descargo de responsabilidad: un ejemplo no debe ofender de ninguna manera los sentimientos de nadie ). Hay una cultura que tiene su propio culto, sus ritos, hay ministros de este culto. Los ministros se pueden dividir en varias clases:
- aquellos que, con su cultura, prefieren ser uno a uno: ermitaños, reclusos, iluminados;
- aquellos que aprendieron todas las reglas, encontraron lagunas, entienden qué y cómo hacer, y usan el culto con fines egoístas, aprovechando las personas, sus miedos y prejuicios;
- fanáticos que intentan plantar su cultura dentro y fuera de lugar. Para quien además de su conocimiento, todo lo demás es herejía;
- aquellos que sinceramente creen, sienten y tratan de compartir, ayudar y dar este milagro a las personas; hablan y explican, escuchan y tratan de ayudar.
Me parece que está sucediendo una historia muy similar con Scrum y SM. Intenta mirar al SM familiar a través de un prisma. ¿Con qué SM te gustaría trabajar?
Veamos qué síntomas alarmantes puede tener SM.
Interacción con el dueño del producto.
Síntoma : SM no funciona con la acumulación de comestibles. Lo deja completamente a la conciencia de PO. Él espera que el equipo reciba la acumulación y sus elementos en la forma que necesiten sin la participación de SM.
Lo que es malo : una de las tareas de SM es construir un proceso efectivo y transparente en el que todos los participantes se sientan cómodos trabajando. SM necesita realizar un seguimiento de todos los elementos scrum para poder mejorarlo, y la acumulación de productos es un artefacto scrum muy importante que SM no puede ignorar.
Cómo tratar : SM debe negociar con PO para trabajar juntos en el trabajo atrasado y comprender el trabajo de PO; analizar el proceso; sugerir mejoras; ofrece tu ayuda SM debe preguntarle al equipo qué expectativas tiene del trabajo atrasado y cómo mejorarlo. Para tomar decisiones colectivas para mejorar el trabajo atrasado, sus elementos, el proceso y las actividades para interactuar con él, podemos dedicar una retrospectiva separada a esto. Y para volver a esta pregunta con cierta periodicidad ( recuerde que la base del scrum es un proceso empírico ).
Síntoma : SM no escucha ideas / deseos de PO. Se contrasta con él. Hay una guerra de influencia en un pueblo pequeño. No hay interacción constructiva entre SM y PO.
Lo que es malo : me gusta comparar un equipo de scrum con una familia, esta metáfora a menudo ayuda a comprender y explicar por qué necesita hacer esto y no de otra manera ( simplemente transfiera la situación a la familia, haga la pregunta: "¿Cómo actuaría en la familia?"). encuentra el camino a la respuesta ). Es difícil llamar a una familia feliz donde la madre y el padre discuten constantemente, porque los niños sufren mucho de esto ( IMPORTANTE : SM y PO no son "padres" para el equipo ). Cuando no hay entendimiento mutuo e interacción constructiva entre SM y PO, el equipo sufrirá: juegos encubiertos, sabotaje de apertura y transparencia. Si SM no puede estar de acuerdo con PO, entonces no puede resolver una de sus tareas más importantes: " El Scrum Master ayuda a todos a cambiar estas interacciones para maximizar el valor creado por el Equipo Scrum " .
Cómo tratar : necesitamos un facilitador experimentado que revele las causas del conflicto para comenzar a mejorar la situación. El equipo activo en sí mismo puede comenzar a recopilar datos sobre el efecto destructivo de las diferencias entre SM y PO en los resultados del equipo, simplemente registrando situaciones de trabajo. Y luego, en retrospectiva, donde ambos participantes están presentes, presente estos hechos, discútalos e intente encontrar soluciones. Si no es posible construir un diálogo y todo se reduce a encontrar al culpable, y no la solución, entonces debe buscar un facilitador externo y escalar los problemas fuera del equipo.
Al mismo tiempo, es importante que el equipo no tome partido: "No nos arrastres a disputas, como estás de acuerdo, así que avísanos sobre la solución". Esta posición será un indicador del problema existente para SM y PO.
Interacción en equipo
Síntoma: Scrum Master no "predican": no explica la esencia de los elementos scrum, no realiza la formación de juegos, sesiones de formación, permitiendo que el equipo para entender mejor el scrum y unirse a la cultura ágil. No explica ni da al equipo respuestas a preguntas relacionadas con el proceso. No conoce el nivel actual de aceptación y comprensión de los miembros del equipo scrum.
Lo que es malo : si no hay reuniones periódicas del equipo donde se discute scrum, entonces la comprensión y la fe en el marco desaparecen. Cualquier cultura ( ágil no es la excepción ) requiere refuerzo ( no debe confundirse con el culto a la carga ), lo más probable es que el esquema no funcione: hemos sido entrenados, sabemos scrum, scrum despegado. Con el tiempo, las personas acumulan experiencia, tienen nuevas preguntas que requieren atención, explicación. Si no ayuda a las personas a comprender, dejarán de vivir con estas ideas y se ahogarán en problemas y malentendidos, en última instancia, se sentirán decepcionados.
Cómo tratar : SM, en primer lugar, debe aprender todo el tiempo solo, comunicarse con colegas, leer artículos, asistir a reuniones, conferencias, etc. Debe compartir regularmente este conocimiento con el / PO / equipo de su organización: realizar entrenamientos y juegos que ilustren los principios de agile / scrum. El equipo / empresa se está desarrollando y es necesario brindar conocimiento relevante que satisfaga las necesidades y requisitos actuales. Para darse cuenta de estas necesidades, debe comunicarse más con las personas sobre los procesos y las dificultades en el trabajo. SM debe mantener conversaciones personales con cada miembro del equipo con el fin de comprender cuáles son las expectativas, los problemas y el nivel de comprensión de scrum en el equipo. Al igual que con scrum en muchos aspectos, es importante establecer el ritmo de las actividades para desarrollar una cultura ágil y scrum dentro de un equipo / empresa.
Síntoma : SM parcial, por ejemplo, en combinación con otro rol. Por otra parte, el dominio de scrum, cuando hay en este momento, de acuerdo con el principio residual.
Lo que es malo : si SM no se rinde completamente a la tarea de desarrollar scrum en un equipo / empresa, pero combina esto con otras actividades, entonces todos los resultados probablemente sufrirán. Ser un buen SM no es fácil, y si lo haces de forma intermitente, es probable que el scrum se degrade. Por ejemplo: si una persona combina los roles de desarrollador y SM, en caso de problemas para lograr el objetivo del sprint, se apresurará a hacer las tareas por sí mismo para lograr el objetivo. ¡Y esto es malo! El comportamiento más correcto de SM en esta situación es establecer un equipo para lograr un resultado, desarrollar un equipo, ayudarlo a mejorar.
Cómo tratar : si estamos hablando del trabajo de SM en un equipo inmaduro, debemos tratar de encontrar formas de liberar a SM de cualquier otro trabajo, excepto el dominio de scrum. Esto se puede ofrecer como un experimento en varios sprints para comprender lo que esto le da al equipo. Si la organización está en el camino de probar ágil y scrum, deberían dar luz verde. Después del experimento, vale la pena que todas las partes interesadas evalúen los resultados y tomen decisiones sobre el destino de scrum, SM asignado y cultura ágil en general.
SM, que ha crecido como un equipo maduro en el que el factor del bus es más de uno y el trabajo se realiza en ausencia de SM, puede permitirse combinar o trabajar con el segundo equipo ( pero sin olvidar al primero, quizás planteando un reemplazo para usted allí ).
Síntoma : SM no facilita reuniones y reuniones. Puede colocar la manta sobre sí misma, "conocer" las respuestas a todas las preguntas y no permitir que los miembros del equipo se expresen. O no "dirige" las reuniones, simplemente reúne a las personas y luego deja que las cosas vayan solas.
Lo que es malo : si SM no facilita, no ayuda a construir comunicaciones efectivas ( entre los miembros del equipo; comunicarse con OP, partes interesadas, etc.; celebrar reuniones; etc. ), entonces se puede gastar mucha energía en la comunicación que podría ser dirigida para desarrollo de producto. Es posible que las reuniones no lleguen a la tarea que se les asignó. Pueden surgir conflictos debido a malentendidos. Y a partir de una herramienta eficaz para la toma de decisiones, es probable que las reuniones se conviertan en una fuente de estrés. Y el dominio de SM en las reuniones generales desmotivará al equipo y afectará negativamente la iniciativa y la autoorganización.
Cómo tratar : SM debe ser capaz de facilitar . Su tarea es construir una comunicación abierta dentro del equipo; establecer la interacción del equipo con el mundo exterior; Enseñe a su equipo a celebrar reuniones útiles. SM debe ser consciente de la necesidad de una reunión, formular el propósito y la agenda de la reunión e indicar la duración por adelantado. Durante la reunión, debe seguir tanto la agenda como el marco de tiempo asignado, interrumpir las discusiones sobre temas abstractos, por ejemplo: "Definitivamente volveremos a este tema más tarde, se ha registrado, y ahora continuemos la discusión de nuestro tema actual". Puede pedirle a uno de los participantes que lo ayude con las reuniones ( o delegar parte de las reuniones al equipo ). Al final de cada reunión, es importante resumir y registrar el resultado. Es útil implementar herramientas de evaluación de reuniones para que, al final, los participantes pasen unos segundos más y den su opinión ( creamos un proceso empírico donde puede ser útil ). Todos los resultados deben transmitirse a todas las partes interesadas al final de la reunión, por ejemplo, por carta.
Síntoma : SM no forma un equipo scrum real de un grupo de personas. No construye relaciones profesionales confiables, no suaviza las esquinas.
Lo que es malo : falta de voluntad para comunicarse, conflictos, una atmósfera que no funciona - afectan negativamente los resultados del equipo. Los equipos muy unidos dan el mejor resultado, otras cosas son iguales.
Cómo tratar : una de las tareas importantes de SM es hacer que un grupo de personas se convierta en un equipo, es decir para hacer crecer un equipo y hacerlo madurar ( cuando SM espera y toca ). Para hacer esto, debe pasar el mayor tiempo posible con el equipo, notar conflictos, para que se puedan resolver y no permitir que se desarrollen, comprender cómo se construyen las comunicaciones ( si las personas sentadas una al lado de la otra no hablan y se escriben correos electrónicos, es alarmante ). SM en situaciones reales debe demostrar los beneficios de la comunicación en vivo sobre la correspondencia. Necesita llegar a las causas profundas del conflicto y el desacuerdo y ayudar a las personas a negociar entre sí. Una herramienta útil para el análisis es la construcción de un gráfico de comunicación ( coloque los vértices de cada miembro del equipo, y los bordes son cada hecho de comunicación ), analizándolo, puede buscar debilidades en las comunicaciones ( por ejemplo, comunicación a través de un miembro del equipo; es un " cuello estrecho "; o falta de comunicación entre pares específicos de personas ). Sobre esta base, puede crear situaciones para la "alineación" de las comunicaciones en las que reúne a personas "no comunicantes"; y viceversa, excluye de algunas situaciones a la persona con quien se cierra la comunicación. Es útil e interesante seguir la dinámica del desarrollo de dicho gráfico.
Síntoma : SM no desarrolla el equipo, no ofrece cambios constantes, no saca al equipo de la zona de confort, no apoya iniciativas y está satisfecho con los éxitos actuales: “¡Somos geniales! Somos un equipo!
Lo que es malo : si SM no es el motor del cambio ( y el desarrollo ), lo más probable es que su equipo se degrade. Cualquier participante en el proceso puede presionar por cambios, pero no se debe contar con esto. Sin cambios en un intento de mejorar, el equipo se retrasará con los requisitos con el tiempo. Agile se trata de poder adaptarse rápidamente al cambio.
Cómo tratar : SM debe ser el iniciador de cambios, ofrecer probar cosas nuevas en los procesos, tareas, implementar prácticas de ingeniería. No puede permanecer en reposo, debe buscar oportunidades de mejora. Para comprender qué cambios se están realizando y en qué condiciones se encuentran, puede aumentar la transparencia y visualizar el proceso. Trabajar con un equipo y su desarrollo es el mismo trabajo que crear un producto. SM puede tener su propio tablero en el que colocará experimentos, elementos de acción de retrospectivas, iniciativas, etc. La ausencia de cambios en el tablero puede ser un indicador de estancamiento SM. Al trabajar con un equipo durante mucho tiempo, SM puede confundir sus ojos, existe la amenaza de dejar de ver oportunidades de mejora, luego puede dejar al equipo solo por un tiempo ( por un lado, es útil para SM, por otro lado, es una buena prueba de la madurez del equipo, cómo se comportan conducirá en ausencia de SM ), o solicitará ayuda externa, por ejemplo, para acordar con el SM del equipo vecino cambiar por un tiempo para ayudarse mutuamente a encontrar puntos de crecimiento.
Síntoma : SM le permite trabajar no en scrum, se refiere con calma al sabotaje. Por ejemplo:
"- sí, parece que el sprint pasó sin fakaps, no realicemos el retroceso, ¿qué discutir entonces?
- ok, lo haremos la próxima vez ".
Lo que es malo : si SM no defiende la pureza y la necesidad de scrum frente a un equipo, PO, compañía, entonces es poco probable que alguien más lo haga. Si no se defienden los principios, entonces no hay sentido de su importancia y utilidad. Se supone que SM es muy adaptable y fiel a cualquier cambio. Un buen SM no dice que no, dice "intentemos. Realizaremos un experimento ". Pero con respecto a los principios del marco scrum, debe ser persistente y comprender claramente qué artefactos, eventos, rituales, valores y otros elementos del scrum son, y para qué se necesitan, qué tareas resuelven. El marco ya está siendo cambiado por equipos maduros, en la etapa de convertirse en un scrum, no puede renunciar a la holgura y alejarse de la guía del scrum ( romper una de las reglas plantea una pregunta razonable: ¿por qué no romper otra? ).
Cómo tratar : una de las tareas de SM es controlar la "limpieza" del scrum, y hasta que el equipo alcance la madurez, debe suprimir todos los disturbios y sabotajes destinados al scrum. SM es útil para hacer ejercicios de interacción escépticos. Es bueno encontrar un "escéptico" inteligente, por ejemplo, un colega SM y realizar ejercicios con él: pídale que sabotee el scrum, y SM debería defenderse. Debe estar preparado para responder las preguntas de por qué estamos llevando a cabo eventos scrum, qué es malo si nos perdemos uno de los eventos, por qué debería yo (un miembro del equipo ) hacer algo. Si SM mismo no sabe las respuestas, entonces debe comunicarse con la comunidad, asistir a la capacitación, leer la literatura.
Síntoma : SM emite instrucciones a los miembros del equipo, actúa como director. Esto puede suceder si el rol de SM fue otorgado al ex gerente de línea, sin explicar qué debería cambiar en el trabajo, los enfoques y las comunicaciones.
Lo que es malo : cuando SM siente el poder y comienza a actuar como director ( distribución de tareas, transmisión en reuniones, etc. ), mata el trabajo en equipo, desmotiva a las personas, y esto ya no es scrum. Puedes poner fin a la autoorganización.
Cómo tratar : una buena opción es enviar a un SM a la capacitación, donde le contarán sobre la cultura ágil y le darán nuevas herramientas para trabajar con el equipo. Otra opción más difícil es que el propio equipo intente cambiar las comunicaciones con SM: construir un diálogo, asumir la responsabilidad al tomar decisiones locales, ofrecer alternativas a las soluciones SM. También puede pensar en trasladar el rol a otro miembro del equipo.
Interacción de la compañía
Síntoma : Scrum master no comparte valores ágiles. Esta cultura no está cerca de él, se adhiere a otros puntos de vista. Esto sucede si SM nombró a una persona, y no él mismo mostró el deseo de cumplir este papel.
Lo que es malo : si una persona no cree en la cultura ágil, no comparte valores, pero al mismo tiempo es SM, lo más probable es que persiga objetivos muy mercenarios y es poco probable que pueda beneficiar al equipo, producto o empresa en estas condiciones.
Cómo tratar : buscamos / educamos / capacitamos a SM, que entiende y comparte los valores ágiles, y que entiende scrum: qué se está haciendo y para qué. Le asignamos la tarea de ejecutar scrum, dar el comando, PO, el producto. Es importante comprender los desafíos que enfrenta scrum en su organización. Necesitamos determinar inmediatamente cómo entendemos que funciona scrum, cómo lo evaluaremos, con la ayuda de qué métricas.
Síntoma : SM no organiza el intercambio de experiencias entre equipos. No traduce el éxito del equipo al nivel de la empresa. No proporciona transparencia de los resultados y procesos de su equipo para toda la organización.
Lo que es malo : el equipo existe dentro de la empresa, tiene un alto grado de autonomía, pero, sin embargo, está estrechamente relacionado con la empresa. Si un equipo está cerrado sobre sí mismo, puede separarse de las realidades de la empresa, puede volverse innecesario o irrelevante, pueden surgir expectativas injustificadas en ambas direcciones, etc.
Cómo tratar : todo depende del nivel de agilidad en la empresa y las tareas que enfrenta el equipo. En general, esta es una gama muy amplia de opciones, pero considere casos simplificados:
- Equipo piloto en una empresa pensando en aplicaciones scrum : este es un verdadero desafío para SM. Su equipo está bajo la mirada de toda la empresa. Que puedo hacer:
- Descubra ( es posible desarrollar junto con los iniciadores de los cambios ) cuál es el desafío que enfrenta el scrum en la empresa ¿Por qué se lanza el "piloto"? ¿Qué hipótesis se está probando? ¿Cómo se evaluará el resultado? Acordará la duración del experimento y el punto de decisión sobre el destino del scrum en la empresa.
- Lleve esta información al equipo. Desarrolle una visualización de los indicadores que la compañía va a monitorear. Actualice periódicamente los indicadores visuales.
- Trabajo abierto tanto como sea posible. Dar a los empleados la oportunidad de observar nuevos procesos para la empresa, pero no en detrimento del equipo. Informar periódicamente a toda la empresa sobre el progreso del trabajo.
- En el momento señalado para preparar los datos sobre los resultados obtenidos durante el experimento (el trabajo del equipo piloto ). Realice una extensa retrospectiva para decidir el destino del scrum en la empresa.
- Uno de los equipos de la empresa, donde parte de los empleados trabajan en scrum y parte no : lo más probable es que la empresa esté en proceso de transición. Y SM debería ayudar a la transición de toda la empresa a scrum. Qué se puede hacer en este caso:
- Mantenga la transparencia con respecto a los procesos y resultados del equipo, difunda esta información dentro de la empresa ( revisión abierta de sprint, boletines, etc. ).
- Organice SM league, donde "polinizarse" entre sí con nuevas ideas y prácticas. Compartir experiencias y apoyarse mutuamente.
- Junto con otros SM combaten las disfunciones organizacionales .
- Para participar en el trabajo de los empleados que no son scrum, capacítelos en scrum, proponga cambios en sus procesos ( si el cambio puede conducir a una mejora ).
- Un equipo de una empresa basada en Scrum que utiliza varios métodos de escala de scrum: LeSS , SAFe , Nexus , etc. : Aquí el problema de la sincronización del equipo recae en SM. No tengo experiencia real en tales empresas, por lo que me abstendré de las ofertas. Pero sería muy interesante leer sobre su experiencia: escriba en los comentarios.
Conclusión
Una vez más, recuerde brevemente ( vea la conclusión de la primera parte ) qué hacer con la información recibida:
- elige el síntoma más relevante para ti;
- discutiendo con el equipo su impacto negativo, como punto de partida para razonar, tome mis tesis;
- el equipo ideó formas de aliviar el síntoma;
- haz lo que se te ocurra;
- analizar los resultados;
- repetir desde el primer punto.
En tres artículos, he podido describir los síntomas más obvios de los roles en el scrum. Además, la descripción de los roles en la
guía scrum toma 3 de las 19 páginas. La guía Scrum dice "qué" hay que hacer, pero deja la discreción del comando "cómo hacerlo", porque depende mucho de la situación particular. Me parece que es importante compartir sus experiencias y prácticas de cómo está exactamente. Me gustaría creer que el material resultó ser útil y usted adoptó las tarjetas "médicas" descritas en esta serie de artículos.
¡Muchas gracias por la ilustración Sai Kin !