Tema 7. Gestión de Liberaciones

Introducción

El Product Owner cumple un papel muy importante para el logro de los objetivos y la generación del valor, así como todos los integrantes del equipo, ya que cada uno cumple una función esencial y es crítico como parte del proceso Scrum. Hay que recordar que se trabaja con un equipo pequeño a través de liberaciones continuas, en aspectos críticos, que generan valor al cliente en periodos cortos denominados sprints.

Así, como parte del proceso, el equipo debe liberar valor constantemente que se debe gestionar de manera adecuada para asegurar que llegue al cliente alineado a sus expectativas. Por lo que se requiere una estrategia, la determinación de la velocidad y estimación de la liberación (alineada a lo que el cliente espera), escalando donde sea necesario y dando visibilidad en todo momento, lo cual es parte de lo que aprenderás en la siguiente experiencia de aprendizaje.

Explicación

1. Estrategia de liberación

La estrategia de liberación es muy importante para obtener el valor esperado. Por lo tanto, se requiere planeación, de lo contrario, existe la posibilidad de que se caiga en juntas que consumen tiempo, recolección de datos innecesaria, mala comunicación, desperdicio de tiempo, asignación de recursos ineficiente y un producto poco funcional. Debido a esto, es necesario que exista una estrategia de liberación conocida por el Product Owner, quien entregará dicho valor al cliente final a través de un plan que incluye los elementos de la Figura 1.

Figura 1. Elementos de la estrategia de liberación.


Fuente: Lucidchart. (s.f.). How to create an Agile release plan. Recuperado de https://www.lucidchart.com/blog/agile-release-planning

El Product Owner, al ser responsable de la entrega de valor, debe tener claridad de la estrategia de liberación, la cual es responsabilidad del equipo de desarrollo. Y a su vez, debe ser visible, como todos los artefactos ágiles, para tomar decisiones y que se obtenga el valor esperado por el cliente.

Aunque en agilidad se habla sobre un enfoque de planeación a corto plazo, eso no implica que haya elementos que deban eliminarse, tal como se muestra en la Figura 1, ya que muchas veces existen actividades que son críticas como la elaboración de un roadmap o una línea de tiempo que de visibilidad del valor que se está generando, de quién lo está generando, cuándo se obtendrá el valor, así como las características que serán liberadas en cada una de las iteraciones para tener claridad de los momentos clave. De igual manera, para realizar pruebas o determinar si se cumplió o no con los objetivos esperados.

Para crear la estrategia de liberación, se deben tomar en cuenta los elementos mencionados de la Figura 1, los cuales se organizan en pasos críticos para definir la visión del producto. Por lo que sus características deben ser priorizadas con el objetivo de buscar enfocar el esfuerzo y recursos al alcance de éstas, a través de una liberación adecuada, y con los ajustes necesarios para mostrar el valor esperado. Dichos pasos se muestran en la Figura 2.

Figura 2. Estrategia de Liberación.


Fuente: Lucidchart. (s.f.). How to create an Agile release plan. Recuperado de https://www.lucidchart.com/blog/agile-release-planning

De acuerdo con Lucidchart (s.f.), Moday.com (2022) y Visualparadigm (s.f.), cada uno de los procesos se define de la siguiente manera:

  • Definición de la visión: consiste en concretar qué es lo que se busca alcanzar como producto, es decir, qué es lo que guiará las decisiones sobre las características para priorizar y enfocar los esfuerzos.
  • Priorización del backlog: se enfoca en la revisión y priorización de las características o historias de usuario dentro del product backlog, las cuales fueron un input de los interesados para determinar las prioridades del producto o historias de usuario.
  • Realización de la junta de planeación de liberaciones: se deben revisar los puntos siguientes:
    • Revisar la hoja de ruta (roadmap): incluye la visión del producto (calendario inicial).
    • Revisar la arquitectura: elementos técnicos para las liberaciones.
    • Revisar la velocidad y cronograma de las iteraciones.
    • Establecer la definición de hecho (DoD).
  • Comunicación del calendario de liberaciones: se realizan los últimos ajustes antes de compartir el calendario del producto con todos los interesados, de tal forma que todos tengan visibilidad de las actualizaciones y lo que ocurre con el producto.

El propósito general de la estrategia de liberaciones es asegurar que el producto siempre se mueva en la dirección correcta y que las liberaciones lógicas ocurran con frecuencia por parte del equipo de desarrollo.

2. Estimación y velocidad

La velocidad es una métrica clave en Scrum y ayuda a estimar la cantidad de trabajo que el equipo completo puede entregar durante el sprint, determinada, al final, totalizando los puntos de historia para todas las historias de usuario completadas (ScrumInc, s.f.). También puede definirse como la cantidad de product backlog que se tornó en un incremento de producto durante un sprint. Si el producto es desarrollado por más de un equipo, la velocidad puede determinarse por medio de la velocidad mínima de todos los equipos, o bien, como la velocidad promedio. (Doshi, 2018).

Dentro de los elementos que ayudan al desarrollo del equipo, además de su capacidad, la velocidad de desarrollo ayuda a establecer cuántos ítems del Product Backlog pueden determinarse en el Sprint actual. Para el Product Owner, dicha velocidad ayuda a medir qué tan rápido el equipo puede trabajar en el backlog, de tal forma que pueda reportar y pronosticar el progreso.

Para determinar la velocidad, se suman los puntos de historia entregados por todo el equipo de desarrollo al final del sprint (Agile Academy, s.f.). Por ejemplo: un equipo tiene tres historias de usuario por completar: Historia A: 3 Puntos, Historia B: 5 Puntos, Historia C: 8 puntos. Si de la Historia B sólo se completó el 80%, entonces la velocidad fue de 11 Puntos de Historia.

La velocidad calculada trae grandes beneficios, siendo un indicador clave de desempeño en contextos ágiles, los cuales se muestran en la Figura 3.

Figura 3. Beneficios de la velocidad en Agile.


Fuente: Agile Academy. (s.f.). Velocity in Scrum – Definition and how you can calculate it. Recuperado de https://www.agile-academy.com/en/scrum-master/velocity-definition-and-how-you-can-calculate-it/

La estimación en el sprint es realizada por el equipo completo, es decir, no es una tarea que debe hacer alguno de los roles de manera aislada, sino que se debe trabajar en conjunto para asegurar la mayor alineación y el logro de los objetivos (Wilhite, 2021).

3. Escalamiento de productos

El escalamiento se refiere a conseguir un balance al crear un equipo que pueda trabajar con el crecimiento dentro del negocio, así como a la capacidad, competencias y equipamiento de los equipos de trabajo como medio para la gestión del valor y el logro de los objetivos (Catauta, s.f.). El escalamiento de Agile requiere también de marcos de referencia, adicionales a Scrum o Kanban, que permitan que la organización pueda escalar los procesos ágiles. Los marcos de referencia para escalar Agile más populares son los que se muestran en la Figura 4.

Figura 4. Marcos de referencia populares de escalamiento Agile


Fuente: Appelbaum, B. (s.f.). SCALING AGILE: HOW TO OVERCOME 3 COMMON CHALLENGES. Recuperado de https://www.planview.com/resources/guide/what-is-agile-program-management/scaling-agile-common-challen/
Berman, J. (s.f.). Agile at Scale. Movin' on up: scaling agile in large organizations. Recuperado de https://www.atlassian.com/agile/agile-at-scale

Cada uno de los marcos tiene un enfoque y características diferentes, tal como lo indican Appelbaum (s.f.) y Berman (s.f.):

  • SAFe: Scaled Agile Framework es un patrón y flujo de trabajo organizacional para implementar prácticas ágiles a nivel empresarial, el cual involucra desarrollo de software ágil, desarrollo de productos esbeltos y pensamiento sistémico.
  • LeSS: Large-Scale Scrum es un Scrum regular aplicado a larga escala. Está enfocado en la idea de que los marcos de referencia deben ser minimalistas para alcanzar el éxito.
  • DA: Disciplined Agile, conocido antes como Disciplined Agile Delivery (DAD), es un marco de referencia de procesos orientado al aprendizaje para entrega de soluciones de TI y que proporciona fundamentos sólidos para escalar entregas ágiles dentro de organizaciones de nivel clase-empresarial.
  • S@S: Scrum@Scale es una extensión de Scrum adoptada por organizaciones que ya han implementado el marco de referencia Scrum de forma correcta a nivel equipo, pero que ahora buscan ampliar a toda la organización para compartir un conjunto de objetivos comunes.

Se debe recordar que se pueden añadir procesos innecesarios como parte del escalamiento, por lo que es importante determinar cuáles son los principios guías para escalar los marcos de referencia ágiles dentro de la organización, tales como la planificación y estrategia a largo plazo, una cultura de equipos ágiles, expertos en agilidad, procesos impulsados o centrados en el valor y en el cliente.

4. Reporteo

El reporteo dentro de Agile se refiere al uso de las métricas y herramientas para analizar y mantener las decisiones informadas sobre la forma de trabajar gestionada. El objetivo principal de esta actividad es asegurar que el sistema de trabajo entrega los resultados de valor con óptima calidad y paz incrementada (Kanbanize, s.f.).

Dado que los equipos ágiles utilizan diferentes conjuntos de métrica para alcanzar mayor visibilidad del trabajo realizado, medir qué tan eficientes son sus procesos, su desempeño en el tiempo, identificar bloqueos de proceso, entre otros, el método de reporteo varía de equipo en equipo y dependerá de este para su selección.

La diferencia principal entre el reporte ágil y el tradicional pueden observarse en los elementos de la Figura 5.

Figura 5. Diferencias entre reporteo ágil y tradicional.


Fuente: Kanbanize. (s.f.). Kanban vs Scrum: Detailed Comparison. Recuperado de https://kanbanize.com/kanban-resources/kanban-software/kanban-vs-scrum-software

Los elementos de la figura 5 muestran la forma en la cual el reporte tradicional ha cambiado, ya que la filosofía ágil busca resultados, más que metas, midiendo al equipo a través del valor alcanzado y su eficiencia como un todo. Mediante métricas que permiten la toma de decisiones a través del contexto, la resolución del problema actual del cliente, los bloqueadores del proceso o las entregas en el tiempo.

La importancia de la metodología ágil se muestra en la Figura 6.

Figura 6. Importancia del reporteo Ágil.


Fuente: Kanbanize. (s.f.). Kanban vs Scrum: Detailed Comparison. Recuperado de https://kanbanize.com/kanban-resources/kanban-software/kanban-vs-scrum-software

Como parte de las herramientas de reporteo ágil, se encuentran diferentes tipos de gráficas (presentados en la Figura 7) que muestran los indicadores de desempeño.

Figura 7. Herramientas de reporteo ágil.


Fuente: Zoho. (s.f.). Agile Reports: know your metrics. Recuperado de https://www.zoho.com/sprints/agile-reports.html

De acuerdo con Kanbanize (s.f.), PMM (2022) y Zoho (s.f.), las gráficas poseen las siguientes características:

  • Gráfica de quemado: se aplica para ayudar a monitorear cuántas historias de usuario han sido completadas para una iteración dada. El esfuerzo permite predecir cuántos sprint se requieren para completar el trabajo.
  • Gráfica de velocidad: utilizada para representar la cantidad promedio de elementos de trabajo que pueden ser completados durante un sprint (iteración) usando Puntos de Historia u horas para medir el esfuerzo necesario.
  • Diagrama de flujo acumulativo: muestra el número total de elementos en cada fase de trabajo del proceso. Expone cuánto toma completar un elemento de trabajo (tiempo de ciclo), si los trabajos entran al flujo con la misma paz con la que salieron (throughput) o cuánto trabajo se procesa en cada fase (trabajo en progreso).
  • Dispersión del tiempo de ciclo: muestra cuánto tiempo toma completar determinada pieza de trabajo, mostrando todo lo que el equipo ha completado a lo largo de un periodo específico.
  • Gráfica de corridas de rendimiento: representa el número de elementos de trabajo que pasan a través del proceso de trabajo sobre un periodo específico. Además, permite medir la capacidad real de carga de trabajo del equipo y planear mejor la cantidad de trabajo que pueden entregar en un tiempo determinado.
  • Gráfica de edad del WIP: facilita el monitoreo de cuántas tareas asignadas se movieron a lo largo de las fases de un proceso y ayuda a mejorar la visibilidad sobre el equipo.
  • Gráfica de eficiencia de flujo: es la razón entre el valor agregado en el tiempo (activamente trabajando en completar una tarea) y el lead time (el tiempo completo requerido para que una asignación sea completada) de un elemento de trabajo.

Cierre

La gestión de liberaciones es un proceso clave para el proceso de agilidad y debe considerarse como parte de los procesos esenciales para una colaboración adecuada, ya que permite, no sólo planear las liberaciones, sino mostrar el desempeño a través del reporteo ágil que hace el equipo, apoyar al logro de la implementación del escalamiento ágil y de la estimación de velocidad del Sprint y la planeación de este. Recuerda que, como Product Owner, deberás conocer todo lo relacionado con la generación del valor que ejecuta el equipo de desarrollo para alcanzar la visión del cliente.

Checkpoint

Asegúrate de:

  • Para poder tener una visibilidad adecuada del valor, el Product Owner debe tener claridad de la estrategia de liberación y alinearla con los interesados y el equipo Scrum.
  • La estimación de la velocidad ayudará a calcular la duración y el número de los sprint a ejecutar para conformar el valor.
  • El escalamiento ágil ayudará a la organización a la implementación de Agile como parte de las nuevas formas de trabajar. No como parte de un equipo pequeño, sino de una organización completa.
  • Como parte de la visibilidad proporcionada, se recomienda el uso del reporteo ágil, el cual contiene los elementos requeridos para poder mostrar el desempeño del equipo, de los procesos y del valor ejecutado.
Para saber más – Recursos adicionales

Los siguientes enlaces son externos a la Universidad Tecmilenio, al acceder a ellos considera que debes apegarte a sus términos y condiciones.

Videos

Para conocer más acerca de gestión de liberaciones, te sugerimos revisar lo siguiente:


Lecturas

Para conocer más acerca de gestión de liberaciones, te sugerimos leer lo siguiente:

Bibliografía

  • Agile Academy. (s.f.). Velocity in Scrum – Definition and how you can calculate it. Recuperado de https://www.agile-academy.com/en/scrum-master/velocity-definition-and-how-you-can-calculate-it/
  • Appelbaum, B. (s.f.). SCALING AGILE: HOW TO OVERCOME 3 COMMON CHALLENGES. Recuperado de https://www.planview.com/resources/guide/what-is-agile-program-management/scaling-agile-common-challen/
  • Berman, J. (s.f.). Agile at Scale. Movin' on up: scaling agile in large organizations. Recuperado de https://www.atlassian.com/agile/agile-at-scale
  • Catauta, R. (s.f.). How to Scale Agile Product Teams. Recuperado de https://storiesonboard.com/blog/how-to-scale-agile-product-teams
  • Doshi, P. (2018). Agile Metrics: Velocity. Recuperado de https://www.scrum.org/resources/blog/agile-metrics-velocity
  • Kanbanize. (s.f.). Kanban vs Scrum: Detailed Comparison. Recuperado de https://kanbanize.com/kanban-resources/kanban-software/kanban-vs-scrum-software
  • Lucidchart. (s.f.). How to create an Agile release plan. Recuperado de https://www.lucidchart.com/blog/agile-release-planning
  • Monday.com. (2022). Everything you need to know about agile release planning. Recuperado de https://monday.com/blog/rnd/agile-release-planning/
  • PMM. (2022). Agile Reporting for Project Management. Recuperado de https://www.pmmajik.com/agile-reporting-for-project-management/
  • ScrumInc. (s.f.). Velocity. Recuperado de https://www.scruminc.com/velocity/
  • Visualparadigm. (s.f.). What is Scrum Release Planning? Recuperado de https://www.visual-paradigm.com/scrum/what-is-scrum-release-planning/
  • Wilhite, D. (2021). Extremely frustrated Product Owner. Recuperado de https://www.scrum.org/forum/scrum-forum/52895/extremely-frustrated-product-owner
  • Wilhite, D. (2021). Sprint Planning Estimation. Recuperado de https://www.scrum.org/forum/scrum-forum/46973/sprint-planning-estimation
  • Zoho. (s.f.). Agile Reports: know your metrics. Recuperado de https://www.zoho.com/sprints/agile-reports.html

La obra presentada es propiedad de ENSEÑANZA E INVESTIGACIÓN SUPERIOR A.C. (UNIVERSIDAD TECMILENIO), protegida por la Ley Federal de Derecho de Autor; la alteración o deformación de una obra, así como su reproducción, exhibición o ejecución pública sin el consentimiento de su autor y titular de los derechos correspondientes es constitutivo de un delito tipificado en la Ley Federal de Derechos de Autor, así como en las Leyes Internacionales de Derecho de Autor.

El uso de imágenes, fragmentos de videos, fragmentos de eventos culturales, programas y demás material que sea objeto de protección de los derechos de autor, es exclusivamente para fines educativos e informativos, y cualquier uso distinto como el lucro, reproducción, edición o modificación, será perseguido y sancionado por UNIVERSIDAD TECMILENIO.

Queda prohibido copiar, reproducir, distribuir, publicar, transmitir, difundir, o en cualquier modo explotar cualquier parte de esta obra sin la autorización previa por escrito de UNIVERSIDAD TECMILENIO. Sin embargo, usted podrá bajar material a su computadora personal para uso exclusivamente personal o educacional y no comercial limitado a una copia por página. No se podrá remover o alterar de la copia ninguna leyenda de Derechos de Autor o la que manifieste la autoría del material.