Hace unos años, participé en una formación de Professional Scrum Product Owner (PSPO) que nos impartió Jerónimo Palacios, de Scrum.org . Durante la formación, estudiamos un módulo sobre Product Management. Estamos muy acostumbrados a trabajar en proyectos basados en control, tratando de tener certidumbre. En el mundo del conocimiento, como el software, es difícil, dada su complejidad, tener certidumbre. Si queremos generar valor, trabajar bajo Producto es la mejor estrategia, porque construimos con foco en resultados, a base de inspección y adaptación.
¿Qué abarca el Product Management?
Durante esta formación, nos mostraron una diapositiva que explicaba la diferencia entre Scrum y Product Managment. El Product Management abarca todo aquello que esté relacionado con el producto, esto es mucho más que construirlo. Entre las muchas labores, destacaremos: ponerle precio al producto, estudiar al mercado, promociones, marketing, proveedores… Todo lo que afecta al producto debe ser gestionado.
Scrum, solo suele cubrir una parte de estas labores, generalmente todo lo relacionado con su construcción (iterativo e incremental). Por tanto, el Product Owner sólo será responsable de una parte de las tareas relacionadas con el producto. Por ejemplo, si queremos reclutar gente, el Product Owner podrá solicitarlo, pero será el Departamento de Recursos Humanos quien fiche. O si queremos mejores ordenadores para el equipo, tendrá que aprobarlo Compras.
El motivo principal es que no construimos empresas en torno a equipos, sino a funciones. Creemos que, si agrupamos las funciones, haremos un gran trabajo. Sin embargo, falta la visión completa del resultado de nuestro trabajo. Que muchos futbolistas corran mucho individualmente no garantiza un buen rendimiento del equipo.
Product Manager o Product Owner
Dado que el Product Owner no cubre todas las funciones, en muchas empresas se apuesta por jerarquizar estas labores y situar a un Product Manager por encima del Product Owner. De esta manera, disponemos de una figura centrada en todo lo que no sea construir el producto.
Analizamos en un artículo pasado esta distinción. Sin embargo, hay que decir que, cuantas más personas tomen decisiones sobre un producto, más complejo lo hacemos. Esto se traduce en muchas reuniones que, analizadas, son improductivas, porque no nos centramos en la generación de valor.
Trabajando con una organización de producto, de cara a organizarse, habían creado funciones de Responsable de Producto, de Tecnologías y de Procesos. De manera que, todo lo que afectaba a un producto, quedaba diluído en varias áreas, lo que suponía muchas reuniones para gestionar y excesivo micromanagement.
Scrum 2020, todo cambia
Scrum nace en 1995, pero se basa en varios estudios previos. Con cada nueva versión de Scrum, se han reforzado dos ideas: Scrum es más que software, y debemos pensar en Producto. De todos los cambios que se han introducido, hay varios que afectan a los roles y a sus responsabilidades.
Por un lado, se ha eliminado el concepto “rol”, para eliminar distinciones dentro del Scrum Team. Se ha querido darle más relevancia. Hablamos de un Scrum Team que se responsabiliza de la entrega de valor y que se autogestiona. La autogestión es un nivel más elevado de la autoorganización, lo que supone que el equipo debe tener más capacidad de decisión. Hay un párrafo que refuerza esta idea de una manera muy clara:
“The Scrum Team is responsible for all product-related activities from stakeholder collaboration, verification, maintenance, operation, experimentation, research and development, and anything else that might be required. They are structured and empowered by the organization to manage their own work.” – Scrum Guide 2020
Es decir, ahora no deberíamos hacer distinción entre Scrum y Product Management, sino que, el Scrum Team debe cubrir todo el Product Management.
Scrum Team Autoorganizado
Vivimos en un mundo donde el trabajo en equipo es la clave del éxito de cualquier iniciativa: cirugía, deporte, bomberos o incluso la crianza de niños, todo se hace en equipo si quieres ser exitoso. Incluso en deportes individuales, los propios deportistas tienen un equipo detrás que les acompañan y apoyan.
Scrum ha evolucionado, trata de dar respuestas a las empresas de por qué tienen problemas al desarrollar software. Toda decisión que afecte a un equipo, y se tome fuera de las “fronteras” del Scrum Team, será un potencial impedimento que afecte a su rendimiento y a su capacidad de entregar valor.
Si lo piensas, tiene sentido, porque reducimos la toma de decisión y evitamos tener conversaciones orientadas al control, en vez de a nuestros usuarios y clientes. De esta manera, si queremos hacer Scrum en una empresa, tendremos que organizarnos por equipos con mayor autonomía y no por funciones tradicionales.
¿Qué te parecen estos cambios de Scrum?
Creo que el marco de Scrum tal vez no lo dejaba claro, pero dentro de las responsabilidades del PO ya constaban el estudio del mercado y otras tareas basadas en la relación con los Stakeholders. No obstante coincido contigo que en las organizaciones nos encanta poner capas de decisión y algunas personas interpretando a su manera distinguen estas dos figuras. Incluso sin llamarlos PM… hay Responsable de Negocio, Gestor de negocio, etc.
Muy buena aportación para dejar claro este aspecto que aunque siendo la Guia de Scrum tan cortita cuesta que se la lean y la estudien bien.
Muchas gracias, desde luego, en las empresas tiene que existir una reflexión sobre las funciones del PO.