Scrum

Introducción a Scrum

Scrum es un framework para el desarrollo y mantenimiento de proyectos complejos.

¿Qué es el cuerpo de conocimiento de Scrum?

• Es una compilación de los mas recientes métodos y las mejores practicas implementadas por sus practicantes y expertos.
• Además, proporciona las pautas para la implementación exitosa de Scrum.
• Es el framework ágil mas popular para la gestión y desarrollo de proyectos.
• Proporciona un framework integral que incluye los principios, aspectos y procesos del framework de Scrum.

Descripción general de Scrum

Un proyecto de Scrum consiste en un esfuerzo de colaboración para crear un nuevo, producto, servicio u otro resultado tal como se define en la Declaración de la visión del proyecto.

Los proyectos se ven afectados por limitaciones de

• Tiempo
• Costos
• Alcance
• Calidad
• Recursos
• Capacidades organizacionales
• Otras limitaciones

Que dificultan su planificación, ejecución, administración y por ultimo, su éxito.

Sin embargo la implementación exitosa de los resultados de un proyecto terminado le proporciona ventajas económicas considerables a una organización.

¿Qué es Scrum?

Scrum es un de los frameworks agiles mas populares.

Es un framework adaptable, iterativo, rápido, flexible y eficaz, diseñado para ofrecer un valor considerable en forma rápida a lo largo del proyecto.

Scrum garantiza transparencia en la comunicación y crea un ambiente de responsabilidad colectiva y de progreso continuo.

El framework de Scrum esta estructurado de tal manera que es compatible con el desarrollo de productos y servicios en todo tipo de industrias y en cualquier tipo de proyecto, independientemente de su complejidad.

¿Por que Scrum es mejor en comparación a otras técnicas de gestión de proyectos?

Una fortaleza clave de Scrum radica en el uso de equipos interfuncionales, auto-organizados, y empoderados que divide su trabajo en ciclos de trabajo cortos y concentrados llamados sprints.

Piensa en Sprints como breve lapsos de tiempo en los que se debe hacer cierta cantidad de trabajo.

Como puedes ver, el ciclo de Scrum empieza con una reunión de stakeholders (clientes), durante la cual se crea la visión del proyecto.

Después, el Product Owner desarrolla un Backlog Priorizado del Producto que contiene una lista de requerimientos por orden de importancia en forma de una historia de usuario.

Cada sprint empieza con una reunión de planificación del sprint durante la cual se consideran las historias de usuario de alta prioridad se consideran para su inclusión en el sprint.

Un sprint generalmente tiene una duración de una a cuatro semanas durante las cuales el Equipo de Scrum trabaja en la creación de entregables potencialmente enviables o incrementos de producto.

Durante el sprint, se llevan a cabo Daily Standups muy breves y concretos, donde los miembros del equipo discuten el progreso diario.

Hacia el final del spring, se lleva a cabo una reunión y revisión del spring, durante la cual el Product Owner y los stakeholders relevantes se les proporciona una demostración de los entregables.

El Product Owner acepta los entregables solo si cumplen los criterios de aceptación predefinidos.

El ciclo del sprint termina con una reunión de retrospectiva del sprint donde el equipo analiza las formas de mejorar los procesos y el rendimiento a medida que avanzan al siguiente sprint.

Historia de Scrum

El framework tuvo sus inicios en la década de 1980.

A mediados de los 80, Hirotaka Takeuchi y Ikujiro Nonaka definieron una estrategia de desarrollo de producto flexible e incluyente donde el equipo de desarrollo trabaja en unidad para alcanzar un objetivo común.

Describieron un método innovador para el desarrollo de productos al que llamaron enfoque holístico o “rugby”, donde un equipo intenta llegar hasta el final como una unidad, pasando el balon hacia atrás y adelante.

Beneficios de usar Scrum

• Adaptabilidad
  • La “adaptabilidad” es el primer beneficio que quiero señalar.
  • Los principios de Scrum sobre el control del proceso empírico y la entrega iterativa hace que los proyectos sean adaptables y abiertos a la incorporación del cambio cuando este ocurra.
  • Los procesos de Scrum están diseñados para aceptar el cambio.
• Centrado en el cliente
  • Uno de los beneficios para los stakeholders es que Scrum esta “centrado en el cliente”.
  • El énfasis en el valor del negocio y en tener un enfoque de colaboración que incluye a los stakeholders, asegura un framework orientado al cliente en los proyectos gestionados con Scrum.
• Entrega continua de valor
  • La “entrega continua de valor” es un beneficio adicional que resulta de su enfoque en el cliente.
  • En Scrum, el proceso iterativo permite la entrega continua de valor mediante el proceso de enviar entregables.
  • Cada spring produce un producto, servicio, o resultado deseado potencialmente enviable.
• Entrega anticipada de valor
  • La “entrega anticipada de valor” es otro beneficio empresarial estrechamente relacionado al uso de Scrum.
  • No solo es la entrega continua de valor; el proceso de crear el backlog priorizado del producto asegura que los requerimientos de mas alto valor para el cliente se cumplan primero.
• Retroalimentación continua
  • Tanto el cliente como el equipo del proyecto se benefician de la “retroalimentación continua”.
  • En Scrum, la retroalimentación continua se proporciona a través de los procesos de realizar daily standup, demostrar y validar el sprint.
• Transparencia
  • La “retroalimentación continua” contribuye a otra de las ventajas fundamentales, la “transparencia”.
  • En un proyecto gestionado con Scrum, todos los centros de información, tales como el Scrumboard y el Sprint burndown chart, se muestran y se actualizan constantemente, lo cual lleva a un ambiente de trabajo abierto.
  • Las reuniones de revisión del sprint muestran los productos potencialmente enviables a los stakeholders, manteniéndolos completamente informados sobre el estado actual y sobre el avance del proyecto.
• Ambiente de alta confianza
  • La transparencia mejora el importante beneficio de “ambiente de alta confianza”.
  • Los procesos de realizar el daily standup y retrospectiva del sprint promueven la transparencia y la colaboración.
  • Esto conduce a un entorno de trabajo de alta confianza que reduce la fricción entre los empleados.
• Mejora continua
  • La adaptabilidad y la transparencia de Scrum crean un ambiente de “mejora continua”.
  • A medida que avanza el proyecto, los entregables mejoran progresivamente sprint tras sprint, con cambios y mejoras que se incluyen y se gestiona a través del proceso de refinar el backlog priorizado del producto.
• Ritmo sostenible
  • Los procesos de Scrum están diseñados para que las personas involucradas pueda trabajar a un ritmo que puedan mantener en forma indefinida.
• Proceso de desarrollo eficiente
  • En Scrum, se ha observado que el time-boxing y disminución del trabajo no esencial lleva a mayores niveles de eficiencia.
• Motivación
  • Los procesos de realizar daily standup y retrospectiva del sprint conducen a mayores niveles de motivación entre los empleados.
• Resolución de problemas de forma mas rápida
  • La “resolución de problemas de forma mas rápida” es uno de los beneficios mas importantes del uso de Scrum en los proyectos.
  • La colaboración y co-ubicación de equipos interfuncionales conducen a la resolución de problemas con mayor rapidez
• Entregables efectivos
  • El proceso de crear el backlog priorizado del producto, las revisiones periódicas después de la creación de entregables aseguran entregas eficientes al cliente.
• Responsabilidad colectiva
  • El proceso de comprometer historias de usuario permite que los miembros del equipo hagan suyo el proyecto y que su trabajo lleve a una mejor calidad en Scrum.
• Alta velocidad
  • Un framework de colaboración permite a los equipos interfuncionales altamente cualificados alcanzar todo su potencial y una alta velocidad.
• Ambiente innovador
  • Los procesos de retrospectiva de sprint y retrospectiva del proyecto crean un ambiente de introspección, aprendizaje y capacidad de adaptación, que conllevan a un ambiente de trabajo innovador y creativo.

Principios Scrum

¿Por que son importantes estos principios?

Los principios de Scrum son las principales pautas para la aplicación del framework de Scrum y siempre se deben utilizar en todos los proyectos de Scrum.

Los 6 principios de Scrum son:

• Control de proceso empírico
  • Este principio enfatiza la filosofía central de Scrum con base a las tres ideas principales de transparencia, inspección y adaptación.
• Auto-organización
  • Se enfoca en los trabajadores de hoy en día, que entregan un valor considerablemente mayor cuando se fomenta la auto-organización en vez de trabajar bajo el estilo de comando y control de la gestión tradicional de proyectos.
• Colaboración
  • Se centra en las tres dimensiones básicas relacionadas con el trabajo colaborativo: conocimiento, articulación y apropiación.
  • También fomenta la gestión de proyectos como un proceso de creación de valor compartido con equipos trabajando e interactúan conjuntamente para ofrecer el mayor valor.
• Priorización basada en valor
  • Este principio poner de relieve el enfoque de Scrum para ofrecer el máximo valor de negocio desde el principio del proyecto hasta su conclusión.
• Time-boxing
  • Este principio hace énfasis en el tiempo como un limitante en Scrum.
  • El time-boxing se utiliza para ayudar a manejar eficazmente la planificación y ejecución del proyecto.
  • Los elementos con time-box en Scrum incluyen sprints, daily standups, reuniones de planificación del sprint y reuniones de revisión del sprint.
• Desarrollo iterativo
  • Este principio define el desarrollo iterativo y hace énfasis en como gestionar mejor los cambios y crear productos que satisfagan las necesidades del cliente.
  • También delinea las responsabilidad del Product Owner y las de la organización relacionadas con el desarrollo iterativo.

Los principios de Scrum se pueden aplicar a cualquier tipo de proyecto en cualquier organización y siempre se deben cumplir a fin de garantizar la aplicación efectiva del framework de Scrum.

Los principios de Scrum no son negociables y deben ser aplicados tal como se especifica en la Guía SBOK.

El mantener los principios intactos y usarlos apropiadamente infunde confianza en el framework de Scrum respecto al cumplimiento de los objetivos del proyecto.

Por otra parte, los aspectos y procesos de Scrum pueden modificarse para cumplir con los requisitos del proyecto o la organización.

Aspectos de Scrum

Los aspectos de Scrum se deben abordar y gestionar a lo largo de un proyecto de Scrum.

Los cinco aspectos de Scrum que discutiremos en este módulo son:

• Organización

  • Roles y responsabilidades en un proyecto Scrum

    • Definir los roles y las responsabilidad asegura la implementación exitosa de Scum.
    • Los roles de Scrum se dividen en dos amplias categorías: Roles centrales y roles no centrales.
    • Los roles centrales son aquellos que se requieren obligatoriamente para crear el producto o servicio del proyecto.
    • Las personas a quienes se les asignan los roles centrales están plenamente comprometidas con el proyecto. Son responsables del éxito de cada iteración del proyecto y del proyecto en su conjunto.
    • Los roles centrales se asignan al Product Owner, Scrum Master y Equipo Scrum.
    • Ahora que hemos visto que hay algunos nombres inevitables relacionados a los roles centrales conozcamos uno a uno y veamos lo que hacen en un proyecto Scrum.

  • Product Owner

    • Product Owner es la persona responsable de lograr el máximo valor empresarial para el proyecto.
    • Es responsable de articular los requerimientos del cliente y de mantener la justificación del negocio para el proyecto.
    • El Product Owner representa la voz del cliente.

  • Scrum Master

    • El Scrum Master es un facilitador que asegura que el Equipo Scrum cuente con un ambiente propicio para completar el proyecto con exito.
    • El Scrum Master guía, facilita y enseña las practicas de Scrum a todos los involucrados en el proyecto.
    • El Scrum Master elimina los impedimentos que pueda tener el equipo y se asegura que se estén siguiendo los procesos de Scrum.

  • Scrum Team

    • Son los que hacen el trabajo.
    • El equipo de Scrum es el equipo o grupo de personas responsables de entender los requerimientos especificados por el Product Owner y crear los entregables del proyecto.

  • Los roles no centrales son opcionales y pueden incluir a miembros de los equipos que estén interesados en el proyecto. No tiene ningún rol formal en el equipo del proyecto, pero interactúan con el equipo. Sin embargo, pueden no ser responsables del éxito del proyecto.

  • Los roles no centrales deben tenerse en cuenta en cualquier proyecto de Scrum.

  • Los roles desempeñados por Scrum Master, Product Owner, Scrum Team y la iteración de esos roles, y la forma en que cada uno de ellos contribuye para cumplir con los requisitos del cliente se resumen así:

  • El aspecto de la organización de Scrum también aborda los requerimientos sobre la estructura del equipo para implementar Scrum en programas y portafolios.

• Justificación del negocio
  • Es importante que una organización lleve a cabo una evaluación adecuada del negocio antes de iniciar cualquier proyecto.
  • Esto ayuda a los tomadores de decisiones clave a entender la necesidad de cambio en la empresa o de un nuevo producto o servicio, la justificación para seguir adelante con un proyecto y su viabilidad.
  • En Scrum, la justificación del negocio se basa en el concepto de entrega impulsada por el valor.
  • Una de las características claves de cualquier proyecto es la incertidumbre sobre los resultados. Es imposible garantizar el éxito de un proyecto, independientemente del tamaño o la complejidad del mismo.
  • Considerando esta inseguridad de lograr el éxito, Scrum busca iniciar la entrega de resultados lo antes posible en el proyecto.
  • Esta entrega tempana de resultados, y por lo tanto de valor, proporciona una oportunidad para la reinversión y demuestra el valor de los stakeholders interesados.
  • Además, la adaptabilidad de Scrum permite que los objetivos y procesos cambien si cambia la justificación del negocio.
  • Es importante señalar que, si bien el Product Owner es el responsable principal de la justificación del negocio, otros miembros del equipo también contribuyen considerablemente.
• Calidad
  • En Scrum, la calidad se define como la capacidad con la que cuenta el producto finalizado o los entregables para cumplir con los criterios de aceptación y de alcanzar el valor de negocio que el cliente espera.
  • Para garantizar que un proyecto cumpla con los requisitos de calidad, Scrum adopta un enfoque de mejora continua mediante el cual el equipo aprender de sus experiencias y de la participación de los stakeholders para mantener actualizado el backlog priorizado del producto con cualquier cambio en los requisitos.
  • El backlog priorizado del producto nunca se finaliza sino hasta el cierre o conclusión del proyecto. Además, cualquier cambio en los requisitos debe reflejar los cambios en el entorno empresarial, ya sean internos o externos y permite al equipo trabajar continuamente y adaptarse para lograr dichos requerimientos.
  • Mediante pruebas constantes, Scrum requiere que el trabajo se haga en forma incremental mediante sprints en vez de esperar hasta el final para producir entregables.
  • Eso significa que los errores se solucionen de inmediato en vez de posponerse hasta el final del proyecto.
  • Además, las tareas importantes relacionadas a la calidad, como el desarrollo, pruebas y documentación, se completan como parte del mismo sprint por el mismo equipo.
  • Esto asegura que la calidad sea inherente a cualquier entregable que se crea como parte de un sprint.
  • A tales entregables de proyectos Scrum, que son potencialmente enviables, se les conoce como “terminados”.
  • Por ejemplo, si los cliente internos no están satisfechos con un producto en términos de calidad, los problemas se pueden incluir en el backlog priorizado del producto. Este tipo de problemas se atenderán durante los sprints y el equipo intentara corregirlos a fin de no comprometer la calidad.
  • Por lo tanto, la mejora continua con pruebas repetitivas optimiza la probabilidad de alcanzar los niveles esperados de calidad de un proyecto Scrum.
  • El dialogo constante entre el equipo principal de Scrum y los stakeholders, incluyendo a clientes y usuarios, junto con incrementos reales del producto que se entregan al final de cada sprint, aseguran que la brecha entre las expectativas de los cliente del proyecto y los verdaderos entregables se reduzca constantemente.
• Cambio
  • Cada proyecto, independientemente del metodo o framework que se utilice, esta expuesto a cambios. Es importante que los miembros del equipo del proyecto entiendan que los procesos de Srum están diseñados para aceptar el cambio.
  • Las organizaciones deben tratar de maximizar los beneficios que se deriven de los cambios y minimizar cualquier impacto negativo a través de procesos de gestión de cambio diligentes, según los principio de Scrum.
  • Un principio fundamental de Scrum es su reconocimiento de lo siguiente:
    • Primero los stakeholders (por ejemplo los cliente, usuarios y patrocinadores) cambian su opinión acerca de lo que quieren y lo que necesitan durante el proyecto (a esto se le conoce en ocasiones como “requisitos volátiles”).
    • Segundo, es muy difícil, si no es que imposible, que los stakeholders definan todos los requisitos al inicio del proyecto. Los proyectos Scrum aceptan los cambios mediante el uso de sprints breves e iterativos que incorporan la retroalimentación del cliente en cada entregable del sprint.
  • Esto permite que el cliente interactúe regularmente con los miembros del Equipo Scrum, que vea los entregables a medida que estén listos y que cambie los requisitos si es necesario antes del siguiente sprint. Asimismo, los equipos de gestión de programa o portafolio pueden responder a las solicitudes de cambio pertenecientes a los proyecto Scrum aplicables a su nivel.
• Riesgo
  • El riesgo es definido como un evento incierto o serie de eventos que pueden afectar los objetivos de un proyecto y pueden contribuir a su éxito o fracaso.
  • A los riegos que pueden tener un impacto positivo en el proyecto se les conoce como oportunidades, mientras que las amenazas son riesgos que pudieran afectar negativamente al proyecto.
  • Por ejemplo, consideremos una situación en la que uno de los principales inversionistas de un proyecto se retracta durante un momento crucial. Esto es un riesgo que afecta el proyecto de una manera negativa. Sin embargo, si el proyecto encuentra a un mejor inversionista dispuesto a invertir mas, se puede considerar como una oportunidad.
  • La gestión de riesgos debe ser proactiva. Es un proceso iterativo que debe comenzar al inicio del proyecto y continuar a lo largo del ciclo de vida del mismo.
  • El proceso de gestión de riesgos debe seguir algunos pasos estandarizados para asegurar que estos se identifiquen y evalúen y que se determine un curso adecuado de acción y se procesa en consecuencia.
  • Los riesgos deben ser identificados, evaluados y atendido con base a dos factores: la probabilidad de ocurrencia de cada riesgo y el posible impacto en el caso de tal ocurrencia.
  • Los riesgos con una alta probabilidad y valor de impacto se determinan multiplicando ambos factores y deben ser atendidos primero que aquellos con un valor relativamente bajo.
  • En general, una vez que se detecta un riesgo, es importante entender el mismo con relación a las causas probables y los efectos potenciales si se produce el riesgo.

Procesos de Scrum

Los procesos de Scrum abordan las actividades especificas y el flujo de un proyecto de Scrum.

En total hay 19 procesos agrupados en 5 fases. Estas fases se presentan en los capítulos del 8 al 12 de la Guía SBOK.

Estas cinco fases describen cada proceso a detalle, incluyendo las entradas, herramientas y salidas de correspondientes.

También, en cada proceso, algunas entradas, herramientas y salidas son obligatorias y otras son designadas como opcionales.

La decisión de incluir cualquier entrada, herramienta o salida opcional depende del proyecto, organización o industria especifica.

Las entradas y salidas señaladas como obligatorias son importantes para la implementación exitosa de Scrum en cualquier organización.

Veamos de cerca las fases y procesos:

Inicio es la primera fase y los procesos que forman de la fase de inicio son los siguientes:

• Primer proceso - Crear la visión del proyecto
  • En este proceso se revisa el caso de negocio del proyecto para crear una declaración de la visión del proyecto que servirá de inspiración y proporcionara un enfoque a todo el proyecto. En este proceso se identifica al Product Owner.
• Segundo proceso - Identificar al Scrum Master y stakeholder(s)
  • En este proceso es donde se identifica al Scrum Master utilizando criterios de selección específicos.
• Tercer proceso - Formar el Equipo de Scrum
  • En este proceso se identifican a los miembros del Equipo Scrum.
  • Normalmente, el Product Owner es el responsable principal de la selección de los miembros del equipo, pero con frecuencia lo hace en colaboración con el Scrum Master.
• Cuarto proceso - Desarrollar épicas
  • En este proceso la declaración de visión del proyecto sirve como base para el desarrollo de épicas, que son historias de usuarios grandes, sin refinar.
  • Se pueden llevar a cabo reuniones de grupos de usuarios para desarrollar épicas.
• Quinto proceso - Crear un backlog priorizado
  • En este proceso se refina y se crean las épicas y después se priorizan para crear el backlog priorizado del producto del proyecto.
  • A este punto también se establecen los criterios de terminado.
• Sexto proceso - Realizar la planificación del lanzamiento
  • En este proceso el equipo principal de Scrum revisa las historias de usuario en el backlog priorizado del producto para desarrollar un cronograma de planificación del lanzamiento que esencialmente es un programa de implementación por fases que se puede compartir con los stakeholders del proyecto.

Planificación y estimación es la segunda fase, y estos son los procesos agrupados bajo esta fase:

• Primer proceso - Crear historias de usuario
  • Podemos ver que es este proceso se crean las historias de usuario y los criterios de aceptación de las historias de usuario.
  • Las historias de usuario generalmente las escribe el Product Owner y están diseñadas para asegurar que los requisitos del cliente están claramente representados y puedan ser plenamente comprendidos por todos los stakeholders.
  • Se pueden llevar a cabo de ejercicios de redacción de historias de usuario donde los miembros del Equipo Scrum desarrollan historias de usuario.
  • Estas se incorporan al backlog priorizado del producto.
• Segundo proceso - Estimar historias de usuario
  • En este proceso el equipo Scrum, con el apoyo del Scrum Master, estimas las historias de usuario e identifica el esfuerzo necesario para desarrollar la funcionalidad descrita en cada historia de usuario.
• Tercer proceso - Comprometer historias de usuario
  • En este proceso, el equipo Scrum se compromete a entregar una serie de historias de usuario en el sprint.
  • El resultado de este proceso son las historias de usuario comprometidas y el backlog del sprint.
• Cuarto proceso - Identificar tareas
  • En este proceso, las historias de usuario comprometidas se desglosan en tareas especificas y se compilan en una lista de tareas.
• Quinto proceso - Estimar tareas
  • En este proceso, el equipo de Scrum estima el esfuerzo necesario para hacer cada tarea en la lista.
• Sexto proceso - Actualizar el backlog del sprint
  • En este proceso, el equipo principal de Scrum actualiza el backlog del sprint con detalles de las tareas como parte de la reunión de planificación del sprint.

Implementar es la tercera fase, y estos son los procesos agrupados bajo esta fase:

• Primer proceso - Crear Entregables
  • En este proceso, el equipo Scrum trabaja en las tareas del Sprint backlog para crear los entregables del sprint.
  • Generalmente se utiliza un Scrumboard para dar seguimientos al trabajo y a las actividades que se llevan a cabo.
  • Los problemas que enfrenta el equipo Scrum pueden actualizarse en el impediment log.
• Segundo proceso - Daily Standup
  • Se lleve a cabo diariamente una reunión altamente focalizada con un time-box asignado y denominada: Daily Standup meeting.
  • Es un foro para que el equipo Scrum se ponga al día sobre sus progresos y sobre cualquier impedimento que pudieran estar enfrentando.
• Tercer proceso - Refinamiento del backlog priorizado del producto
  • En este proceso, constantemente se actualiza y refina el backlog priorizado del producto.
  • Se puede celebrar una reunión de revisión del backlog priorizado del producto, donde los cambios y actualizaciones al backlog se analizan y se incorporan al Backlog Priorizado del Producto, según corresponda.

Revisión y retrospectiva es la cuarta fase, y estos son los procesos agrupados bajo esta fase:

• Primer proceso - Demostrar y validar el sprint
  • En este proceso, el equipo Scrum demuestra los entregables del sprint al Product Owner y a los stakeholders relevantes durante una reunión de revisión del sprint.
  • El propósito de esta reunión es lograr la aprobación y aceptación del Product Owner respecto al producto o servicio.
• Segundo proceso - Retrospectiva de sprint
  • En este proceso, el Scrum Master y el equipo Scrum se reúnen para discutir la lecciones aprendidas durante el sprint. Dicha información se documenta como lecciones aprendidas que pudieran implementarse en futuros sprints.
  • Generalmente, como consecuencia de esta reunión pudieran resultar mejoras accionables aceptadas o recomendaciones actualizadas del Scrum Guidance Body.

Lanzamiento es la quinta fase, y estos son los procesos agrupados bajo esta fase:

• Primer proceso - Enviar entregables
  • En este proceso, se entregan a los interesados del negocio relevantes todos los entregables de las historias de usuario aceptadas en sprints previamente terminados .
  • La conclusión satisfactoria del sprint se documenta en un acuerdo de entregables funcionales.
• Segundo proceso - Retrospectiva de la liberación
  • En este proceso, en el cual se concluye el proyecto, los interesados del negocio y los miembros del equipo principal de Scrum se reúnen para reflexionar sobre el proyecto e identificar, documentar e internalizar las lecciones que se aprendieron.
  • Generalmente, dichas lecciones permiten documentar las mejoras accionables acordadas e implementarlas en futuros proyectos.

Ceremonias de Scrum

Las reuniones o ceremonias de Scrum tienen una función muy importante en la implementación eficaz del marco de trabajo de Scrum y son un medio clave para implementar los principios de Scrum.

Las reuniones importantes de Scrum y los procesos respectivos en los que se llevan a cabo estas reuniones son:

• Reunión de la visión del proyecto, se lleva a cabo como parte del proceso de Crear la visión del proyecto. En esta reunión se elabora una declaración de la visión del proyecto

• Reuniones con grupos de usuarios y reuniones de grupos de enfoque, se utilizan para desarrollar épicas y crear historias de usuario.

• Reuniones de planificación de la liberación, se llevan a cabo con el fin de crear un cronograma de planificación de la liberación.

• Reuniones del backlog priorizado del producto pueden se útiles para actualizar el backlog priorizado del producto con historias nuevas o modificando las ya existentes, o incluso eliminando o volviendo a priorizar ciertas historias, dependiendo de las necesidades de los principales interesados del negocio.

• Reunión de planificación del sprint es utilizada por los equipos de Scrum para estimar y comprometer historias de usuario, identificar y estimar tareas, y actualizar el backlog del sprint.

• Daily standup es utilizado por los equipos de Scrum durante la fase de implementación a fin de mantener actualizados el Scrumboard y el Sprint Burndown Chat para que muestren diariamente el avance del trabajo.

• Reunión de revisión del sprint se utiliza como parte del proceso de demostrar y validar el sprint a fin de facilitar la evolución y aceptación del incremento del producto en un sprint.

  

• Reunión de retrospectiva del sprint se lleva a cabo después de la reunión de revisión del sprint el ultimo día del sprint a fin de que los equipos de Scrum y otros interesados del negocio puedan hacer una introspección e identificar oportunidades de mejoramiento en futuros sprints.

• Reunión de retrospectiva de la liberación se establecen las formas para mejorar la colaboración y la eficiencia en futuras liberaciones. También se discuten los aspectos positivos y negativos, asi como posibles oportunidades para mejorar.

Scrum para grandes proyectos y la empresa

Al trabajar en grandes proyectos donde se requiere el trabajo de múltiples (cuatro o mas) equipos de Scrum con varios Product Owners y múltiples Scrum Masters, puede incluir necesidades adicionales de coordinación y sincronización.

La definición de lo que constituye un proyecto grande generalmente depende de la organización o de la complejidad de los proyecto emprendidos.

Un criterio clave para saber si un proyecto se considera pequeño en vez de una grande es si requiere múltiples Scrum Masters o múltiples Product Owners.

Si el proyecto requiere solo un Scrum Master y un Product Owner, generalmente estos pueden manejar cualquier actividad adicional de comunicación y sincronización que requiera el proyecto.

Al trabajar con Scrum al nivel de una empresa (un programa o un portafolio) tal vez sea necesaria la participación de cientos de equipos con miles de personas a cargo de múltiples proyectos dentro de los programas o portafolios de la compañía.

El uso de Scrum a nivel de un programa o portafolio tendrá ciertos efectos en los proyecto subyacentes.

La sincronización entre los equipos y la colaboración general son los principales retos en los grandes proyectos.

Esto también representa un reto al aplicar Scrum al nivel del programa o del portafolio. Sin embargo, los mas grandes retos en un programa o en un portafolio pueden presentarse en el aspecto de negocio, dado que pudieran contraponerse las prioridades del negocio en los distintos proyecto y estar en conflicto con los objetivos generales del programa o del portafolio. Estas metas y prioridades deben estar en armonía.

Al implementar Scrum al nivel de la empresa, no solo se deben aplicar entradas, herramientas y salidas tal como en un proyecto grande, también hay procesos adicionales específicos que son necesarios para atender la priorización adicional, la armonización y las actividades de coordinación.

Scrum vs Gestión de proyectos tradicionales

¿Por qué Scrum se esta haciendo mas popular con el pasar de los días?

Scrum es mejor que los métodos tradicionales de gestión de proyectos en muchas formas

Veamos las diferencias entre Scrum y un típico modelo tradicional de gestión de proyectos en forma detallada.

La principal deferencia entre los modelas tradicionales de gestión de proyectos y el framework de Scrum es la forma en que se maneja el proyecto.

La gestión tradicional de proyectos se basa en procesos, mientras que Scrum pide un cambio de mentalidad con un enfoque en las personas involucradas en el proyecto.

Aunque los procesos y herramientas son necesarios para completar con éxito un proyecto, son siempre las personas quienes asumen, participan e implementan el proyecto.

Hacen el trabajo que lleva al proyecto de la idea a la realidad.

Según Scrum, los factores clave en cualquier proyecto son las personas, y el énfasis debe estar en ellas y en sus acciones.

Varios equipos interfuncionales trabajan en paralelo en los sprints a fin de ofrecer entregables potencialmente enviables al final de cada print.

En un modelo tradicional, la cantidad de funcionalidades no terminadas sigue siendo alta y no se entrega ningún producto hasta el final o casi al final del proyecto.

¿Qué ventajas tiene Scrum en comparación a otras practicas cuando se trata del tamaño del equipo?

Scrum se puede utilizar para la gestión de proyectos de todos los tamaños. Scum funciona bien para la mayoría de proyectos y tamaños de equipo. Los grandes proyectos utilizan múltiples equipos Scrum que trabajan en sincronía para asegurar el proceso del proyecto.

Desde sus inicios, Scrum se ha enfocado en la producción de software funcional en vez de la documentación integral. Lo sigue haciendo y ha expandido ese enfoque para incluir el desarrollo incremental de productos aparte de software.

Aunque la documentación es necesaria y útil para cada proyecto, los equipos de Scrum se enfocan en entregables provisionales donde se entrega un valor real al cliente. La documentación se mantiene al mínimo cuando sea necesaria. Las lecciones aprendidas se registran durante las reuniones de retrospectiva.

El proceso que se sigue en Scrum es iterativo, a diferencia del modelo lineal utilizado en frameworks tradicionales tales como el modelo de cascada. El modelo iterativo ayuda a que el desarrollo del producto mejore con el tiempo. Maximiza las oportunidades de retroalimentación y asegura versiones potencialmente enviables de productos funcionales al final de cada sprint o iteración.

Scrum fomenta la toma de decisiones basadas en datos por encima de la planificación detallada por adelantado que se implementa en la gestión de proyecto al estilo cascada.

El enfoque no esta en el cumplimiento de las metas del plan del proyecto, sino en satisfacer los requerimientos del cliente.

La gestión tradicional de proyectos puede conducir a una situación en la que el plan ha tenido éxito, pero el cliente no esta satisfecho.

Además de la planificación y la entrega iterativa, Scrum apoya la colaboración de todas las partes involucradas (el cliente, el equipo de negocios, y el equipo del proyecto) para minimizar el riesgo y lograr satisfacción.

En Scrum, el entregar el mayor valor en el menor lapso de tiempo significa que hay que priorizar el trabajo con base en las necesidades del cliente y dividiendo “lo que debe hacerse ahora” de “lo que necesita hacerse”.

Scrum a menudo se contrasta con otros métodos de proyectos de manera lineal debido a su baja planificación por adelantado y a la programación de actividades que llevan inmediatamente a la ejecución.

En el entorno empresarial de hoy en día, el cambio es rápido y la planificación de largo alcance es problemática.

Predecir y planificar cada detalle de nuevos servicios y del desarrollo de nuevos productos es casi imposible.

Scrum utiliza su framework de baja planificación por adelantado para que sea adaptables y acomodarlo al cambio.

La gestión de riegos es constante en un proyecto gestionado con Scrum, donde la gestión de riesgo funciona con el Product Owner, el equipo de Scrum y el Scrum Master para determinar el mejor enfoque para manejar los riesgos identificados; mientras que en los modelos tradicionales los riesgos se manejan por adelantado, incluso antes de que se hayan identificado muchos riesgos.

De acuerdo a Scrum, cada entregable pasa por el equipo de garantía de calidad a medida que se desarrolla y se prueba, teniendo en mente el valor del cliente.

Los estrictos controles, tales como los criterios de aceptación y una clara definición de terminado, se utilizan para evitar desviaciones de los requerimientos del cliente.

En métodos tradicionales, se le da mas importancia al proceso.

A diferencia del estilo tradicional de gestión de comando y control, Scrum cree que los trabajadores de hoy en día tiene mucho mas que ofrecer que solo sus conocimientos técnicos, por lo tanto, ofrecen un mayor valor cuando se organizan por cuenta propia.

A diferencia de los métodos tradicionales de proyectos, donde la justificación de valor se hace antes del inicio del proyecto, en Scrum se hace a lo largo del proyecto.

El estilo de gestión que se sigue en Scrum es de naturaleza descentralizada, de manera que la fuerza laboral no depende del todo de la gerencia, lo que si es el caso en los métodos de gestión de proyecto antiguos, autocráticos.

Esto anima a los trabajadores a ser innovadores, a solucionar su propios problemas.

Scrum cree que el desarrollo de productos es un proceso de creación de valor compartido que necesita que todos los stakeholders trabajen e interactúen entre si para entregar el mayo valor.

El “comando y control” es la regla en los métodos tradicionales.

¿Cómo se mide el desempeño del equipo en Scrum y en los métodos tradicionales?

En Scrum se mide en términos del valor de negocio que genera el equipo, mientras que el cumplimiento del plan es la medida del desempeño en métodos de proyectos tradicionales.

En Scrum, el equipo entrega valor al negocio al final de cada Sprint.

¿Da Scrum un buen retorno de la inversión?

La respuesta es un gran “si”, y el RSI inicia temprano y continua a lo largo del la vida del proyecto; mientras que los métodos tradicionales de gestión de proyectos, el proyecto empieza a proporcionar RSI para el cliente al final del proyecto.

¿Cómo valora Scrum la participación del cliente?

Scrum recomienda encarecidamente, y esta diseñado para la participación del cliente a lo largo del proyecto. En los métodos tradicionales, la participación del cliente durante el desarrollo del producto o servicio, generalmente esta limitada, aunque puede variar dependiendo del ciclo de vida del proyecto.

En conjunto, Scrum es un framework innovador para la gestión de cualquier tipo de proyecto. Es adecuado para nuestro tiempo y era; listo para reemplazar las técnicas tradicionales de gestión de proyecto que fueron creadas en y para una época pasada.

Guía de Roles y Control de Procesos Emprical

En Scrum, las decisiones se basan en la observación y la experimentación, en vez de la planificación inicial detallada.

El control del proceso empírico se basa en las tres ideas principales de

Autoorganización

Colaboración

Priorización Basada en El Valor

Tiempo-Boxing

El desarrollo iterativo

Scrum vs Gestión de proyectos tradicionales

20 Key Concepts of Scrum Foundation

20 Key Concepts of Scrum Foundation

1. Scrum: A lightweight framework to solve complex problems and deliver value.
2. Empiricism: Based on experience, constant inspection, and adaptation.
3. Lean Thinking: Minimizes waste and focuses on what is essential.
4. Transparency: All work and processes must be visible to those responsible for results.
5. Inspection: Artifacts and progress are regularly reviewed.
6. Adaptation: Immediate adjustments are made when deviations are found to reduce risks.
7. Scrum Values: Commitment, Focus, Courage, Openness, and Respect.
8. Scrum Team: A cohesive unit composed of Scrum Master, Product Owner, and Developers.
9. Scrum Master: A leader who teaches, ensures proper use of Scrum, and fosters continuous improvement.
10. Product Owner: Responsible for maximizing product value and managing the Product Backlog.
11. Developers: Professionals committed to creating functional increments each Sprint.
12. Sprint: A work cycle of up to one month where a usable increment is created.
13. Sprint Planning: Initial meeting where the “why,” “what,” and “how” of the Sprint are defined.
14. Daily Scrum: A daily 15-minute meeting to inspect progress and adjust the plan.
15. Sprint Review: Review of the increment with stakeholders and adaptation of the Product Backlog.
16. Sprint Retrospective: Internal team reflection to improve quality and effectiveness.
17. Product Backlog: An evolving, prioritized list of everything required for the product.
18. Sprint Backlog: The visible Sprint plan including the Sprint Goal, selected items, and action plan.
19. Increment: A deliverable that adds value and meets the Definition of Done.
20. Definition of Done (DoD): A clear quality standard that every increment must meet to be considered deliverable.