the dark side of scrum (sgba2012)

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…