Product Owners vs. Product Executors

Van a ser casi dos años desde que empecé a trabajar en King y en todo este tiempo he aprendido muchas cosas. Una de ellas ha sido poder experimentar otra forma de trabajar, de organizarse y de gestionar equipos. Parte, probablemente, facilitado por usar una metodología de trabajo agile, parte promovido por la filosofía de la empresa.

Hasta el momento, en todas las empresas que había trabajado, tenían una organización y métodos de trabajo clásicos. Con estructuras piramidales, donde hay jefes y donde los miembros de un equipo eran Product Executors. Es decir, miembros que se dedican a ejecutar órdenes en el desarrollo y evolución del producto, sólo ejecutan decisiones tomadas. El jefe o departamento de turno deciden el qué, el cuándo y el para cuándo y el equipo, en general, sólo tiene poder para decidir el cómo. Poco margen de decisión le puede quedar al equipo, más allá de cómo se desarrollará tecnológicamente el producto/proyecto (a veces ni eso)

Ahora, no es que tengamos jefes, que los tenemos. No es que no tengamos organigrama, que también lo tenemos. Y no es que nadie tome decisiones, que se toman. Pero el equipo tiene mucho peso en las decisiones y cada miembro del equipo de desarrollo es, en parte, también un Product Owner. El equipo tiene la figura de Product Owner que es el responsable de marcar la ruta de trabajo, de estudiar al cliente final, de conocer qué se quiere. Pero al final es el propio equipo quien decide qué se implementa (todo el mundo tiene la libertad de convocar reuniones para definir nuevas cosas), el cuándo se implementa algo (se hacen reuniones regulares donde el equipo planifica qué se hace y qué no), para cuándo estará cada cosa implementada (si el equipo decide que no estará para la fecha esperada se acepta la decisión del equipo o se negocia un menor alcance del producto) y el cómo.

Esto redunda en muchos beneficios para el equipo y, por consiguiente, para la empresa. Porque los miembros del equipo trabajan más motivados y sienten al producto como suyo propio. No son meros ejecutores de órdenes, si no que se involucran en las decisiones y, principalmente, se respeta cualquier decisión que sale desde el equipo. Los miembros están más implicados en el desarrollo y éxito del producto/proyecto.

Pero, obviamente, esto no es tan fácil de implementar. Para su éxito, se requiere una alta dosis de confianza de la empresa en el equipo, en su trabajo y en sus decisiones. Característica que no siempre (y, especialmente, en este país) se suele dar.

It's almost two years since I started working at King, and during all this time I've learned lot of things. One of them, being able to experience another way of working, organising and managing teams. Most likely, provided by using an agile methodology, but also promoted by the company culture.

All the companies I've worked for so far had a classic organisation and work methods. Pyramidal hierarchies, with typical bosses and where the team members were Product Executors. I mean, the members could only execute commands, already taken and agreed decisions. The boss or corresponding department decided the what, when, by when and, usually, the team could only decide how.

I don't mean we don't have bosses now, because we do have. I don't mean we don't have hierarchy, because we do have as well, or nobody takes decisions, because they are taken. But the team has too much to say when taking decisions and each team member is, kind of, a Product Owner. The role of Product Owner exists within the team, who is the person responsible of making the roadmap, study the final user, know what he/she wants. But, in the end, it's the own team who decides what is going to be implemented (everybody in the team has the freedom to organise meetings in order to specify and define new features), the when it's implemented (there are often meetings where the team plans what to do and what not to do), by when a feature is to be implemented (if the team decides that something can't happen for an expected date, the team decision is accepted or a smaller product scope is negotiated) and the how.

This results in many benefits for the team and, therefore, for the company. Because the team members will be working much more motivated and feeling the product as their own. They are not just command executors, but they are involved in the decision taking flow and, specially, any decision taken by them is respected. Resulting in a team totally get involved in the development and success of the product/project.

But, obviously, not everything is too easy to implement. For its success, this requires a high amount of trust from the company in the team, in its work and decisions. Something that usually (specially in Spain) doesn't happen.

Gestión de proyectos: PMP vs Scrum

En mis últimos 7 años en Gigames, mi rol estuvo siempre moviéndose entre  Team Leader y Project Manager. Digo que estuvo moviéndose entre estos dos roles porque, aunque supuestamente yo era un Team Leader, creo que siempre hice tareas de más responsabilidad cercanas a un Project Manager, aunque nunca llegando a serlo al 100%.

Además de mi experiencia, durante todo este tiempo también me estuve formando como Project Manager, tanto de forma autodidacta con la lectura de diversos libros, como a través de un par de cursos, siempre todo basado en la metodología PMP del PMI. Mientras recibía esta formación, sentía cierta curiosidad por otras metodologías como Prince2 y Scrum.

De la misma forma que de Prince2 he leído y escuchado varias veces que es una metodología muy parecida y similar al PMP, no pasaba lo mismo con Scrum, donde todo lo leído y escuchado se dirigía a que eran metodologías muy diferentes. Incluso hace pocas semanas, en una entrevista de trabajo, el entrevistador me comentaba que, mientras PMP era una metodología muy rígida y escricta, Scrum se trataba de una metodología flexible y ágil. Al final la curiosidad me mató y terminé por leer varias cosas de Scrum para saber de qué iba dicha metodología tan famosa. Así que después de leer el artículo Explicando Scrum a mi abuela, el libro Scrum desde las trincheras y Scrum Guide, puedo decir que por fin sé de qué trata Scrum y cómo funciona (al menos desde la teoría)

A parte de encontrar Scrum como una metodología interesante que permite un desarrollo bastante flexible y adaptable, muy rápidamente, a cambios, también creo que he visto claro que PMP y Scrum no sólo son opuestas, sino que son metodologías compatibles que podrían usarse a la vez, siempre que se traten proyectos de software.

PMP se trata de una metodología de gestión para todo tipo de proyectos, independientemente el sector, el entorno, el tamaño o la complejidad del mismo. Divide el proceso de gestión de proyectos en 5 fases, controlando durante todo el proceso 9 variables o áreas de conocimiento. Mediante estas 5 fases o procesos y las 9 áreas de conocimiento, pretende marcar unas reglas y bases para gestionar todo el ciclo de vida de un proyecto desde que éste se le da OK para llevarlo a cabo, hasta que se de por finalizado y se cierra, gestionando variables como el riesgo, la calidad, la comunicación, los recursos, la gestión de cambios,...

Scrum, en cambio, es una metodología o marco de trabajo para el desarrollo sólo de proyectos de software, encaminando la gestión a una gestión flexible y adaptada al cambio, con equipos pequeños y completamente flexibles.

Dada la natularela de ambas metodologías, creo que están enfocadas a soluciones diferentes. Mientras que PMP se encarga de gestionar todo el ciclo de vida del proyecto, Scrum se enfoca en el desarrollo de software. Es decir, pienso que fácilmente ante un nuevo proyecto de software se puede enfocar su gestión usando metodología PMP en toda su amplitud y, al llegar a las fases de Ejecución, Seguimiento y Control, usar Scrum para el desarrollo y seguimiento del desarrollo del producto.

Ahora toca ir a por Prince2.