Si bien existe abundante material y oferta de cursos de formación para iniciarse en el agilismo, la implantación exitosa en un ámbito industrial sigue siendo un aspecto poco tratado y no resuelto satisfacoriamente. Un cambio en la forma de trabajo de un equipo conlleva los desafíos evidentes asociados a, por ejemplo, la introducción de una sistematización del trabajo, el cambio de actitud de los integrantes de equipo, el liderazgo necesario para impulsar la iniciativa de implantación, el apoyo de la dirección, la selección de herramientas, etc. Obviamente todos estos aspectos son claves para una implantación exitosa, sin embargo, hay otro, de carácter más técnico, que ha sido poco atendido y que resulta clave en el proceso de implantación de prácticas ágiles. Cada equipo tiene un contexto particular en cuanto al tipo de productos, servicios o proyectos en los cuales trabaja. Es bastante usual que un equipo deba gestionar de forma efectiva no sólo un producto, servicio o proyecto sino varios, posiblemente una mezcla de estos tipos y varios a la vez. Cada producto, servicio o proyecto tiene características específicas, con lo cual, aunque se trate de un mismo equipo, si se ignoran dichas diferencias y se aplica un solo enfoque para todo los tipos de trabajo probablemente el desempeño no será el más satisfactorio. Además, aparece un inconveniente adicional cuando se intenta dar una solución especial a cada tipo de trabajo, ¿como gestionar de forma integrada diversos tipos de trabajo y abordados con un mismo equipo?. Finalmente, otra dimensión que complica aún más la implantación de prácticas ágiles es la selección e implantación progresiva de prácticas. Si bien siempre existe la posibilidad de producir una "revolución" en cuanto a la forma de trabajo del equipo, en la mayoría de los casos el cambio debe hacerse más bien como una "evolución", es decir, el proceso de implantación es un punto de partida para lo que inmediatamente debe constituirse como un proceso de mejora continua, el cual extienda en el tiempo dicha selección y refinamiento estratégico de las prácticas aplicadas. En este taller comentaremos estos desafíos y estableceremos pautas que permitan ayudar en la implantación del agilismo en un equipo de trabajo con dicha diversidad de tipos de trabajo.

1. Implantando prácticas ágiles en un contexto
multi-proyecto
Patricio Letelier Torres
letelier@dsic.upv.es
Departamento Sistemas Informáticos y Computación (DSIC)
Universidad Politécnica de Valencia (UPV) - España

2. Agenda
Motivación
Visualización esencial => Tablero kanban
Solución a medida => Workflows
“Multi-kanban” visualización uniforme e integrada
Kanban, Sprints o mezcla
Planificación y Seguimiento
Visual Project Management
Conclusiones

3. Motivación

4. Soluciones a medida
Diversidad
o altamente configurables
4

5. Situación ideal
1
Proyecto
Equipo
Un equipo trabajando solo en un proyecto
en el mismo periodo de tiempo
5

6. Situación frecuente
*
Proyecto
Equipo
- Desafíos en cuando a la gestión de la capacidad del equipo
- Degradación del desempeño del equipo
6

7. Similar pero desde una perspectiva de supervisión
Departamento X
Proyecto1
Equipo1
Proyecto2
Equipo2
Proyecto3
Equipo4
Proyecto4
Equipo3
7

8. Tipos de agrupación del trabajo
Proyecto
Producto Servicio
8

9. Simplificación tipos de agrupación del trabajo
Proyecto
Producto/Servicio
9

10. Configuración básica para cada Producto/Servicio
Definición de actividades y workflows
(Método) Kanban
Limitar/Supervisar el WIP
Pre-asignación y balanceo de carga
Pre-asignación Sin pre-asignación
encargados Pre-asignación parcial
Ninguna
Medida del Esfuerzo Puntos
y Capacidad Tiempo restante
Tiempo estimado y tiempo invertido
No usar Sprints
Sprints Usar Sprints solo como agrupador
Usar Sprints como previsión o compromiso
No usar Proyectos/Releases
Proyectos/Releases
Usar Proyectos/Releases
10

11. Trabajo del equipo

12. Visualización esencial →
Tablero kanban

13. kanban elemental
To Do Doing Done
A B
C
D
E
F
G
13

14. …kanban elemental
To Do Doing Done
A
C
D E
B
F
G
Flujo

15. …kanban elemental
To Do Doing Done
A
C
D F E
H B
G
Flujo

16. …kanban elemental
To Do Doing Done
A C
D E
I
H B F
G
Flujo

17. …kanban elemental
To Do Doing Done
J A C
G
I E
H B F
D
Flujo

18. …kanban elemental
To Do Doing Done
H C
J
G A
I E
B F
D
Flujo

19. …kanban elemental
To Do Doing Done
C H
G
K A
E
J
L G
F
I
D B
Visibilidad del estado del trabajo
Conseguir un flujo de producción “Pull”
Limitar Supervisar el WIP (Work in Progress)

20. kanban más especifico
Actividad 1 Actividad 2 … Actividad n
Doing Done Doing Done … Doing Done
C H
…
K L G I
J D E A
G
F B
Las columnas corresponden a las actividades del workflow que sigue cada unidad de trabajo
Las WUs son cogidas en orden desde las actividades precedentes, desde la columna “Done” pasándolas a “Doing” en la
actividad que se inicia
Se podría establecer un límite para el WIP en cada columna Doing o Done de cualquier actividad  Kanban

21. Un kanban manual (de pared) es un excelente medio para motivar al equipo durante la introducción del
agilismo pero a medio y largo plazo es cuestionable como forma de trabajo escalable/sostenible
(http://bit.ly/ABKlOW), ¿debería ser soportado por una herramienta software? Solo Kanban
http://bit.ly/JBWE0U o algo más completo http://bit.ly/JoT9ou

22. Analizando el Flujo: Cumulative Flow Diagram (CFD)
Theory of Constraints (TOC) + Limitar Supervisar el WIP

23. Solución a medida =>
Workflows

24. Workflow “estilo” Scrum

25. Workflow “mediano” y más “tradicional”
25

26. Workflow más “complejo/completo”

27. “Know How” explícito en los WFs

28. “Multi-Kanban” visualización
uniforme e integrada

29. Equipo *
1..
*Proyecto
* Backlog
1..
* *
1..
*
*
1..
* *
1.. 1
Agente Producto/Servicio1 * Sprint
29

30. Desafíos de visualización
Vista integrada de
todo el trabajo de un
equipo o agente
Equipo *
1.. 0..
*Proyecto
* Backlog
1..
* 1..* *
Múltiples vistas del
trabajo, desde
*
1..
* *
1.. 1 Proyecto y desde
Producto/Servicio
Agente Producto/Servicio1 * Sprint
30

31. 31

32. Kanban, Sprints o mezcla

33. Sólo flujo (≅Kanban) para todo tipo de trabajo

34. Usando Sprints
SprintX Sprintx+1 Sprintx+2

35. Usando Sprints independientes
SprintX Sprintx+1 Sprintx+2
Sprinty Sprinty+1 Sprinty+2

36. Mezcla de tipos de trabajo con y sin Sprints
Capacidad
100%
Sprint1 Sprint2 Sprint3
80%
60%
40%
20%
0%
Semana1 Semana2 Semana3 Semana4 Tiempo

37. Usar el método Kanban, Sprints o incluso
mezcla es una decisión que debería tomarse
según características del tipo de trabajo del
equipo (es decir, para cada producto o
servicio)
37

38. Sólo flujo (Kanban) o usar Sprints
Recomendaciones
Usa Kanban si no existe un compromiso inflexible de plazos ni de alcance.
Usa Kanban si tienes poco control sobre la demanda (puedes priorizar pero no se
suele aplazar el trabajo, existen SLAs).
No uses Sprints previamente definidos si continuamente se estaría cambiando su
contenido, o úsalos pero no los consideres un compromiso. (Forecast versus
Commitment)
Usa Sprints previamente definidos para realizar un seguimiento con respecto de
estimaciones del trabajo (debes estimar) y de acuerdo a un compromiso.
38

39. Sólo flujo (Kanban) o usar Sprints
…Recomendaciones
Puedes usar Kanban mezclado con Sprints posteriormente definidos o implícitos,
éstos solo para estudiar la Capacidad invertida en Sprints vistos como intervalos
de tiempo que agrupan trabajo terminado (no sería necesario estimar).
Si usas Sprints previamente definidos debes planificar en base a una previsión de
Capacidad disponible y restante con respecto a la que te dejarían otros productos o
servicios.
39

40. Planificación y Seguimiento

41. Desafíos ante varios Productos/Servicios y Proyectos
Limitar el número de productos/servicios y/o proyectos en marcha
Reservar Capacidad para cada producto o servicio, o proyecto
Activación/Desactivación de Proyectos
Priorización de Proyectos
Acuerdo de Niveles de Servicio (para servicios)
Políticas explicitas para orientar al equipo en la selección de trabajo
41

42. Obtención de la Capacidad
42

43. Planificación de Proyecto o de Sprint
Backlog
*
Equipo *
1..
*Proyecto
Planificación de un
1..
* *
1..
* Proyecto asignandoun
Planificación de WUs
Proyecto
al Backlog o al Sprint
*
1..
* 1..
* 1
Agente Producto/Servicio1 * Sprint
43

44. El trabajo de un proyecto, según corresponda,
bien se incluye directamente en el kanban como
trabajo pendiente y ordenado, o se asigna en
Sprints o Backlog de los correspondientes
productos o servicios.
44

45. Seguimiento de Sprint o Proyecto
• Multi-kanban
• Burndown
Seguimiento • Trabajo Finalizado
del Proyecto • VPM
Equipo *Proyecto
0..
*
1.. 0..
* Seguimiento
del Sprint
*
0..
*
1..
Agente Producto/Servicio *
0.. Sprint
45

46. Seguimiento de 1 Sprint o 1 Proyecto
46

47. Hacia un“Cuadro de Mandos”
A B C
D E F
47

48. Visual Project Management - VPM
Holt, J. R., & Srinivasan, M. M., (2011, February). How to Get Things Done, Visual project
management shows the way,
http://bus.utk.edu/cba/news_articles/2011/documents/JF11_Reprint_Srinivasan_Holt.pdf
49

49. Configuración básica para cada Producto/Servicio
Definición de actividades y workflows
(Método) Kanban
Limitar/Supervisar el WIP
Pre-asignación y balanceo de carga
Pre-asignación Sin pre-asignación
encargados Pre-asignación parcial
Ninguna
Medida del Esfuerzo Puntos
y Capacidad Tiempo restante
Tiempo estimado y tiempo invertido
No usar Sprints
Sprints Usar Sprints solo como agrupador
Usar Sprints como previsión o compromiso
No usar Proyectos/Releases
Proyectos/Releases
Usar Proyectos/Releases
50

50. Implantando prácticas ágiles en un contexto
multi-proyecto
Gracias por vuestra atención!!
www.tuneupprocess.com
agilismoatwork.blogspot.com