Referencias de SCRUM

Acerca de Scrum
Un Framework de gestin Scrum es un framework para un desarrollo incremental de productos de software utilizando uno o ms equipos multifuncionales, autoorganizados y conformados por un promedio de 7 miembros en cada equipo. Scrum proporciona una estructura de roles, reuniones, reglas y artefactos. Con Scrum los equipos son responsables de crear y adaptar sus procesos con este framework. Scrum emplea iteraciones de duracin fija llamadas Sprints, las cuales duran entre 2 semanas a 30 das como mximo. Con Scrum, los equipos se esfuerzan por construir un potencial entregable del producto adecuadamente probado en cada iteracin. Una alternativa al modelo de cascada La estrategia iterativa e incremental de Scrum contrasta con las fases tradicionales del desarrollo en cascada por la capacidad para desarrollar un subconjunto de caractersticas primarias de alto valor, incorporando un feedback temprano.

Figura 1: El tradicional desarrollo en cascada depende de una perfecta comprensin de los requerimientos del producto al principio y un mnimo de errores en cada etapa.

Figura 2: Scrum combina todas las actividades de desarrollo en cada iteracin, adaptndolo a cada realidad en intervalos de tiempo fijo.

El mayor y potencial beneficio de Scrum se aprecia en proyectos complejos que involucran creacin de conocimiento y colaboracin, tal como el desarrollo de un nuevo producto. Scrum es usualmente asociado al desarrollo de software orientado a objetos. Es tambin ampliamente utilizado para el desarrollo de productos tales como semiconductores, hipotecas, sillas de ruedas, etc. Hacer Scrum o tratando de hacerlo? La verificacin implacable que realiza Scrum de la realidad, expone restricciones disfuncionales en los individuos, equipos y organizaciones. Muchas personas dicen que aplicar Scrum modifica las piezas que requieren atravesar los impedimentos organizacionales y termina robndose a s mismo la mayora de los beneficios.

Roles en Scrum
Product Owner / Dueo del Producto Persona responsable de maximizar el retorno de la inversin (ROI) del esfuerzo de desarrollo. Responsable de la visin del producto Constantemente re prioriza el Product Backlog, realizando los ajustes necesarios en el tiempo de acuerdo a las expectativas, tales como el plan de lanzamiento o liberacin del entregable. Absuelve las preguntas acerca de los requerimientos. Acepta o rechaza cada entregable incremental del producto.

Decide si lo libera. Decide si contina el desarrollo. Considera los intereses de los stakeholder Puede contribuir como miembro del equipo. Tiene un rol de liderazgo.

Scrum Development Team / Equipo Scrum de desarrollo Es multifuncional (incluye miembros con habilidades en testing y otros con perfiles no tradicionales como analistas de negocios, expertos del dominio, etc.) Auto organizado / auto administrado, sin roles externamente asignados. Negocia los compromisos con el Product Owner, un solo sprint a la vez. Tiene autonoma en la forma como logra sus compromisos. Intensa colaboracin en el equipo. Es ms exitoso cuando estn ubicados en un nico ambiente de trabajo, principalmente para los primeros sprints. Tiene ms xito a largo plazo, con los miembros dedicados a tiempo completo. Scrum se mueve hacia el trabajo de un equipo de aprendizaje y evita trasladar las personas o separarlas entre los equipos. En promedio constituido por 7 2 miembros. Tiene un rol de liderazgo. ScrumMaster Facilita el proceso de Scrum. Ayuda a resolver problemas e impedimentos en la ejecucin del proyecto. Crea el ambiente de un equipo auto organizado Captura datos empricos para ajustar los estimados o proyecciones. Protege al equipo interferencias externas y distracciones. Hace respetar los periodos de tiempo establecidos. Mantiene visibles los artefactos de Scrum. Promueve el uso de prcticas mejoradas de ingeniera. No tiene autoridad sobre el equipo. Esto es por definicin. Cualquiera con autoridad sobre el equipo no es un ScrumMaster. Tiene un rol de liderazgo.

Reuniones Scrum
Todas las reuniones de Scrum son coordinadas por el ScrumMaster, quien no tiene poder de decisin en estas reuniones.

Sprint Planning Meeting / Reunion de Planeamiento de Sprint Al inicio de sprint, el Product Owner y el equipo sostienen una reunin de planeamiento (Sprint Planning Meeting) para negociar cuales de los tems del Product Backlog trataran de convertir en entregables (working product) durante el sprint. El Product Owner es responsable de establecer cuales de los tems son los mas importantes para el negocio. El equipo es responsable de definir y seleccionar la cantidad de trabajo que ellos creen que pueden implementar sin complicaciones (deuda tcnica / technical debt). El equipo obtiene el trabajo a desarrollar desde el Product Backlog y lo coloca en el Sprint Backlog.
Figura 3: Flujo de trabajo de Scrum.

Cuando los equipos reciben un trabajo complejo que tiene una incertidumbre inherente, deben trabajar juntos para estimar intuitivamente su capacidad para realizar los tems, mientras aprenden de los Sprint anteriores. Planear su capacidad de trabajo por horas y comprar sus estimados con lo realizado hace que el equipo trate de ser mas preciso y reducir la propiedad de sus compromisos. A menos que el trabajo sea realmente predecible, se deberan descartar tales prcticas dentro de los primeros sprints o evitarlos por completo. Hasta que un equipo haya aprendido como completar un incremental de producto potencialmente entregable, debera reducir la cantidad de funcionalidades en su compromiso. El fracaso de cambiar los viejos hbitos conduce a la deuda tcnica y una eventual muerte del diseo, como se muestra en la Figura 14. Si los tems ms importantes del Product Backlog no han sido refinados, una parte importante de la reunin de planeamiento (Planning Meeting) deber ser utilizada para hacer esto, como se describe en la seccin Reunin de Refinamiento de Backlog (Backlog Refinement Meeting). Hacia el final del sprint de planeamiento, el equipo desglosa los tems seleccionados en una lista inicial de tareas del sprint (Sprint Tasks) y elabora un compromiso final para hacer el trabajo. El tiempo mximo asignado (timebox) para un sprint de planeamiento de 30 das es 8 horas, es cual es reducido proporcionalmente para un Figura 4: El resultado del Sprint Planning Meeting es sprint mas corto. enviado al Product Backlog Items (PBIs) y a las Sprint Tasks
subordinadas.

Daily Scrum and Sprint Execution / Scrum diario y Ejecucin de Sprint Cada da a la misma hora y lugar, los miembros del equipo de desarrollo Scrum consumen alrededor de 15 minutos para dar un reporte a los otros miembros del equipo. Cada miembro del equipo brinda un resumen de lo que hizo el da anterior, lo q planea hacer durante el da y los problemas o dificultades q deber afrontar. Mantenerse de pie durante la revisin diaria (Daily Scrum) ayudar a hacer una reunin corta. Aquellos tpicos que requieran atencin adicional o especial pueden ser discutidos por los interesados al final de la revisin diaria y luego que todos los miembros han dado su reporte.

El equipo puede encontrar muy til mantener una lista de tareas del sprint actualizada (Sprint Task List), un diagrama de progreso del sprint (Sprint Burndown Chart) y una lista de problemas o issues. Durante la ejecucin del sprint, es comn identificar nuevas tareas necesarias para lograr los objetivos del sprint. Las dificultades causadas por los issues que estn ms all del control del equipo son consideradas Impedimentos organizacionales. Estas reuniones son de gran utilidad para el Product Owner. Pero cuando alguien ms asiste, como el jefe del equipo, el efecto arma invisible surge e impide la autoorganizacin y el liderazgo emergente. Las personas que no tienen una real experiencia de equipos autoorganizados no podrn identificar este problema. Por el contrario, un equipo que necesita experiencia adicional en requerimientos de productos, se beneficiar del aumento de la participacin del Product Owner, incluyendo las asistencias a las reuniones diarias. La reunin diaria de Scrum intenta romper los viejos hbitos de trabajar de manera separada. Sus miembros deberan mantenerse vigilantes ante indicios de las antiguas prcticas. Por ejemplo, que sea solamente el ScrumMaster quien habla es un sntoma que el equipo no ha aprendido a trabajar como una entidad autoorganizada. Sprint Review Meeting / Reunin de revisin de Sprint Despus de la ejecucin del Sprint, el equipo sostiene una reunin de revisin para demostrar un incremental del producto realizado al Product Owner y a todos los que estn interesados. Esta reunin debera realizar una demostracin del producto trabajando, no solo un reporte. Despus de la demostracin, el Producto Owner revisa los compromisos realizados en la reunin de planeamiento de Sprint y declara cuales de los tems considera como realizados o terminados. Por ejemplo, un tem de software que esta simplemente como cdigo completo no se le considera terminado, porque un software que no ha sido probado o testeado no es entregable. Los tems incompletos son devueltos al Product Backlog y re priorizados nuevamente por el Product Owner como candidatos para futuros Sprints. El ScrumMaster ayuda al Product Owner y los stakeholders a convertir su feedback en nuevos tems del Product Backlog para ser priorizados por el Product Owner. Frecuentemente, el nuevo alcance descubierto supera la tasa de desarrollo del equipo. Si el Product Owner siente que el alcance recientemente descubierto es ms importante las expectativas originales, el nuevo alcance desplaza al antiguo en el Product Backlog. La reunin de revisin de Sprint es la reunin apropiada para que asistan los stakeholders externos (y los usuarios finales). Esta es la oportunidad para inspeccionar y adaptar el producto de acuerdo a como va mostrndose, y refinarlo de manera iterativa para satisfacer todos los requerimientos. Los nuevos productos, particularmente los productos de software, son difciles de visualizar sin tener nada hecho. Muchos clientes necesitan tener una parte del software funcionando para darse cuenta de que es lo que ellos realmente quieren. El desarrollo iterativo, una estrategia dirigida por el valor del producto (valuedriven), permite la creacin de productos que no podran haber sido especificados utilizando una estrategia dirigida por planeamiento (plan-driven). Sprint Retrospective Meeting / Reunin de retrospectiva de Sprint Cada sprint finaliza con una retrospectiva. En esta reunin, el equipo reflexiona sobre su propio proceso, inspeccionan su comportamiento y toman acciones para adaptarlas en futuros sprints. Los ScrumMasters dedicados encontraran alternativas a las terribles y viejas reuniones que todos esperaban. Una profunda retrospectiva requiere un ambiente de seguridad psicolgica que no se encuentra en la mayora de las organizaciones. Sin seguridad, la discusin en retrospectiva evitara los temas desagradables o terminar en hostilidad y buscar culpables. Un tpico impedimento para una completa transparencia en el equipo es la presencia de personas que dirigen una evaluacin de rendimiento. Otro impedimento para una retrospectiva exhaustiva y perspicaz es la tendencia de las personas a saltar a conclusiones y proponer acciones demasiado rpido. Agile Retrospectives, el libro ms popular en este tema, describe una serie de pasos para aterrizar este proceso: Establecer las bases, obtener la informacin, generar ideas, decidir que hacer, cerrar la retrospectiva. Otra gua recomendada para ScrumMasters es The Art of Focused Conversations, que desglosa el proceso en pasos similares: Objetivo, reflexivo, interpretativo y decisional (ORID).

Un tercer impedimento para la seguridad psicolgica es la distribucin geogrfica. Los equipos geogrficamente dispersos usualmente no colaboran tan bien como aquellos que estn en un mismo ambiente de trabajo. La retrospectiva usualmente expone los impedimentos organizacionales. Una vez que un equipo ha resuelto los impedimentos dentro de su influencia inmediata, el ScrumMaster deber trabajar para expandir esa influencia, reduciendo los impedimentos de la organizacin. El ScrumMaster deber utilizar una variedad de tcnicas para facilitar la retrospectiva, incluyendo la escritura en silencio, lneas de tiempo e histogramas de satisfaccin. En todos los casos, el objetivo es lograr una comprensin comn de mltiples perspectivas y desarrollar acciones que tomar el equipo en el siguiente nivel. Backlog Refinement Meeting / Reunin de Refinamiento de Backlog La mayora de los tems del Product Backlog (PBIs) necesitan un refinamiento inicial debido a que son demasiado extensos y de escasa comprensin. Los equipos han encontrado til tomar un tiempo extra, fuera de la ejecucin del Sprint Sprint Execution para ayudar a preparar el Product Backlog para la siguiente reunin de planeamiento. En esta reunin (Backlog Refinement Meeting), los equipos estiman la cantidad de esfuerzo que debern realizar para completar los tems del Product Backlog y proporcionar informacin tcnica adicional para ayudar al Product Owner a establecer prioridades. Los grandes tems son segmentados y aclarados, considerando las preocupaciones tcnicas y de negocio. Algunas veces un subconjunto del equipo, en coordinacin con el Product Owner y algunos stakeholders, podrn preparar y dividir los tems del Product Backlog antes de involucrar a todo el equipo en la estimacin. Un ScrumMaster calificado puede ayudar al equipo a identificar delgadas porciones verticales de trabajo que an tiene valor para el negocio, mientras promueven una rigurosa definicin de terminado que incluye un adecuado testing y refactoring. Es comn escribir los tems del Product Backlog en un formato de User Story. En esta estrategia, los tems del Product Backlog demasiado grandes se les conoces como epics (picas). El desarrollo tradicional desglosa las caractersticas del producto en tareas horizontales (similar a las fases de cascada) que no pueden ser priorizadas de manera independiente y no proporcionan valor para el negocio desde la perspectiva del cliente. Este hbito es difcil de cambiar. La agilidad requiere aprender a dividir grandes picas en user stories que representen caractersticas muy pequeas del producto. Por ejemplo, en una aplicacin de registros mdicos la pica mostrar el contenido completo de los registros de alergia de un paciente al mdico produjo el user story mostrar o no cualquier registro de alergia que exista. Si bien los ingenieros haban previsto retos tcnicos significativos analizando los aspectos internos de los registros de alergia, la presencia de alguna alergia era lo ms importante que el mdico necesita saber. La colaboracin entre la gente de negocios y personal tcnico para dividir esta pica produjo un user story que represent el 80% del valor de negocio para el 20% del esfuerzo de la pica original. Dado que la mayora de los clientes no utiliza muchas de las caractersticas de los productos, es recomendable dividir las picas con el fin de entregar primero los user story de mayor valor. Mientras se retrasa la entrega de caractersticas de menor valor es probable que se realice un re trabajo, lo cual es mejor que no hacer ningn trabajo. La reunin de refinamiento de backlog carece de un nombre oficial y tambin ha sido llamado Backlog Grooming, Backlog Maintenance o Story Time

Figura 5: Durante el Backlog Refinement, los grandes items del Product Backlog (usualmente llamados picas) cerca del top del Product Backlog son divididos en delgadas caracteristicas verticales (stories), y no en una implementacin horizontal por fases.

Scrum Artifacts
Product Backlog
Figura 6: Product Backlog

Lista de ranking forzado de las funcionalidades deseadas. Visible para todos los stakeholders Cualquier stakeholder (incluyendo el equipo) puede agregar tems Constantemente repriorizado por el Product Owner Los tems arriba del ranking son ms granulares que los tems que estn al final Actualizado durante el Backlog Refinement Meeting

Product Backlog Item (PBI) Especifica el Que ms que el Cmo de una caracterstica centrada en el cliente Escrito a menudo en forma de User Story Tiene una amplia definicin de producto hecho para prevenir la deuda tcnica Puede tener un criterio de aceptacin especfico por cada tem. El esfuerzo es estimado por el equipo, idealmente en unidades relativas (ejemplo story point) El esfuerzo es ms o menos de 2-3 personas durante 2-3 das, o menor para equipos avanzados

Figura 7: Un PBI representa una caracterstica centrada en el cliente, usualmente requiere varias tareas para lograr la definicin de realizado.

Sprint Backlog Conformado por los PBI enviados y negociados entre el equipo y el Product Owner durante el Sprint de planeamiento. El alcance del compromiso se fija durante la ejecucin del sprint. Las tareas iniciales son identificadas por el equipo durante el sprint de planeamiento. El equipo descubrir tareas adicionales necesarias para lograr el compromiso de alcance fijado durante la ejecucin del sprint. Visible al equipo. Se le hace referencia durante las reuniones diarias de Scrum.

Figura 8: Sprint Backlog is often represented with an information radiator such as a physical taskboard.

Figure 9: Sprint Backlog may also be represented electronically in a collaboration tool such as ScrumWorks Pro.

Sprint Task Especifica Cmo lograr los Que del PBI Requiere como mximo un da de trabajo El esfuerzo restante es reestimado diariamente, por lo general en horas. Durante la ejecucin del sprint, una persona especfica puede ser voluntaria para ser responsable de una tarea. Es propiedad del equipo, y se espera la colaboracin de todos.

Figure 10: Sprint tasks required to complete one backlog item require a mix of activities no longer done in separate phases (e.g., requirements elicitation, analysis, design, implementation, deployment, testing).

Sprint Burndown Chart Indica el total de horas restantes de tareas del equipo en un sprint. Re estimado diariamente, por lo que podra subir antes de bajar. Diseado para facilitar la auto organizacin del equipo. Interesantes grficas, tales como detalles por persona o lneas de tendencia, tienden a reducir la efectividad y promover la colaboracin. Pareca una buena idea en los inicios de Scrum, pero en la prctica ha sido a menudo mal utilizado como reporte de gestin, invitando a la intervencin. El ScrmMaster debera descontinuar su uso si esta herramienta se convierte en impedimento para la auto organizacin del equipo.

Figure 11: Sprint Burndown Chart

Product / Release Burndown Chart Sigue la trayectoria del esfuerzo restante del Product Backlog de un sprint al siguiente. Puede utilizar unidades relativas tales como Story Points para el eje Y Muestra las tendencias histricas para hacer ajustes a las proyecciones.

Figure 12: A Release Burndown Chart variation popularized by Mike Cohn.5 The red line tracks PBIs completed over time (velocity), while the blue line tracks new PBIs added (new scope discovery). The intersection projects release completion date from empirical trends.

Scaling
Malas noticias. Es difcil Scrum dirige los riesgos de tecnologa y requerimientos inciertos agrupando personas de distintas disciplinas en un solo equipo (idealmente en una misma rea de trabajo) para maximizar la comunicacin, visibilidad y confianza. Cuando los requerimientos son inciertos y los riesgos de la tecnologa son altos, agregar personas hace que la situacin empeore, as como agrupar personas por componentes de arquitectura.

Figura 13: Las vas de comunicacin se incrementan al cuadrado del tamao del equipo.

Buenas noticias: Equipos por caractersticas puede ayudar La estrategia ms exitosa para este problema ha sido la creacin de equipos completamente multifuncionales, capaces de operar en todas las capas de la arquitectura con la finalidad de entregar caractersticas centradas en el cliente. En un gran sistema, esto requiere adquirir nuevas capacidades. Como equipos enfocados en el aprendizaje, en lugar de pequeas eficiencias en el corto plazo, pueden ayudar a crear una organizacin de aprendizaje.

Figura 14: Equipos de caracteristicas aprenden a abarcar componentes de arquitectura.

Ms malas noticias: Esto es an difcil Las grandes organizaciones son particularmente cuestionadas cuando se trata de agilidad. La mayora no lo ha logrado superar tratando de hacer Scrum. Los ScrumMaster en las grandes organizaciones

debern reunirse con otros regularmente, para promover la transformacin a travs de una lista visible de impedimentos organizacionales, y leer libros tales como Scaling Lean & Agile Development.

Prcticas relacionadas
Lean Scrum es un framework de gestin de propsito general que coincide con el movimiento gil en desarrollo de software, el cual es parcialmente inspirado por estrategias de fabricacin Lean tales como el sistema de Produccin de Toyota. eXtreme Programming (XP) Si bien Scrum no sugiere prcticas especficas de ingeniera, los ScrumMasters son responsables de promover el rigor en la definicin de terminado. Los tems que son considerados terminados debern estar terminados. Las pruebas de regresin automatizadas previenen historias de vampiros que salen de sus tumbas (resultados inesperados). El diseo, la arquitectura e infraestructura deben surgir con el tiempo, sujeto a continuas reconsideraciones y refinamientos, en lugar de ser finalizado al principio, cuando no se sabe nada. El ScrumMaster puede inspirar a su equipo a aprender prcticas de ingeniera asociadas con XP: Integracin continua (pruebas automatizadas continuas), Test-Driven Development (TDD), refactorizacin despiadada constante, programacin de pares, verificaciones frecuentes, etc. La aplicacin informada de estas prcticas previene la deuda tcnica.

Figura 15: La lnea verde representa el objetivo general de los mtodos agiles: entrega temprana y sostenible de caractersticas de valor. Aplicar Scrum apropiadamente implica aprender a satisfacer la definicin rigurosa de hecho para prevenir la deuda tcnica.

Auto Organizacin de equipos

Los equipos comprometidos superan los equipos manipulados Durante la ejecucin del sprint, los miembros del equipo desarrollan un inters intrnseco en las metas compartidas y aprenden a gestionar a los dems para lograrlos. La tendencia humana natural de rendir cuentas a un grupo de compaeros contradice aos de hbitos de los trabajadores. Permitir a un equipo que sea auto motivado en lugar de ser manipulado a travs de recompensas y castigos, contradice aos de hbitos de los gerentes. Las habilidades de observacin y persuasin de los ScrumMasters incrementa la probabilidad de xito a pesar de la incomodidad inicial. Retos y Oportunidades Los equipos autoorganizados pueden radicalmente superar ampliamente los equipos gestionados de manera tradicional. Los grupos de tamao familiar se auto organizan naturalmente cuando se cumplen las siguientes condiciones: Los miembros se comprometen a objetivos claros en el corto plazo. Los miembros pueden medir el progreso del grupo. Los miembros pueden observar la contribucin de los dems. Los miembros se sienten seguros de poder manifestar sus comentarios abiertamente. El psiclogo Bruce Tuckman describe las etapas del desarrollo del grupo como formacin, discusin, normatividad, realizacin. La auto organizacin ptima toma tiempo. En las primeras iteraciones el

equipo puede trabajar peor que si lo hubiera hecho como un equipo de trabajo gestionado de manera tradicional. Los equipos heterogneos superan a los equipos homogneos en los trabajos complejos, pero tambin experimentan ms conflictos. Los desacuerdos son normales y saludables en un equipo comprometido; el rendimiento del equipo ser determinado por la forma como el equipo maneja estos conflictos. La teora de la manzana podrida sugiere que un solo individuo negativo (retencin de esfuerzo del grupo, expresas sentimientos negativos o violar normas interpersonales importantes) puede afectar mucho al rendimiento de todo un grupo. Tales individuos son raros, pero su impacto es grande si el equipo se resiste a removerlo. Esto puede ser parcialmente mitigado dando a los equipos una mayor influencia sobre aquellos que se le une. Otros individuos que tienen un rendimiento inferior en un escenario de jefe / compaero (debido a ser micro gestionados o tener pocos desafos) brillaran en un equipo de Scrum. La auto organizacin es obstaculizada por condiciones como la distribucin geogrfica, la dinmica jefe/trabajador, miembros a tiempo parcial e interrupciones no relacionadas a los objetivos del sprint. La mayora de los equipos se beneficiaran de un ScrumMaster a tiempo completo que trabaja duro para mitigar este tipo de obstculos.

Cuando es apropiado aplicar Scrum?

Scrum est diseado para el tipo de trabajo que las personas han encontrado inmanejable utilizando procesos definidos requerimientos inciertos combinados con riesgos impredecibles de implementacin de tecnologas. Al decidir aplicar Scrum como una alternativa a las estrategias plan-driven como las descritas por el PMBOK, considerar si los mecanismos resaltados estn bien comprendidos o si el trabajo depende de la creacin de conocimiento y colaboracin. Por ejemplo, Scrum no fue diseado inicialmente para tipos repetibles de produccin y servicios. Considerar tambin si hay el compromiso suficiente para crecer como un equipo auto organizado.

Figura 16: Scrum, an empirical framework, is appropriate for work with uncertain requirements and/or uncertain technology issues.

Acerca del Autor

Michael James aprendi a programar hace mucho tiempo. Trabaj directamente con Ken Schwaber para ser un Scrum Trainer. Entrena a tcnicos, gerentes y ejecutivos en optimizer la entrega de valor al negocio. Invita a enviar sus comentarios a mj@collab.net o http://twitter.com/michaeldotjames

About CollabNet
CollabNet elabora ScrumWorks Basic y Pro productos libres y de bajo costo para ayudar a gestionar un desarrollo aplicando Scrum. CollabNet tambin produce TeamForge, una plataforma de aplicacin de gestin gil para el ciclo de vida (Agile Application Lifecycle Management - ALM) optimizada para trabajar con Subversion, sisatema de control de versiones open-source con millones de usuarios. CollabNet proporciona capacitacin y consultora en Scrum. Visita http://www.collab.net/scrumtraining para ms detalles.