Lo que pocos dicen sobre las certificaciones y responsabilidades del Scrum Master y es necesario saber
Por Vanessa Amaya
Para escribir este blog me basé en la sesión de #AgileTalks con Juan Banda donde habló de “Scrum Master avanzado o nivelación de lo mal aprendido”, nos dio mucho de qué hablar pero sobre todo, nos dio para reflexionar.
En este blog desarrollaré los conceptos que considero más valiosos de lo que Juan nos platicó:
“Por más que lo intentemos, un curso de dos días de Scrum Master no sienta todas las bases”.
Las responsabilidades que conlleva el ser Scrum Master traen consigo cambios profundos, cambios que si bien pueden ser disparados por el conocimiento que se reciba en un curso de dos días, estos disparadores deben de llevar a nuevos hábitos, nuevas reflexiones y mejoramiento continuo.
Y precisamente por ser un disparador importante, hay que cuidar el medio para recibirlo y en este caso, es quienes diseñen e impartan la experiencia de aprendizaje. Yo he estado en varias empresas que imparten cursos de agilidad y por ello hoy te puedo decir esto: Fíjate en QUIÉN imparte el curso, no solo que tenga acreditaciones sino que cuente con experiencia. Gracias a las redes sociales y al internet puedes indagar sobre antecedentes y reputación de la persona.
Sobre esto, Juan comentó “Las bases deben estar sólidas para poder escalar”. “Las bases frágiles de Scrum acaban repercutiendo en una práctica inadecuada”.
Algunos toman el curso de certificación para iniciar su camino como Scrum Master, otros cuando su camino ya va avanzado, lo importante es saber que esa certificación es PARTE DE UN CAMINO. Sobre esto, Juan comentó: “Un curso de dos días NO es un techo, es una plataforma”. “No es un TÉRMINO del camino, es un INICIO”.
“Aceptemos que, la palabra MASTER crea la ilusión de que realmente dominaste Scrum”
Los que trabajamos como instructores, no sólo nos enfrentamos al aprendizaje continuo en conocimientos y habilidades relacionadas al tema que impartamos, también nos enfrentamos a retos pedagógico. Lo anterior es lo esperado, pero algo inesperado (ya que no es nuestra especialidad) es el Marketing alrededor de la venta de un curso .
Si te crees “Master”, vas a generar creencias limitantes para tu continuar tu aprendizaje, no puede haber Gurús dentro de una rama tan reciente en entornos laborales con alta variabilidad. Dicho lo anterior, retomo otra frase que dijo Juan: “Hay que bajar el EGO para seguir avanzando”.
¡De manejo de ego hay tanto material y tanto que trabajar! Solo por el momento, te digo a ti que me lees, que si trabajas en ello, grandes oportunidades se abrirán para ti y para tus equipos.
“De nada sirve Scrum, si la gente sigue codificando/trabajando como antes”
Muchos asocian cambiar la forma de trabajar solamente relacionada a hacer los eventos que Scrum pide (Sprint Planning, Sprint, Daiy Meeting, Sprint Review, Retrospective), incluso con frecuencia ni siquiera se enfocan en que esos eventos sean vehículos de cambio, con llevarlos a cabo (como sea y sin profundidad) se cree que ya es suficiente, los resultados con alta frecuencia mostrarán lo contrario.
Pero en el mejor de los escenarios, que si se hagan bien los eventos, como dije, es un vehículo de cambio, no es el cambio en sí mismo, el cambio es que la dinámica de trabajo se convierta en colaborativa, donde se manifiesten los valores de Scrum (Compromiso, apertura, valentía, respeto, enfoque) y donde cambien las formas de “hacer” para generar valor y esto incluye, mejorar la forma de programar.
“El Scrum Master NO debe descuidar lo técnico”.
¡Este punto ha ocasionado controversias en varios foros! Me encantó que Juan hablara de este punto porque si bien varios hemos defendido que, en un equipo de desarrollo de software el Scrum Master no se suele asignar tareas de programación (por la carga de trabajo que generan sus responsabilidades) pero cuando tiene conocimientos técnicos puede entender mejor el origen de los impedimentos que tiene el equipo y ayudar mejor. En el video se menciona, que si estás en un equipo de desarrollo de software, el/la Scrum Master debe entender para colaborar con lo técnico y esto incluye el fomentar mejores prácticas de programación y de integración continua. Fomentar no necesariamente es que el Scrum Master enseñe directamente pero que busque la manera de que el equipo reciba guía sobre estos temas, sin embargo, cuando descuida lo técnico, estos temas nunca entrarán en su agenda.
