Esto es algo que suelo comentar en mis formaciones: Scrum es la mejor opción para la mayoría de los casos y sin embargo hay mucha gente a la que no sólo no les gusta, sino que lo llegan a detestar, siendo la mayoría de ellos Desarrolladores. ¿Cómo es posible que esto pase? Muy fácil: porque se hace mal. Por desgracia, la mayoría de los Desarrolladores sólo han visto usar Scrum en uno de sus múltiples tipos de aberraciones, provocado por la falta de conocimiento real en las organizaciones y, en los que muchos llaman ser, los Scrum Master. En un entorno ideal, un Desarrollador amaría Scrum: Está muy empoderado; tiene un peso importante en la toma de decisiones; se trabaja en equipo de verdad, no es un grupo que hace cosas sino que somos un conjunto unido que nos apoyamos y ayudamos en todo momento; ve cómo crece a todos los niveles (personal, equipo, organización, producto, etc.); está valorado personal y profesionalmente; la motivación aumenta día a día, etc. Todo esto provoca una importante reducción de rotación de personal, puesto que el talento no quiere irse de este tipo de entornos. Sin embargo, lo que la mayoría encuentra en entornos absurdos (he intentado buscar otra palabra, pero ninguna describe mejor esos entornos que "absurdo") es que se usa Scrum como una forma de controlar el progreso, midiendo velocidad por Sprint (por ejemplo) para que toda la planificación anual encaje con la previsión dada, sin evaluar si lo que se hace tiene sentido, ni si da valor, ni si los usuarios lo usan... Básicamente mantienen esos desarrollos en cascada (waterfall) del siglo pasado, pero lo hacen en iteraciones. Además, los Desarrolladores no tienen margen de decisión, ni de proponer mejoras... y peor aún, ni siquiera de opinar en las estimaciones que vienen dadas por otros departamentos. Para colmo a esos Desarrolladores se les asigna un perfil en su contratación y de ahí no se pueden salir pase lo que pase, provocando cuellos de botella internos. Un disparate lo mires por donde lo mires. ¿Qué pasa aquí? Pues cualquier Desarrollador que se vea en un entorno "absurdo" acabará por desmotivarse y lo normal es que busque alternativas para continuar creciendo personal y profesionalmente, por lo que la rotación de personal es alta y cuesta mantener los flujos de trabajo. ¿Qué provoca esto? Pues como casi todo en la vida: El desconocimiento. Muchas organizaciones oyen hablar de Scrum y quieren copiarlo en sus organización. Aquí se abren dos opciones: O contratan al "Scrum Master" más barato que encuentran para que se encargue de hacer el cambio en toda la organización, al que lo contratan porque tiene cuatro años de experiencia usando Jira y gestionando el backlog (bandera roja clarísima de alguien a quien no hay que contratar); o bien contratan una formación (tan absurda como el entorno que se les queda) donde les dicen que tienen que hacer Dailys, Retros y usar la herramienta X para la gestión del Backlog, con la que se llevan comisión, y sin hablar de la mentalidad que debe acompañar a esta forma de trabajar. Con esta información el equipo empieza a hacer las reuniones que les han dicho que se haga, con la máxima garantía (99,99%) de que lo van a hacer mal, puesto que van a mezclar lo que hacían con los eventos de Scrum y la mezcla será peor que lo que ya tenían. ¿Sabes qué me da pena/rabia? Que cuesta lo mismo hacerlo bien que mal. Si me dijeras que haciéndolo mal ahorras tiempo en algo, o que mejoras el rendimiento en algún punto, pues podríamos evaluarlo. Pero es que no es el caso. Muchas veces basado en el auto-engaño de "Es que en nuestra organización nuestra casuística es muy especial y Scrum no se puede aplicar tal cual", pero esa es la excusa para seguir manteniendo aquello que se estaba haciendo, con los mismos malos resultados que estabas teniendo y sin conseguir que el personal tenga esa motivación, ambición y empoderamiento que provoque unos resultados óptimos. ¿Sabes algunas "red flags" que anuncian entornos muy alejados de la excelencia? Cuando en la oferta de trabajo ponen: "Tu función, como Scrum Master, será la de mantener actualizado Jira y exportar métricas del equipo a Management para su evaluación" (uffff, es que no hay ni una palabra correcta). Si te preguntan en una entrevista cómo ayudas al equipo y tu primera respuesta es "Les actualizo el backlog y tomo nota en las dailys". Si te contratan, es que esa organización está lejísimos de trabajar bien. Espóiler: Si yo te hago la entrevista y me respondes eso, no necesito hacer más preguntas para descartarte. Next! Puede que seas un gran secretario, pero Scrum Master no. ¿Cómo solucionar este problema? Si eres (o quieres ser) Scrum Master, pero de verdad, tienes que formarte bien, entender bien para qué se hace cada punto que nos propone el marco de Scrum, cuestionarte todo lo que se hace en tu empresa y proponer cambios y mejoras continuamente (a todos los niveles). Si tienes una organización y has visto publicar alguna oferta de trabajo que se parezca a la del ejemplo, igual tienes que hacer una revisión de cómo estáis trabajando para salir de la cultura de la complacencia para poner el foco en la cultura de la excelencia. Sea cual sea el motivo, la solución la tienes con mi curso de Scrum Master con certificación oficial más las sesiones de consultoría Agile . Ahora sí entenderás por qué Scrum funciona, obtendrás las ventajas de usar Scrum, te costará lo mismo que cuando lo hacías mal y verás con el tiempo cómo los Desarrolladores pasan de odiar la forma en la que trabajáis a empezar a decir "así es como deberíamos haber trabajado antes", consiguiendo también que mejore su actitud y aptitud en el trabajo diario. Esto es algo parecido a lo que pasa con el modelo Spotify, que en el 99% de los casos no funciona porque lo único que se hace es llamar a los equipos "squads" y "tribus". ¿También haces eso? Entonces deberías contactar conmigo con bastante urgencia, porque hay mucho que corregir en tu empresa. Imagen de la entrada de Duncan Maddox