• Saltar a la navegación principal
  • Saltar al contenido principal
Icono Jeronimo Palacios

Jeronimo Palacios & Associates

Transformación digital

  • Agile Academy
    • Scrum Mastery
  • Próximos cursos
  • Scrum.org
    • Applying Professional Scrum
    • Applying Professional Scrum for Software Development
    • Professional Scrum Master
    • Professional Scrum Master II
    • Professional Scrum Product Owner
    • Professional Scrum Product Owner Advanced
    • Scaled Professional Scrum
    • Professional Agile Leadership
    • Professional Scrum with Kanban
  • Kanban University
    • Team Kanban Practitioner
    • Kanban System Design
    • Kanban Systems Improvement
  • Servicios
    • Formación
      • Management 3.0
      • SAFe 5.0
      • Lean Change Management
      • DevOps Institute
    • Agile Coaching
      • Discover and deliver Agility
      • Solicitud de propuesta de servicios profesionales
    • Software
      • Diagnóstico de Arquitectura de Software
    • Recursos
  • Blog
  • Guías
    • Método Kanban
    • Nexus
    • Definitiva Scrum
    • Oficial Scrum
  • Acerca de
    • Videos sobre Scrum y Kanban
  • Contacto
  • Show Search
Hide Search

mitos de scrum

En Scrum se entrega solamente una vez cada Sprint

La aceptación de los PBIs en Scrum es algo que suscita dudas en los equipos. En realidad es muy fácil.

En Scrum tenemos cuatro eventos y un metaevento. Los eventos son el Sprint Planning, Daily Scrum, Sprint Review y Retrospectiva. El metaevento es el Sprint, que es un contenedor para todos los demás.

Durante el Sprint Planning, seleccionamos los PBIs que queremos completar durante ese Sprint y trazamos un Sprint Goal que marcará la dirección de lo que queremos conseguir en ese Sprint. Una vez que vayamos trabajando en ellos, colaboramos con el Product Owner para que los validarlos. Los entregámos de acuerdo con nuestra Definition of Done tan pronto como estén validados.

En algunas organizaciones es más difícil, porque dependen de un proceso manual auditado de subida a producción, pero en aquellas que utilizan DevOps, tan pronto como se cumplen los criterios que tengamos establecidos, será un sistema automatizado el que se encarga de subir a producción. Una vez que esté hecho, los PBIs son aceptados.

Lo que no hay que hacer nunca es esperar hasta el Sprint Review para entregar los PBIs. Esto provoca una espera innecesaria. En cuanto el Product Owner los valida, deberían entrar en el pipeline de puesta en producción.

Poner en Producción y hacer una release

¿Que ocurre si los PBIs que hemos seleccionado en el Sprint no queremos ponerlos en producción? Esta es una cuestión de configuración. En Scrum, el concepto de “En Producción” y “Released” son distintos. El uso de herramientas que permitan hacer toggling feature permite tener software en producción y configurarlo a gusto del Product Owner.

Puede ser que hoy estemos haciendo elementos para la próxima campaña de Navidad. Este Software puede estar terminado y subido a producción pero no activado a ojos del usuario, lo cual nos permite también ver como se comporta y hacer cuantas modificaciones necesitemos sin correr tanto riesgo como en un sistema de despliegue tradicional.

Además, esta estrategia nos permite tener una Definition of Done más completa que incluya “puesta en producción” aunque sigamos trabajando en los elementos durante más tiempo, haciendo el desarrollo iterativo e incremental. Ante la duda, no, esperar a tener toda una nueva funcionalidad para ponerla en producción no es iterativo e incremental. Es más Waterfall.

En Scrum los PBIs se entregan tan pronto están finalizados, independientemente de si hemos llegado al Sprint Review o no. Nos permite desacoplar la entrega de los eventos. Así éstos se centren más en la estrategia de nuestro producto en lugar de en el funcionamiento técnico. O una demo.

Para validar el valor del Software realizado, esta vez sí, el Product Owner debería de buscar hacer una release cuanto antes.

Puedes leer más sobre como conseguir un buen Sprint Review en este artículo del blog.

En Scrum lo que importa es la velocidad

La velocidad es uno de los temas de Scrum más discutidos online y offline. Sólo hace falta acercarse a la comunidad de Scrum Masters en Facebook para comprobar como muchas de las cuestiones planteadas están en la linea de la velocidad de entrega de los equipos de desarrollo de Software.

En muchas compañías, existen sofisticados métodos de estimación basados en la velocidad y yo mismo he tenido la oportunidad de usar -y odiar- hojas de excel que hacen estimaciones basadas en Puntos de Historia de usuario para intentar manejar la incertidumbre.

Es tal la obsesión que muchas organizaciones y Scrum Masters jóvenes hacen de la velocidad su arma de trabajo. Contar Story Points. Hacer proyecciones. Aleccionar al equipo a cumplir sus compromisos y a esforzarse más.

Sin embargo, leyendo la guía de Scrum, no hay ningún sitio donde se hable de velocidad. Concretamente, en Scrum se habla de estimar los PBIs (Product Backlog Items) como parte del proceso para refinarlos y que estén listos.

Es la asignación de Puntos de Historia junto con el popular planning póquer y la obsesión insana por evitar cualquier tipo de riesgo lo que lleva a las organizaciones que usan Scrum a hacer todo este trabajo de presión y previsión que es, en la mayoría de los casos, inútil.

El motivo por el que estimamos en Scrum es simple: El desarrollo de Software es complejo, e incluir a muchas personas en crear una pieza de algo complejo, añade más complejidad todavía. Las estimaciones son una herramienta para facilitar una conversación.

Uno de los miembros de mi equipo de desarrollo considera que un ítem conlleva 2 puntos y otro considera que conlleva 12. Parece claro que uno de los dos se está perdiendo algo. Quizás el primero no esté considerando todos los aspectos contenidos en la Definition of Done. O por el contrario, el segundo puede estar obviando una solución mucho más simple que la que tenía en mente. Esta estimación nos ha facilitado una conversación.

En Scrum no importa la velocidad. Lo que importa es entregar software terminado al final de cada Sprint. Y poner ese Software enfrente del cliente lo más tempranamente posible. Esos datos, junto con algunas herramientas, nos pueden dar una fiabilidad bastante buena de nuestra predicibilidad para los próximos meses. Los puntos de historia no. Las estimaciones no. Estos solamente son herramientas para tener una conversación.

Un buen punto de partida es echarle un vistazo a la guía de #NoEstimates que contiene múltiples enlaces a técnicas alternativas de previsión de entrega que están al margen de puntos de historia. En Kanban, también utilizamos herramientas estadísticas como las simulaciones de Montecarlo que nos dan un nivel de fiabilidad bastante bueno sobre la capacidad de cumplir fechas y compromisos.

Para esto hacen falta datos. Intentar estimar sin tener al menos tres o cuatro medidas (Sprints terminados) es simplemente una locura. Dependiendo del modelo estadístico que utilicemos necesitaremos entre tres y veinte medidas para poder dar una previsión con un alto nivel de fiabilidad.

Un problema nuevo

Esto nos lleva a un problema nuevo. Necesitamos datos fiables y en mi experiencia, lo que los equipos de desarrollo entregan en muchas organizaciones es simplemente cero. Nada. Desde no completar los requerimientos funcionales hasta no cumplir los requerimientos de puesta en producción.

Es por eso que antes de empezar a pensar en velocidad, tenemos que cumplir Scrum e introducir cuantas prácticas de ingeniería sean necesarias para así poder tener estimaciones fiables.

Quizás el principal problema es que cuando enfrentamos a los que toman decisiones en las organizaciones con la realidad de los datos de sus equipos, no quieren admitir que el problema no es la velocidad, sino que el Software que se desarrolla no cumple, ni ha cumplido nunca, un estándar de calidad para ponerlo en producción.

A pesar de todos nuestros Scrum Masters, Estimaciones, Project Managers y compañía, en realidad nunca hemos dejado de hacer Software como si de hacer un puente se tratase.

Es mucho más fácil hacer estimaciones a ojo y llamar a esa información velocidad. Pero eso no es Scrum. Porque en Scrum la velocidad no importa. Importa el software terminado.

Mantente al día a través de nuestra Newsletter Susbribirse

Jeronimo Palacios & Associates

Copyright © 2023 · Jerónimo Palacios & Associates S.L.

  • Aviso legal
  • Condiciones de venta
  • Política de cookies
  • Política de privacidad