Algunos ciclos en gestión de proyectos, gestión de productos, gestión de equipos en el mundo del software, por John Cutler

 ¿Por qué ese equipo siempre parece asumir demasiado trabajo?

 (Why does that team seem to always take on too much work? )

---

¿Por qué ese recurso compartido parece estar perpetuamente falto de personal?

(Why does that shared resource seem to be perpetually under-staffed?)

---

¿Por qué el equipo sigue empezando a planificar grandes lotes?

      (Why does the team keep slipping into planning big batches?)

---

¿Por qué una óptica miope se concentra en aumentar la velocidad, finalmente daña la calidad?

(Why does a myopic focus on increasing velocity eventually hurt quality?)

---

¿Por qué las historias del equipo nunca son "suficientemente buenas"?

(Why are the team’s stories never “good enough” ?)

---

¿Por qué mi equipo me oculta cosas?

(Why does my team hide things from me?)

---

Bueno ... viste lo que pasó cuando tratamos de asignarles un problema, ¿verdad?

(Well…you saw what happened when we tried to just hand them a problem, right?)

---

BONO (que envuelve muchas de estas)

{BONUS (that wraps up lots of these)}

---

Este es el tweet original

Some common loops #proddev #systems

1/7 Why does that team seem to always take on too much work? pic.twitter.com/AAbaTXzsQk

— John Cutler (@johncutlefish) November 22, 2019

Cómo evitar la "Ingenuidad Ágil", o sobre como tener éxito en proyectos ágiles en entornos tradicionales

Tomado de (1)

Hola a todos


En este acompañar equipos y organizaciones hacia el mindset ágil, con frecuencia he observado a Scrum Masters, e incluso Agile Coaches, ser ingenuos respecto al entorno en el que se encuentran y creer que su iniciativa, proyecto o producto ágil va a salir adelante solo con el burndown, burnup, kanban, uno que otro tablero y compartir sus pedidos de forma verbal con el o los interesados encargados de ayudar a la gestión del entorno empresarial, en efecto, esto debería ser suficiente pero la noticia cruel es que la mayoría de nuestros proyectos ágiles se desarrollan al inicio en entornos tradicionales, no amigables con el mindset ágil, por lo que  es necesario emplear herramientas de la gestión tradicional a modo de interfaz, como lo llamaría Michael Sahota (2).

Adaptado de (2)

Adaptado de (2)

Una de las herramientas que comúnmente sugiero, y bastante poderosa en entornos tradicionales es un informe semanal o quincenal con el estado de

• la gestión de riesgos
• la gestión de problemas o impedimentos

Claro, claro esto se puede gestionar con dos tableros,

o incluso con uno solo, que tenga dos carriles, unos impedimentos sean problemas a resolver lo antes posible y los riesgos sean problemas a resolver en el mediano plazo

y post-it que indiquen:

• descripción del problema o impedimento
• fecha de identificación
• persona a la que fue asignado
• días que lleva sin resolverse (pueden ser solo líneas en el post-it)

Pero un informe de carácter frecuente, con esta información con seguridad pondrá en evidencia la necesidad de gestión por parte del entorno tradicional.

Igual que un tablero, un informe frecuente también es transparencia.

Informe de Problemas o Impedimentos (3)

Informe de Riesgos(3)

como lo comparto muchas veces

"hasta que el entorno y las personas no muestren indicios de mindset ágil, deberemos interactuar con ellos con las herramientas a las que están acostumbrados y ayudarles a transitar a nuestro mindset"

Adaptado de (2)

Nota importante:
Esta misma ingenuidad la he visto en proyectos de gestión tradicional.


Bienvenidos sus comentarios

Saludos Ágiles
Jorge Abad

Notas, Comentarios, Aclaraciones y Observaciones

1. Photo on Visualhunt.com
2. Una guía de supervivencia a la adopción y transformación ágil: trabajando con cultura organizacional. Michael Sahota-  http://www.lecciones-aprendidas.info/2017/08/una-guia-de-supervivencia-la-adopcion-y.html
3. No dudo que estos reportes podrán tener más o menos información, deberán ser adaptados de acuerdo al contexto, pero recomiendo fuertemente:
• tener a alguien asignado para su resolución
• tener el tiempo de "no resolución"
• la importancia para el "proyecto"
4. Por lo general pongo "proyecto" (entre comillas) debido a que en el mundo ágil no se gestionan proyectos, sino productos.

Problema o Impedimento, una duda frecuente en Scrum

Hola a todos

Uno de los conceptos que con más recurrencia explica uno como Scrum Master al equipo después de un daily, es el concepto de IMPEDIMENTO

Generalmente se confunde Impedimento con Problema, veamos la definción de los dos bajo el contexto de Scrum y Equipos Ágiles:

Problema:

Dificultad que puede ser solucionada en el tiempo, ejemplo:

• una validación compleja
• incorporar un componente de software nuevo a la solución
• Un error que le esta saliendo a la persona que esta haciendo la tarea y le esta tomando tiempo resolverla
• etc

Impedimento:

Son eventos que bloquean la construcción de una o varias historias de usuario,  funcionalidades o ítemes del Sprint Backlog comprometido. Los impedimentos dependen demasiado del contexto, pero por lo general están asociados a una falta de información.

Ahora una cosa es cierta, cuando un problema lleva mucho tiempo sin resolverse, se convirtió en impedimento y es necesaria la intervención del Scrum Master.

Muchas veces luego del daily pregunto: "¿consideras que el problema X sabes/saben como resolverlo o definitivamente requieres/requieren ayuda?" y de acuerdo la respuesta entra o no en mi backlog de impedimentos a gestionar.

Bienvenida la discusión y aportes


Saludos ágiles
Jorge Abad

_