Seminario Kanban y Scrumban

Kanban & Scrumban

Madrid, Junio 2011

© 2011 Proyectalis Gestión de Proyectos S.L. – Presentaciones en http://slideshare.net/proyectalis

ngel M edinilla!
Á @proye
c talis.co
m
edinilla
angel.m l_m
@ange


¡Un placer!


Ejercicio: Scrum Ball


Ground
Rules


**
*

Tomad notas

Open Mind


¡No matéis al mensajero!


Mmmmm…
Almuerzo…


Suficiente para empezar


Lean Systems


Lean Thinking
“Una manera de pensar que permite a las organizaciones
especificar el valor, alinear las actividades que añaden
valor en la mejor secuencia posible, desarrollar estas
actividades sin interrupción cuando alguien las solicita
y desempeñarlas más y más eficientemente”


5 principios
 Valor máximo al cliente (eliminar desperdicios)
 Optimizar la cadena de valor
 Flow (flujo productivo)
 Pull Systems
 Mejora continua


Valor
 Definido por el cliente
(maximizar)
 No todo lo que el cliente
paga es valor – actividades
que tienen coste y no
añaden valor al producto
(desperdicio)


Standish
68% proyectos
Group fallidos o problemáticos

59¢ valor por
cada $ de software

64%
funcionalidades no
usadas


MUDA
 Actividades que no añaden valor
 En manufactura:
 Sobreproducción
 Esperas
 Transportes
 Movimiento innecesario
 Inventario
 Sobreproceso
 Defectos
 Retrabajos


MUDA
 Actividades que no añaden valor
 En IT:
 Features no usadas
 Retrasos
 Reuniones
 Hand-offs, burocracias
 WIP, portfolio
 Gold-plating
 Bugs
 Devoluciones, QA al final


MURA
 Ineficiencia por variabilidad del proceso
 En manufactura:
 Altibajos en producción
 Retrasos
 Flujo hacia atrás
 Cuellos de botella
 Falta de estándares
 Atajos oficiales y oficiosos


MURA
 Ineficiencia por variabilidad del proceso
 En IT:
 Paradas y rearranques
 Cambio de contexto
 Multitarea
 Repriorizaciones
 Heterogeneidad
 Prescindir de calidad
 Tiempo de ciclo impredecible


MURI
 “No razonable”, ineficiencia por
sobrecarga del proceso
 En manufactura:
 Sobrecarga de maquinaria
 Sobreexplotación


MURI
 “No razonable”, ineficiencia por
sobrecarga del proceso
 En IT:
 Plazos de entrega irreales
 Sobrecompromiso
 “No podemos decir NO”
 Horas extra por sistema
 “Wishful thinking”
 “Belief in magic”


Debate: las estimaciones como
MUDA


Estimaciones


Cono de Incertidumbre

(Pista: estimar aquí )

Cono de incertidumbre


Incertidumbre


Precisión vs tiempo

Suficientemente
buena


Complejidad
Requisitos

Tecnología


Triángulo de hierro

Tiempo Alcance

?
Recursos


Tradicional vs. Ágil

Fijar: Alcance Coste Tiempo

Orientación
a Valor

Orientación
a Plan

Estimar: Coste Tiempo Alcance


Gedanken: el P.O. perfecto

…..


Histograma


Histograma
Norma


Histograma
Norma

95% SLA
80% SLA


Proyectos dispares

 Con tallas de camiseta (para
tamaño de peticiones)
 Distintos histogramas:
 XS – 3 días
 S – 40 días
 M – 90días
 L – 150 días
 XL – 220 días


“pero necesitamos presupuestos…”


Cadena de valor


Ejercicio: Cadena de valor


Visualizar el flujo de trabajo


Waste!


“Stop the line”
 Política de cero defectos
 Reducción del gasto
 Pensamiento a largo plazo
 Foco en calidad
 Si detectamos un
problema, paramos y
solucionamos


Ejercicio: serie o
paralelo


Fabricación por lotes
Proceso 1 A B

Proceso 2 A+B


Fabricación por lotes
Proceso 1 A B

Proceso 2 A+B

Proceso 1 A B A B A B A B
Lotes más
pequeños:
Proceso 2 A+B A+B A+B A+B


Agilidad y tamaño de lotes


Flow
Procesos de 1 minuto, 3 procesos consecutivos, lote (batch) de 10 productos

B B B BB B BB B C C
C C

Proceso A: 10 minutos Proceso B: 10 minutos Proceso C: 10 minutos

Lead Time : para todo el lote 30 ++ minutos


Flow

B B B BB B BB B C C
C C



Continous Flow
Lead Time: 12 minutos
“produce uno,
entrega uno” – cero
inventarios

3 min. 12 min.


Flow

B B B BB B BB B C C
C C



INTEGRACIÓN
CONTINUA + LOTES
PEQUEÑOS

3 min. 12 min.


Flow

B B B BB B BB B C C
C C



Ley de Little: tiempo de
ciclo aumenta con el
número de elementos
en curso

AAA BBB CCC (30min)
3 min. 12 min.
ABC ABC ABC (12 min)

Lean Software Development
“In lean enterprises, traditional organisational structures give
way to new team-oriented organisations which are centred
on the flow of value, not on functional expertise.”

Mary Poppendiek


Flow

WIP++ WIP--


Flow & Batch Size

 6 grúas, 6 muelles, 6 barcos
 1 grúa = 1 barco / 6 días (acumulable, 2 grúas 3 días)


Flow & Batch Size

 Descarga simultánea: todos 6 días
 Total uso muelles: 36 días


“Swarming”

 Todas las grúas a un barco (1 día)
 Día 6: todos en el mar
 Total uso muelles: 21 días


Colas múltiples / cola simple


“Swarming”

 Buscar compromiso entre
eficiencia en cola e ineficiencia al
trabajar todos en lo mismo
(coordinación, dependencias…)
 “9 mujeres embarazadas no dan
a luz a un niño en un mes”
 Sin embargo, técnicas como Pair
Programing, integración continua
o propiedad colectiva de código
aportan una mayor eficiencia que
“cada uno a lo suyo”


Optimización vs Suboptimización

Optimizar el tiempo de ciclo, no los tiempos
individuales de cada célula productiva


Suboptimización


Suboptimización
50l/sg
20/sg

10l/sg

100/sg

30/sg


Suboptimización
- Antiguo troughput: 10
50l/sg - Nuevo troughput: 11 (10% ok)
- Coste: 16
22/sg

11l/sg

¡¡+10%!! 110/sg

33/sg


Suboptimización
- Antiguo troughput: 10
50 23l/sg - Nuevo troughput: 23 (130%)
- Ajusta carga a capacidad
23/sg
- Coste: 16

- I+D+i
23l/sg - Deuda técnica
- Desacople
¡Kaizen! 100l/sg

33l/sg


Suboptimización

“Pero es que…”


Cuellos de botella
 Teoría de las limitaciones (ToC)
 Cuidado con pedir “mas recursos” como
primea opción (elevar)
 Explotar:
 Asegúrate que el cuello de botella
opera al máximo de capacidad (elimina
tareas superfluas / waste)
 Asegura que la entrada a tu cuello de
botella es de buena calidad
 Asegura que tu cuello de botella no
pasa tiempo detenido / bloqueado
 Asegura que existe una priorización
correcta


Cuellos de botella
 Teoría de las limitaciones (ToC)
 Cuidado con pedir “mas recursos” como
primea opción (elevar)
 Subordinar:
 Asegura que el sistema opera al ritmo
del cuello de botella
 Utiliza el “slack” en torno al cuello para
reducir el cuello: forma en nuevas
habilidades, divide el tipo de tareas,
identifica las rutinarias / sencillas…


Recapitulando…
 Valor máximo al cliente (eliminar desperdicios)
 Optimizar la cadena de valor
 Flow (flujo productivo)
 Pull Systems
 Mejora continua


14 Principios Toyota
1. Pensamiento a largo plazo
2. Flujo de proceso que saque problemas a superficie
3. Sistema Pull
4. Heijunka (balanceo de carga)
5. Cultura “stop the line” (Andon / Jidoka)
6. Estandarización y mejora continua (Kaizen)
7. Control visual
8. Tecnologías fiables y probadas
9. Forma líderes
10. Desarrolla personas excepcionales
11. Respeta a suminstradores y colaboradores
12. VE y comprueba por ti mismo (Genchi Genbutsu / Gemba Kaizen)
13. Difiere el compromiso, decide lo más tarde posible
14. Reflexión constante (Hansei) y mejora continua (Kaizen)


Kanban!
1. Pensamiento a largo plazo
2. Flujo de proceso que saque problemas a superficie
3. Sistema Pull
4. Heijunka (balanceo de carga)
5. Cultura “stop the line” (Andon / Jidoka)
6. Estandarización y mejora continua (Kaizen)
7. Control visual
8. Tecnologías fiables y probadas
9. Forma líderes
10. Desarrolla personas excepcionales
11. Respeta a suminstradores y colaboradores
12. Ve y comprueba por ti mismo (Genchi Genbutsu / Gemba Kaizen)
13. Difiere el compromiso, decide lo más tarde posible
14. Reflexión constante (Hansei) y mejora continua (Kaizen)


Kanban!
“Los dos pilares del sistema de
producción de Toyota son la producción
Just-in-Time y la automatización con un
toque humano. La herramienta para
operar este sistema es Kanban.”


Kanban

Kanban
 Comienza donde estés
 Visualiza el flujo de valor
 Limita el WIP (ajusta carga
a capacidad)
 Mide y mejora el tiempo de
entrega / tiempo de ciclo
 Haz las reglas explícitas
(definición de terminado,
WIP limits, estándar de
código, bloqueos…)


Kanban
 Empezar menos cosas
 Acabar más cosas
 Reducir el número de
cosas en curso para
reducir el tiempo de
entrega
 En caso de bloqueos o
ralentizaciones, liberar
recursos para resolver el
problema


Kanban
 No construimos
funcionalidades que nadie
necesita ahora mismo
 No escribimos más
especificaciones de las que
podemos construir
(backlogs interminables)
 No escribimos mas código
del que podemos testear
 No testamos más código
del que podemos
implementar

(Corey Ladas)


Axiomas:
 Es posible dividir el trabajo
en pequeños incrementos
de valor añadido que
pueden ser calendarizados
de forma independiente
 Es posible realizar estos
incrementos de forma
continua (Flow), desde la
toma de requisitos a la
entrega


Kanban en portfolio

400 días

Backlog

?


Kanban en portfolio

Backlog

40 días

¿Cuáles son las 5 cosas que
más valor nos aportarían en
los próximos 40 días?

?


Kanban en portfolio

1 año en backlog (inventario, muda, muri, eliminar)

40 días

¿Cuáles son las 6 cosas que
más valor nos aportarían en
los próximos 40 días?

?


Kanban
Design Code
Selected Test
Backlog Done!
On Rdy On Rdy


Avatares

Colas
Design Code
Selected Test
Backlog Done!
On Rdy On Rdy


WIP limits
Design -4 Code -4
Selected - 2 Test - 2
Backlog Done!
On Rdy On Rdy


Estableciendo WIP Limits
 Muchas opciones:
 2 por persona (o un
poco menos)
 Tantas como personas
en el equipo
 La mitad del equipo
(equipos XP maduros)
 Comenzar por el cuello
de botella, evolucionar
desde ahí


Estableciendo WIP limits

Design Code -1 Test - 1 Design Code Test - 1
Backlog Selected - Done! Backlog Selected - Done!
2 On -1 Rdy On Rdy 2 On -8 Rdy On-10 Rdy

WIP muy bajo WIP muy alto


Lead time / cycle time
Total Lead Time ~120 días

LEAD TIME ~15 días

Cycle Time ~4 días

Design Code Test
Backlog Selected Done!
On Rdy On Rdy On Rdy


Políticas explícitas
 Límites WIP
 Terminado-terminado,
estándar de calidad
 Objetivos Lead Time,
Throughput, SLA’s
 Criterios de priorización,
calidades de servicio
 Actuación ante bloqueos o
interrupciones
 Reporte de progreso, criterios
de tablón
 Criterios de branches, builds,
releases
 …….

Design Code Test
- ormal
N Backlog Selected Done!
On Rdy On Rdy On Rdy
- ug
B

SPRINT
- volutivo
E

Atención FIRE!
inmediata
PRIO
Atención
prioritaria

Sólo si hay
buffer y el ASAP
Sprint va bien

- nte
A - est
T
bloqueos, automatizados - oc.
D
ayudar tester antes de ready actualizada
con criterios - eguir
S
aceptación estándar de - 5% coverage
9
- ax. 3 avatars por
M
persona código



Código J-43745
Ticketing “Como administrador, quiero Descripción
saber quién está conectado en
todo momento para poder
comunicarme con ellos”!
Bck: 3/2/11 BufCount: I I I I I I
Días en colas (una
Tiempos marca por día)
Sel: 9/2/11
Est: 20 25
An: 12/2/11 Re-estimaciones
Left: 18 16 14 19 16
Dsg: 17/2/11
14 9 6 2 0
Tst: 19/2/11
Don: 19/2/11 Seguimiento


Políticas explicitas

 Orden de atención (ej):
 Si puedes ayudar a terminar
algo en curso, haz eso
 Si no puedes, localiza un
cuello de botella y trabaja para
resolverlo
 Si tampoco puedes, coge un
nuevo elemento
 Si tampoco puedes, encuentra
algo interesante a lo que
dedicarte (I+D+I, formación,
deuda técnica…)


Colas + WIP limits
Design -4 Code
Selected - 2 Test - 2
Backlog Done!
On Rdy On -2 Rdy -6


WIP compuestos 6

Design Code
Selected - 2 Test
Backlog Done!
On Rdy On -2 Rdy -6


Cola revisión
Design Code - 7
Selected - 2 Test-2
Backlog Done!
On Rdy On -2 Review-2 Rdy -6

- arcar
M
para
retrospect.


Cola Bloqueos
Design Code - 7
Selected - 2 Test-2
Backlog Done!
On Rdy On -2 Block-2 Rdy -6

- arcar
M
para
retrospect.


Cola integración
Design -4 Code
Selected - 2 Test - 2 Wait
Backlog integration Done!
On Rdy On -2 Rdy -6

Min.

Max. (Go!)

Integraciones
tan frecuentes
como sea
posible


Proveedores
Design -4 Code
Selected - 2 @TEST
Backlog SUPPLIER - 3 Done!
On Rdy On -2 Rdy -6

- Sync. Diaria
- SLA: 3 días
- Marcar todos los
días una raya


Proveedores
Design -4 Code
Selected - 2 Test int. - 2
Backlog Done!
On Rdy On -2 Rdy -6

Test Out. - 4

- ync. Diaria
S
- LA: 3 días
S
- arcar todos los
M
días una raya


Backlog & “Disneyland Queue”
Design -4 Code Test - 2
Backlog - 6 Done!
On Rdy On -2 Rdy -6

1 semana

2 semanas


Espacio adicional
Selected - Design -4 Code Test - 2
Backlog Done! Proyecto:
2 On Rdy On -2 Rdy -6 Retro:

1. Necesidad de
Equipo: Scrum, Demo: un Product
Owner
2. Bloqueos en
testing
Burn-down:: 3. Maquinas
nuevas
4. Historias mal
definidas
5. Pair
programming
Release Plan: 6. Piloto Hudson-
Maven

Vacaciones


Througput & Burn-Down

Establecer una cadencia arbitraria


Calidades de servicio
Design Code Test
SPRINT On Rdy On Rdy On Rdy

FIRE!

PRIO

ASAP


Kanban


Fuegos
 Alguien debe dejar lo que está
haciendo y atenderlo de
inmediato (Context
Switching!)
 Límite de uno en curso en
cada momento dado
 Puede romper límites WIP
 Deben ser severamente
auditados
 No todo es un fuego (si es
así, buscad un pirómano!)


Prioridades
 En cuanto alguien esté libre,
debe atender este elemento
 Introduce un cambio de
contexto controlado
 Si siempre hay prioridades,
puede haber atasco en otras
calidades de servicio
(starvation)


“As Soon As Possible”
 “As possible”
 Si existe capacidad
diferenciada / excedente para
atenderlo (si no, no)
 No se estimarán


Opcional: fecha de entrega
 Requieren de cierto análisis y
estimación inicial (waste)
 Tendrán un punto de no
retorno para ser iniciadas –
seleccionar antes de dicho
punto


“Olores”


Design Code Test
SPRINT On Rdy On Rdy On Rdy

FIRE!

PRIO

ASAP


J-43745 Alberto
“Como administrador, quiero
saber quién está conectado en
todo momento para poder
comunicarme con ellos”!
Bck: 3/2/11 BufCount: I I I I I I
Sel: 9/2/11
Est: 20 25
An: 12/2/11
Left: 18 16 14 19 16
Dsg: 17/2/11
14 9 6 2 0
Tst: 19/2/11
Don: 19/2/11


Kanban Stand-ups

 Enumerar trabajo de
derecha a izquierda
(Pull)
 Concentrarse en
excepciones
 Impedimentos
 Bloqueos
 WIP rotos
 Prioridades…


Diagrámas de flujo acumulado



Scope Creep

Lead time

WIP



Carga de trabajo (MURI)

Capacidad



Carga de trabajo (MURI)

Ensachamiento =
Cuello de botella, MURA

Capacidad


Backlog
 Censo de proyectos (backlog)
 Priorización y estimación del backlog
 Visualización del flujo de valor (VSM + Visual
Management)
 Iterar


Backlog
 Scrum: priorizado y estimado (al menos en talla)
 Priorización:
 No todo el mundo puede ser satisfecho
(receta para la mediocridad)
 La gestión del backlog es política (de la
buena ;-)
 Si no puedes decir “NO”, tu “SÍ” no vale nada
(Esther Derby)
 Generalmente hay más ideas que capacidad:
el backlog es FUNNEL, no TUNNEL


Backlog
 Centrado en valor de negocio
 Alineado con objetivos estratégicos
 Incluir factores como riesgo, coste de retraso
 Cuidado con criterios como ROI (estimaciones)
 Mejor cuantos más representados
 Cuidado con priorizaciones
“emocionales” (prisas, presiones, enfados…)
 Asegura que todo el mundo conoce los criterios
(comunicación, comunicación, comunicación)


Backlog

Min. Cap. Para la fecha propuesta, esto
seguro que lo hacemos

Probablemente acabemos en
algún sitio por aquí
Max. Cap.

¿Te estás quedando conmigo o qué?


Backlog
Peor caso: mínimo
alcance (o máximo
tiempo)

Min. V

Predicción / estimación

Max. V

Mejor caso: máximo
alcance (mínimo
tiempo)


Kanban

Scrumban

The 40 hour week fallacy:

Programming (value adding tasks, focus
100% (40
factor, sprint dedication, project
hours a
advance…)
week)


A more realistic approach:

Programming ( value adding tasks, focus
factor, sprint dedication, project 50%
advance…)

Overhead 10%

Bugs, technical debt, stoppers, blocked tasks, rework,
15%
context switching, other forms of waste…
Reports, e-mail, internal meetings, hiring interviews, 10%
admininistrative stuff, bureaucracy…

Slack 10%
Research, Development, training, innovation 5%

Naked truth:

Programming ( value adding tasks, focus
factor, sprint dedication, project 35%
advance…)

Overhead 10%

Bugs, technical debt, stoppers, blocked tasks, rework, 30%


Slack 10%

Naked truth:

Scrum (measured & known)
35%

Overhead 10%

Bugs, technical debt, stoppers, blocked tasks, rework, 30%


Slack 10%

Naked truth:

Scrum (measured & known)
35%

65%


Scrumbam
Burn-down::

Pending Selected. Dev. Valid. Integration Done!

Release Plan:


Scrumbam
Burn-down::


Release Plan:

! ! ! !


Velocity

?
?


Scrumbam
Pending Selected. Dev. Valid. Integration Done! Burn-down::

Release Plan:



Scrumbam
Burn-down::

Release Plan:


5

1

Esto ha sido un
tres…


Scrumbam

V Scrum


V Buffer


V Scrum V Buffer
80 20
85 20
75 30
70 35
75 25
80 25
? ?

¿Vuestra predicción?


V Scrum V Buffer
80 20 Uuuh… Buenos, de
media hacemos algo así
85 20 como 75 scrum points
75 30 por sprint. Supongo que
70 35 nos podemos
comprometer a eso
75 25 mientras mantengas el
80 25 Buffer bajo control…
? ? Eso significa no
pasar de 25 Buffer
points


V Scrum V Buffer
80 20
85 20
75 30
70 35
75 25
! 80 25
60 50

Yaaargh!
¡Habéis faltado
a vuestra
promesa!


V Scrum V Buffer
80 20 No, de hecho hemos
85 20 hecho 110 puntos de
velocidad agregada,
75 30 que no está nada mal.
70 35 TÚ nos priorizaste 50
puntos Buffer durante el
75 25
! 80 25
Sprint y nos hiciste fallar
el objetivo
60 50


Scrumbam

V Scrum


V Buffer +

V Buffer -


Análisis de demanda

Evolutivos Valor
Proyectos (V. Scrum)

Waste (Failure Demand)


Scrumbam
Burn-down::

Release Plan:


? ?? ?


Scrumbam
Burn-down::
COMMITTED

Release Plan:

Fire!
PRIO
ASAP


Scrumbam
Burn-down::
COMMITTED

Release Plan:

Fire!
PRIO

¿¿Eso ha sido
ASAP

un fuego??

Para nada…
oh-oh… Hora de hacer
coaching al
P.O.


Burn-down::

COMMITTED

Release Plan:

Fire!
Prio
ASAP


Dev. Done! Sprint Burn-down:
Pending Selected. Valid. Integration

COMMITTED

Fire!
Buffer Burn-down:
Prio
ASAP

Mmm…Supongo Uh-oh, parad el
que tampoco buffer, tíos!!
estaría mal hacer
algo de Scrum…


Dev. Done! Sprint Burn-down:
Pending Selected. Valid. Integration

COMMITTED

Fire!
Buffer Burn-up:
Prio
ASAP

Mmm…Supongo Uh-oh, parad el
que tampoco buffer, tíos!!
estaría mal hacer
algo de Scrum…


V Scrum V Buffer
80 7500 Uuuh… Buenos, de
media hacemos algo así
85 7000 como 75 scrum points
75 8000 por sprint. Supongo que
70 8500 nos podemos
comprometer a eso
75 7500 mientras mantengas el
80 7000 Buffer bajo control…
? ? Eso significa no
pasar de 7500
¿vuestra predicción? Buffer points


V Scrum V Kanban
80 7500 No, en realidad hemos
85 7000 hecho over-buffering
(50% más de lo
75 8000 habitual). TÚ nos
70 8500 priorizaste 11.200
puntos Buffer durante el
75 7500
! 80 7000
Sprint y nos hiciste fallar
el objetivo
60 11.200

Yaaargh!
Habéis fallado
a vuestra
promesa!


Añade colas y WIP limits!
Design Code Test
Backlog Selected - 3 Done!
On- 3 Rdy On -2 Rdy On - 2 Rdy
SPRINT

FIRE!

PRIO

ASAP


Especialistas y generalistas
Design Code Test
On Rdy On Rdy On Rdy Sprint Burn-down:
SPRINT

FIRE! Buffer burn-up:

PRIO

ASAP


Bonus:
personal Kanban


Conclusiones
 Distinguir kanban de Kanban
 Un sistema Kanban necesita una
cultura Kaizen
 Equipos auto-organizados
 Propiedad del sistema
 Pensamiento sistémico
 Completar trabajo y reducir el
tiempo es tarea de todos


Conclusiones

 El sistema Kanban comienza donde
estas y progresa evolutivamente, un
cambio cada vez
 Una correcta priorización es
esencial
 Si el sistema opera a máxima
capacidad, no tiene sentido
aumentar la carga de trabajo – en
su lugar, trabaja el sistema


Conclusiones

 El foco de un sistema Kanban
está en mejorar el tiempo de
ciclo, la capacidad y la entrega
de valor, no en seguir un plan
 La categorización y
normalización de la demanda
permite no obstante una alta
predictibilidad
 Si el sistema no fluye, no tiene
sentido aumentar los objetos en
cola (inventario)


Epílogo


No hay camino…

Conocer el
camino, andar
el camino


¡Aprendamos a nadar!


Read this books!


Retrospectiva
del curso

angel.medinilla@proyectalis.com

¡¡¡¡ Blog It !!!!


http://creativecommons.org/
licenses/by-nc-nd/3.0/

This presentation is based upon
the ideas and work of many
people. And while I’ve tried to
recognize copyrights and give
credit and attribution where
possible, I cannot possibly list
them all, so if you feel like
there’s something that should be
added, changed or removed
from this presentation, please
drop me an e-mail at

Special thanks to Henrik Kniberg, David J.
Anderson, Mattias Skarin, Corey Ladas, Mary
Poppendieck & David Joyce.


Seminario Kanban y Scrumban

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Andere mochten auch

Andere mochten auch (20)

Ähnlich wie Seminario Kanban y Scrumban

Ähnlich wie Seminario Kanban y Scrumban (19)

Mehr von Proyectalis / Improvement21

Mehr von Proyectalis / Improvement21 (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Seminario Kanban y Scrumban