Sencillamente explicado el Marco de Trabajo SCRUM

1. SCRUM
alacret@4geeks.co
Angel Lacret

2. Módulo I: El Origen
Metodologías ágiles
Antecedentes
Manifesto agile
¿Por qué Agil?
Filosofia Ágil
Valor en el manejo de proyectos
SCRUM

3. Módulo II: Las Herramientas
SCRUM
Roles
Artefactos
Eventos (Planning, Daily, Retrospective)
MOSCOW (ROI)
SCRUM

4. Módulo III: Un poco “más acá”
La planificación hoy en día
Raíces de SCRUM
Equipos, Equipos, Equipos
Tiempo
Desechando los males comunes
Planeando la realidad y no la fantasía
Oh la felicidad!!!
Prioridades
SCRUM

5. Módulo I
El Origen
SCRUM

6. Metodologías ágiles
Las metodologías ágiles son una alternativa al manejo tradicional de proyecto usado
típicamente en el desarrollo de software. Ayuda a los equipos a responder a la
incertidumbre a través del trabajo iterativo e incremental en periodos conocidos como
sprints. Las metodologías ágiles son una alternativa al desarrollo secuencial o en cascada.
(http://agilemethodology.org/)
SCRUM

7. Antecedentes
SCRUM
1957
Bernie Dimsdale
en IBM (Los
Ángeles,
California)
1970
New York Telephone
Company's Systems
Development Center 1974
1994
1995
Edmons, E.A. “A Process
for the Development
Software for
Nontechnical Users as
an Adaptive System “,
General Systems
El Proceso unificado
Racional de IBM
SCRUM
Muchas otras más durante los 80 y 90 criticando la rigurosidad de los procesos en cascadas

8. SCRUM
Antecedentes
1996
2001
Crystal Clear y
Extreme Programming
(XP)
Agile Manifesto

9. En el 2001, un grupo de desarrolladores se reúnen
en SnowBird, Utah, USA, para discutir nuevas formas
ligeras de desarrollar el software, y concluyen en lo
siguiente:
SCRUM
Agile Manifesto

10. “Nosotros estamos descubriendo mejores maneras de
desarrollar el software, y ayudando a otros a hacerlo.
A través de este trabajo hemos llegado a valorar:”
SCRUM
Agile Manifesto

11. Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on
the right, we value the items on the left more.
SCRUM
Agile Manifesto

12. Agile Manifesto
1) Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana y
continua de software con valor.
2) Aceptamos que los requisitos cambien, incluso en etapas tardías del desarrollo. Los
procesos Ágiles aprovechan el cambio para proporcionar ventaja competitiva al cliente.
3) Entregamos software funcional frecuentemente, entre dos semanas y dos meses, con
preferencia al periodo de tiempo más corto posible.
SCRUM

13. Agile Manifesto
4) Los responsables de negocio y los desarrolladores trabajamos juntos de forma cotidiana
durante todo el proyecto.
5) 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.
6) 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.
SCRUM

14. Agile Manifesto
7) El software funcionando es la medida principal de progreso.
8) Los procesos Ágiles promueven el desarrollo sostenible. Los promotores, desarrolladores
y usuarios debemos ser capaces de mantener un ritmo constante de forma indefinida.
9) La atención continua a la excelencia técnica y al buen diseño mejora la Agilidad.
SCRUM

15. Agile Manifesto
10) La simplicidad, o el arte de maximizar la cantidad de trabajo no realizado, es esencial.
11) Las mejores arquitecturas, requisitos y diseños emergen de equipos auto-organizados.
12) A intervalos regulares el equipo reflexiona sobre cómo ser más efectivo para, a
continuación, ajustar y perfeccionar su comportamiento en consecuencia.
FUENTE: http://agilemanifesto.org/
SCRUM

16. ¿Por qué tomar una aproximación ágil a un proyecto?
¿Por qué adoptar una filosofía ágil de desarrollo de software?
SCRUM
¿Por que Ágil?

17. INCERTIDUMBRE y CULTURA
SCRUM
¿Por que Ágil?

18. SCRUM
¿Por que Ágil?
INCERTIDUMBRE:
❏ En la tecnología a implementar
❏ En el alcance de las fases o de la totalidad del proyecto
❏ En la respuesta o aceptación de los usuarios
❏ En el mercado objetivo
❏ En los procesos de negocio
❏ En los requisitos
❏ En los cambios

19. SCRUM
¿Por que Ágil?
CULTURA:
La Cultura Organizacional se refiere a los gustos, costumbres, valores,
experiencias y creencias de un grupo de personas dentro de una Empresa.
Con el pasar de los años, la experiencia ha demostrado que la productividad en
los miembros de una organización está directamente relacionada con la
motivación y la sensación de bienestar que éstos puedan tener dentro de su
entorno laboral, sensaciones que están directamente relacionadas con la
Cultura dentro de la empresa.

20. SCRUM
¿Por que Ágil?
CULTURA:
Actualmente, cada vez más empresas han evolucionado a una Cultura más
orientada o propensa a adaptarse al día a día de las personas, siendo
consecuentes con las emociones y sensaciones de éstas.
Factores como empoderamiento, confianza, interacción y autoorganización,
-pilares fundamentales dentro de las metodologías ágiles- representan valores
que van en consonancia con las nuevas tendencias de culturas organizacionales.
La agilidad, como la cultura es “peoplecentric”.

21. SCRUM
Filosofia Ágil

22. SCRUM
Filosofia Ágil
No podemos predecir o planear con absoluta certeza lo que vamos a entregar, cuándo lo
entregaremos y cuál será su costo.
Empecemos con planes iniciales alrededor de las estimaciones, fechas y alcances, pero
enfoquémonos en la revisión continua de estas restricciones a medida que avanzamos.
La meta es entregar el mejor software posible dadas estas restricciones, pero ningún
método con el enfoque de receta de cocina mejorará lo que es “mejor”.
Fuente: http://www.slideshare.net/luchoslide/cultura-agil-v210

23. SCRUM
Valor en el manejo de Proyectos

24. Valor en el manejo de Proyectos
Aumento de la productividad por el uso de una metodología
alrededor de la cultura.
Comunicaciones eficientes gracias a un marco de interacción entre
sus miembros.
Respuesta rápida de parte de equipos autoorganizados.
Capacidad de maniobrabilidad por el empoderamiento de las
estructuras ágiles.
SCRUM

25. Módulo II
Las
Herramientas
SCRUM

26. Módulo II: Las Herramientas
SCRUM
Roles
Artefactos
Eventos (Planning, Daily, Retrospective)
MOSCOW (ROI)
SCRUM

27. SCRUM
SCRUM
Fuente (www.scrumalliance.org)

28. SCRUM
Un Marco de trabajo con el que las personas pueden atacar problemas de índole adaptativo, mientras
entregan productiva y creativamente productos con el más alto valor posible.
Scrum es: Ligero, Simple de Entender, Dificil de Dominar
Scrum es Marco de Trabajo que ha sido utilizado para manejar desarrollo de productos complejos desde los
tempranos 1990s.
Scrum no es un proceso o una técnica para construir productos; en vez, es un marco de trabajo en el que
puedes emplear varios procesos y técnicas. Scrum hace clara la eficacia relativa de tus prácticas en el
manejo y desarrollo del producto para que puedas mejorar.
Scrum consiste en Equipos de Scrum y sus Roles asociados, Eventos, Artefactos y Reglas. Cada componente
en el Marco de Trabajo sirve un propósito específico y esencial para el uso y éxito de SCRUM.
SCRUM

29. SCRUM
PILARES:
Empirismo (Experiencia y conocimiento): Transparencia,
Inspección y Adaptación
Iterativo e Incremental (Sprint)
SCRUM

30. SCRUM
VALORES:
Enfoque: Pocas cosas a la vez
Coraje: Tomar grandes retos
Franqueza: expresar emociones y preocupaciones
Compromiso: Comprometerse con el equipo
Respeto: Para cada miembro del equipo
SCRUM

31. SCRUM
ARTEFACTOS: (El equipo)
Product Backlog
Sprint Backlog
Definition of Done
SCRUM

32. ARTEFACTOS: Product Backlog
Única fuente de requerimientos para el equipo
Todo lo que debería tener el producto
Responsabilidad del Product Owner
Ordenado por prioridad
No necesita estar completo
Estimado por el Development Team
SCRUM

33. ARTEFACTOS: Product Backlog
SCRUM
Product Backlog

34. ARTEFACTOS: Sprint Backlog
Subconjunto del Product Backlog
Priorizado
Bien claro
Compone el Sprint Goal
Suficientemente atómico
SCRUM

35. ARTEFACTOS: Sprint Backlog
SCRUM
Product Backlog Sprint Backlog

36. ARTEFACTOS: Definition of Done
Definición de qué quiere decir LISTO
Cuando se declara un ítem como LISTO, es necesario que todo el
mundo sepa qué quiere decir LISTO
En equipos complejos incluye requerimientos e ítems de calidad.
Ejemplo: Pantallas, Pruebas unitarias, Desarrollo, Integración, QA
SCRUM

37. SCRUM
ROLES: (El equipo)
Product Owner
Scrum Master
Team Member: Desarrollador, Especialista QA, Diseñador
SCRUM

38. ROLES: Product Owner
Responsable de maximizar el valor del producto
Responsable del Backlog
Expresa bien los requerimientos o hace que el equipo lo haga
Es uno solo, y es el punto de convergencia de los cambios solicitados
por interesados
Comunicativo y transparente
SCRUM

39. ROLES: Team members
Autoorganizado y Multidisciplinario
Es el único que entrega valor al producto a través del incremento
Scrum no reconoce títulos (Ministro, Super intendente, Mariscal …)
No hay subequipos
Pueden ser diversos, pero todos cuentan como Development Team
Idealmente entre 4 y 8 (Two Pizza Teams)
SCRUM

40. ROLES: Scrum Master
Garantizar la correcta aplicación de Scrum. Esto incluye, desde la correcta transmisión de
sus principios a las altas gerencias, hasta la prevención de la inversión roles (es decir,
guardar especial cuidado en que el dueño de producto no actúe en nombre del Scrum
Team y viceversa, o que la audiencia se inmiscuya en tareas que no le son propicias).
Resolver los conflictos que entorpecen el progreso del proyecto.
Incentivar y motivar al Scrum Team, creando un clima de trabajo colaborativo, fomentar la
autogestión del equipo e impedir la intervención de terceros en la gestión del equipo.
SCRUM

41. ROLES: Scrum Master
Es el un SERVANT-LEADER.
Mejorar las interacciones dentro del equipo.
Buscar y mejorar las prácticas y herramientas de desarrollo para garantizar que cada
incremento de funcionalidad sea potencialmente productivo.
Mantener la información actualizada sobre el progreso del equipo y que sea visible
para cualquier persona.
Ayudar al product owner a entender la agilidad y a maximizar el valor del negocio.
Ayudar con las posibles mejoras detectadas en la retrospectiva del sprint, para que
sean llevadas a cabo.
SCRUM

42. SCRUM
EVENTOS o Ceremonias
Sprint Planning
Daily Scrum
Sprint Review
Sprint Retrospective
SCRUM

43. EVENTOS: Sprint Planning
En él se define el trabajo a ser realizado en el Sprint
Participa todo el equipo de trabajo
Máximo de 8 horas para Sprints de un mes
Responde a lo que va ser entregado en el Sprint (Sprint Goal)
Los ítems seleccionados para el Sprint deben ser aclarados en este evento
SCRUM

44. EVENTOS: Sprint Planning
LISTA DE VERIFICACIÓN:
Todos están de acuerdo con la cantidad de trabajo
Todos entienden por completo todas y cada una de las actividades a
realizar
Todos entienden el objetivo del Sprint
SCRUM

45. EVENTOS: Daily Scrum
Reunión diaria de 15 minutos para sincronizar las actividades que se están
realizando
Lo miembros del Development Team responden: ¿Qué hice ayer?, ¿Qué
haré hoy? ¿Noté un impedimento para continuar con el trabajo?
Es responsabilidad del Scrum Master que se dé la reunión, pero es
ejecutada por el Development Team
Solo para el Development Team
SCRUM

46. EVENTOS: Daily Scrum
LISTA DE VERIFICACIÓN:
Están todos los que deben estar
Todos han participado
Todos entienden lo que los demás están haciendo
SCRUM

47. EVENTOS: Sprint Review
Inspeccionar el incremento
Se cambia el Backlog de ser necesario
4 horas en sprint de un mes
El product owner explica el avance
Se revisan los problemas y cómo se resolvieron
Se revisan los tiempos, presupuestos, etc.
SCRUM

48. EVENTOS: Sprint Review
LISTA DE VERIFICACIÓN:
Está claro qué se cumplió y qué no se cumplió, para todos los miembros del
equipo
Los ítems no terminados se devuelven al Backlog con cualquier otro ítem
descubierto o nuevo
SCRUM

49. EVENTOS: Sprint Retrospective
Después del Sprint Review
Una oportunidad para mejorar e implementar correcciones
Crear un plan para estas mejoras
SCRUM

50. EVENTOS: Sprint Retrospective
LISTA DE VERIFICACIÓN:
Todos los problemas durante el Sprint han sido presentados
Se plantean soluciones a estos problemas
Se traza un plan para hacerlo
SCRUM

51. SCRUM
SCRUM

52. SCRUM
SCRUM
Product Backlog Sprint Backlog DONEDOING

53. SCRUM
MOSCOW

54. MOSCOW
Must have: Items necesarios en el Sprint.
Should: Importante pero no necesario, no críticos.
Could have: deseables pero no necesarios, pueden mejorar la experiencia o
satisfacción a un bajo costo.
Won't have: menor criticidad, bajo valor, o no apropiados en este
momento.
SCRUM

55. Módulo III
Un poco
“más acá”
SCRUM

56. Módulo III: Un poco “más acá”
La planificación hoy en día
Raices de SCRUM
Equipos, Equipos, Equipos
Tiempo
Desechando los males comunes
Planeando la realidad y no la fantasía
Oh la felicidad!!!
Prioridades
SCRUM

57. La Planificación hoy en día
SCRUM

58. La Planificación hoy en día
La planificación hoy en día no funciona, dando cabida a nuevas formas de
hacer las cosas (SCRUM).
La planificación es una buena herramienta, pero seguir un plan
ciegamente es algo realmente tonto: Todos los planes cuando se enfrentan
a la realidad fallan, la mejor forma de construir un producto o de llevar a
cabo cualquier actividad se fundamenta en el cambio, el descubrimiento y
la creatividad.
SCRUM

59. La Planificación hoy en dia
Inspecciona y Adapta: Cada cierto tiempo tómate un momento para el
panorama, el “big picture”, lo que has hecho y lo que vas a hacer, y encuentra
una manera de hacer mejor las cosas.
Cambia o muere: Apegarse a las viejas costumbres de hacer las cosas sola
traerá fracaso, mientras otros que descubren maneras mejores y más
eficientes, te sacarán ventaja.
SCRUM

60. La Planificación hoy en dia
Falla tan pronto como puedas, para que lo puedas arreglar a tiempo: Es
importante atreverse, saber lo que no está bien es una forma de avanzar, y
es preferible eliminar los desperdicios al principio, que ya cuando se han
convertido en problema.
SCRUM

61. Raíces de SCRUM
SCRUM

62. Raices de SCRUM
Jeff Sutherland, y su descubrimiento al volar aviones en Vietnam, al
observar a su desfile militar y al estudiar a la Toyota.
La duda es la muerte: Observa, Orienta, Decide y Actúa.
Las respuestas siempre están alrededor.
Los grandes equipos son: Multifuncionales, Autónomos y Empoderados,
con un propósito que Trasciende.
SCRUM

63. Raices de SCRUM
Jeff Sutherland, y su descubrimiento al volar aviones en Vietnam, y al
observar a su desfile militar.
No Adivines!!!: Planifica, Haz, Revisa y Actúa.
Shu Ha Ri: Aprende las reglas, haz mejor el proceso y finalmente, cuando lo
dominas descarta todo lo que sabes, y solo “sé”.
SCRUM

64. Equipos, Equipos, Equipos
SCRUM

65. Equipos, Equipos, Equipos
Los esfuerzos deben ir donde los esfuerzos deben ir: Enfócate en el
rendimiento del equipo y no de los individuos.
Trasciende: Grandes equipos tienen un propósito mayor que el de los
individuos.
Autonomía: Los equipos deben poder decidir si cambiar de rumbo o no, la
libertad hará la diferencia
SCRUM

66. Equipos, Equipos, Equipos
Multifuncional: Los equipos deben tener todas las disciplinas necesarias
para actuar en cualquier circunstancia.
Pequeñas victorias: Equipos pequeños son más eficientes que equipos
grandes.
La culpa es estúpida: No busques por malas personas, busca malos
sistemas y procesos que premian mal rendimiento. (Nazis)
SCRUM

67. Tiempo
SCRUM

68. Tiempo
El tiempo es finito, respeta eso: Corta el trabajo en tiempos prudentes,
alcanzables y cortos.
Demuestra o muere: Cada Sprint, muestra el resultado, algo que pueda ser
usado, que sea el resultado del esfuerzo.
No hay títulos: Se conocido por lo que haces, y no por cómo te refieren.
SCRUM

69. Tiempo
Todo el mundo sabe todo: La Sobresaturación de la información ayuda a
acelerar los procesos.
Una reunión por día: Las reuniones diarias son fundamentales, ve cómo se
puede acelerar el cumplimiento de objetivos, y hazlo!
SCRUM

70. Desechando los males comunes
SCRUM

71. Desechando los males comunes
El “Multitasking” te hace estúpido: Hacer más de una cosa a la vez te hace
más lento y peor en todas las tareas.
Medio Hecho, es que no está listo: Todo lo que está a medias representa
recursos desperdiciados.
Trabajar demasiado no reduce el trabajo, lo aumenta: Trabajar horas de
más produce fatiga, la fatiga produce errores.
SCRUM

72. Desechando los males comunes
No seas irracional: Objetivos retadores son emocionantes, objetivos
imposibles son depresivos.
No hay héroes: Si tu necesitas un héroe para hacer las cosas, entonces las
cosas están peor de lo que piensas.
Basta de reglas tontas: Tontos formularios, tontos horarios, tontas
reuniones, tontas aprobaciones, tontos estandares.
SCRUM

73. Planificando la realidad, no la fantasía
SCRUM

74. Planificando la realidad, no la fantasía
El Mapa no es el Terreno: No te enamores del plan, estoy seguro que está
mal.
Solo planifica lo necesario: Solo lo necesario para que el equipo esté
ocupado.
Planifica de forma relativa: Planning Poker.
SCRUM

75. Planificando la realidad, no la fantasía
Pregúntale al Oráculo: Para planificar lo mejor es utilizar técnicas a ciegas,
donde la gente no está mal influenciada.
El trabajo es una Historia: Describe el trabajo como una historia, algo que
le aporta valor a alguien.
Conoce tu velocidad: Cada equipo debe saber sus capacidades, así como su
debilidades.
SCRUM

76. Oh! La Felicidad!!
SCRUM

77. Oh! La Felicidad!!
Es el viaje, no el Destino: La felicidad es encontrada al hacer las cosas y no
al terminarlas.
Feliz es el nuevo Negro: Te hace más productivo, dispuesto, eficiente y
eficaz.
Mide la Felicidad: No es necesario sólo sentirse bien, hay técnicas para
medir qué bien se sienten las personas.
SCRUM

78. Oh! La Felicidad!!
KAIZEN: Mejora algo cada día, cada sprint, cada mes
Los secretos son venenos: Nada debe estar oculto, todo debe estar visible,
especialmente el trabajo
La felicidad es Autonomía, Maestría y Propósito: Todo el mundo quiere
controlar su destino, y tener un propósito más allá de sí mismo.
SCRUM

79. Oh! La Felicidad!!
No dejes crear la burbuja de la Felicidad: Si bien es importante sentirse
bien, la felicidad debe atarse al rendimiento.
SCRUM

80. Prioridades
SCRUM

81. Prioridades
Haz la lista: Revísala dos veces
El Product Owner: Debe entender el Backlog, el producto, la visión y el
mercado.
Un Líder no es el Jefe: El Product Owner dice qué es lo que se tiene que
hacer y por qué. El cómo se hace, es problema del equipo
SCRUM

82. El Product Owner: El Product Owner tiene poder para tomar decisiones
finales, y debe saber qué es lo que le da valor al producto.
Temerle a la incertidumbre está bien
Ser pagado para hacer nada, y mis cambios gratis: Debes estar preparado
para entregar esfuerzos no contemplados sin cobrar y cambiarlos por cosas
de igual esfuerzo y sin valor
Prioridades
SCRUM

83. Algo Extra
SCRUM

84. Project Manager Vs. SCRUM MASTER
SCRUM

85. PECADOS en SCRUM
SCRUM

86. PECADOS en SCRUM
Tener un líder o jefe
Puntos de historia como horas de trabajo
Sobreestimar a conveniencia
Convertir las reuniones diarias en mini entregas
Convertir al project manager en el scrum master
Convertir al scrum master en el product owner
SCRUM

87. PECADOS en SCRUM
No tener dailys meeting
Alargar los sprints
No hacer retrospectives meetings
No tener un Definition of Done
Mover las reuniones de horario
No tener Equipos multitasking
Imponer cómo cada quien debe hacer las cosas
SCRUM

88. Y por último:
SCRUM

89. CAMBIA AL MUNDO!
SCRUM
Jefe SCRUMLíder

90. Mantra
"En la actualidad, el éxito en la prestación de un servicio ya no se mide
principalmente por la calidad con la que se presta, si no por la
satisfacción del usuario al ser atendido"
Angel Lacret
SCRUM

91. alacret@4geeks.co
Angel Lacret
@alacret