Cómo evitar convertirse en un equipo con un enfoque de fábrica de características altamente eficiente

En el post anterior (que puedes leer aquí), estuve mostrando el manifiesto anti-ágil que guía a los equipos con un enfoque de fabrica de características. Por lo que en esta ocasión mi querido amigo lector, te quiero mostrar como tu equipo podría evitar convertirse en un equipo con un enfoque de fábrica de características altamente eficiente

Lo primero que tenemos que tener presente es que sin un enfoque que cree un escenario solido de gestión de productos, los equipos divagan en lo poco que los puede guiar el marco de trabajo que utilizan. Dado que cualquiera de estos, sea un método o un Framework, son solo marcos o métodos referenciales, lo que nos lleva a tener que complementarlos a través del principio básico de la experimentación.

Empecemos por responder la pregunta: ¿Qué es la Gestión de Productos o Product Management? La gestión de productos/Product Management, se ocupa de crear productos que resuelvan los problemas de los clientes, mejorando su experiencia, al tiempo que satisfacen las necesidades de la empresa.

La gestión de productos/Product Management, es un desafío para los equipos y sobre todo para los Product Owner, porque requiere una comprensión empresarial profunda junto con un conocimiento afondodo del cliente para tomar las decisiones de producto correctas. Al tiempo que exige de la empresa una cultura de confianza y delegación en la toma de decisiones.

Cuando las empresas tienen Product Owner que no cuentan con conocimiento ni experiencia en gestión de productos o Product Management, su implementación de Scrum, solo sirve para optimizar su capacidad de entrega, al hacerla más eficiente (si es que el Framework es correctamente implementado). Por lo tanto, no logran llenar el vacío que Scrum te deja, por lo que sus equipos terminan siendo guiados por el manifiesto anti-ágil de los equipos con enfoque de características, ahora altamente eficientes.

Los equipos con un enfoque de fabrica de características, pueden parecer productivos; después de todo, producen muchos entregables (algo que les gusta a sus lideres). Pero los entregables, se generan sin ninguna garantía de que están generando valor o que es la forma correcta de maximizarlo.

Ahora, ¿Qué es un escenario sólido de gestión de productos?

Mi querido amigo lector, en un escenario solido de gestión de productos, los equipos agiles se mueven en torno a los problemas que buscan resolver. Dado que hasta que no se comprenda el problema, las posibles soluciones a desarrollar, no forman parte de ninguna conversación.

Otro punto importante en este contexto consiste en que el resultado, es el foco. Por lo que los equipos tienen claridad sobre el impacto que quieren generar. Aquí los Roadmap de liberación definen objetivos a perseguir en lugar de los entregables a cumplir.

La gestión del Product Backlog es guiada por la estrategia de liberación con la que se busca maximizar el valor, por lo que a menudo se eliminan Historias de Usuario que pierden el sentido de realizarlas, ya que se encuentra una nueva funcionalidad que genera mas valor o sencillamente se valido una hipótesis que indica que el camino seguido ya no es el mas idóneo.

Es bien sabido que no solo conocer al cliente juega un papel fundamental, sino también el viaje que este sigue en nuestro flujo de generación de valor. Además, se interactúa con el, lo que permite recoger un feedback real, con el cual se validan las hipótesis que dieron pie a los posibles entregables.

Esto ultimo nos lleva a otro punto importante, el cual es la validación de las hipótesis. Los equipos con un escenario en el que prima el enfoque de gestión de productos, desde el momento de la creación de las hipótesis, definen no solo el tipo de valor que van a generar, sino también la forma en como van a medirlo. Y lo hacen, porque dentro de su proceso de generación de valor, tiene mucha importancia la validación de dichas hipótesis, ya que esta les brinda información valiosa del camino a seguir.

Ahora, en este escenario, una persona es responsable de principio a fin de la maximización del valor a generar, en Scrum lo llaman Product Owner y es este el que debe tener el poder de toma de decisión, a partir de la inspección de las necesidades de los clientes, de las necesidades de la organización (dado que debe maximizar también el ROI y en muchos casos hasta el ROE) y el análisis de los resultados obtenidos con los entregables.

Algo que sin duda debemos tener en cuenta, es que la gestión de productos es compleja. Motivo por el cual, el trabajo que realizan los Agile Coach y los Scrum Masters no es suficiente para entrenar a los Product Owner, debido a que muchos de estos, tampoco tienen conocimiento de lo que significa el Product Management. Lo que da como resultado, que estos, solo puedan entrenar una parte limitada del rol de Product Owner y cómo este encaja con Scrum. Algo que solo es el 10 al 20% de lo que un Product Owner debe saber.

Por lo tanto, si los equipos con un enfoque de fabrica de características, son guiados por un manifiesto anti-ágil, los equipos con un enfoque en la generación de valor, además de guiados por el manifiesto ágil, también tienen como referencia el manifiesto no oficial de la gestión de productos, el cual es:

Valores del manifiesto NO oficial de la Gestión de productos

  • Resolver problemas sobre la implementación de soluciones
  • Orientación al resultado sobre la definición de características
  • Validación de hipótesis en lugar de seguir opiniones
  • Empatizar con los usuarios finales en lugar de asumir sus necesidades

Principios del manifiesto NO oficial de la Gestión de productos

  1. Generar valor es la máxima medida de éxito.
  2. Establecer claridad sobre lo que significa valor y lo que no es clave para el éxito.
  3. Nunca comience a evaluar soluciones hasta que comprenda el problema.
  4. Establezca una prioridad a la vez y diga no a lo que le distraiga de eso.
  5. Adopte el aprendizaje encontrando formas rápidas de validar suposiciones.
  6. El liderazgo confía en que los equipos hacen lo correcto. Por lo tanto, los equipos están facultados para tomar decisiones.
  7. No guarde funciones inútiles en el Product backlog; eliminar lo que no agrega valor es fundamental.
  8. Adáptese continuamente a lo que se ha aprendido.
  9. Esfuércese por alinearse con las partes interesadas en lugar de tratar de complacerlas.
  10. Aprenda a diferenciar las necesidades de los deseos.
  11. El Feedback de los usuarios finales es más importante que las opiniones de las partes interesadas.
  12. Defina qué conduce al éxito y cree formas de medirlo a diario.

Espero que todo esto mi querido amigo lector, te sirva para que tus equipos no caigan en el enfoque de fabrica de características y por el contrario estos, cada vez entreguen más valor.

Mi querido amigo lector una vez mas, 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: