Este documento discute los desafíos de aplicar Scrum en una empresa que no utiliza Scrum habitualmente. Presenta cuatro problemas comunes: 1) solicitudes de fechas firmes para funcionalidades, 2) coordinación entre equipos distribuidos, 3) estimaciones imprecisas que conducen a errores, y 4) cambios en el alcance durante una iteración. Sugiere que las herramientas de Scrum pueden ayudar a abordar estos problemas mediante la mejora de la visibilidad, comunicación, estimación y capacidad de respuesta a cambios.
3. SCRUM EN UNA EMPRESA NO SCRUM
Planificación
Fechas
Cambios en el Negocio
Errores
Adopción
Comunicación
Disponibilidad
Equipos Distribuidos
Proyectos en paralelo
4. PROBLEMA #1
Nos piden fechas concretas para un grupo de
funcionalidades del backlog. ¿Qué responder?
12. ALGUNAS CONCLUSIONES
Un resultado malo no es bueno, pero un resultado muy
variable es aún peor (incluso con un resultado bueno )
Muchas veces no podemos mejorar la velocidad, pero sí
podemos trabajar sobre la capacidad. (+gente, +equipos )
En un escenario “complejo” la visibilidad es clave para
poder atacar a tiempo los problemas
Las herramientas nos ayudaron en la toma de decisiones:
Punto centralizado de acceso a la información
Recuerdan toda la historia (velocidad, cambios pedidos, etc. )
Permiten estimar fechas/compromisos
Facilitan la interacción (distinto idioma y horarios)
Reportes que muchas veces son exigidos por el negocio
13.
14. REFERENCIAS
The Enterprise and Scrum: amazon.com/The-Enterprise-Scrum-
Ken-Schwaber/dp/0735623376
Agile Project Management with Scrum: amazon.com/Agile-
Project-Management-Microsof t-Professional/dp/073561993X
Serena Agile Planner: serena.com /products/agile-
software/index.html?hphdr
Hallmarks of Agile Development Success:
versionone.com/Agile101/Agile-Development-Success/
Agile Estimation: slideshare.net /sfnyc/agile-estimation-6478349
Solving the Scrum Deadline Debate:
labs.openviewpartners.com/solving-the-scrum-deadline-debate/
Agile - Estimación y Planificación: http://dev -
jeronimo.blogspot.com.ar/2012/04/scrum -estimacion-y -
planificacion.html
Hinweis der Redaktion
Para llevarse bien con la empresa/clientes debemos trabajar en estos puntos:Predictability & PlanningFechas: Muy difícil establecer deadlines/hitos, comprometerse con alcance a una fecha.Cambios del Negocio: Muchas veces no pueden esperar al fin de una iteración, pero tampoco se puede cancelar lo ya comprometido. Imposible!Errores:Tamaño (estimación): Se manifiesta sobre todo al inicio. Subjetividad, no existe un modelo repetible y confiable. Bugs: Difícil de evitarlos, difícil de estimarlos. Suelen impactar siempre en los compromisos.Ease of AdoptionComunicación: En equipos remotos o múltiples equipos se dificulta mucho la misma. Se pierde información y visibilidad del estado del proyecto.Difícil de implementarProduct owner no siempre disponible y suele estar sobrecargadoHusos horarios y distribución geográficaMultiples proyectos en simultaneoVamos a presentar cuatro escenarios de nuestro día a día que ejemplifican estas problemáticas y mostrar de que forma los solucionamos.
Que mostrar:Separacion entre el team backlog y el sprint backlog (scrums de scrums)Planning->Team Planning (product owner, poder planificar/asignar trabajo a cada equipo y ver velocidades pasadas para tener idea del tamaño de lo que está asignando)Planning->Sprint Planning (equipos planifican sus iteraciones en un solo lugar independientemente que estén distribuidos, visibiidad!)Visibilidad de estado/avanceTracking->Sprint Task Board (pizarra virtual, orientada a tareas)Tracking->Sprint Story Board (pizarra virtual, orientada a stories, para PO)Tracking->Sprint Task Burndown (visibilidad tiempo real de avance de cada equipo)Linkshttp://www.youtube.com/watch?v=Ht2xcIJrAXohttp://www.scrumalliance.org/resources/17Interesados: Scrum Master y Product OwnerEs el problema de la visibilidad y la comunicaciónVariables Típicas (SCRUM):Sprint Planning: Tamaño/Velocidad/EquiposRevisión diaria de statusScrums de ScrumsOtros ConceptosEmpezamos con pizarra, equipo crece y nos quedamos sin lugar.Pizarra: No es fácil registrar owner de las tareas ni la separación de un user story en tareas.Comunicación: Skype y teléfono.Visibilidad unificada: Dashboard multiequipo-multisprint en un solo lugar (Sprint Tracking).Scrum de ScrumsMultiples equipos trabajando en un mismo backlogMultiples Sprints en paraleloCalendarios y Velocidades por equipos
Que mostrar:Reports->Defects By SprintReports-> Armar un reporte hs en defectos vs en no defectos por iteración/equipo/proyectoAnalogíaPintor->Calcule mal los m2 o la complejidad, por lo que mi velocidad no vario pero en realidad había más para hacer de lo que pensaba.Pintor->Mi velocidad se redujo por algún factor intangible (motivación, cansancio, problemas personales, etc.)Pintor->Termine de pintar, pero el cliente encuentra que falta una mano de una determinada pared.Interesados: Equipo y Scrum MasterEs el problema de la estimación y la ejecuciónVariables Típicas (SCRUM):Estimación de Tamaño (estimación)Velocidad promedio (ejecución)Sprint Burndown Chart (esfuerzo pendiente, velocidad y proyección)Problemas con las variables típicasStaffing: persona idóneas para las tareas. De no ser así, cambio de persona. (no es un error)Causas: Motivación, Time-off, Tecnología o problema novedoso, Cambios en el equipo, falta de historia (primeras iteraciones).Efecto: Incertidumbre en las Estimaciones (difícil de detectar a priori)Variabilidad de Velocidad. Si la velocidad es muy variable, el promedio no significa nada.Contemplar errores -> conocer y administrar la variabilidad y la incertidumbreVariabilidad (velocidad)Velocidad a lo largo del tiempo (ver la curva de velocidad)Intervalo de confianza (no usar el promedio 2 desvíos standard)Incertidumbre (estimaciones)Técnicas: Planning Poker, Delphi o Comparación.Evidenciar errores de estimación en el momento (lean) -> aumento en el Sprint BurndownDefectosClasificar en dos tipos: 1.“Ya sé que es”, 2.“No tengo idea que pasa”Tipo 1) asociar a un userstory “Defectos” y estimarTipo 2) muy difícil de estimar, asignar un tiempo fijo x iteración a la solución de este tipo de issues (alcance variable, tiempo fijo)Con información histórica se puede acordar un tiempo razonable que de lugar a solucionar problemasSi aparece uno urgente, hacer de inmediato y desplazar user-story de menor prioridad
Que mostrar:Opción CAPACIDAD:Tracking->Release BurndownAnalogíaPintor->Estoy pintando y me piden que frene para pintar otra cosa. Que hago?Pintor->Estoy pintando el living y además me piden que pinte la cocina.Interesados: Producto Owner, Equipo y Scrum MasterEs el problema de la capacidad (dado una velocidad)Opciones TipicasDO-NOTHING: Esperar al fin de la iteración en cursoSTOP: Interrumpir la iteración en curso y comenzar una nuevaLuego:Entrego lo que esta listo (Sprint Review)Dimensiono y priorizo el backlogComienzo un nuevo Sprint con lo prioritarioOtras Alternativas (trabajar con la capacidad)Aumentar la velocidad: Sumar gente al equipo (Indirectamente es un STOP+START)Sumar otro equipo en paraleloPuedo agregar un equipo?Que velocidad tiene?
Tener un resultado malo no es bueno, pero tener un resultado muy variable es aún peor (incluso con un resultado bueno)Muchas veces no podemos mejorar la velocidad, pero sí podemos trabajar sobre la capacidad. (+gente, +equipos)En un escenario “complejo” (múltiples equipos, remotos, etc.) la visibilidad es clave para poder atacar a tiempo los problemasEn nuestro caso, las herramientas nos ayudaron en la toma de decisiones:Punto centralizado de acceso a la informaciónÚnica información válidaRecuerda toda la historia (velocidad, cambios pedidos, etc.)Permite calcular fechas/compromisosFacilita la interacción a pesar de hablar distinto idioma y trabajar en distintos horariosGenera reportes que muchas veces son exigidos por el negocio