Fuente de la foto
Por tercer año ahora, he estado introduciendo los valores y principios de Agile en la vida de los equipos de desarrollo. Detrás de los hombros: trabajo como Scrum Master en dos grandes empresas, experiencia en la implementación remota de metodologías ágiles en industrias completamente diferentes, innumerables libros leídos y asistencia a reuniones.
Pero todo comenzó poco a poco, y durante este tiempo he llenado más de un bulto. Y con el tiempo, comencé a notar que estos golpes eran bastante típicos, y mis colegas novatos los encuentran con regularidad. Sin querer quedarme al margen, y con el fin de advertir a los compañeros de posibles fallos, decidí compartir mi experiencia en este artículo.
Entonces, ¿qué lecciones aprendí y conclusiones extraídas en el primer año de trabajo como Scrum Master (que describí brevemente en puntos al final):
Gafas rosas
Después de dos días de entrenamiento en Scrum, estaba listo para mover montañas, cambiar el mundo en el camino de la empresa para mejor. ¡Nada inspira más que un entrenador competente y un equipo de personas con ideas afines! Pero tan pronto como comienzas, de repente te quedas solo con tu marco de Scrum. Hay muchachos cargados con sus propias tareas, hay hábitos y valores que ya se han formado en el trabajo del equipo, hay una dirección que ve los procesos a su manera, y esto no siempre va en paralelo con los valores. e ideas de Agile. Considerándolo todo, bienvenido al mundo real .
Por lo tanto, al principio hay que ganarse la confianza y la apertura del equipo. Es importante confiar en su experiencia previa y en su sentido común.Comprenda lo que su equipo realmente necesita ahora, qué problemas y subestimaciones existen y cómo puede ayudarlos a cerrar al menos algunas de las preguntas que surgen.
Resistencia
Por supuesto, las innovaciones y los próximos cambios obvios no fueron muy felices. En mi caso, fue más bien una resignación a que alguien más hubiera venido a dirigir y enseñar: " Bueno, al fin y al cabo, todo está bien ". No hay nada que hacer, tuve que demostrar que vine a ayudar y, en la práctica, demostrarlo.
Un punto importante: si al principio no encuentras seguidores en el equipo de desarrollo, corres el riesgo de ser rechazado.
Lo primero que enfrenta un Scrum Master recién creado cuando intenta cambiar es la resistencia. El proceso, por supuesto, es natural, pero no indoloro. Las personas están dispuestas a cambiar solo cuando ven su valor por sí mismas.Por lo tanto, la mejor opción es darle al equipo la oportunidad de llegar a la idea de que Scrum mejorará tanto sus procesos como sus vidas.
Pregúntese: "¿Cuál es el propósito de mi presencia en este puesto y cómo puedo ayudar a mi equipo a mejorar los procesos de trabajo existentes?" Si puede encontrar la respuesta, genial, ¡pasemos a los cambios! Si no es así, vale la pena verlo un poco más.
Hablando de mejora, puede tener una serie de reuniones destinadas a identificar los dolores del equipo y crear apertura, por ejemplo. Pero quiero hablar de esto en los siguientes artículos.
La prisa es la peor ayuda
La prisa y el deseo de mostrarse desde los primeros días de trabajo es probablemente el mayor error que comete un Scrum Master principiante. Es de vital importancia saber que cambios drásticos sin entender por qué es necesario y cómo afectará la forma de vida actual del equipo pueden provocar aún más resistencias y desconfianza. Ha habido ocasiones en las que el Scrum Master dañó a los equipos precisamente debido a cambios mal concebidos e inconclusos.
La disposición para el cambio proviene del equipo gradualmente.Observe al equipo durante 1-2 semanas sin interferir con el curso "natural" de las cosas. En las primeras etapas, debe comprender por sí mismo la cadena lógica de procesos y valores establecidos, ver las vulnerabilidades en el trabajo y, de hecho, proponer una solución. Paso a paso, intente introducir los eventos y valores de la metodología en la conciencia y la vida de su equipo.
Facilitación de reuniones, interacción frecuente con el equipo, tanto personal como en formato de eventos, el coaching te ayudará en esto. Y, por supuesto, confianza y apertura al diálogo.
Entendiendo el medio ambiente
Cuando comencé a trabajar con el equipo, cometí un gran error, que al principio no me llamó la atención y me pareció una nimiedad. Es decir, perdí de vista los muchos chats temáticos de desarrolladores que los revelaron desde el otro lado. Se distanció de la dirección y se perdió información importante que, a su vez, podría transmitir al equipo.
No repitas mi error: no importa si tu empresa es pequeña o grande, pero necesitas entender la comunicación entre departamentos y conocer personalmente a un par de compañeros clave . Se dice que el Scrum Master debe eliminar los obstáculos que distraen al equipo de la creación de un producto de TI. Pero, ¿cómo puede hacer esto si no sabe a quién acudir?
Entonces, al principio, es especialmente importante:
- ir a todos los chats y ver cómo y con quién se comunican los equipos, qué problemas tienen;
- comunicarse con la gerencia, realizar un seguimiento de los objetivos globales y secundarios que persigue la empresa en un período de tiempo determinado;
- Comuníquese con personas de ideas afines si la empresa ya cuenta con Scrum masters con más experiencia.
Estoy seguro de que es muy probable que todo lo anterior le ayude a sumergirse rápidamente en el entorno y realizar una observación más completa de los procesos.
Presencia estratégica
Y así hablamos con el equipo y la gerencia, hicimos preguntas de interés, recibimos respuestas, ingresamos a todos los chats y recibimos invitaciones a todos los eventos. Vemos el problema, conocemos los objetivos de la administración, pero aún no está claro dónde empezar a resolverlo. ¿Qué hacer a continuación?
Para tomar una decisión, es importante formular objetivos claros sobre qué es exactamente y por qué queremos cambiar . Y luego - para elaborar un plan de trabajo que responda a la pregunta, “ ¿cómo vamos a hacer esto? ".
La mayoría de las veces, cuando llegué al equipo, vi cómo los muchachos celebran reuniones diarias durante 1,5-2 horas, durante las cuales intentan resolver todos los problemas. Y esto, por cierto, es una cantidad colosal de tiempo que se deduce de las horas de trabajo y reduce la eficiencia del trabajo de los equipos. Y la Guía Scrum sugiere solo 15 minutos para este evento y ni un minuto más.
Cómo ser: el enfoque más correcto, en mi opinión, es separar estas actividades y enfocarse en las tareas establecidas dentro de los objetivos del Sprint.
Basado en dolores y las preguntas más frecuentes, además de los principales eventos de Scrum (planificación, diario, demo, retro), por ejemplo, una reunión de investigación semanal, una discusión de la acumulación de ideas o sesiones de lluvia de ideas para discutir en profundidad se pueden formar problemas, como está sucediendo hoy en ICL Services. ... Vemos el dolor, sabemos cómo solucionar la situación y lo que se debe hacer; todo lo que queda es discutir el cambio de formato de trabajo con la gerencia y el equipo para lograr el mejor efecto.
El plan también debe ser flexible y cambiar según las condiciones y características de los miembros del equipo. Es importante discutir la ruta planificada con la gerencia, porque no siempre todo lo propuesto por usted se implementará inmediatamente en el trabajo. Y algo puede cambiar por completo según el establecimiento de objetivos y las solicitudes de la propia dirección.
Falta de conocimiento técnico
No tengo una educación técnica y, por lo tanto, comprender a fondo la extensa terminología del equipo de desarrollo fue (y en algunos lugares sigue siendo) una tarea bastante difícil para mí, dado que la tecnología no se detiene.
Pero aquí también hay algunos trucos de vida bastante simples:
- no tenga miedo de pedir ayuda al equipo;
- estudiar la literatura relevante;
- busque en Internet diccionarios terminológicos para tontos o consiga un diccionario personal si es necesario.
Breve resumen
- Aproveche la experiencia previa. Comprenda qué necesita el equipo, qué problemas y subestimaciones existen y cómo puede ayudarlo.
- Identifique cómo el cambio puede beneficiar al equipo y enséñelo. La gente no está preparada para cambiar hasta que vean el valor de ello por sí mismos.
- Sprint, , .
- – , , – -.
- « ?», . « ?» , , . . .
- Falta de conocimientos técnicos. Si no tiene experiencia técnica, pero quiere o necesita dominar la terminología, no tema pedir ayuda. Un diccionario de terminología personal también puede ser una buena ayuda.
Estoy seguro de que todas las lecciones que he aprendido te ayudarán a sacar conclusiones y reconstruir en la dirección correcta, porque realmente amo lo que hago. Y, lo más importante, no tenga miedo de los errores, aprenda de ellos. ¡Buena suerte!