No existe un consenso total sobre este tema, como era de esperar, más aún cuando la propia guía de Scrum no entra en cuestiones técnicas (que se dejan fuera, para tomarlas de otros frameworks, típicamente de eXtreme Programming).
La guía de Scrum no cita actividades como programar, ya que Scrum no es un framework de desarrollo software (alguna referencia).
La guía de Scrum (abajo pantallazo) no entra en ello, solo dice, como cercano, que el Scrum Master debe ayudar al equipo de desarrollo a crear productos de alto valor, y esa línea cada uno la interpreta como quiere. Puedes sacar de ahí la idea de que ayuda programando o que ayuda aplicando, por ejemplo, técnicas de motivación (así son de interpretables estas cosas).
Así que, como en otras ocasiones, vamos a ver que se dice por ahí, que opinan los que saben, y luego te contaré que opino yo.
En este post no vamos a entrar en otros conocimientos que se espera que tenga un Scrum Master, ni en los que refieren a la mejora el proceso, eficiencia, eficacia, valor, mejora de equipos, etc.
En este post sólo vamos a hablar de si debería tener conocimientos técnicos. Para estas y otras cuestiones, te dejo los principales post que hay en el blog sobre Scrum Master:
- Cómo ser Scrum Master: 6 consejos (en vídeo)
- Los origenes del Scrum Master
- Una infografía (en español) sobre el rol del Scrum Master (año 2014, ya está un poco viejuna)
- La pedazo serie de 3 post que escribieron Sergio Tiscar y Rubén Ortiz: Enlace al primer post de esta serie, aquí esta el Enlace al segundo post de esta serie y el enlace al tercero
- Scrum Master: ¿Qué es? ¿Qué hace?
- Por qué algunos Scrum Master fallan: el Scrum Master complaciente
El problema de centrarse sólo en mejorar el proceso sin apoyarse en conocimientos técnicos
Han sido varios de los firmantes del Manifiesto Ágil los que se han pronunciado sobre este tema.
Principalmente Ron Jeffries y, quizá con más rotundidad, Robert Martin (al que tuve la suerte de entrevistar hace años, aquí te dejo la entrevista).
En una de sus charlas (penosamente grabada, por cierto, pero se puede ver), de hace unos años, dejó bastante clara su opinión, te dejo algunas frases de esa charla (translated by jgarzas):
- Scrum olvidó incorporar las disciplinas técnicas que hacen que la agilidad funcione [de esto somos conscientes y en numerosas ocasiones se ha hablado que la idea era usar Scrum con eXtreme Programming, en ámbitos técnicos]
- Inicialmente un Scrum Master era un entrenador [él utiliza la palabra coach, a la que tantas interpretaciones le hemos dado], un Scrum Master no era un el gerente explícitamente, el Scrum Master era responsable de defender el proceso.
- Se suponía que el rol rotaría entre los distintos miembros del equipo y, francamente, la idea del rol era desaparecer lentamente, así que al final no necesitarías un Scrum Master.
- Pero sucedió que no se enseñaron las prácticas técnicas en los cursos de certificación de Scrum Master, todo lo relacionado con la programación por pares, el diseño simple, la refactorización y el desarrollo dirigido por pruebas, que estaban allí por una razón, porque cuando vas rápido necesitas algo que te mantenga limpio, necesitas algo que evite que el código se pudra
- Lo que se olvidó de Scrum fue que no se puede tener velocidad sin calidad, no se puede tener velocidad sin calidad técnica, no se puede tener velocidad mientras se tiene deuda técnica y cuanto más deuda técnica se tenga, más lento se irá, este es un círculo horrible
- (Ojo a esta) Si la agilidad va a sobrevivir es recordando sus raíces, que fueron un conjunto de prácticas técnicas combinadas con un conjunto de prácticas de gestión, las dos estaban unidas inseparablemente
Hay más referencias que apoyan que el Scrum Master debe tener conocimientos técnicos para apoyar a los equipos, como esta, en la que el autor también opina que un gran Scrum Master debe conocer eXtreme Programming.
También aquí hay un artículo largo, y bien referenciado, sobre la necesidad de conocimientos técnicos por parte de los Scrum Master.
Y también habrá gente que opine lo contrario, así que…
Cómo lo veo yo
Obviamente, si un Scrum Master quiere ayudar al máximo a un equipo es necesario que conozca aspectos y prácticas técnicas, de esto ya había hablado en su momento, por ejemplo en este vídeo (min 2:41) y mucho antes, en 2014, en el post de «El problema de no entender nada de tecnología. Si no tienes formación técnica haz ya un curso básico de programación, mejorarás como profesional«.
¿Tiene que dedicarse a programar? Yo creo que NO tiene que dedicarse a programar en el equipo, no como el resto del equipo técnico, que se asignan tareas derivadas de Historias de Usuario, porque entonces nos quedaríamos sin Scrum Master y sin todas las otras cosas en las que apoya (más allá de cuestiones técnicas).
Pero si debe dar apoyo en, además, cuestiones técnicas, relacionadas con aumentar al eficiencia del proceso. Al igual que apoya en otras cosas, y da ese apoyo según las necesidades y circunstancias del equipo.
Puede que un Sprint, por lo que sea, el Scrum Master no tenga que entrar en dar apoyo en cuestiones técnicas y en otro sí. Y esto diferencia bastante la dedicación técnica de un Scrum Master frente a la de un programador (que todos los Sprints hace tareas de programación).
¿Qué conocimientos técnicos?
De manera general, más allá de las particularidades del producto que desarrolla cada equipo, creo existe bastante consenso en los siguientes (te dejo esta referencia y también esta otra), resumiendo y agrupando mucho:
- Mucho Test: Test Driven, automatización de Test, by example, Test Unitarios, etc.
- Deuda Técnica: código limpio, calidad de código, etc.
- Integración continua y continuous delivery.
Ampliaría lo anterior entrando en conocer las prácticas de eXtreme Programmming.
¿Y si no soy técnico de formación?
Aquí mi recomendación, como en su día dejé en «el problema de no entender nada de tecnología. Si no tienes formación técnica haz ya un curso básico de programación, mejorarás como profesional«, es que al igual que muchos Scrum Master hacen cursos de Coaching, de Managment 3.0, de liderazgo, etc., que se formen también en cuestiones técnicas que les sirvan para mejorar, poder entender mejor a sus equipos y darles apoyo (e incluso formación) en cuestiones técnicas, no tanto de programación pura y dura, y si en cuestiones técnicas referentes a Testing, código limpio, integración continua, Sonar, etc.
Se puede hacer, se puede aprender, cómo no, y tener el conocimiento técnico necesario para entender el lenguaje del equipo y apoyar en cuestiones técnicas que potencien la eficiencia del proceso.
No es cuestión de que te conviertas en un gran programador, es cuestión de que te conviertas en un gran Scrum Master (que no es lo mismo).
postdoctorado en la Universidad Carnegie Mellon,
EE.UU. Es pionero en management, planificación,
estimación, product management, Agilidad y en la
aplicación de la inteligencia artificial generativa a la
gestión de la creación de productos y servicios
tecnológicos. Fue el único español en la primera
conferencia Ágil de la historia.
- Diario: cómo Javier Garzás evita quedarse obsoleto estudiando a un X10 con IA-Esteroides - 7 noviembre, 2024
- Si creas Historias de Usuario con IA ¿A quién pertenecen? ¿A ti o la IA? El mono Naruto te lo explica - 31 octubre, 2024
- HistorIAs de usuario y como a Maximiliano lo ENGAÑABAN con la IA y como una viejuna historia del 1500 le salvó - 24 octubre, 2024
Excelente post Javier, gracias por compartir.
La guía scrum, cuando habla del tamaño de los equipos, dice: «Los roles de Propietario del Producto (Product Owner) y Scrum Master no se contabilizan en el cálculo del tamaño del equipo a menos que también estén contribuyendo a
trabajar en la Pila del Sprint (Sprint Backlog)», así que la guía scrum SÍ contempla la posibilidad de que un Scrum Master trabaje en los PBI, es decir que pueda ser técnico. Incluso un PO. De hecho en un equipo pequeño, de 3 o 4 personas puede tener bastante sentido en mi opinión. Quizás no en la misma medida para no perder otras competencias como bien comentas. Pero afirmar un rotundo NO creo que es un error. Y para los puristas esa frase puede hacerles pensar.
Excelente post, yo soy programador y aspiro a ser scrum master, creo que mi rol de futuro scrum master ayudaria mas a un grupo de programadores. saludos
Hola Javier, excelente reflexión, clara y sencilla, de lectura rápida. Y como siempre nos dejas otras vías para profundizar sobre el tema.
La frase que me iluminó de este artículo fue «Se suponía que el rol rotaría entre los distintos miembros del equipo y, francamente, la idea del rol era desaparecer lentamente, así que al final no necesitarías un Scrum Master.»
Aprovecho para comentar, que el equipo mismo podrá apoyar al Scrum Master en compensar su conocimiento técnico y viceversa, al fin y al cabo de eso se trata la «construcción de equipos».
Gracias.
Hola Javier,
Gracias por el post, esta muy bueno, como siempre.
Me gustaria saber si podrias hacer algun post, acerca del rol de Scrum Master en equipos que no son netamente de desarrollo. Sobretodo ahora que Scrum se usa para gestionar proyectos de toda indole.
Hola Javier, te sigo para saber sobre todo este mundo, Trabajo en una empresa, soy la jefa de control de calidad y nuestra área siempre se ha basado en pruebas funcionales, hasta hace poco estamos implementando crear casos de prueba. Que recomendaciones me darías para aplicar mejores prácticas en este rol de jefe. Gracias!