Este documento presenta una discusión sobre la adopción de metodologías ágiles. Explica las razones para adoptar enfoques ágiles, como mitigar riesgos más rápido, eliminar desperdicios y maximizar la comunicación. También describe fallas comunes como falta de involucramiento del product owner, equipos que no son multidisciplinarios, y mal uso de las prácticas de Scrum como las reuniones diarias y de planificación. El documento concluye enfatizando la importancia de enfocarse en soluciones y construir el product

1. 1
HABLEMOS DE AGILIDAD
RAZONES, FALLAS Y TIPS
JORGE HERNÁN ABAD LONDOÑO
@jorge_abad
Blog http://www.lecciones-aprendidas.info/
Agile Coach, Project Leader, Scrum Master and Always a Learner

2. 2
Miembro de Ágiles Colombia

3. 3
Miembro PMI Capítulo Antioquia
 pmiantioquia.org
 @pmiantioquia
 facebook.com/PMIAntioquia
 meetup.com/es-ES/Proximo-Capitulo-PMI-Antioquia/

4. 4
Agenda
 ¿Por qué adoptar metodologías ágiles?
 ¿Por qué los equipos ágiles son más
rápidos y efectivos que los tradicionales?
 Fallas Comunes en la Adopción Ágil
 Tips
 Preguntas

5. 5
Agenda
 ¿Por qué adoptar metodologías ágiles?
 ¿Por qué los equipos ágiles son más
rápidos y efectivos que los tradicionales?
 Fallas Comunes en la Adopción Ágil
 Tips
 Preguntas

6. 6
¿Quiénes…?

7. 7
Contestemos sinceramente

8. 8
UNAS PREGUNTAS
¿Quiénes han o les han
fallado en una estimación
el cuádruple…
El triple….
El doble….?

9. 9
UNAS PREGUNTAS
¿Quiénes han trabajado
seguido 6 meses o más…
(sábados, domingos y
festivos)?

10. 10
UNAS PREGUNTAS
¿Quiénes han
trabajado más de
36 horas
seguidas…?
¿24 horas…?

11. 11
UNAS PREGUNTAS
¿quiénes han
tenido
ultimatum
familiar?

12. 12
Unas preguntas
¿Se les dañó
un paseo o
viaje
planeado
debido a un
proyecto?

13. 13
UNAS PREGUNTAS
¿a quiénes se les ha
dañado una entrega
lista?

14. 14
UNAS PREGUNTAS
les han dicho o han dicho:
¿es lo especificado pero no es
lo que necesito?

15. 15
UNAS PREGUNTAS
les han dicho o han dicho:
¿es lo especificado pero ya
cambió el negocio?

16. 16
UNAS PREGUNTAS
les han dicho o han dicho:
¿Cómo van a pagar ese tiempo?

17. 17
UNAS PREGUNTAS
 Han dicho o han pedido
¿Una estimación EXACTA?

18. 18
UNAS PREGUNTAS
Has dicho o has escuchado:
¿a eso vamos a tener que darle
manejo?

19. 19
UNAS PREGUNTAS
¿los controles de
cambio costaron más
que el proyecto
original?

20. 20
UNAS PREGUNTAS
¿consideran que el 100%
del software construido es
usado….?

21. 21
UNAS PREGUNTAS
¿el 90% del software?
¿el 80%?
¿el 70%?
¿el 60%?
¿el 50%?

22. 22
Chaos Manifesto 2013
http://www.versionone.com/assets/img/files/ChaosManifesto2013.pdf
De las funcionalidades en el sw:
• 20% usado frecuentemente
• 30% usado algunas veces
• 50% poco o nunca usadas
Pareto también se cumple en software

23. 23
UNAS PREGUNTAS
 Va el 92% de avance
 Dos semanas después
 Va el 92.4% de avance
 Tres semanas después
 Va el 92.7% de avance
 Etc
 Etc
 Etc
Han dicho o les han dicho

24. 24
UNAS PREGUNTAS
¿se han demorado
cerrando el 10% del
proyecto otro 90%?
(o sea, más o menos el 180% del tiempo para todo el proyecto)

25. 25
UNAS PREGUNTAS
 ¿Las salidas a
producción son
hiper-preparadas, le
llenan de temor y
terror y requieren de
sus mejores
“hombres”?

26. 26
UNAS PREGUNTAS
¿Quiénes han
estado en un
proyecto que se
ha cumplido
alcance, tiempo,
costo, calidad y
felicidad?

27. 27
¿Dónde estamos?

28. 28
Creemos que hacer
software es…

29. 29

30. 30

31. 31
Navegar en los ríos de la
predictibilidad

32. 32
Ensamblar
componentes y dar clic
derecho: configurar y
desplegar

33. 33
Para acabar más rápido
pongo más UMPALUMPAS

34. 34
Hacemos software empleando
el enfoque
WATERFALL

35. 35

36. 36
Pero hacer software
es…

37. 37

38. 38

39. 39
 «Estudio de la Universidad de Missouri: la
vida media del valor de los requisitos ha
ido disminuyendo Exponencialmente. En
1980 esta fue de alrededor de 10 a 12
años, en el 2000 había caído a 2 a 3 años,
y actualmente está funcionando a
alrededor del 6 meses».
"Software Development: How the Traditional Contract Model
Increases the Risk of Failure" de Susan Atkinson y Gabrielle
Benefield
Radioactividad de los Requisitos

40. 40

41. 41
Hacer software es…
 Saber trabajar REALMENTE en equipo
 Que los riesgos saltan y se materializen por
doquier
 Convivir con la incertidumbre, y saber
como reaccionar a ella.
 Saber que no vamos a tenerlo TODO
definido,
 Aprender de las fallas y corregir el camino
(Inspección y Adaptación)

42. 42

43. 43
Lacey, Mitch. The Scrum Field Guide: Practical
Advice for Your First Year (Agile Software
Development Series)

44. 44
¿hemos tratado de
resolver el problema
del software con la
herramienta
equivocada?

45. 45
www.agilemanifesto.org

46. 46
Principios del Manifiesto Ágil
 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.
 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.

47. 47
Principios del Manifiesto Ágil
 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.
 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.
 La simplicidad, o el arte de maximizar la cantidad de trabajo no realizado, es
esencial.

48. 48
Principios del Manifiesto Ágil
 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.

49. 49

50. 50
“Nuestro trabajo no es hacer (toneladas de) software,
nuestro trabajo es hacer la MENOR cantidad de
SOFTWARE que maximice el VALOR del negocio de
nuestros clientes”
Ángel Medinilla
@angel_m

51. 51
Valor y riesgos en enfoque tradicional y ágil

52. 52
Agenda
 ¿Por qué adoptar metodologías ágiles?
 ¿Por qué los equipos ágiles son más
rápidos que los tradicionales?
 Fallas Comunes en la Adopción Ágil
 Tips
 Preguntas

53. 53
Repasemos
un poco de
Scrum

54. 54
Scrum
Cancel
Gift wrap
Return
Sprint
2-4 semanas
Objetivo del Sprint
Sprint
Backlog
Incremento del producto
potencialmente entregable
Product
Backlog
24 horas

55. 55
Reuniones de Scrum

56. 56
• Sprint
Execution
• Review
• Retrospectiva
• Sprint
Planning
• (kaizen
=mejora)
Actuar Planear
HacerVerificar
SCRUM es un ciclo de
mejora continua

57. 57
Hagamos recorderis
 Recuerdan el Infome del caos donde la
principales causas de fracaso son:
– Falta de involucramiento del usuario*
– Requisitos incompletos y cambiantes*
– Expectativas irreales *
– Falta de planificación *
 Y las de éxito
– Involucramiento del usuario*
– Requisitos claros*
– Hitos acotados*
– Expectativas realista*
– Buena planificación*
– Proceso ágil**
* The CHAOS Report (1994), Standish Group -
http://www.standishgroup.com/sample_research/chaos_1994_1.php
**The CHAOS Report (2013), Standish Group -
http://www.versionone.com/assets/img/files/ChaosManifesto2013.pdf

58. 58
¿En dónde radica
la agilidad si los
equipos ágiles
hacen lo mismo o
más que los
tradicionales?

59. 59
 Los roles adecuados para construir el
producto
– Product Owner
– Scrum Master
– Team Members
No sobra, ni falta nadie
No hay silos

60. 60
Un Product Owner
 interesado en LIBERAR
A PRODUCCIÓN EL
PRODUCTO LO ANTES
POSIBLE Y LO QUE MÁS
VALOR GENERE
 Que resuelve dudas
durante el sprint, que
tiene toda la autoridad
sobre el producto • El involucramiento del usuario tan buscado
• Se elimina la burocracia
• Hay respuesta rápida a inquietudes del equipo

61. 61
El Scrum Master
 cuida al proceso
 está preocupado
por mejorar cada
vez el desempeño
del equipo
 Remueve
impedimentos Un líder al servicio del
equipo

62. 62
Un equipo:
 Que tiene un objetivo
claro
 Que jala trabajo en un
ciclo corto (pull) en vez
de que se le asigne
(push).
Un equipo autoorganizado
y multidisciplinario

63. 63
Enfoque en el valor y no en el
alcance
Se posterga lo incierto, se
construye lo que genera
valor

64. 64
 Un Sprint Backlog congelado durante el
sprint

65. 65
 Un Planning que compromete a los
directos responsables.
El compromiso es asumido
no asignado

66. 66
El Scrum Diario o Daily que
sincroniza al equipo
Evita el trabajo de islas y
repúblicas independientes
Ayuda a evidenciar
problemas y resolverlos más
rápido

67. 67
 Un Review que permite validar el
producto y compromete más al
equipo
Inspección y adaptación
sobre el producto

68. 68
 La retrospectiva
que busca la
mejora continua
Inspección y adaptación
sobre el equipo y proceso

69. 69
 Ciclos cortos de desarrollo (Sprints) que
–mitigan riesgos y que estos se propaguen por
largos periodos
–Evidenciar el avance

70. 70
 Requerimientos (Historias de
usuario, Casos de uso, etc)
en Ready para el sprint backlog
 No se trabaja en algo que no está
claro

71. 71
 La Definition of Done / DoD/
Definición de Terminado / Realizado que es el
criterio de calidad y de entrega claro para todo
el equipo

72. 72
TRANSPARENCIA
 Transparencia
(Visual
Management)
que permite a
todos saber el
estado del
proyecto y del
producto
No hay posibilidad de darle “manejo”

73. 73
Existe una construcción
orgánica y completa del
producto, orientadas
incialmente al MVP
(Mínimo Producto Viable)

74. 74

75. 75
http://idrawgirls.com/tutorials/2011/12/12/painting-chinese-
woman-portrait/

76. 76
Porciones completas de producto (software)
Se entregan al final del ciclo
porciones producto que se
pueden poner en producción
OJO: NO se entregan capas
que NO le entregan valor al
cliente

77. 77
Razones para la adopción ágil
 La razón radica en que las prácticas de Scrum mitigan
bastantes problemas del desarrollo tradicional y
aligeran el desarrollo
– eliminando reprocesos
– mitigando riesgos más rápido
– suprimiendo el desperdicio
– acabando burocracia
– Maximizando la comunicación
– Enfocados en entregar software de valor lo antes
posible

78. 78
Estos elementos estan enmarcados por Lean Software
Development
 Eliminar los desperdicios
 Ampliar el aprendizaje
 Decidir lo más tarde posible
 Reaccionar tan rápido como sea
posible
 Potenciar el equipo
 Crear la integridad
 Véase todo el conjunto

79. 79
State of agile development survey. 9th -2015
Version One
Logros de este enfoque

80. 80
Pero no debemos perder el foco
Entender el
problema
LEAN AGILE
ENFÓQUESE EN
SOLUCIONES, NO
EN SOFTWARE
CONSTRUYA EL
PRODUCTO
CORRECTO
CONSTRUYA DE
LA FORMA
CORRECTA

81. 81
Agenda
 ¿Por qué adoptar metodologías ágiles?
 ¿Por qué los equipos ágiles son más
rápidos y efectivos que los tradicionales?
 Fallas Comunes en la Adopción Ágil
 Tips
 Preguntas

82. 82
Fallas Comunes en
la Adopción Ágil

83. 83
 ¿Cual creen ustedes que es el punto de
falla más critico de Scrum?

84. 84
Puntos de falla en el Product Owner
 Sin visión
 Sin un roadmap del producto o plan de releases
 Sin poder sobre el backlog
 No disponible para aclarar dudas
 Un Product backlog no priorizado por valor de
negocio

85. 85
Puntos de falla en el Scrum Master
 Sin dedicación al equipo
 Creer que su trabajo es mínimo
 Que no remueve impedimentos
 Que no «huele» impedimentos
 Sin capacidad comunicativa
 Que no escucha

86. 86
Puntos de falla en el Planning
 El backlog no esta en ready
 El equipo hace malas estimaciones
 Existe sobre-estimación
 Falta transparencia

87. 87
Puntos de falla en el Equipo
 Pobre conocimiento técnico
 Part –time
 Multi-tasking individual
 Prueban tarde
 No es multidisciplinario y no puede lograr el
DONE
 No mejora técnicamente en prácticas de
ingeniería
 Mal uso de la libertad

88. 88
Puntos de falla en el Daily
 Equipo superior a 9 personas
 Las personas no hablan
 Las personas no entienden para que sirve
 Dura más de 15 minutos

89. 89
Puntos de falla en el Review
 No muestra codigo trabajando y testeado (El
incremento no esta en DONE)
 No genere feedback sobre el producto
 No se inviten interesados

90. 90
Puntos de falla en la Retrospectiva
 No hay mejora sprint tras sprint
 No genera impacto y compromiso en el equipo
 Se desecha del framework
 No se inspecciona y mejora el proceso y/o el
equipo

91. 91
Puntos de falla en General
 No hay mejora
 No se eliminan los desperdicios
 No hay enfoque en el valor
 No se remueven impedimentos
 Se hace microgestión
 El equipo no es retado y se queda en zona de
confort

92. 92
UN SPRINT DE ANÁLISIS
UN SPRINT DE DESARROLLO
UN SPRINT DE PRUEBAS
Scrum un grupo de cascadas

93. 93
Si se evitan las malas prácticas

94. 94
 Ken Schwaber: “En Scrum, un grupo en
el que se lleven mal entre ellos, no
comprendan el negocio del cliente y
trabajen con malas herramientas...
también producirán incrementos
periódicos... de basura. ”

95. 95
Creer que Scrum y las metodologías ágiles son
una bala de plata
Mitos, Monstruos y Leyendas Urbanas
Ágil también falla

96. 96
 En metodologías ágiles no se
documenta
Se documenta lo que agrega valor
Mitos, Monstruos y Leyendas Urbanas

97. 97
 En metodologías
agiles no se realiza
planeación
User Story Map
Mitos, Monstruos y Leyendas Urbanas

98. 98
 Ágil no necesita diseño previo
Hay un diseño que se realiza y se vá refinando
Sprint tras Sprint
Mitos, Monstruos y Leyendas Urbanas

99. 99
 Ágil siempre usa
“Historias de Usuario“
El Product Backlog no tiene prescrito que
sean historias de usuario solo ítemes
priorizados los cuales pueden ser
requerimientos, en prosa, casos de uso,
etc. Pero es de aclarar que las
metodologiías ágiles funcionan mejor con
historas de usuario.
Mitos, Monstruos y Leyendas Urbanas

100. 100
 Ágil no se usan
herramientas
Mitos, Monstruos y Leyendas Urbanas
Las hay pero no son el foco, primero las
personas y sus interacciones , luego las
herramientas.

101. 101
Mitos, Monstruos
 Ser ágil es solo
proceso y no es
necesario lo técnico
Principio 9 del Manifiesto
La atención continua a la excelencia
técnica y al buen diseño mejora la
agilidad

102. 102
Mitos, Monstruos
 Ágil es solo para
superdotados
Principio 5 del Manifiesto
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.

103. 103
No hay
• Ni compromisos
• Ni planes
• Ni métricas
Es desarrollo hippie

104. 104
 Scrum Master igual a Gerente de
Proyecto
 Podemos hacer Scrum sin un Dueño de
Producto
 Scrum no funciona con CMMI u otros
modelos de procesos
 Ágil significa más rápido
Mitos, Monstruos y Leyendas Urbanas – Otros

105. 105
Tips para la
adopción ágil

106. 106
Tips
 Busque acompañamiento y otros que lo hayan logrado
 El Scrum Master es esencial
 No tenga equipos UNI-DISCIPLINARIOS
 Garantice el DONE
 Fortalezca el equipo técnicamente y tenga prácticas
como TDD, Integración continua, ATDD, refactoring,
automatización de pruebas, etc
 Empiece con pocas métricas
– Para medir la realidad de los proyectos
– No a las personas

107. 107
Tips
 Reclute al Cliente
 Proporcione un Product Owner que tenga voz y voto
sobre el producto y esté disponible para el equipo
 Evalúe los contratos, permita la colaboración y el riesgo
compartido
 Haga una semilla y vaya creciendo poco a poco (Scrum
orgánico)
 Use scrum para implantar scrum
– ciclos cortos, con planeación, revisión y
retrospectiva

108. 108
Tips centrales de scrum
 No combinar roles
 No alargar, ni acortar los sprints
 No suprimir reuniones
 Retrospectivas, retrospectivas, restrospectivas,
restrospectivas

109. 109
UNAS FRASES Y UNOS
NÚMEROS PARA TERMINAR

110. 110
 “Consistencia y predictibilidad aun son
deseables, pero nunca han sido las cosas
más importantes. En los últimos 40 años,
por ejemplo, nos hemos torturado con
nuestra incapacidad de terminar
proyectos de software a tiempo y en el
presupuesto. Pero esta nunca ha sido la
meta suprema. La meta más importante
es transformación, creando software que
cambie el mundo o que transforme una
compañía o cómo esta hace negocios.”
Tom DeMarco 2009 - “Software Engineering: An
Idea Whose Time Has Come and Gone?”

111. 111

112. 112
Olvídese de la frase,
Mi Organización es un caso especial,
«la verdad, todas lo son»
Agile se puede implantar, ya no es una moda se
esta convirtiendo en la forma de trabajo de la
industria

113. 113

114. 114
PREGUNTAS

115. 115
¡GRACIAS!
Jorge H. Abad L.
jorge.abad@gmail.com
@jorge_abad
Blog http://www.lecciones-aprendidas.info/

116. 116

117. 117Conferencia auspiciada por el PMI Antioquia Colombia Potential Chapter – La propiedad intelectual de esta pertenece al facilitador
Anexos

118. 118
Estas presentación contiene algunas diapositivas de
 LeanSight – Agustín Villena
 Proyectalis - Ángel Medinilla
 Henrik Kniberg
 Lucho Salazar – Agil es algo que eres
 Nota: Traté de dar crédito a todos, pero consideras que faltaste
por que no te referencié o debo modificar algo de tu propiedad
por favor no dudes en hacérmelo saber, contactándome al
email: jorge.abad@gmail.com

119. 119
Aviso de Copyright
 Usted es libre de:
– Compartir- copiar, distribuir y trasmitir el trabajo
– Modificar- adaptar el trabajo
 Bajo las siguientes condiciones
– Atribución. Ud. debe atribuir el trabajo en la manera especificada por el autor
o licenciante (pero de ninguna manera que sugiera que ellos aprueban su uso
del trabajo).
 Nada de lo dispuesto en esta licencia menoscaba o
restringe los derechos morales del autor.
 Para más información ver http://creativecommons.org/licenses/by/3.0/

120. 120
Información de contacto
 Jorge Hernán Abad Londoño
–jorge.abad@gmail.com
–@jorge_abad