¿Será que Agile está en Crisis? (el caso del extremo #WIP)

RespuestasAgiles: ¿Qué es la LEY DE LITTLE y por qué es importante para las GERENCIAS DE TI y PMOs?

Video: Obtención y Explicación de la Gráfica de Flujo Acumulativo

A continuación encontrarás la Hoja de Cálculo empleada durante el ejemplo, puedes descargarla para tu uso.

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

Varios proyectos a la vez generará más retraso en la generación de valor. Limita el WIP.

Hola a todos

Muchas veces tenemos la sensación de que debemos satisfacer las necesidades de todas las áreas o personas que nos piden tareas, requerimientos o proyectos, esto sucede a nivel:

• individual
• de equipo
• de áreas de construcción o ejecución de proyectos y productos de software,

con la sensación de que debemos atenderlos a todos, ya sea para no generar quejas, o por evitar problemas políticos, pero esto en vez de ayudarnos generará:

• pérdida de foco
• grandes esfuerzos de gestión y pérdida de energía, pues debes estar pendiente de varias cosas a la vez
• retrasos en la entrega, que a su vez generará:
• más inconformidad en las áreas que esperan resultados
• pérdida de valor de las funcionalidades construidas y la necesidad de introducir cambios
• sobrecostos por los cambios introducidos
• pérdida de dinero debido a la no generación oportuna de valor
• poca flexibilidad para reaccionar a los cambios, debido a que debes resolver muchas cosas a la vez y habrá demoras resolviendo un problema puntual.

Por eso, si lideras un equipo, un área de ejecución o aún de forma individual, te sugiero que:

• tengas foco
• hagas una o pocas cosas a la vez
• Limita el Work In Progres (WIP) o trabajo en progreso
• Aprende a decir ¡No!

Sino, tu propias ganas de satisfacer a todos, distruirá tu propósito de generar valor, cayendo en el adagio popular 

"El que mucho abarca, poco aprieta"

Saludos ágiles

Jorge Abad

Tweet sobre DevOps

"Hasta que el código no esté en producción, en realidad no se está generando ningún valor, porque es WIP atrapado en el sistema" #devOps pic.twitter.com/1RwBcvmKYv

— Mauro Strione (@MauroStrione) June 24, 2017

Una dinámica/juego para enseñar Scrum - Revista Scrum

El pasado 20 de marzo de 2013 en la materia Gestión de Proyectos Informáticos la cual imparto para lacohorte 9 de laEspecialización y Maestría en Ingeniería de Software en la Universidad de Medellín (Medellín - Antioquia - Colombia) www.udem.edu.co ,  realizamos una simulación para aprender como funciona de Scrum.

Antes del Juego se realizó la presentación  SCRUM (ver diapositivas) en la cual se revisaron los conceptos principales y más importantes del marco de trabajo (framework) de SCRUM.


Los parámetros fueron los siguientes:

3 equipos de 6 personas, cada equipo provisto al menos de:

• Un Scrum Master (elegido por el equipo)
• Un Product Owner (elegido por el equipo)
• 3 Revistas de variedades
• 3 Tijeras
• Pegante
• 40 Hojas reciclables tamaño carta
• 2 tacos (bloques) de Pos-it/Sticky Notes/
• Lapiceros y marcadores

Objetivo:

• Construir una revista basada en recorte de imágenes y textos que estos sean pegados en las hojas reciclables tamaño carta. 

Requisitos:

• La revista debe contar con un índice de artículos y numeración para cada hoja.
• Todo a excepción del indice de artículos debe ser cortado y pegado

Para construir las hojas se emplearán fotos de diferente tipo y renglones de texto cortados en forma de rectángulo. Se emplearán los siguientes tipos de fotos

• A: Foto de una mujer
• B: Fotos de un carro
• C: Fotos de un hombre
• D: Foto de algo que sea diferente a A, B, C y D

 Las hojas de la revista pueden de las siguientes tipos:

• Hoja Tipo 1:  1 foto + 1 descripción
• Hoja Tipo 2:  2 fotos + 2 descripciones
• Hoja Tipo 3:  3 fotos
• Hoja Tipo 4:  5 fotos + 1 descripciones
• Hoja Tipo 5:  Menú
• Hoja Tipo 6:  2 fotos
• Hoja Tipo 7:  3 fotos + 3 descripciones

Fotografía 1

Por lo tanto si se me pide una Hoja Tipo 7 con fotos A, significa que la hoja debe contener:

• 3 fotos de mujeres recortadas
• 3 descripciones de texto recortadas

DETALLES DEL EJERCICIO

1. Se crearon los tres equipos
2. Se explicó la forma de armar la revista
3. Se creó un Product Backlog priorizado para cada equipo (Ver imagen en las columnas PB1, PB2, PB3)
4. Se definió un Sprint de 41 minutos con las siguientes características de tiempo:

• Plannig = 8 minutos
• Duración del dia 1= 7 minutos
• Reunión de daily 1 = 2 minutos
• Duración del día 2 = 7 minutos
• Reunión de daily 2 = 2 minutos                                    
• Duración del día 3 = 7 minutos                                   Fotografía 2
• Review = 4 minutos
• Retrospectiva 4 minutos

Al final del ejercicio se realizaron 3 sprints, para un total de 123 minutos. (2 horas de trabajo)

5. Se realizó una calificación (al inicio del juego) por puntos para cada "HOJA TIPO" en donde por votación por EL JUEGO DEL POKER (puntuando con 1, 2, 3, 5, 8,13 - y empleando cada integrante la aplicación para Android Scrum Poker para simular las cartas) se puntuaron cada de las hojas asi:

• Hoja Tipo 1:  3 puntos
• Hoja Tipo 2:  8 puntos
• Hoja Tipo 3:  5 puntos
• Hoja Tipo 4:  13 puntos
• Hoja Tipo 5:  3 puntos
• Hoja Tipo 6:  3 puntos
• Hoja Tipo 7:  13 puntos

Fotografía 3

6. A cada Scrum Master se le enfatizó las características de su rol.
7. A cada Product Owner se le enfatizó las características de su rol y la potestad de recibir o rechazar las Hojas con sus diferentes fotografías y descripciones (que vendrían a ser el símil de las historias de usuario), adicionalmente de hacer respetar la prioridad del product backlog
8. Se estableció el criterio de DONE como: "una hoja con todos sus elementos correctamente pegados"
9. Se insistió que el objeto del planning era:

• establecer el compromiso de puntos
• realizar el tasking plasmando la hoja (u símil de Historia de Usuario) de la siguiente manera :

   HISTORIA TIPO 4 = Foto1 + Foto2 + Foto3 + Foto4 + Descripción1 

(ver la Fotografía 1)

• Construir el Kanban de acuerdo al tasking y  poniendo en la parte superior la historia de mayor prioridad.
• Construir el Burndown chart

10. Se insistió que NO era un ejercicio donde se COMPETÍA por construir la mayor cantidad de Backlog, sino que tenía como objeto REALIZAR CORRECTAMENTE Y PASO A PASO LO FORMULADO POR EL FRAMEWORK DE SCRUM.

12. Se empoderó al equipo para que alguien dentro del mismo se encargara de actualizar la gráfica de BURNDOWN CHART con los puntos pendientes al final de cada día.

13. [esto se olvido, aunque se debió haber hecho] En el uso de Kanban se debe recordar quien va y toma una tarea del kanban (va y "merca" decimos donde trabajo) para ejecutarla debe firmala y pasarla WIP y luego a DONE cuando la termine.

Fotografía 4

Fotografía 5

Fotografía 6

RESULTADO FINAL DEL EJERCICIO

1. Se realizaron 3 Sprints para construir el Backlog.
2. Los equipos lograron con las retrospectivas corregir el proceso y ser más eficientes construyendo páginas y de esta manera aumentaban el compromiso durante los dos planes subsiguientes.
3. Durante el ejercicio se corrigieron aspectos como:

• la necesidad de hacer el daily de pie
• la actualización día a día del Burndown chart
• la actualización y paso de tareas en el kanban
• en el kanban en la columna del WIP (work in progress) solo puede existir una tarea por miembro del equipo.

4. Se hizo una retrospectiva del ejercicio por parte de los estudiantes diciendo que la compresión del framework aumento de forma considerable con el ejercicio.

-----

Este fué el ejercicio que se realizó, pienso seguir empleándolo en las capacitaciones que dicto y en los cursos que imparto.

Queda así a disposición de la comunidad ágil y si tienen retroalimentación será bienvenida.

Saludos

Jorge Abad