Scrum 101, charla Barcamp 2015 Col30

1. Generamos valor para su empresa con tecnología y diseño

2. Scrum 101

3. Contenidos de la charla
● Tipos de proyectos
● Manifiesto ágil
● Marco Scrum
● Roles
● Actividades
● Artefactos
● Reglas Scrum
● Datos Scrum
● Pros/Cons/Tips Scrum
40 minutos

4. ¿Qué es Scrum?

5. “Es un marco de trabajo en el que las personas
pueden hacer frente a problemas complejos
adaptables, mientras que de manera
productiva y creativa entregan productos del
mayor valor posible. Scrum es:
● Ligero
● Fácil de entender
● Difícil de dominar”
Ken Schwaber & Jeff Sutherland
¿Qué es Scrum?

6. ● Simple
● Complicado
● Complejo
● Anárquico
David J. Snowden & Mary E. Boone
Harvard Business Review 2007
Tipos de proyecto

7. Tipos de proyecto: Definiciones
Simple Complicado Complejo Anárquico
- Caótico
Desorden
Detectar,
categorizar,
responder
Detectar, analizar,
responder
Probar, detectar,
responder
Actuar, detectar,
responder
Encontrar dominio
correcto
Basado en
prácticas
establecidas
Afrontar situación,
investigar opciones
Explorar y aprender
del problema
Actuar en
búsqueda de
estabilización
No actuar dada la
preferencia
personal o método
conocido. Hay que
encontrar el
dominio.
Dominio de las
mejores prácticas
Expertos para ganar
“insight”
Ambientes de fallo
seguro para
experimentar
Buscar lo que
funcione, en vez
de LA respuesta
Causa-efecto
claro y evidente
Múltiples opciones
correctas
Explorar,
inspeccionar,
adaptarse
Muchas
decisiones, poco
tiempo

8. Tipos de proyecto: Ejemplos
Simple Complicado Anárquico
- Caótico
Caótico
Detectar,
categorizar,
responder
Detectar, analizar,
responder
Probar, detectar,
responder
Actuar, detectar,
responder
Call-center,
construcción,
comercio
franquicias
Mantenimiento de
software, minería o
petróleos
Modelos de
negocio digitales,
productos nuevos e
innovadores
Bolsa de valores,
línea de
emergencias

9. Dominio Complejo: Agile Manifiesto
Estamos descubriendo formas mejores de desarrollar
software, tanto por nuestra propia experiencia como
ayudando a terceros.
A través de este trabajo hemos aprendido a valorar:
Personas e interacciones
sobre
procesos y herramientas
Software funcionando documentación
comprensible
Colaboración con clientes negociación de contratos
Responder a los cambios seguir un plan
www.agilemanifesto.org

10. Dominio Complejo: Cascada Vs. Ágil
Reporte Chaos, Standish Group, 2011

11. Dominio Complejo: Métodos Ágiles
VersionOne - State of agile survey 2011

12. ¿Qué es Scrum?

13. “Es un marco de trabajo en el que las personas
pueden hacer frente a problemas complejos
adaptables, mientras que de manera
productiva y creativa entregan productos del
mayor valor posible. Scrum es:
● Ligero
● Fácil de entender
● Difícil de dominar”
Ken Schwaber & Jeff Sutherland
¿Qué es Scrum?

14. “Es un marco de trabajo basado en un
conjunto de valores, principios y prácticas
que suministran los fundamentos para que
cada organización le agregue su
implementación única.”
Kenneth Rubin, Essential Scrum
¿Qué es Scrum?

15. ● Método ágil más popular
● Puede complementarse para convivir con otras
metodologías
● Equipos auto-organizados
● Equipos enfocados a resultados
● Adaptación contínua
● Centrado en personas
● No solamente software
● Valores y prácticas administrativas (SM)
● Técnicas de desarrollo (SD)
¿Qué es Scrum?

16. Bases de Scrum
Proceso Empírico
Transparencia, Adaptación e Inspección

17. ¿Por qué Scrum?
● Proyectos de software
● ¿“El cliente siempre tiene la razón”?
● El cliente en verdad muchas veces no sabe lo que
quiere
● Calidad de software
● Rápido testeo
● Rápidos resultados
● Costos reducidos a largo plazo

18. ¿Cómo se ve Scrum?

19. Se compone de:
● Roles
● Actividades
● Artefactos
● Reglas
Scrum

20. Scrum: Roles

21. Scrum: Roles de un Scrum Team (ST)
Nombre del Rol Abreviación Cantidad Recomendaciones
Product Owner PO 1 Conocedor de negocio, parte
del cliente, en contacto
constante con usuarios e
interesados
Scrum Master SM 1 x ST Capacitado en la
metodología, conocimiento
sólido en negocio y tecnología
Scrum Developer
(Development
Team)
SD (DT) 4-9 Equipo auto-organizado y
multidisciplinario

23. ● Centro de empoderamiento de las características del
producto
● Principal responsable por el avance y la entrega
definitiva
● Autoridad primaria en el orden y la importancia de las
características del producto
● El PO colabora constantemente con dudas de negocio
del DT y el SM
Product Owner (PO)

25. ● Lider servil
● Colabora con el entendimiento y la aplicación de los
valores, prácticas y principios de Scrum (agile
approach)
● Remueve obstáculos del equipo de desarrollo y los
protege de interferencias externas
● NO ES UN PROJECT MANAGER, no tiene autoridad
sobre prioridades o métodos de implementación
Scrum Master (SM)

27. ● No hay roles específicos, sino uno
transversal
● Equipo multifuncional
● Auto-organizado para asumir y
auto-asignar tareas definidas en
cada Sprint
● Actitud mosquetero
● Todo el equipo es responsable de
la construcción del producto
● Habilidades “T”
Scrum Developer (SD) → (DT)

28. Scrum: Artefactos

29. Scrum: Artefactos
Nombre del Artefacto Abreviación
Product Backlog PB
Sprint Backlog SB
Potentially Shippable Product
Increment
PSPI - PI

30. ● Lista priorizada y
secuencial de
características o “historias
de usuario”
● Basada en la visión de
producto del PO
● Responsabilidad del PO
● Siempre el trabajo más
valioso va primero, y va
más detallado
Product Backlog (PB)

31. Sprint Backlog (SB)
● Lista prevista de desarrollo
o ejecución para un (1)
Sprint
● Items primeros en el PB,
con estimación acorde al
Sprint
● Desagregado de los items
del PB en tareas
específicas y asignadas en
el DT
● Items susceptibles de ser
afrontados con KANBAN

32. Potentially Shippable Product Increment (PSPI - PI)
● Una parte o sección de
producto construida o
“hecha”
● Parte o sección dispuesta a
ser liberada
● La liberación es una
decisión de negocio, no es
imperativo

33. Scrum: Actividades

34. Scrum: Actividades
Actividad Duración
Sprint 1-4 semanas (4)
Sprint Planning 8 horas
Daily Scrum 15 minutos (indiferente de la
duración del Sprint)
Sprint Execution 4 semanas
Sprint Review 4 horas
Sprint Retrospective 3 horas
Product Backlog Grooming Continuo durante ejecución

35. Sprint
● Corazón de Scrum
● Cajas de tiempo que tienen un inicio y finales FIJOS
● Generalmente recomendados de una misma duración
(1-4 semanas)
● La finalización de un Sprint es seguida inmediatamente
del inicio del siguiente

36. Sprint Planning
● Primera actividad
dentro del Sprint
● Reunión de revisión de
PB para llegar a
acuerdos
● PO, SM, DT
● Selección de común
acuerdo de X cantidad
de ítems del PB → SB
● Estimación de ítems
(generalmente horas)
● Ítem > Tareas > Llenar la
capacidad

37. Daily Scrum
● Revisión de inspección y
adaptación.
● SM, DT, PO (pasivo)
● “Daily stand-up”
● Generalmente:
● ¿Qué logré desde el
último Daily?
● ¿Cuál es mi plan para el
siguiente Daily?
● ¿Qué obstáculos
enfrento?
● Gallinas y cerdos

38. Sprint Execution
● Ejecución de las tareas dada
su estimación, asignación y
adaptación en los daily
● El equipo debe estar
protegido de interferencias
externas
● El PB y SB deben estar
siempre a la vista, y
actualizado
● El control se hace
generalmente con KANBAN
● Gráfica Burndown

39. Sprint Review
● Revisión de características internas
(“hecho”)
● Revisión del PSPI
● PO, SM, DT, Clientes, Usuarios,
Interesados
● Centrada en las características
terminadas
● Información bidireccional de avance y
ajuste de la dirección e importancia del
PB restante
● Todos obtienen visibilidad de lo que está
ocurriendo y del estado del proyecto

40. Sprint Retrospective
● Inspeccionar y adaptar el
proceso
● Reunión interna del ST
para revisar cuán
colaborativo y productivo
es el equipo
● Identificar obstáculos y
comprometerse con
acciones concretas de
mejora

41. Product Backlog Grooming
● El grooming consiste en el
refinamiento, estimación y
priorización de los ítems
del PB.
● Participación significativa
de interesados, SM y DT en
cabeza del PO
● Generalmente 10% del
tiempo del DT debe estar
dispuesto a ayuda del
PBGrooming basados en:
○ Dependencia técnica
○ Restricciones de
recursos

42. ¿Cómo se ve Scrum?

43. ★ Variabilidad e incertidumbre
○ Acoge la variabilidad útil,
desarrollo iterativo e incremental,
reduce incertidumbre
simultáneamente (end, means,
customer)
★ Predicción y adaptación
○ Mantén opciones abiertas, no
puedes lograrlo todo desde el
inicio, favorece la exploración y
adaptación, sé sensible
económicamente
★ Aprendizaje validado (LEAN)
○ Valida en vez de asumir,
aprovecha la retroalimentación
Scrum: Reglas
★ Trabajo en progreso
○ Usa tamaños de carga
económicamente sensibles,
enfócate en trabajo en espera, y
no en trabajadores en espera
★ Progreso
○ Entregado y validado, enfócate
en la entrega centrada en valor,
el progreso ayuda a adaptar y re-
planear
★ Rendimiento
○ Vé rápido pero no te apures,
construye con calidad, emplea
mínima/suficiente
ceremonia/protocolo

44. Datos Scrum: Adopción
La adopción de Scrum en empresas de software existentes
depende de su ubicación en la curva de innovación

45. Datos Scrum: Modelo de Cambio
Virginia Satir (1991, 1997)
http://stevenmsmith.com/ar-satir-change-model/

46. Datos Scrum: Adopción
Pregunta Razón Primer Resultado
Causa de fracaso en ágil Filosofía de la compañía o
desacuerdo fundamental cultural
13%
Obstáculos al adoptar ágil Habilidad para cambiar cultura
organizacional
53%
Preocupaciones sobre
adoptar ágil
Falta de planeación anticipada 30%
Resultados (tiempos) en
proyectos ágiles
Más rápida 73%
Beneficios obtenidos Habilidad para cambiar
prioridades
92%
Ayudas para implementación Apoyo de la gerencia 22%

47. Datos Scrum: Certificaciones
Scrum Agile Institute, 2014

48. Datos Scrum: PROs
● El cliente obtiene resultados importantes/utilizables
desde etapas tempranas
● Se comienza el proyecto con requerimientos de alto
nivel
● Los cambios se administran de manera natural
● Se mitigan los riesgos del proyecto desde el inicio
● Se gestiona la complejidad al apuntar a la construcción
de aquello que brinda más valor
● Se optimizan los recursos disponibles
● Se minimizan el número de errores y se aumenta la
calidad

49. Datos Scrum: CONs
● La disponibilidad del cliente e interesados debe ser alta
durante el proyecto
● El PO debe tener disponibilidad de manera continua
(igual que los SD)
● La relación con el cliente es más colaborativa que
contractual (modelo de cambio)
● Es una metodología recomendada para proyectos de
dominio complejo

50. Scrum: Fuentes Principales
● SEONTI - Scrum Methodology Certification
● Essential Scrum - Kenneth S. Rubin
● Agile Manifesto

51. Generamos valor para su empresa con tecnología y diseño