El lado oscuro de la agilidad - Frase

_

"El lado oscuro de la agilidad no es medir, es no mejorar" - Jorge Rafael Aristizabal - Agile Coach

_ 

Presentación: Las Seis Cosas que no Debe Hacer un Scrum Master

Presentation: The six (6) things a #ProductOwner should never do

Presentación: Las Seis (6) Cosas que no Debe Hacer un Product Owner

Podcast - Hormigas Agilistas - EP102 — Antipatrones de OKRs con Cristhian Arias Venturo

10 Anti-patterns (bad practices) in prioritization of Product Owners, PMO and VMO

Hello everyone

One of the factors that most destroys agility is the lack of adequate prioritization patterns according to the context in which it is located, that is, both upstream (1) and downstream (2) practices are used (which even from the good intention) destroy value for the organization. In general, we can incur:

• Building unnecessary things
• Building things that are necessary but worthless
• You don't build what's important
• We let ourselves be carried away by intuition
• We let ourselves be carried away by authority
• We let ourselves be carried away by feelings of friendship or enmity
• etc.

We destroy value and generate waste by dedicating time, effort and money from business areas, execution areas and suppliers in things that should not have been developed and relegating others, which would allow better financial performance or customer satisfaction.

---

---

---

(and one of mine)

"Building something that was not correctly prioritized is destroying value for the organization"

---

Below, I share some of the anti-patterns that I have observed when prioritizing both PMO - Project Management Office -, VMO -Value Management Office- and Product owners, and that I promote to be removed in processes of agile transformation or team agile coaching.  

I hope they will help you advance in the knowledge of better ways to prioritize the work to be done.

Expect more articles on this topic.

Agile greetings,

Jorge Abad.

 

References, notes, or comments

1. Upstream: where the project, product or initiative is prioritized by the PMO, VMO or those who are responsible for prioritizing the portfolio.
2. Downstream: where the product is being developed, and the solution team builds the different functionalities.

De Colección: 10 Antipatrones (malas prácticas) en priorización de Product Owners, PMO y VMO

Hola a todos,

Uno de los factores que más destruye la agilidad es la carencia de patrones adecuados de priorización de acuerdo con el contexto en el que se encuentre, es decir, tanto aguas arriba (upstream) (1) como aguas abajo (downstream) (2) se emplean prácticas (que aun desde la buena intención) destruyen valor para la organización. En general podemos incurrir en:

• construir cosas innecesarias
• construir cosas necesarias pero carentes de valor
• no se construye lo realmente importante
• nos dejamos llevar por la intuición
• nos dejamos llevar por la autoridad
• nos dejamos llevar por los sentimientos de amistad o enemistad
• etc.

En últimas, destruimos valor y hacemos que se genere desperdicio por dedicar tiempo, esfuerzo y dinero de áreas de negocio, áreas de ejecución y proveedores en cosas que no debían haber sido elaboradas y relegando otras, que permitirían un mejor desempeño financiero o de satisfacción del cliente.

---

---

(y una mía)

"Construir algo que no fue correctamente priorizado es destruir valor para la organización"

---

A continuación, te comparto algunos de los antipatrones que he observado al momento de priorizar tanto por PMO - Project Management Office -, VMO -Value Management Office- y Product owners, y que promuevo sean removidos en procesos de transformación ágil organizacional o de acompañamiento de equipos.

Espero te sirvan para avanzar en el conocimiento de mejores formas de priorizar el trabajo a realizar.

Espera más artículos sobre este tema.

Saludos ágiles,

Jorge Abad.

--- Ver video explicativo aquí ---

Referencias, notas o comentarios

1. Upstream: donde se prioriza el proyecto, producto o iniciativa por parte de la PMO, VMO o quienes se encargan de priorizar el portafolio.
2. Downstream: donde se está desarrollando el producto, y los equipos de solucionadores a construyen las diferentes funcionalidades.

Serie: Lesa Agilidad

-Mucho gusto soy el Product Owner

-¿Y vas a estar con el equipo?

- No, ya escribí todas las hu, solo vendré a los review a recibir el producto y ver el progreso

Dos Errores Comunes en las Historias de Usuario

Hola a todos

Aunque a través de varios escritos y post (1) he compartido que el formato de las historias de usuario es un formato libre,  pues

"cualquier modo de escribir o representar las Historias de Usuario sirve, siempre y cuando el Product Owner y el Equipo de Trabajo tengan la misma imagen mental de lo que se está requiriendo construir."

Pero, si un equipo se siente cómodo empleando la plantilla popularizada(2) por Mike Cohn,

Yo como _____ROL____ Deseo____UNA FUNCIONALIDAD___ Para_______BENEFICIO DE NEGOCIO__

La cual es ampliamente usada, ¡pues está bien!, ¡no hay lío con eso!.

Ahora, respecto a esta plantilla (la de Mike Cohn) quisiera compartirles dos errores frecuentes que he observado acompañando equipos de diferentes organizaciones:

El Primero, cuando se pone la historia de usuario en voz del Product Owner

Yo como _____PRODUCT OWNER____ Deseo____REGISTRAR LOS EGRESOS MENSUALES_   Para___PODER CALCULAR LA CAPACIDAD DE ENDEUDAMIENTO____

Y El Segundo, cuando ponemos la historia de usuario en voz del área funcional que la solicita

Yo como __VICEPRESIDENCIA FINANCIERA__ Deseo____REGISTRAR LOS EGRESOS MENSUALES____  Para___PODER CALCULAR LA CAPACIDAD DE ENDEUDAMIENTO____

La Forma Correcta es escribirla en voz de la persona que hace clic en el sistema, es decir, de quien usa la funcionalidad, que en este caso sería el SOLICITANTE DEL PRÉSTAMO, quedando la historia de usuario "bien escrita" de la siguiente forma:

Yo como _____SOLICITANTE DE PRÉSTAMO__  Deseo____REGISTRAR LOS EGRESOS MENSUALES____  Para___PODER CALCULAR LA CAPACIDAD DE ENDEUDAMIENTO____

Hasta acá este compartir

Saludos Ágiles
Jorge Abad

Referencias, Notas, Aclaraciones y Comentarios

1. Algunas referencias son:
• Libro de Historias de Usuario (clic aqui)
•  Modos de Representación de las Historias de Usuario - Un Capítulo del Libro Historias de Usuario una Visión Pragmática - clic aquí
• [De Colección] Lo más importante de las historias de usuario no es el formato sino la esencia - Tweet de Colección
• Algunos Tweets Importantes sobre Historias de Usuario
2. La plantilla fue desarrollada por Rachel Davies en la compañía Connextra de Inglaterra, en 2001, pero luego la popularizó Mike Cohn junto a otros entusiastas del modelo.