¿Debe un Scrum Master ser técnico?

En este caso, voy a dar la respuesta clara y directa: no, un Scrum Master no tiene por qué ser técnico. Ello no significa que un Scrum Master técnico no sea, en muchos casos, muy útil dentro de las empresas y muy valorado por los equipos. Analizamos todas las posibilidades y argumentos sobre el Scrum Master técnico. ¡Empezamos!  

Cambiamos el nombre, pero nada cambia

Las eternas dudas que surgen en las empresas son las funciones y labores de un Scrum Master. A pesar de que, en la Guía Scrum, tenemos una definición de sus responsabilidades, en muchas empresas existen dudas sobre sus verdaderas funciones. 

Como aprendimos, gracias a las Leyes de Larman, las empresas muchas veces tienden a cambiar el nombre a sus roles, pero sin que nada cambie. La consecuencia de esto es clara: tenemos que crear la figura del Scrum Master dentro de las organizaciones.

En muchas de ellas, se apuesta por convertir a los antiguos Jefes de Proyectos en Scrum Master. Esto tiene un problema derivado, las personas acaban por seguir haciendo sus funciones de siempre pero “al estilo Scrum”. Es decir, ahora tenemos más reuniones, lo que hace que Scrum sea menos efectivo bajo los parámetros tradicionales. 

En una ocasión, haciendo una formación en un gran retail, uno de los participantes nos dijo: “el Director del Departamento ha dicho que él iba a ser el Scrum Master, que le gustaba el nombre”. Esta anécdota reflejaba una grave incomprensión dentro de la empresa, lo que acaba generando casi siempre un gran fiasco Scrum. 

¿Debe un Scrum Master opinar sobre la parte técnica? 

Hace unos años, mientras viajabamos para jugar al fútbol, un amigo, Arquitecto Software, y otro, Scrum Master, conversábamos sobre este tema: ¿Debe un Scrum Master opinar sobre una solución técnica? Mi amigo Scrum Master decía que sí, que si tenías una buena idea, ¿por qué no? Sin embargo, el Arquitecto decía que prefería lo contrario. “Quiero que mi Scrum Master nos traslade a los técnicos el problema y que nosotros demos la solución”. Ante esta respuesta, le pregunté: “¿y qué esperas de tu Scrum Master?”. Y me respondió: “Con que entienda la solución y sea capaz de defenderla fuera del equipo, es suficiente”. 

Esta conversación sigue sin responder a la pregunta original del post. Por un lado, decimos que no “incide” en lo técnico, pero, por otro lado, queremos que tenga conocimientos para entender soluciones que provengan del equipo ¿Cuánto conocimiento tienen que tener?

Que un Scrum Master domine lo técnico permite entender muy bien los impedimentos técnicos del equipo y poder trabajarlos con la empresa.  Sin embargo, tiene un riesgo. En un mundo donde el Scrum Master viene de ser el Jefe de Proyectos, o en culturas donde el Scrum Master es “superior” en la jerarquía, podemos convertir su opinión en “ordeno y mando”. Esto es grave, porque una de las ventajas de Scrum es utilizar la inteligencia colectiva como herramienta en la toma de decisiones. 

Scrum es más que software

Las primeras personas que hablaron del modelo “rugby” o “Scrum” fueron Nonaka y Takeuchi en su paper de 1986. Tal y como analizamos en su momento, ellos estudiaron diferentes equipos en varias empresas top del momento y observaron que había aparecido una manera diferente de trabajar en equipo. Es curioso, ninguno de estos equipos era de desarrollo software. Sin embargo, el marco Scrum actual sí que parte de equipos software con los que Jeff Sutherland y Ken Schwaber trabajaron a principio de los 90. Por tanto, Scrum es impulsado gracias a equipos software, pero no solo se usa para el software. 

En la edición de Scrum de 2017 se aseguraba que se podía utilizar para muchos ámbitos, no solo en el desarrollo software. Es más, en la reciente edición de 2020, se ha modificado gran parte del lenguaje,  para enseñar que Scrum es un marco para crear productos en entornos complejos, sean software o de otro tipo. 

Por tanto, si aplicamos Scrum en muchos ámbitos, la duda que nos debemos hacer es: ¿Debe ser el Scrum Master un experto del dominio sobre el que trate su producto? 

Cómo mejorar las habilidades de un equipo

Hace unos años, me encontraba acompañando a un equipo nuevo que hacía Scrum. Me invitaron a participar en la primera retrospectiva. Cuando llegué, me percaté de que el Product Owner no estaba y les pregunté cuál era el motivo. La respuesta fue: “Javi, tenemos que hablar de cosas que no podemos contarle al Product Owner, le hemos vendido que somos expertos en una tecnología en la que no tenemos experiencia”. Tuvimos un análisis moral sobre la situación, aún así, la realidad era clara: hay que aprender sobre una tecnología. 

En este caso, la chica que hacía de Scrum Master planteó varias opciones, entre ellas pedirle a la empresa que un compañero les diera formación y acompañamiento. Optaron por ello y la Scrum Master gestionó que ocurriera. 

Para mí, este tipo de situaciones son en las que un Scrum Master debe entrar. Hay un impedimento claro y se buscan soluciones. Obviamente, si el Scrum Master hubiera sabido de esa tecnología, podría haberles enseñado, pero el objetivo es que el equipo mejore sus habilidades. 

El trabajo de un Scrum Master es buscar que, entre otras cosas, el equipo mejore sus habilidades para ser capaz de entregar valor. Hay muchas maneras de conseguirlo, además de enseñarles. Entre otras cosas, porque puede perder objetividad o ser muy prescriptivo. Es mejor que sea el propio equipo quien determine cómo mejorar, y el Scrum Master el que busque vías viables para ello.

Los impedimentos no son solo técnicos

El objetivo de un Scrum Master no es solo que los Developers mejoren sus habilidades de desarrollo o su capacidad de entrega. También, debe enseñar Product Management al Product Owner, lo que supone gestión del Product Backlog, métricas de Producto o gestión de expectativas. A todo esto, sumamos que debe resolver impedimentos, y muchos de ellos no son técnicos, requieren trabajar con la organización para su implantación Scrum. 

Dominar todas esas técnicas es casi imposible. En mi experiencia, si como Scrum Master solo te centras en las habilidades de los Developers, descuidarás muchos otros factores. En el mejor de los casos, muchos equipos acabarán quejándose de que su organización no les deja trabajar o que les impone fechas imposibles. 

Hace unos meses, lancé una encuesta en Linkedin sobre qué factor era el más importante en las empresas. En la encuesta, las opciones eran: fecha de entrega, coste, producto (alcance) y calidad. La calidad, acabó en último lugar con muy poca importancia. Sin embargo, la calidad es clave para la agilidad de un equipo y para su capacidad de responder y de mantener el producto. Por ello, el primer paso de un Scrum Master es hacer ver a la organización la importancia de la calidad y por qué hay que apostar por ella. De poco sirve enseñar a un equipo calidad técnica, si no pueden aplicarla: ello sólo generará frustración. 

¿Quién elige al Scrum Master?

Hace unos años acompañé a un equipo en un conflicto grave con su Scrum Master. No se ponían de acuerdo y la organización decidió separarlos. Para evitar que el nuevo Scrum Master no funcionara, la empresa dejó que los Developers entrevistaran a los candidatos. Esto les permitió un mayor entendimiento entre Scrum Master y el equipo al que debía servir, lo que generó una buena relación entre ambos y que funcionara. 

Este hecho, me enseñó que puede ser una buena práctica dejar que los Developers elijan o, al menos, propongan a su Scrum Master. En mi experiencia, esto apenas ocurre entre otros motivos porque el Scrum Master suele ser un “jefe” del equipo. Las empresas quieren a alguien de confianza y esto provoca que impongan a los Scrum Master. 

Sinceramente, si los Developers seleccionaran a su Scrum Master, seguramente muchos querrían que fueran personas técnicas. Considero es válido, pero cuidado, hay una regla muy clara en Scrum: no se puede anteponer el trabajo de Scrum Master a otra labor. 

Y tú ¿crees que el Scrum Master debe ser técnico?