Dentro de una Startup bastante joven y fresca, actualmente ocupo el rol de Scrum Master, así como de desarrollador. Mis tareas se dividen 50/50 entre esos roles. El año y medio anterior a eso, trabajé como Scrum Master de tiempo completo (FTE), por lo que este rol no es completamente nuevo para mí.
El equipo consta de 2 desarrolladores de tiempo completo, 1 desarrollador independiente, 1 pasante muy talentoso para control de calidad y creación de prototipos, un PO y yo. Entonces, en total, tenemos alrededor de 3,5 desarrolladores FTE, 1 FTE para PO y 0,5 FTE para Scrum Master.
Para el Product Owner (PO), es su primera vez en este rol, la primera vez dentro de una empresa de software y también la primera vez que trabaja en un proyecto de software/Scrum/Agile. Le va muy bien y aprende bastante rápido. Todavía tiene algunas asperezas, pero estoy satisfecho con su progreso personal hasta ahora.
Entre los 2 desarrolladores de tiempo completo, hay un tipo que es mi supervisor directo y tiene acciones en la empresa. Esa persona tiene experiencia en Scrum, pero en mi opinión bastante sucia e ineficaz. Llamémoslo simplemente Mike.
Para que todos los miembros del equipo pensaran en el proceso Scrum, al principio les pregunté a todos sobre su rol dentro del equipo. Mike me dio la respuesta de que solo es un desarrollador. Período.
En este momento, me enfrento a la dificultad de que Mike está impulsando y haciendo cumplir las cosas por su rol organizacional. A mí, como Scrum Master, no me gusta mucho esta situación, ya que está dañando el proceso y también nos está ralentizando. Al empujar y hacer cumplir me refiero, por ejemplo,
mis preguntas son ahora
Las empresas tienen muchas opciones en los marcos de gestión de proyectos. Sin embargo, si eligen Scrum, entonces han optado por cumplir con la metodología del marco. Esto incluye hacer cumplir los roles de Scrum y las reglas de participación. Cualquiera que interrumpa el proceso de manera no constructiva debe ser eliminado del equipo.
No eliminar a los miembros del equipo disruptivos socava el proceso de Scrum, debilita al equipo y evita que la organización obtenga algún beneficio del marco formal de Scrum. ¿Quieres capitanear ese barco que se hunde? Probablemente no.
En cualquier organización, una persona tiene tres opciones:
Su desarrollador fundador no está haciendo ninguna de estas tres cosas correctamente. Francamente, esto es insostenible tanto desde el punto de vista metodológico como organizativo, y ya está experimentando resultados tóxicos en esta situación.
Como árbitro del proceso, es su trabajo como Scrum Master educar a la organización sobre Scrum. Si tiene un equipo de liderazgo de apoyo, deberá educarlos sobre los roles de Scrum, la necesidad de límites de trabajo en curso (WIP) y el requisito no negociable de tener todas las prioridades administradas a través del propietario del producto. El propietario del producto debe estar a su lado, animándolo mientras comunica esto a las partes interesadas, porque también afecta su capacidad para entregar un producto efectivo.
Dado que ya tuvo una conversación privada con el desarrollador fundador, él sabe que está violando los principios básicos del marco y no se ha comprometido a reformar sus formas, deberá involucrar al resto del liderazgo para eliminarlo del equipo. Si no logran hacer esto, también podrían reemplazar al Scrum Master y al Product Owner con este tipo, y dejar que administre los proyectos a su manera.
Debe estar preparado para defender el proceso Scrum y los límites de capacidad y los principios de autoorganización del equipo. Si no está dispuesto a defenderlos a fondo, incluso alejarse de los roles de Scrum Master (y posiblemente de la empresa) si no quieren adherirse al marco que ellos mismos eligieron, entonces se está preparando para falla.
Si "Mike" tiene suficiente influencia para salirse con la suya a pesar de burlarse del marco y los principios de Scrum, simplemente llámelo Pseudo-Scrum de Mike y déjelo ser responsable de los resultados. Si usted y el resto del equipo siguen fingiendo que están siguiendo un proceso formal mientras que en realidad solo hacen lo que Mike cree que es importante, entonces están abdicando de sus responsabilidades y tácitamente dando su aprobación a esta desviación del proceso. Los miembros del equipo Scrum que permiten que cualquier miembro del equipo secuestre el proceso son, al menos parcialmente, culpables de cualquier falla del proceso que resulte.
Siga el proceso. No seas "como Mike".
Creo que Scrum no es perfecto para las pequeñas empresas de desarrollo de software. Es difícil comprometerse y concentrarse en un ámbito de trabajo fijo durante un período de tiempo fijo cuando todos los días llegan nuevos conocimientos y los clientes/usuarios están cambiando su mundo.
Las pequeñas empresas necesitan la flexibilidad para cambiar su enfoque más rápido de lo que permite Scrum, a menos que haga sprints de una semana.
Sugeriría echar un vistazo a ScrumBan . La flexibilidad de Kanban y la mentalidad Agile, roles y reuniones de Scrum. Un flujo continuo de trabajo y planificación/lanzamientos justo a tiempo. Programe un buen ritmo para revisiones y retrospectivas.
Hablaría con Mike en privado y le señalaría que, como Scrum Master, es su responsabilidad asegurarse de que se siga el proceso de Scrum.
Discuta con él lo que está motivando su comportamiento. ¿Quizás le preocupan los plazos o la salida del equipo? Una vez que entiendas mejor su motivación, entonces pueden trabajar juntos para encontrar una manera de reducir sus preocupaciones.
En mi experiencia, la mejor manera de resolver este tipo de problema es resaltar los problemas y sugerir enfoques que podrían mejorar las cosas. Intenta crear una atmósfera positiva y constructiva en la que el equipo esté dispuesto a dar un paso al frente y resolver su propio problema.