Es habitual que lectores del blog y alumnos de los cursos de Scrum y de Kanban me escriban para preguntarme dudas sobre la forma en la que implementan Scrum en sus organizaciones. Hasta ahora, siempre he respondido en privado. Me gustaría aprovechar esas ideas para inaugurar dos secciones: #ScrumClinic y #KanbanClinic. Si tienes una consulta, mandala a través del formulario de contacto
Hola Jerónimo, se que debes tener una agenda muy ocupada, pero agradeceria mucho me puedas ayudar con esta duda que tengo.
Sigo tu blog muy asiduamente desde aqui Perú. Actualmente en nuestra organización están comenzando a implementar Agile (Scrum propiamente dicho) y los coaches nos comentan que el flujo a seguir es Inception – Sprint 0 – Ejecución Scrum.
Lo que me parece curioso es que hablan de Sprint 0, sin embargo tu lo mencionas como algo inmaduro en tu blog (https://jeronimopalacios.com/2016/09/formar-equipos-agiles-cuando-estas-empezando-en-scrum/).
Después de una ejecución en un proyecto aquí en la empresa, vi necesario un espacio de tiempo entre el inception y el Sprint 1, y mi duda es la siguiente:
Si este espacio de tiempo para preparar el terreno (infraestructura, IDEs, herramientas, refinamiento del MVP en Historias de Usuario) es parte de un posible Sprint 0 o son actividades propias de un Inception.
Te estare muy agradecido que me puedas brindar tus comentarios.
Gracias, desde Perú!
En Scrum, no hay Sprint 0
Si vamos a la guía de Scrum, no encontraremos mención a ninguna de estas dos técnicas. La gestión de proyectos en Scrum se produce en un sólo Sprint y abarca todo el ciclo de vida del software: planificación, diseño, desarrollo, testeo y entrega en un sólo Sprint.
Tener un Sprint 0 es solo una manera de intentar hacer Scrum en fases o lo que es lo mismo, waterfall en Sprints. En Scrum siempre se comienza por el primer Sprint y al final del mismo se entrega una funcionalidad de negocio terminada. Eso permite enfocarse en lo que es realmente fundamental para entregar esa pieza de Software.
Existe una manera de tener el tiempo necesario para montar todo el despliegue usando Scrum, y esto es simplemente ajustando la longitud del Sprint. Esta depende de dos factores:
- El tiempo mínimo que el equipo de desarrollo necesita para producir valor: Si el equipo no es capaz de producir software terminado en dos semanas, ¿Para que poner Sprints de dos semanas? Si el equipo no es capaz de entregar software en 30 días o menos, hay que ver los impedimentos y eliminarlos.
- Un horizonte aceptable de riesgo para el Product Owner: El Product Owner, como responsable de gestionar la inversión del desarrollo, tiene que sentirse cómodo con el horizonte de planeamiento planteado por el equipo de desarrollo.
Si el equipo no puede entregar software en dos semanas, pueden tener Sprints de 3 o de 4 semanas. Scrum no dice: “Sprints de dos semanas”, sino “Software en 30 días o menos”.
¿Que sentido tiene hacer un Sprint 0 si las necesidades del proyecto pueden cambiar en dos, tres o cuatro Sprints? Scrum es desarrollo de Software iterativo e incremental, donde cada Sprint tiene varias oportunidades de inspeccionar y adaptar. Un Sprint es un proyecto completo.
Si tomamos todas las decisiones en el Sprint 0, no estamos haciendo mucho más que una fase de “preparación al desarrollo”, donde estaremos tomando muchas decisiones que luego pueden ser erróneas conforme vayamos descubriendo nuevas necesidades que antes no estaban claras. No es muy distinto de PMP o Prince2 y nos llevará al mismo problemas.
La utilidad de un inception
Un inception es una técnica que permite descubrir que se quiere hacer para poder llenar un Product Backlog. Es una reunión ligera, que puede durar unas pocas horas, y su lugar ideal de realización es durante el Sprint Planning del primer Sprint.
Sin embargo, muchas organizaciones intentan hacer inceptions que duran varios días y luego necesitan una o varias semanas para poder analizar con detalle cada uno de los Product Backlog Items para poder ordenar el Product Backlog.
Esto tiene otro nombre: Toma de requisitos. Da igual que ahora se haga con Post-its® y en una reunión facilitada, sigue siendo lo mismo que se lleva haciendo muchos años.
Los inceptions no forman parte de Scrum, son técnicas que no deben de interferir en el framework. Por lo que nos cuentas, querido lector, los coaches de tu organización, están adaptando el marco de trabajo Scrum a las técnicas que ellos conocen.
Esto en realidad esto está inventado, y se llama Waterfall
El problema es que en organizaciones en las que se dan estas situaciones, la inversión en agilidad está directamente desperdiciada. Es solamente ponerle distintos nombres a lo que se ha hecho siempre. Un proyecto se convierte en las siguiente fases:
- Inception: Conocido como fase de toma de requisitos.
- Sprint 0: Conocido como fase de preparación al desarrollo/arquitectura/infraestructura.
- Desarrollo: Conocido como el mismo nombre en métodos tradicionales
- Testeo: ídem
- Hardening: Conocido como fase de estabilización
- Despliegue: Conocida como fase de igual nos hemos equivocado en cosas y tenemos que volver a empezar
Asumiendo que cada una de esas fases dura 1 o 2 sprints, estamos poniendo Software enfrente del cliente cada 3 o 6 meses. Eso en el mejor de los casos. En el peor de los casos desarrollaremos durante un año sin que el cliente haya visto nada ¿En qué es distinto esto de los métodos tradicionales como PMP o Prince2? En nada.
La premisa de Scrum es: “Software terminado en 30 días o menos”, de forma iterativa e incremental. Todo lo que sea salirse de eso, llámese Sprint 0 o Inception no es Scrum y es una señal de organizaciones y equipos inmaduros.
Si no son capaces de hacer esto, es mejor empezar con otra técnica, como Kanban, que permite una mejora evolutiva partiendo de un proceso ya existente. Seguir con Scrum es abocarse al fracaso en esta situación.
Recomiendo la lectura del libro de Ken Schwaber y Jeff Sutherland, creadores de Scrum: Software en 30 días o menos. En el mismo se explican las mecánicas básicas de como funciona Scrum y de cual es el ciclo de vida de desarrollo de software cuando se utilizan métodos ágiles.
La premisa de Scrum es: “Software terminado en 30 días o menos”, de forma interactiva e incremental….¿No sería “iterativa” e incremental?
Gracias Jero
Tienes razón. El corrector me la ha jugado. Ya está corregido. Gracias a ti, Pedro.
Hablas de “métodos tradicionales como PMP…”, el PMP es una certificación del PMI no un método, sorprende tu desconocimiento de que es el PMP. Una vez más compruebo q la mayoría de “agilistas” que critican el PMP o PMI no tienen ni idea de que es. La agilidad promueve la apertura y respeto sin embargo la mayoría de “agilistas” radicales no aceptan nada que sea diferente a Scrum, generalmente con fines comerciales o por posiciones dogmáticas.
Hablas de “métodos tradicionales como PMP…”, el PMP es una certificación del PMI no un método, sorprende tu desconocimiento de que es el PMP. Una vez más compruebo q la mayoría de “agilistas” que critican el PMP o PMI no tienen ni idea de que es. La agilidad promueve la apertura y respeto sin embargo la mayoría de “agilistas” radicales no aceptan nada que sea diferente a Scrum, generalmente con fines comerciales o por posiciones dogmáticas.
La premisa de Scrum es: “Software terminado en 30 días o menos”, de forma interactiva e incremental….¿No sería “iterativa” e incremental?
Gracias Jero
Tienes razón. El corrector me la ha jugado. Ya está corregido. Gracias a ti, Pedro.