DispararEste artículo es una traducción autorizada del post "I Killed The Scrum Master (And Why He Had It Coming) de Daniel Markham publicado el pasado jueves, 24 de octubre en Tiny Giant Books, y al que desde aquí agradezco el permiso y la disposición para publicarlo en Navegápolis.

Por qué maté al Scrum Master

Ayer me preguntaba un cliente cómo podía mejorar un equipo que ya estaba trabajando muy bien. No lo tuve que pensar dos veces, vi la respuesta inmediatamente:

"Desazte del ScrumMaster"

¿Por qué?. ¿Lo estaba haciendo mal el ScrumMaster?. No. Su ScrumMaster es muy bueno. 
¿Se está confundiendo al SM con uin gestor de proyectos?. Quizá un poco, pero no más de lo habitual.

Tras haber visto decenas o cientos de equipos intentando lograr niveles altos de scrum y agilidad, sigo viendo una cosa: a una persona especial que sólo se ocupa de las tareas del ScrumMaster. Es como si tuviéramos en el equipo a alguien que sólo trabaja con bases de datos, o a una persona encargada sólo del interfaz de usuario. Es algo que simplemente no encaja en un equipo autónomo. Peor aún, es algo que genera una barrera entre los desarrolladores y el resto de la organización.
No era un rol destinado a producir eso, pero lo hace.

Siempre he pensado que el papel del SM debe rotar entre los miembros del equipo, y cuantos más equipos scrum conozco, más me reafirmo.
Veo que está surgiendo una industria en torno a "ser un líder de su equipo" y lo que está transmitiendo es claro: el SM es un líder, un perro pastor, un facilitador del que se espera un don de gentes especial.

En otras palabras, el ScrumMaster es sólo la versión del siglo 21 del gestor del proyecto.

¡Esto se pone bueno!  Sería volver a los viejos tiempos del gestor del proyecto: si el equipo no funciona se despide al gestor del proyecto. Pero ahora supone diezmar el equipo, porque el gestor del proyecto era el responsable cuando las cosas iban mal, y sin embargo hoy el ScrumMaster ha eludido por completo esa responsabilidad:  "¿El equipo no va bien? ¡Hey, estamos en agilidad y significa que el equipo es autónomo! Si el equipo no lo hace bien, ¡es su culpa, maldita sea! Sólo soy un facilitador. No se puede hacer nada si usted me da un montón de idiotas para trabajar."

No me malinterpreten: creo firmemente en la responsabilidad del equipo para conseguir y entregar el incremento de cada sprint. Es sólo que el papel de ScrumMaster también es parte del equipo y sin embargo ocupa un extraño lugar de supuesto campeón del proceso. 

Bah.

Voy a compartirles el pequeño y oscuro secreto del desarrollo de la tecnología que todo el mundo sabe pero nadie quiere admitir es mucho más fácil desarrollar en un programador habilidades básicas de gestión y negociación, que traer a alguien nuevo que es experto en esas habilidades, pero que no va a hacer nada útil.

Hablamos del ScrumMaster como si fuera un fin en si mismo. No lo es. Simplemente hace una serie de cosas en el sprint. Cualquier desarrollador debe ser capaz de hacerlas. Después de todo se trata de equipos que trabajan juntos y se llevan bien ¿cierto?   Los programadores son buenos con los números ¿cierto? ¿No van a poder hacer un par de gráficos en el tablero?.

No, el trabajo del ScrumMaster debe rotar en el equipo. Todo el mundo debería tener su turno. Acaba con la idea de que hay un tipo especial, con habilidades especiales que está involucrado en el equipo. 

Puede que ayude a vender cantidad de cursos de formación, puede que dé algo que hacer a toda esa gente en tu organización con certificaciones PMP, pero no es útil para el equipo ni para la cadena de valor.

Y no me refiero a los problemas con el propietario del producto :-)

Vídeo del autor Daniel Markham charlando sobre este artículo con Alan Dayley (en inglés).


Comentarios   

0 #5 Alberto 06-10-2015 08:04
Creo que el artículo es muy acertado en el fondo del que trata:
La "enmascaración" de un SM como un JP.

No comparto la comparación entre skills de los miembros del proyecto (tal y como cita Juan Quijano).
Esa idea en la homogeneidad de conocimientos entre los miembros del equipo que defienden algunas personas dentro del mundo Agile creo que no es acertada.
Nunca se conseguirá una especialización del equipo sin que haya una especialización en cada una de las áreas necesarias para la consecución del proyecto y eso; en desarrollo de SW complejos requiere especialización de muy distintas áreas. (BBDD y UX por ejemplo)

Voy más allá incluso.
A veces, estos especialistas de Scrum o la metodología concreta sólo saben de ésta y desconocen todos los aspectos relacionados con la jefatura o gestión del proyecto. Lo cual deja al equipo con una pata coja.
Citar
0 #4 Andoni 29-10-2013 01:11
Comparto la idea aunque en mi opinión el product Owner es fundamental en este escenario.
Un Product Owner que entienda y apoye al equipo facilitará esta transición, sino no lo veo tan claro. En este escenario parece que es así.
Citar
0 #3 Juan Quijano 28-10-2013 15:24
Si, ciertamente partiendo de la premisa de un equipo maduro, si. Posiblemente no solamente les sobre el SM, si no hasta una metodología específica.
Citar
0 #2 Juan Palacio 28-10-2013 13:48
Hola tocayo!

Para mi una clave con la que entiendo (o creo entender) la idea del artículo es la premisa con la que empieza: "cómo mejorar más a un equipo que está trabajando MUY BIEN" ("how to optimize a team that was already doing very well").

O por lo menos lo interpreto así, porque para mi un scrum master es como las ruedas guía o los ruedines para aprender a ir en bicicleta. Muy útiles para empezar, pero sobran cuando ya se ha aprendido.

Si un equipo tiene ya un nivel de fluidez muy alto y la cultura de la empresa ya es ágil (el equipo funciona "MUY BIEN") ¿cómo mejorar?.... pues quitando de la ecuación al scrum master que ya estorba más que ayuda.

Un saludo!
Citar
+1 #1 Juan Quijano 28-10-2013 11:43
Mmmm, me chirría mucho el artículo.

Tiene toda la razón en que el SM se puede ver convertido en un gestor de proyectos clásico. Pero no veo porqué eso está en contra del Agilismo, el cual trata de equipos auto suficientes, pero no autodirigidos.

Pero sobre todo me chirría que alguien que trabaje en el día a día en desarrollo pueda decir una barbaridad como que los skill, formación o conocimientos de un DBA pueden ser intercambiados trivialmente con los de un especialista en UX, o con un diseñador gráfico de interfaces o un desarrollador de backend puro.

Eso, no solamente es falso, si no que minimiza la dureza de cada especialidad. Y de las bondades de la especialización en los equipos de desarrollo.

Mmmm, no sé. Me chirría.
Citar

Escribir un comentario


Código de seguridad
Refescar