Trabajo en la gran empresa, donde Agile está en su núcleo. Hace tres años los equipos recibieron autonomía para decidir cómo trabajan.
Me he unido al equipo como Scrum Master. Los ingenieros del equipo no aceptan ninguna ayuda, no quieren cambiar sus rutinas. Quieren tener un gerente tradicional, que sea como su padre: el más inteligente entre ellos, diseñando sus horarios, protegiéndolos, diciéndoles qué hacer y cómo.
Muy a menudo, el gerente está ocupado y la gente tiene que esperar sus decisiones, instrucciones, sin hacer nada. Probé retrospectivas, reseñas y la gente simplemente lo ve como una pérdida de tiempo. Quieren que su gerente decida por ellos. Ni siquiera están interesados en conocer la visión de su producto. Parece que las personas no están dispuestas a asumir la responsabilidad por el valor que aportan.
¿Qué es lo primero que harías para arreglar ese equipo? No necesariamente como Scrum Master.
Suponiendo que está pintando una imagen precisa, que el gerente es consciente de esto y que los cuellos de botella que describe están ocurriendo y están claros, entonces el gerente está permitiendo la disfunción del equipo. El primer paso probablemente sería pedirle al gerente que cambie su comportamiento.
Veo tres posibles soluciones a su problema, cada una con distintos grados de dificultad y eficacia.
La primera opción es probablemente la más difícil. Tendrías que convencer al equipo de dos cosas. Primero, que la forma en que se están manejando las cosas actualmente es perjudicial para la empresa; que una metodología más Agile será mucho mejor (esta es la parte fácil). La segunda parte, la más difícil, es convencer al equipo de que les debe importar . Convencer a un equipo que ha sido precondicionado para ver un trabajo como una fuente de ingresos de nueve a cinco que deberían verlo como parte de sus propios valores fundamentales personales es... difícil . Peor aún, el método necesario para cada persona es diferente... pero en (casi) todos los casos simplemente arrojarles dinero dañará más que ayudará.
La segunda opción es obligar al Equipo a autoorganizarse, a través de la presión gerencial. Veo dos formas obvias de hacer esto, y ambas requieren la aceptación y el empoderamiento inmediatos del gerente. La primera es que el gerente simplemente le diga al Equipo que necesitan resolver sus propios problemas. La segunda es que el gerente simplemente deje de estar disponible para tales cosas ("Lo siento, estoy abrumado en este momento. ¿Pueden resolver esto por sí mismos?") e informar al Equipo que si no preparan las cosas de alguna manera , el proyecto va a estar en peligro... junto con sus puestos de trabajo.
La tercera opción es despedirlos y contratar empleados más acordes con los valores ágiles. Simple, efectivo, costoso y probablemente malo para la moral de otros equipos... pero posiblemente no peor que la opción 2. También podría ser simplemente imposible, dada la cultura de su organización y otras limitaciones.
Primero, analizaría si hay algunas tareas (componentes, flujos, procesos) que tienen algún empleado establecido para realizar (a pesar de que scrum implica funciones cruzadas, en la vida real es difícil de lograr).
Teniendo tal mapeo, lo mezclaría para que las personas se acerquen a los objetivos con los que no se sientan cómodos y convenientes, sin embargo, donde pueden pedir consejo a un compañero de equipo que solía ser responsable de eso. Dado que cada desarrollador tiene su propia visión sobre la mejor manera de implementar una tarea, habrá muchas colisiones de opiniones y disputas y esto haría que las personas produzcan un código más efectivo, ya que la presunción es uno de los factores de motivación más fuertes entre TI. multitud.
Configuraría un tablero que usaría en las reuniones de scrum donde se resaltarían algunas métricas y entre esas métricas (no ocupando el lugar principal pero empesadas entre otras) introduciría una calificación de los miembros del equipo (como, número de arreglos en los compromisos de una persona y algunos otros dependiendo del proyecto específico) que impulsarían el engreimiento de la persona. Ni siquiera diría una palabra sobre esa calificación, simplemente la dejaría ahí para siempre.
Establecería una reunión uno a uno mensual donde una persona respondería una pregunta como "¿qué cambiarías si fueras dueño de una empresa", ya que a las personas les suele dar vergüenza hablar de problemas o proponer innovaciones públicamente.
Hay muchos factores que podrían causar tal comportamiento y las propuestas anteriores implican que los miembros de su equipo no son simplemente perezosos.
Creo que el comentario de Mark es la clave que se pasó por alto en la pregunta misma y en algunas respuestas: ¿por qué el equipo necesita cambiar?
En mi experiencia, aprendí que las diferentes culturas reaccionan a las reglas de manera diferente. Hay algunas culturas donde las estructuras verticales son la regla (no solo desde una perspectiva profesional, sino también desde una perspectiva social), y cualquier cosa fuera de esto suena como un intento de alejarse de la zona de confort. ¿Has evaluado si eso es lo que está pasando?
Muy a menudo, el gerente está ocupado y la gente tiene que esperar sus decisiones, instrucciones, sin hacer nada.
Realmente, realmente parece el tipo de cultura vertical donde las decisiones las toma algún tipo de líder, responsable del éxito (y principalmente y más importante, de los fracasos).
O tienes un equipo donde
Es posible que tenga tres opciones posibles:
Solo podrá ver la mejor respuesta para su escenario una vez que responda el comentario de Mark: ¿por qué el equipo debe cambiar?
MCW