Marco de trabajo ágil de In Motion

Nuestro marco de trabajo está basado en la definición de SCRUM específicamente detallada en la guía de scrum https://www.scrumguides.org/scrum-guide.html.

Por lo tanto, nuestro marco de trabajo es una implementación de las prácticas definidas y detalladas en la guía de referencia a través de nuestros colaboradores certificados en distintos niveles de Scrum Master y Product Owner en https://www.scrum.org/.

El éxito en la utilización del marco de trabajo mencionado se encuentra dado por cada uno de los siguientes elementos, los cuales definimos y trabajamos en conjunto con el cliente de forma previa al inicio de un nuevo proyecto o negocio a través de una sesión de entendimiento:

• Sesión de entendimiento marco de trabajo:
  • Explicación marco de trabajo en general.
  • Definición y explicación de los roles que forman el equipo “Scrum Team”.
  • Definición y explicación de los eventos que dan vida al marco de trabajo.
  • Definición y explicación de los artefactos utilizados.
  • Definición y explicación de los prerrequisitos para implementar el marco de trabajo:
    • Definición e identificación de los stakeholders del proyecto o negocio.
    • Definición de quién será el “Product Owner” asignado por el cliente.
    • Definición de los elementos clave del marco de trabajo:
      • Definición de “Listo”.
      • Definición de “Incremento de Valor”.
      • Definición de la duración del “Sprint”.

El equipo de trabajo de Scrum está formado por:

• Product Owner: Responsable de maximizar el valor del producto resultante del trabajo de equipo de desarrollo o Development Team. Responsable de la gestión y administración del Product Backlog, priorización del mismo, y responsable de que este sea transparente y entendible para el equipo de desarrollo.

• Development Team: Equipo de profesionales responsables de hacer las tareas de desarrollo y entregar en cada sprint un incremento potencialmente desplegable de valor según la definición de “Listo” acordada con el cliente.

• Scrum Master: Responsable de promover y soportar el marco de trabajo según las buenas prácticas, apoyar y dar soporte al Product Owner, Development Team y a la organización para maximizar el valor creado.

Los eventos de Scrum que se realizan en cada sprint son los siguientes:

• Sprint: Es el contenedor de todos los eventos de Scrum y el elemento que permite organizar al equipo de trabajo dentro de un marco enfocado a crear valor. Los sprints pueden tener una duración de 1 a 4 semanas.

• Sprint Planning: Actividad de planificación donde, por medio de trabajo colaborativo, se define cuál debería ser el resultado del sprint y cuánto trabajo será necesario para lograrlo.

• Daily Scrum: Plan respecto de las tareas a realizar en las próximas 24 horas e inspección de las tareas realizadas.

• Sprint Review: Sesión de inspección entre el equipo Scrum y los stakeholders a la finalización de cada sprint con el objetivo de determinar cuáles entregables del sprint cumplen con la definición de “Listo”.

• Sprint Retrospective: Sesión de inspección del equipo Scrum para determinar los puntos de mejoras a aplicar en el próximo sprint.

Los artefactos que se trabajan en cada sprint son los siguientes:

• Product Backlog: Lista de requisitos que debe tener el producto a desarrollar, el cual es administrado por el Product Owner.

• Sprint Backlog: Subconjunto de requisitos del Product Backlog seleccionados para un sprint con el objetivo de producir un incremento de valor potencialmente desplegable.

• Increment: Es la sumatoria de todos los elementos terminados en un sprint más los ya producidos en sprints anteriores. Este artefacto permite determinar el cumplimiento de las expectativas para el sprint.

• Definition of “Done” (DoD): Permite que las partes interesadas en el proyecto estén de acuerdo y entiendan qué significa que un requisito o un conjunto de requisitos de un sprint están terminados. DoD es una definición que permite asegurar la transparencia y entendimiento de todas las partes respecto de qué esperar y qué exigir para considerar un entregable terminado o listo. Este artefacto es uno de los elementos que asegura el éxito del proyecto.

A continuación, se muestra la organización recomendada con base en sprints de 2 semanas de duración:

Utilizando el marco de trabajo SCRUM es posible gestionar un equipo de 3-9 personas trabajando sobre un producto/negocio determinado. Cuando es necesario disponer de una mayor capacidad productiva lo cual implica que existen múltiples equipos trabajando sobre un mismo producto/negocio y todo este trabajo debe producir un incremento integrado, utilizamos dos formas de escalar SCRUM según el contexto de la organización, cantidad de personas, locaciones de trabajo, etc., que se analizan previamente y permiten adoptar la mejor opción para cada caso:

• Primera forma: Utilizando marco de trabajo Nexus y Nexus + (https://www.scrum.org/resources/online-nexus-guide), lo cual nos permite:
  • Nexus: Gestionar hasta 9 equipos de 3-9 colaboradores.
  • Nexus +: Gestionar hasta 9 equipos Nexus donde cada uno de ellos tiene hasta 9 equipos de 3-9 colaboradores.

• Segunda forma: SQUADS o Marco de Trabajo de Spotify, si bien no es un marco de trabajo establecido por SCRUM.ORG, es un marco de trabajo ágil producto de la adaptación de varios fundamentos ágiles a una corporación que requiere grandes cantidades de equipos, personas y recursos colaborando en un único producto/negocio. Adoptamos esta forma de escalar SCRUM debido a que se ha transformado en un estándar de la industria y se basa en el principio de autonomía de los equipos.

A continuación, describimos los KPIs utilizados para evaluar el performance del equipo y el progreso del producto o servicio en desarrollo.

• Burn Down Chart: Lo utilizamos para medir el trabajo pendiente en un sprint o del producto.
• Burn Up Chart: Lo utilizamos para medir el trabajo completado del sprint o del producto.

• Velocity: Medición de los “story point” comprometidos versus los terminados según la definición de Done (DoD). De esta forma es posible medir el performance del sprint y del equipo, además permite proyectar el esfuerzo y/o rendimiento. Una diferencia considerable entre puntos desarrollados vs completados puede denotar:
  • Deuda técnica.
  • Problemas de planificación.

• Incrementos de Funcionalidad y Despliegues a Producción:
  • Aprobación de Sprints: Permite medir el nivel de aceptación de los sprints en los eventos de revisión.
  • Despliegues a Producción: Permite medir si se mantiene una conducta de despliegue continuo ya que la única forma de validar si los incrementos de funcionalidad son realmente de valor, es por medio del mercado y tal retroalimentación solo es posible desplegando a producción.

Todos los nombres de producto y marcas comerciales como Scrum.org™ y Spotify® así como las imágenes son propiedad de sus respectivos dueños, que son de ninguna manera asociada o afiliada con In Motion. Los nombres de productos son utilizados con el único fin de dar a conocer el marco de trabajo ágil con el que In Motion gestiona sus implementaciones de proyectos. El uso de estos nombres no implica ninguna cooperación o respaldo.