Agile: Scrum, Kanban y Scrumban (material formación Proyectalis)

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

Agile: Scrum, Kanban y Scrumban

Madrid, Mayo 2011


Ángel [email protected]

@angel_m





¡Un placer!


Ejercicio: Scrum Ball


Ground Rules



* * *



Tomad notas


Mmmmm… Almuerzo…



Suficiente para empezar


Agile


Valores

Principios

Procesos

Roles

Herramientas

Artefactos

Prácticas


Historia de dos estados

Statewide Automated Child Welfare Information System (SACWIS)

Florida: comienza 1990, plan a 8 años, $32M

2002: $170M, estiman terminar en 2005, coste acumulado de $230M

Source: Jim Johnson, Standish Group President, as quoted in “Lean Software Development,” , Mary&Tom Poppendieck


Standish Group

68% proyectos fallidos o problemáticos

64% funcionalidades no usadas

59¢ valor por cada $ de software


Los desarrolladores en todo el mundo sufren terriblemente


Círculos viciosos

Mala calidad

Prisa

Errores

Interrupciones

Baja productividad

Retrasos


Círculos viciosos

Mala calidad

Prisa

Errores

Interrupciones

Baja productividad

Retrasos

Cliente insatisfecho

Reducción de beneficios

Aumento de costes


Círculos viciosos

Mala calidad

Prisa

Errores

Interrupciones

Baja productividad

Retrasos

Cliente insatisfecho

Sin formación

Reducción de beneficios

Aumento de costes

Falta de competencia

Desmotivación

Presión


Meanwhile, in Minessota

Esenciamente el mismo sistema, con la misma funcionalidad, comienzan en 1999

Terminan a principios de 2000, coste $1.1M

Source: Jim Johnson, Standish Group President, as quoted in “Lean Software Development,” , Mary&Tom Poppendieck


¿Cuestión de suerte?

No emplees a gente sin suerte. Tira la mitad de los CV a la basura sin leerlos.

Suerte



Principios: Nuestra mayor prioridad es satisfacer al cliente mediante la entrega

temprana y continua de software con valor. Aceptamos que los requisitos cambien, incluso en etapas tardías del

desarrollo. Los procesos Ágiles aprovechan el cambio para proporcionar ventaja competitiva al cliente.

Entregamos software funcional frecuentemente, entre dos semanas y dos meses, con preferencia al periodo de tiempo más corto posible.


Principios: Los responsables de negocio y los desarrolladores trabajamos juntos de

forma cotidiana durante todo el proyecto. Los proyectos se desarrollan en torno a individuos motivados. Hay que

darles el entorno y el apoyo que necesitan, y confiarles la ejecución del trabajo.

El método más eficiente y efectivo de comunicar información al equipo de desarrollo y entre sus miembros es la conversación cara a cara.


Principios: El software funcionando es la medida principal de progreso. Los procesos Ágiles promueven el desarrollo sostenible. Los promotores,

desarrolladores y usuarios debemos ser capaces de mantener un ritmo constante de forma indefinida.

La atención continua a la excelencia técnica y al buen diseño mejora la Agilidad.


Principios: La simplicidad, o el arte de maximizar la cantidad de trabajo no realizado, es

esencial. Las mejores arquitecturas, requisitos y diseños emergen de equipos auto-

organizados. A intervalos regulares el equipo reflexiona sobre cómo ser más efectivo para

a continuación ajustar y perfeccionar su comportamiento en consecuencia.


Agile101

Estimate

Ouch!

Estimate

Replan R1.0 ¿R2.0?

BV

t

R1.0 ¿R2.0?


Agile101

Estimate

Ouch!

Estimate

Replan R1.0 ¿R2.0?

BV

t

R1.0 ¿R2.0?

- Equipo auto-organizado y motivado - Trabajando a paso sostenible - Colaborando con cliente y personal de negocio de forma cotidiana - Comunicándose cara a cara - Persiguiendo la excelencia técnica - Reflexionando sobre como mejorar y eliminar el desperdicio


Ideas simples…


Pero recordad:

Valores

Principios

Procesos

Roles

Herramientas

Artefactos

Prácticas


Reglas


Primera regla

Bueno, bonito, barato… ¡Elije dos!

?

Tiempo Alcance

Recursos


Buffers de proyecto

Monitorizar velocidad de consumo del buffer Aprendemos sobre el “global” del proyecto Los “paddings” no quedan ocultos

Buffer

80% proyecto consumido

60% proyecto consumido

Min T Max T


Tradicional vs. Ágil

Fijar:

Estimar:

Alcance

Alcance

Coste Tiempo

Coste Tiempo

Orientación a Plan

Orientación a Valor


El cambio es la única constante

Segunda regla


Cono de Incertidumbre

(Pista: estimar aquí )


Cono de incertidumbre


Precisión vs tiempo

Suficientemente buena


Incertidumbre


Gedanken: el P.O. perfecto

…..



…..



…..



…..


Histograma


Histograma Norma


Histograma

95% SLA

80% SLA

Norma


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


Es complejo (quizás imposible) caracterizar perfectamente a priori un sistema software

Tercera regla

Req

uisi

tos

Tecnología


Software no es ESTO:


Software es ESTO:


Ejercicio: círculo humano


El proceso empírico

© 2006-2007 Jeff Patton, www.agileproductdesgin.com


Walking Skeleton:

1 2 3

1 2 3

© 2006-2008 Jeff Patton, www.agileproductdesgin.com


“Empirico” no quiere decir…


Un sistema empírico


Un sistema empírico


Scrum


Una herencia aciaga

Politicas Procedimientos Procesos Control Inspección Supervisión Burocracia Papeles Más papeles Todavía más papeles…

Trabajadores insatisfechos

ISO CMMI TQM

EFQM ITIL

PMBOK PRINCE2

…






Thin is In


El nombre:


Qué usan los equipos Ágiles:

5thAnnual ”State of Agile Development” Survey, 2010


Algunas empresas haciendo Scrum:


Que NO es Scrum


Scrum 101


Scrum 101

Previsión

Ouch!

Previsión

Replanificación R1.0 ¿R2.0?

BV

t

R1.0 ¿R2.0?


Scrum 101

Dueño de Producto

Equipo

Scrum Master

Pila de Producto

Pila Sprint

Stakeholders

?


El framework:


Estructura Scrum / Multiproducto

?

?

?

? ?


Mountain Goat: 243 personas


“Scrum de Scrums”

Team A

Team B

Team C

Team A

Team B

Team C


Comunidades de práctica

?

?

?

? ?


Ejercicio: burning man project


“El énfasis está en conducir el proyecto – que es bastante sencillo- en lugar de obtener una predicción exacta de qué hará falta y cuánto durará – lo cuál es muy dificil”

Ron Jeffries, XP co-founder


Velocidad

Min. V

Max. V

Esto seguro que lo hacemos

¿Te estás quedando conmigo o qué?

Probablemente acabemos en algún sitio por aquí


Campana de Gauss

Min. V

Max. V

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

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

Predicción / estimación


Capacidad 105

80

90

80

93

86

100

86

90

100

¡¡900 puntos en 9 semanas!!

+5 -5 -25 -32 -46 -46 -59 -70 -70


¡¡Entre 700 y 900 puntos en 9 semanas!!

Capacidad 105

80

90

80

93

86

100

86

90

100

¡¡900 puntos entre 9 y 11 semanas!!

+15 +5 -5 -2 -6 +4 +0 +0 +10 +5


Nuestras 10 reglas de Scrum: 1. Individuos 2. No es una bala de plata 3. Retrospectivas, retrospectivas,

retrospectivas 4. Scrum diario, control diario 5. El producto funcional es la medida

de progreso. 6. Equipos auto-organizados, auto-

gestionados y comprometidos: Scrum Master no es un jefe, sino un sirviente del equipo

7. Desarrollo iterativo e incremental


8) “Terminado, terminado”


9) “Orcos a las puertas”

?


9) “Orcos a las puertas”

?


10) “El horno de las magdalenas”

?


!!

?

!! +3

“El horno de las magdalenas”



?

Las opciones del horno Poner el bizcocho en cola

(puede afectar al valor) Retrasar las magdalenas

rojas y poner el bizcocho en su lugar (clientes iguales)

Poner el bizcocho al principio (cliente prioritario, retrasa todo el portfolio)

Reservar una capacidad extra para imprevistos (Scrumban)

Cambios de contexto, exigir esfuerzos, tirar calidad (no Agile)


Estos diez mandamientos se cierran en uno:

¡Time Boxing!


Scrum Framework

Artefactos

Pila de Producto Pila de Sprint

Tablón Scrum

Pila de impedimentos

Roles

Dueño de Producto

Scrum Master

Equipo

Procesos Plan de Producto Plan de Sprint Scrum diario

Retrospectivas Demo


Los roles:


Los roles:


Dueño de Producto

Gestiona la visión y el Roadmap

Recopila requisitos, escribe historias de usuario

Gestiona la Pila de Producto: decide alcance y prioridad

Define criterios de aceptación para cada historia y valida

Responsable de satisfacción del cliente y éxito financiero

Interfaz de negocio con Scrum “Cerdo con plumas”


Dueño de Producto

1. ESCRIBIR HISTORIAS 2. PRIORIZAR HISTORIAS 3. VALIDAR HISTORIAS


Realiza estimaciones, reporta progreso Comprometidos con la entrega de

software funcional al final del sprint Cross-funcional, auto-gestionado Responsable de calidad y velocidad 7±2 personas (“feed them two pizzas”)

Equipo


1. ESTIMAR HISTORIAS 2. CONSTRUIR HISTORIAS 3. REPORTAR PROGRESO Equipo


Scrum Master

“Perro pastor”, siervo lider, Coach

Cercano al equipo Mantiene el proceso Gestiona pila de

impedimentos Hace mejorar al equipo Mejora la vida del equipo Moderador - facilitador Si es necesario, actua como

interfaz del Dueño de Producto


Scrum Master

1. MEJORAR RENDIMIENTO 2. MEJORAR CALIDAD DE VIDA 3. MANTENET Y MEJORAR EL

PROCESO


Evolución del Scrum Master

ScrumButt Scrum Agile Nirvana

“El tío del Scrum”

- Convocar reuniones - Listar problemas





“Mama Scrum”


- “Ya me encargo yo” - Moderador - Diagnostica y decide - Elimina impedimentos - Interfaz del equipo - Evitar el conflicto (armonía artificial) - Coordinación, cooperación - No confía del todo en el equipo, aun algo “Jefe”





“Mama Scrum”

Auténtico Scrum Master



- Formador, mentor - Facilitador - Motivador - Jardinero del equipo - Implica a todos - Delegación progresica - Colaboración - Innovación - Trata el conflicto - Agente del cambio - Evangelista Ágil - Lider





“Mama Scrum”


Scrum Sensei – Agile Coach



- Escucha - Domina el silencio - Pregunta - Es un espejo

- Formador, mentor - Facilitador - Motivador - Jardinero del equipo - Implica a todos - Delegación progresica - Colaboración - Innovación - Trata el conflicto - Agente del cambio - Evangelista Ágil - Lider







- Escucha - Domina el silencio - Pregunta - Es un espejo





“Mama Scrum”



Decide Vende Consulta Participa Aconseja Delega Pregunta





“Mama Scrum”




Duración Sprint

Estimar historias

Definition of done Miembros de equipo

Estrategia de negocio





“Mama Scrum”




Duración Sprint

Estimar historias



TEAM

SM

PO

Manager

Manager





“Mama Scrum”




Duración Sprint

Estimar historias



TEAM

SM

PO

Manager

Manager

C&C Coach (leader?)


Procesos


Planificación de producto


La Pila Iceberg

Sprint

Producto

Version


Planificación de Sprint


Scrum diario


Demo


Retrospectiva


Artefactos


Pendiente Desarrollo Test Terminado Historia Proyecto:

Equipo: Scrum, Demo:

Burn-down::

Release Plan:

Impedimentos:

Tablón scrum







“Olores”




Burn-down::

Release Plan:

Impedimentos:




Burn-down::

Release Plan:

Impedimentos:




Burn-down::

Release Plan:

Impedimentos:


Burn-down Trabajo

Tiempo

OK!

KO!


Release Plan


“Olores”


Trabajo

Tiempo


Trabajo

Tiempo


Trabajo

Tiempo


Trabajo

Tiempo


Trabajo

Tiempo


Trabajo

Tiempo


Trabajo

Tiempo


Trabajo

Tiempo


Trabajo

Tiempo


Trabajo

Tiempo


Trabajo

Tiempo


Trabajo

Tiempo

Historias


Trabajo

Tiempo

Historias



Lavar platos Pasear al perro Cortar el cesped Regar las plantas Hacer las camas Colada Planchar Limpiar el horno Compra del mes Compra frutería Limpiar los suelos Limpiar ventanas Pintar dormitorio

Proyecto Rodriguez


Planning Poker


Kanban


Ejercicio: serie o paralelo


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)


Capacidad

50l/sg 20/sg

10l/sg

100/sg

30/sg


Capacidad

50l/sg 22/sg

11l/sg

110/sg

33/sg

¡¡+10%!!

- Antiguo troughput: 10 - Nuevo troughput: 11 (10% ok) - Coste: 16


Capacidad

50 23l/sg

23/sg

23l/sg

100l/sg

33l/sg

¡Kaizen!

- Antiguo troughput: 10 - Nuevo troughput: 23 (130%) - Ajusta carga a capacidad - Coste: 16

- I+D+i - Deuda técnica - Desacople


Colas Selected Backlog

Code Test Done!

Design

Rdy Rdy On On


WIP limits Selected - 2 Backlog

Code -4 Test - 2 Done!

Design -4

Rdy Rdy On On




Design -4

Rdy Rdy On On




Design -4

Rdy Rdy On On




Design -4

Rdy Rdy On On




Design -4

Rdy Rdy On On




Design -4

Rdy Rdy On On




Design -4

Rdy Rdy On On




Design -4

Rdy Rdy On On




Design -4

Rdy Rdy On On




Design -4

Rdy Rdy On On




Design -4

Rdy Rdy On On




Design -4

Rdy Rdy On On




Design -4

Rdy Rdy On On


Colas + WIP limits Selected - 2 Backlog

Code Test - 2 Done!

Design -4

Rdy Rdy -6 On On -2


Cuellos de botella

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 Subordinar:

Asegura que el sistema opera al ritmo del cuello de botella

Utiliza el “slack” en torno al cuello para reducir el cuello


“Stop the line”

Política de cero defectos Reducción del gasto Pensamiento a largo plazo Foco en calidad


Histograma

95% SLA

80% SLA

Norma


Kanban

Scrumban


The 40 hour week fallacy:

100% (40 hours a week)

Programming (value adding tasks, focus factor, sprint dedication, project

advance…)


A more realistic approach:

50%

10%

15%

10%

10%

5%

Bugs, technical debt, stoppers, blocked tasks, rework, context switching, other forms of waste…

Reports, e-mail, internal meetings, hiring interviews, admininistrative stuff, bureaucracy…

Slack

Research, Development, training, innovation

Programming ( value adding tasks, focus factor, sprint dedication, project

advance…)

Overhead


Naked truth:

35%

10%

10%

10%

5%

30% Bugs, technical debt, stoppers, blocked tasks, rework, context switching, other forms of waste…


Slack


Programming ( value adding tasks, focus factor, sprint dedication, project

advance…)

Overhead


Naked truth:

35%

10%

10%

10%

5%

30% Bugs, technical debt, stoppers, blocked tasks, rework, context switching, other forms of waste…


Slack


Scrum (measured & known)

Overhead


Naked truth:

35% Scrum (measured & known)

65%


Selected. Dev. Valid. Pending Integration Done!

Burn-down::

Release Plan:

Scrumbam



Burn-down::

Release Plan:

! ! ! !

Scrumbam


Velocity

? ?


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

Release Plan:


Scrumbam



Release Plan:


Esto ha sido un tres…

5

1

Scrumbam




V Scrum

V Buffer

Scrumbam


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

85 20

75 30

70 35

75 25

80 25

? ?

Uuuh… Buenos, de media hacemos algo así como 75 scrum points por sprint. Supongo que nos podemos comprometer a eso mientras mantengas el 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

85 20

75 30

70 35

75 25

80 25

60 50

No, de hecho hemos hecho 110 puntos de velocidad agregada, que no está nada mal. TÚ nos priorizaste 50 puntos Buffer durante el Sprint y nos hiciste fallar el objetivo !




V Scrum

V Buffer +

V Buffer -

Scrumbam


Velocity

Vavg Scrum

Vavg Buffer+

Vavg Buffer-

Scrumbam



Release Plan:


? ? ? ?

Scrumbam



Release Plan:

CO

MM

ITTE

D

PR

IO

Fire!

ASA

P

Scrumbam


Fire!


Release Plan:

CO

MM

ITTE

D

PR

IO

ASA

P

Scrumbam


Fire!


Release Plan:

CO

MM

ITTE

D

PR

IO

ASA

P ¿¿Eso ha sido un fuego??

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

oh-oh…

Scrumbam


Prio

Fire!


Release Plan:

CO

MM

ITTE

D

ASA

P


ASA

P Pr

io

Fire!


Release Plan:

CO

MM

ITTE

D


ASA

P Pr

io

Fire!

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

CO

MM

ITTE

D

Buffer Burn-down:

Uh-oh, parad el buffer, tíos!!

Mmm…Supongo que tampoco estaría mal hacer algo de Scrum…


ASA

P Pr

io

Fire!

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

CO

MM

ITTE

D

Buffer Burn-up:

Uh-oh, parad el buffer, tíos!!

Mmm…Supongo que tampoco estaría mal hacer algo de Scrum…


V Scrum V Buffer

80 7500

85 7000

75 8000

70 8500

75 7500

80 7000

? ?

¿vuestra predicción?

Uuuh… Buenos, de media hacemos algo así como 75 scrum points por sprint. Supongo que nos podemos comprometer a eso mientras mantengas el Buffer bajo control…

Eso significa no pasar de 7500 Buffer points


Yaaargh! Habéis fallado a vuestra promesa!

!

V Scrum V Kanban

80 7500

85 7000

75 8000

70 8500

75 7500

80 7000

60 11.200

No, en realidad hemos hecho over-buffering (50% más de lo habitual). TÚ nos priorizaste 11.200 puntos Buffer durante el Sprint y nos hiciste fallar el objetivo


Añade colas y WIP limits!

Selected - 3 Backlog Code Test

Done! Design

Rdy Rdy Rdy On- 3 On -2 On - 2 S

PR

INT

FIRE!

PRIO

ASAP


Epílogo






No hay camino…


Conocer el camino, andar el camino


¡Aprendamos a nadar!



Read this books!



Retrospectiva del curso

[email protected]


¡¡¡¡ Blog It !!!!

[email protected]


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 [email protected]

Special thanks to Henrik Kniberg, Mike Cohn, Lyssa Adkyns, Jurgen Appelo, David J. Anderson, Mary Poppendieck and Jeff Patton. I owe you so much I’ll have to buy you some drinks if you ever happen to come to Spain ;).

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

Business

Agile: Scrum, Kanban y Scrumban (material formación Proyectalis)