Una Mirada a: «la simplicidad, el arte de maximizar la cantidad de trabajo no realizado, es esencial.» desde los ojos de un Product Owner.

Encontrar la solución adecuada para el problema que queremos resolver es vital para lograr el éxito. De ahí, que los grandes equipos se esfuerzan por desarrollar soluciones precisas, ya que entienden que al construir una solución más compleja de lo necesario, se generaran residuos, se ralentizará el tiempo de comercialización y para colmo, se generará inevitablemente más deuda técnica.

En este sentido, toma mucha relevancia para un equipo entender claramente el principio del manifiesto ágil que dice: “la simplicidad, el arte de maximizar la cantidad de trabajo no realizado, es esencial.», que se expone en el manifiesto ágil. Es por eso mi querido amigo lector, que en esta ocasión, estaré proponiéndote una mirada de este principio que debería tener un Product Owner.

Y es que todo Product Owner, debería alegrarse cuando los desarrolladores le desafían sobre los temas que trae al refinamiento de los ítems del Product Backlog. Ya que esto demuestra que están interesados ​​en resolver problemas reales. Sin embargo, muchos desarrolladores no aceptan que los Product Owner desafíen la solución técnica. Ya que, en muchos casos piensan que estos se están entrometiendo en su definición del cómo, tal vez algunos lo hagan con esa intención (cosa que no debería suceder), pero en realidad hay que entender que los equipos de alto desempeño, logran resultados asombrosos porque no les temen a las diferencias de opinión que puedan llegar a tener entre ellos. Por el contrario, potencializan esas diferencias para diseñar y desarrollar soluciones que generen alto valor.

Patrick Lencioni, en su libro: “The Five Dysfunctions of a Team: A Leadership Fable” (Las cinco disfunciones de un equipo: una fábula de liderazgo), plantea lo siguiente: “Es tan simple como esto. Cuando las personas no descargan sus opiniones y sienten que han sido escuchadas, realmente no se unirán”. Y nada más cierto que esto, ya que de parte la premisa que debemos hacer partícipes a las personas de las definiciones, para que logren empoderarse de lo que hacen. De ahí la importancia, que dicha comunicación y desafío sea en doble vía.

En Scrum, por ejemplo, los Product Owner son dueños del por qué. Entonces, como responsables de la maximización del valor a generar, deben decidir por qué el equipo debe trabajar en algo. Ahora, dado que el equipo de desarrollo es dueño del cómo, ellos deciden cómo resolver los problemas. Sin embargo, no debemos olvidar que la responsabilidad final de todo lo que se elabora es de todo el Scrum Team. Por lo que, el grado de colaboración entre los miembros del equipo determinará su éxito.

Los Product Owner entonces, deben “desafiar” al equipo de desarrollo en la solución técnica. La intención de hacerlo es asegurarse de que no se generen residuos, se reduzca el time to market y se produzca la mínima cantidad de deuda técnica, entre otros factores importantes para el éxito de la solución. Otro punto importante con esto, es que un Product Owner, debe garantizar que no se estén diseñando soluciones demasiado complejas, de tal modo que dicho desafío, también buscara que el equipo traiga más opciones planteadas a la mesa.

Hay que tener claro entonces, que no se trata de cuestionar las habilidades técnicas del equipo de desarrollo. Por el contrario, se trata de ayudarles a pensar qué solución técnica se adapta perfectamente al problema que queremos resolver.

En este sentido, algunas preguntas planteadas por el Product Owner al equipo que podrían ayudar a identificar soluciones precisas, podrían ser:

  1. ¿Es esta la solución más simple que podemos construir?
  2. ¿Por qué es esta la mejor solución para este problema?
  3. ¿Qué creen que podríamos estar omitiendo?
  4. ¿Cuáles son las otras opciones que podríamos considerar?
  5. ¿Qué suposiciones tenemos con esta solución?

Según mi experiencia, si los desarrolladores no desafían al Product Owner, tendemos a crear soluciones que son demasiado simples. Y si los Product Owner no desafían a los desarrolladores, tendemos a desarrollar soluciones que son demasiado complejas para el problema que queremos resolver. Por lo que, mi querido amigo lector, el equilibrio adecuado en estos desafíos, es vital para construir soluciones de alto valor y que estemos alineados con el cumplimiento del principio ágil que se planteó en este post.

Mi querido amigo lector una vez más, Gracias por tu tiempo.

Ah y porque no todo es lectura, quiero compartir también contigo los videos de algunos de los espacios en los que he participado y que podrás encontrar en mi canal de YouTube llamado «Habilitando la Agilidad«

Podrás visitar y suscribirte al canal aquí

Pd1:Te invito a dar un vistazo a mi libro recomendado del mes (Clic Aquí)

Pd2: Ahora puedes escuchar AudioPost Aqui, una nueva forma que tengo de compartir contigo nuevas entradas.

Saludos,


También te puede interesar Leer



SUSCRÍBETE A MI BLOG

Y cada vez que realice una nueva publicación, recíbela al instante.


    
Suscríbete al Blog
Y entérate cada vez que realice una nueva publicación.
Suscribirse
Te puedes dar de baja cuando lo desees!
close-link
A %d blogueros les gusta esto: