Se habla mucho sobre el tamaño fijo que debe de tener el Sprint, en la Guía Oficial de Scrum menciona de una duración máxima de 4 semanas.
Scrum Guide: "El corazón de Scrum es el Sprint, tiempo fijo de un mes o menos, durante el cual "Listo", usable y un incremento potencialmente puesto en producción es creado. Sprints tienen duración consistente a través del esfuerzo de desarrollo, un Sprint comienza inmediatamente despues de concluir el anterior.
Los Sprints están limitados a un mes calendario. Cuando el horizonte del Sprint es muy largo, la definición de lo que es construido puede cambiar, puede llegar la complejidad y pueden incrementar los riesgos. Los Sprints habilitan predictibilidad, asegurando la inspección y adaptación del progreso a través del Objetivo del Sprint, al menos cada mes calendario. Los Sprints limitan el riego, al costo de un mes calendario"
Sin embargo en el SBOK mencionan de 1 a 6 semanas como máximo, lo cual va en contradicción de la guía oficial de Scrum.
En cuanto al Sprint, contamos con dos reglas inquebrantables.
1. No se deben de aceptar cambios en el transcurso de la ejecución del Sprint, cuidando y respetando lo pactado y comprometido por el equipo (Cuidando el cumplimiento del objetivo del Sprint)
2. La duración del Sprint es inamovible
Claro que existen casos extremos donde se puede negociar con el Product Owner el romper estas reglas (aunque no es aconsejable)
Pude observar en alguna ocasión el negociar el modificar el Sprint ya sea a 1 semana donde se tenían que acortar las integraciones para poder salir mas rápido a producción, donde era el producto final un sitio Web donde se ofertaban cursos en linea, aunque el manejo de la información era muy sensible por lo que se tenia que tener sumo cuidado al momento de realizar la integración.
Así mismo trabaje en otra empresa donde se tenia el Sprint de 1 mes donde se requería bastante coordinación, la ventaja era que daba el tiempo necesario al equipo de control de calidad de realizar todas las pruebas necesarias antes de completar el Sprint. Esto ayudaba a mantener la calidad en los incrementos desarrollados.
En lineas generales la duración del Sprint debería ser lo mínimo que toma al equipo de desarrollo completar un User Story (Listo).
Hay que tomar en consideración el factor de poder trabajar en los cambios de requerimientos que llegan durante el Sprint,
Mi percepción personal es que deberíamos tomar en cuenta los factores clave, según el tamaño del equipo, cual es la capacidad que se tiene, nuestro equipo esta maduro, el producto a desarrollar permite entregas in iteraciones cortas, no nos olvidemos tambien que se debe realizar el grooming dentro del Sprint para asegurar el tener por lo menos User Stories "Listas" por lo menos para dos Sprints siguientes.
sábado, 11 de julio de 2020
jueves, 9 de julio de 2020
Implementando Agilidad en ambientes tradicionales
Retomando el blog personal, después de una pausa larga debido a mis tiempos cortos libres, ahora es tiempo de escribir acerca de una experiencia que me toco vivir hace un tiempo atrás.
Tuve la oportunidad de ayudar a incluir la agilidad en la gestión tradicional de proyectos estratégicos de la PMO de una importante empresa, donde se realizo un ajuste a toda la metodología tradicional aprovechando mi conocimiento y experiencia en el mundo ágil de muchos años atrás dentro de varias empresas de desarrollo de Software.
A continuación algunos puntos a resaltar según este emocionante reto.
1. Es imprescindible trabajar en cambiar el mindset tradicional de los ejecutivos para poder recibir el soporte requerido.
Análisis: Es muy difícil poder romper los paradigmas y costumbres del personal de la organización, ya que muchas veces estos se encierran en poder continuar con lo tradicional (funciono hasta ahora por que cambiarlo o deseo ver lo mismos resultados que hasta hoy veo con los métodos tradicionales)
Es critico trabajar en primera instancia en poder cambiar el mindset para asegurar que el cambio no se truncara en el camino.
2. Resaltar los beneficios de incluir frameworks ágiles dentro del desarrollo de los productos de la organización (mejorando el time to market)
Análisis: Esta parte salio naturalmente como una necesidad del mercado, al tener cambios tan frecuentes en las necesidades de los clientes, se vuelve imperativo el poder adaptarnos a estas necesidades si queremos ser competitivos dentro del mercado en la época actual en la que vivimos.
3. Documentar la nueva metodología a aplicarse dentro la organización
Análisis: El trabajar en la nueva metodología híbrida, fue bastante retador, viniendo de un mundo ágil, pero habiéndome preparado también en algún momento en la metodología tradicional, lo mas interesante fue el adaptar toda la gestión de ejecución del proyecto con el marco de trabajo Scrum.
Esto conllevo al siguiente punto muy importante, el poder socializar dentro la empresa.
4. Capacitación del personal sobre la nueva metodología
Análisis: Realizamos capacitaciones tanto presenciales, como remotas (on demand). Tomo bastante tiempo debido a la cantidad de personas de la organización, pero acomodando los tiempos de todos, realizando material facil de digerir, se puede completar el objetivo de poder preparar a los colaboradores en poder entender y ejecutar de forma adecuada la nueva metodología.
5. Implementación
Análisis: La implementación a mi parecer resulto mas fácil de lo esperado, lo que mas costo fue el poder crear habito de los team members para poder utilizar herramientas colaborativas para realizar el control y seguimiento con tableros Scrum y Kanban.
Todo el comienzo de la incubación, pre factibilidad y constitución del proyecto se realiza con la metodología tradicional, la parte de la ejecución con el marco Scrum y el cierre con las gestiones tradicionales.
Conclusión: Escuche a muchas personas de la comunidad no creer en las metodologías híbridas, sin embargo puedo dar fe que si se pone empeño es posible poder implementarlas y obtener buenos resultados, siempre y cuando nos aseguremos de poder trabajar en el cambio de mindset de los ejecutivos para poder recibir el respaldo necesario.
Trabajar en evangelizar los beneficios principales de la Agilidad en cualquier ámbito de cualquier industria para poder tener la credibilidad, el compromiso y la predisposición de los colaboradores.
También me gustaría señalar que revisando el SBOK, me parece que estuvimos bastante alineados a las practicas y principios de esta Guía.
Tuve la oportunidad de ayudar a incluir la agilidad en la gestión tradicional de proyectos estratégicos de la PMO de una importante empresa, donde se realizo un ajuste a toda la metodología tradicional aprovechando mi conocimiento y experiencia en el mundo ágil de muchos años atrás dentro de varias empresas de desarrollo de Software.
A continuación algunos puntos a resaltar según este emocionante reto.
1. Es imprescindible trabajar en cambiar el mindset tradicional de los ejecutivos para poder recibir el soporte requerido.
Análisis: Es muy difícil poder romper los paradigmas y costumbres del personal de la organización, ya que muchas veces estos se encierran en poder continuar con lo tradicional (funciono hasta ahora por que cambiarlo o deseo ver lo mismos resultados que hasta hoy veo con los métodos tradicionales)
Es critico trabajar en primera instancia en poder cambiar el mindset para asegurar que el cambio no se truncara en el camino.
2. Resaltar los beneficios de incluir frameworks ágiles dentro del desarrollo de los productos de la organización (mejorando el time to market)
Análisis: Esta parte salio naturalmente como una necesidad del mercado, al tener cambios tan frecuentes en las necesidades de los clientes, se vuelve imperativo el poder adaptarnos a estas necesidades si queremos ser competitivos dentro del mercado en la época actual en la que vivimos.
3. Documentar la nueva metodología a aplicarse dentro la organización
Análisis: El trabajar en la nueva metodología híbrida, fue bastante retador, viniendo de un mundo ágil, pero habiéndome preparado también en algún momento en la metodología tradicional, lo mas interesante fue el adaptar toda la gestión de ejecución del proyecto con el marco de trabajo Scrum.
Esto conllevo al siguiente punto muy importante, el poder socializar dentro la empresa.
4. Capacitación del personal sobre la nueva metodología
Análisis: Realizamos capacitaciones tanto presenciales, como remotas (on demand). Tomo bastante tiempo debido a la cantidad de personas de la organización, pero acomodando los tiempos de todos, realizando material facil de digerir, se puede completar el objetivo de poder preparar a los colaboradores en poder entender y ejecutar de forma adecuada la nueva metodología.
5. Implementación
Análisis: La implementación a mi parecer resulto mas fácil de lo esperado, lo que mas costo fue el poder crear habito de los team members para poder utilizar herramientas colaborativas para realizar el control y seguimiento con tableros Scrum y Kanban.
Todo el comienzo de la incubación, pre factibilidad y constitución del proyecto se realiza con la metodología tradicional, la parte de la ejecución con el marco Scrum y el cierre con las gestiones tradicionales.
Conclusión: Escuche a muchas personas de la comunidad no creer en las metodologías híbridas, sin embargo puedo dar fe que si se pone empeño es posible poder implementarlas y obtener buenos resultados, siempre y cuando nos aseguremos de poder trabajar en el cambio de mindset de los ejecutivos para poder recibir el respaldo necesario.
Trabajar en evangelizar los beneficios principales de la Agilidad en cualquier ámbito de cualquier industria para poder tener la credibilidad, el compromiso y la predisposición de los colaboradores.
También me gustaría señalar que revisando el SBOK, me parece que estuvimos bastante alineados a las practicas y principios de esta Guía.
Suscribirse a:
Entradas (Atom)