Esta pregunta me la han hecho decenas de veces. Dejar a un lado los esquemas tradicionales de cadena de mando es una de las cosas que más cuesta a la hora de adoptar Scrum. No, en Scrum no hay jefes. No hay jefe de proyecto ni project manager o espécimen que podamos asemejar.
Entonces, ¿quién manda? Porque alguien tiene que mandar, ¿no? Pues no. O, al menos, no de la manera a la que estamos habituados.
En Scrum, “el mando” corresponde a la totalidad del equipo, si bien la responsabilidad se reparte entre los tres roles que define el framework: Scrum Master, Product Owner y Equipo de Desarrollo. En otras palabras, las atribuciones del project manajer al uso se distribuyen de una forma diferente, de modo que el rol del jefe de proyecto no existe. No.
Veamos, grosso modo, las responsabilidades de los roles que sí existen en Scrum.
– El Scrum Master es el responsable del proceso, de la gestión de impedimentos y de la correcta utilización de Scrum como framework.
– El Product Owner vela por maximizar el valor del producto -le compete el llamado Total Cost of Ownership- y es el responsable de gestionar el Product Backlog. Define el qué y aporta su visión sobre el producto.
– El Equipo de Desarrollo se encarga de transformar los elementos del Product Backlog seleccionados para el Sprint en el Incremento de funcionalidad. Define e implementa el cómo.
Hacer la transición de project manager a Scrum Master o Product Owner es viable, aunque tendremos que abandonar antiguos hábitos y empaparnos de una mentalidad distinta: en Scrum no hay única persona responsable de la entrega de un alcance cerrado en presupuesto y tiempo, ni la velocidad es una medida del valor que estamos creando.
Lo anterior no quiere decir que Scrum solo pueda utilizarse en organizaciones horizontales o sin jefes. De hecho, lo normal será que los equipos Scrum convivan con el organigrama jerárquico de la empresa. Y he aquí uno de los principales escoyos a la implantación con éxito de Scrum: si los directivos de la organización no lo entienden ni lo predican, lo tendremos muy complicado. La labor evangelizadora del Scrum Master tiene sus límites.
En empresas de software, los managers tradicionales deben hacer la transición para convertirse en agile managers (recordemos aquí el concepto de liderazgo de nivel 5). En lugar de obstaculizar la adopción de Scrum o de impedirla al someter a los equipos a las viejas prácticas (micro-gestión, reporting excesivo, etc.), deben contribuir a crear un entorno en el que los equipos Scrum puedan autoorganizarse, en el que puedan florecer, eliminando los impedimentos para ello.
Próximamente hablaremos del llamado management 3.0.
Imagen: Vector de Hombre creado por pch.vector – www.freepik.es