the dark side of scrum (sgba2012)
TRANSCRIPT
The Dark Side of Scrum – SGBA 2012
Federico Zuppa
Porque nos gusta tanto?
Que problemas surgen en la práctica?
Scrum
Scrum Diario
24 horas
Sprint1-4 semanas
Planificación de Sprint Demode Sprint
Retrospectiva de Sprint
Product Backlog Sprint Backlog
Incremento de funcionalidad
Visión + ROI
Planificación de Release
Product Owner
ScrumMaster
Equipo
Auto-Organización
La auto-organización es el proceso donde una estructura o patrón aparece en un sistema sin una autoridad central.
▶ Un sistema auto-organizado no es inherentemente bueno (chequeen esto sino)
– Dirección– Restricciones– Guias
▶ Alinear Restricciones (Jurgen Appelo)
“Los equipos en Scrum son auto-organizados. Nadie les dice como convertir el backlog en un incremento de funcionalidad”
Auto-Organización [problemas]
▶ No ha sido claro el rol del manager
– El rol del manager en Scrum es el de un “Servant Leader”
▶ La auto-organización no encaja con ciertos tipos de caracteres
Colocation
No es una práctica de Scrum per se (es más bien una práctica de XP open workspace)
▶ Comunicación
– El equipo trabaje en un contexto donde fluya la información
▶ En un equipo distribuido se pierde (Cory Foy):– Gestos corporales– Conversaciones de cafe-mate– Introspección instantanea– Ayuda instantanea
Colocación [Comunicación]
Colocation [problemas]
▶ Equipos Grandes
– Subdividir en equipos
▶ Equipos Distribuidos
– Aumentar el bandwith de comunicación
– Tener una buena herramienta
– Tener equipos cross funcionales en todas las ubicaciones y minimizar las dependencias
Capacidad de Batch Limitada
“El corazón de Scrum es el Sprint, una iteración acotada donde se crea un incremento de producto potencialmente listo para salir a producción”
Scope box o Time box?
Por que time boxes?
Timeboxes traen estos beneficios al desarrollo de software:
▶ Timeboxing fuerza un cierre, fuerza al equipo a entregar algo concreto
▶ Time boxes son aventuras de corto plazo. Entender la capacidad– Permite realizar una estimación más precisa del backlog
▶ Permite generar una cadencia
Time boxes [problemas]
▶ Las User Stories son muy grandes
– Existen técnicas para dividir las US
▶ Fluctuaciones
– Termina antes
– No llega y toma atajos para llegar a la demo
▶ El mismo equipo tiene otras responsabilidades (soporte de producción)
– Dejar un buffer
▶ La capacidad del equipo fluctua
– Abandonar los time boxes?
Contacto con el cliente
El product owner es el encargado en Scrum de crear un backlog de requerimientos priorizado y de asegurar que el equipo de desarrollo lo entienda.
▶ El equipo tiene que entender el problema.
– El desarrollo de software es un problema de comunicación!
Pregunta a los expertos: Tiene que ser el PO alguien del cliente?
Contacto con el cliente [problemas]
▶ El PO no tiene tiempo
– Un BA puede ayudar
▶ El PO no tiene la capacidad para llevar a cabo esta tarea
▶ El PO no esta colocado con el equipo de desarrollo
Equipo Multidisciplinario
“Los equipos en Scrum son multidisciplinarios con todas las habilidades necesarias para crear unincremento del producto.”
Equipo Multidisciplinario [problemas]
▶ La carga entre las diferentes especializaciones no esta balanceada
– Escoger las stories de acuerdo a la carga
Planificación
“El product backlog es una lista priorizada de items necesarios en el producto final. Los items en el tope de la lista estan más detallados y mas precisamente estimados”
Planificación [problemas]
▶ Cuanta planificación debemos hacer?
– Dividir en releases
▶ Cuanto tiempo debemos invertir en esta planificación?
– Estimaciones time boxed
Cuanto invertir en la estimación?
Estimaciones [problemas]
▶ Son usadas para presionar a los desarrolladores
User Stories
▶ Una User Story es una descripción corta y simple de un feature visto desde el punto de vista de un cliente
– Las user stories son escritas en fichas o sticky notes, lo cual facilita la planificación y alienta la discusión
User Stories [problemas]
▶ Se pierde el big picture
– Story Maps
▶ Se filtra diseño
– Que se necesita y no como se logra
▶ En muchos contextos, las US no son la manera más adecuada de expresar los requerimientos
– No usar US!
Roles
Scrum tiene 3 roles:
▶ Scrum Master
– Vela por el proceso y elimina impedimentos
▶ Product Owner
– Es el responsable del Product Backlog
▶ Equipo de Desarrollo
– Es el responsable de construir el producto
Roles [problemas]
▶ Una persona comparte 2 roles
– Nunca los roles de PO y SM!
Retrospectiva
“Es una oportunidad para que equipo inspeccione y cree un plan para mejorar en el próximo Sprint”
El proposito de la retrospectiva es:
▶ Inspeccionar como anduvo el Sprint respecto a la gente, relaciones, procesos y herramientas
▶ Identificar y ordenar los items que anduvieron bien y las potenciales mejoras
▶ Crear un plan para implementar estas mejoras
Retrospectiva [problemas]
▶ Se vuelven aburridas
– Varias las actividades
▶ No existe confianza entre los integrantes del equipo
Prácticas Técnicas
Las prácticas técnicas no son parte de Scrum
Que pasa cuando hacemos Scrum sin tener tests, CI y sin refactoring continuo?
The Scrum Wall
“You can’t keep your commitments, you can’t release software, your customers get annoyed and angry, it looks like Scrum is broken.”
Muchas gracias…