Esta es una situación común en muchas organizaciones que empiezan con Scrum en su búsqueda de la solución a todos los problemas.
El Product Owner no existe o está ausente todo el tiempo, lo que hace que recaiga todo el trabajo encima del equipo de desarrollo. Veamos que hacer.
Si no hay Product Owner o Scrum Master
Uno de los alumnos de mis clases era el CTO de una empresa mediana de desarrollo de herramientas para Recursos Humanos. Después del primer día de clase, en las preguntas finales del día, levantó la mano y dijo: Pero… si no hay Scrum Master o Product Owner, Scrum se puede adaptar, ¿No?
La respuesta es NO. Scrum requiere muy pocas cosas. Un Product Owner, un Scrum Master, un Equipo de Desarrollo.
Si no somos capaces de poner dos de esas tres, no vamos a obtener muchos beneficios.
Esta situación es típica de empresas muy rígidas que están afrontando problemas verdaderamente graves pero que buscan una solución fácil.
Todo les vale mientras no tengan que cambiar. Lo siento. Malas noticias. Scrum requiere unos cambios mínimos para avanzar.
La solución en este caso es, simplemente, no hacer Scrum. No llamar a lo que hacemos Scrum, porque el día que decidamos darle un oportunidad, los miembros de la organización ya tendrán una visión negativa del mismo.
Es mejor implementar algunas prácticas de XP, como el Daily Standup, Release and Iteration Planning o una base de código compartido que intentar hacer Scrum.
XP es una introducción perfecta a muchas prácticas que se utilizaran más adelante en Scrum.
Si el Product Owner está ausente todo el tiempo
Esta segunda situación es bastante común, y se da también en empresas consultoras que nominan como Product Owner al cliente sin pensar siquiera si entiende lo que esto supone.
El nivel de colaboración entre el Product Owner y el equipo de desarrollo es muy necesario, pero la mayoría de los Product Owners lo que entienden es que es un representante del negocio.
Nada más alejado de la realidad. El Product Owner es el negocio y no estando disponible para el equipo de desarrollo está poniendo en riesgo la inversión que supone dedicar un Sprint a hacer Software sin tener ningún feedback.
Al final, es el Product Owner el que tiene que dar la cara por todas las decisiones que se han tomado en torno a qué invertir el tiempo durante el Sprint.
Un Sprint del equipo Scrum cuesta de 25.000€ a 75.000€ por Iteración y es el Product Owner el responsable de manejar ese presupuesto. Una buena pregunta para el Product Owner ausente es: ¿En que hemos invertido los últimos 25/50/100.000€?
Es habitual que aquellos Product Owners que están demasiado ocupados para dar la cara respondan que ellos no manejan el dinero. Incluso se sientan ofendidos.
En la mayoría de las ocasiones, esta situación viene dada por no entender cuales son sus responsabilidades. Alguien les ha explicado que tienen que representar al cliente y las ha recomendado ver Scrum en 8 minutos o Scrum explicado a mi abuela, pero nunca les han explicado por qué existe el perfil.
Mi recomendación en este caso es invertir tiempo en explicar al Product Owner cual es el sentido del rol en Scrum. Empezar por preguntas como ¿Donde has invertido los último X€ de la empresa? llamará su atención lo suficiente como para propiciar una conversación
Cuando el Scrum Master o el equipo toman la responsabilidad del Product Owner
En algunos equipos ocurre algo distinto. El Product Owner delega en el Scrum Master o el equipo de desarrollo la toma de decisiones sobre lo que hacer. Esta opción es válida en Scrum, siempre y cuando tengamos claro que el último responsable de lo que haga el equipo sigue siendo el Product Owner.
Se puede delegar el hacer el trabajo pero no la responsabilidad sobre el trabajo. Un ejemplo típico sería el del Product Owner que ha estado ausente y llega al Sprint Review a quejarse del trabajo. Lo primero que hay que apuntar es que él o ella son responsables de lo que ha ocurrido y que han preferido no ejercer su rol y dejarlo a otros.
Cuando el Scrum Master toma la iniciativa de cubrir al Product Owner, no sólo le está haciendo un flaco favor al resto, sino que además está haciendo mal su trabajo como SM. El objetivo final del rol del Scrum Master es que Scrum funcione. Tomando la iniciativa de cubrir al PO, lo único que está haciendo es tapar las distinciones y problemas del marco de trabajo.
Deja una respuesta