Utilizar Scrum nos reta a cambiar la visión de trabajar por proyecto a trabajar por producto. Las dos palabras comienzan con “p” y ambas tienen la misma cantidad de letras, pero la connotación es muy distinta y en este aparente sencillo cambio de letras hay un trasfondo con respecto a cómo enfocamos nuestro esfuerzo.

El proyecto típicamente está regido por fecha de inicio y fecha fin, en la mayoría de las definiciones que se busquen se va a encontrar la palabra “temporal” o alguna combinación interesante como “esfuerzo temporal”. Esta definición nos llevó inconscientemente (o tal vez consciente) de regirnos por el tiempo, a eso le dimos peso, al esfuerzo (actividades) sobre el tiempo y ocurrieron los siguientes escenarios:

Al tener un solo periodo de tiempo (fecha inicio y fecha fin) compuesto de varias etapas (con su propia fecha de inicio y fecha fin) que a su vez tenían bloques (con su fecha tiempo y su fecha fin), nos enfocamos regularmente a centrarnos en el cumplimiento del tiempo olvidando: la calidad y el entendimiento de la solución.
A las personas asignadas a los proyectos se les pedía justificar su trabajo semanal (con frecuencia en un hermoso formato de excel) en horas trabajadas y nos olvidamos de que el tiempo es relativo en cada persona y una hora puede ser sumamente productiva en alguien y la misma hora ser totalmente improductiva en otra persona.
Ante un incumplimiento en calidad, entendimiento o en la fecha pactada de entrega, los equipos buscaban demostrar su esfuerzo en el tiempo otorgado tratando de justificarse ante su cliente y ya todos sabemos cómo termina esa historia.

La lista de escenarios relacionados al tiempo y la justificación del mismo ante un retraso o a un problema de calidad es larga, pero por lo menos estos 3 anteriores sirven de ejemplo para demostrar que nos sirvió de poco tener al tiempo como eje principal.

Cuando Scrum nos pide que nos orientemos a producto y no a proyecto, lo primero que hay que soltar es pensar en el tiempo y tomar como nuevo eje al valor.

La generación de valor es una nueva guía que nos redirige hacia:

Cuidar la calidad – Llegar a la fecha acordada habiendo generado valor, valor de negocio y valor técnico (minimizar la deuda técnica).

Podemos estar saturados de actividades durante toda la semana y llegar al viernes sin haber generado valor.

Y apareció el Product Owner... ¿apareció?

No es casualidad que exista el rol de Product Owner dentro del marco de Scrum y créanme, no se puso ahí para re-bautizar los nombres de los roles que ya se tenían dedicados a pasar requerimientos, ni se puso ahí de adorno para que el Scrum Master fuera Product Owner a la vez, se puso para romper el silo que puede provocar pensar en proyectos asignados al área de desarrollo de software sino pensar en que el producto lo creamos todos y que para que esto suceda hay una necesidad de presencia en el equipo rompiendo la barrera de ser solo “solicitantes de software” sino que haya un dueño de producto que se encargue de tiempo completo a entender las necesidades de los usuarios, de los clientes, del mercado. Alguien que custodie los intereses del cliente para poder negociar en favor del mismo (por cierto, negociar no es imponer fechas). Alguien que ayude a priorizar los requerimientos cambiantes manteniendo el valor que se planea y que se entrega en cada iteración.

El producto no responde a los silos porque está compuesto de todas las esencias en una proporción muy similar, es decir, un producto exitoso lleva mezcladas las esencias de sus creadores: negocio, ventas, marketing, diseño, desarrollo, pruebas, infraestructura, entre otras muchas.

Conclusiones:

Aceptemos que de nada sirve justificar lo que hacemos en el tiempo si no generamos valor para el cliente y no generamos negocio.
Aceptemos que es difícil romper los silos que tantos años nos llevó construir, pero ahora son estorbos que nos impiden avanzar.
Aceptemos que colaborar no es sencillo cuando hay un equipo multidisciplinario, pero no es imposible.
Aceptemos que no le hemos dado el suficiente peso e importancia al rol de Product Owner.