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.
martes, 15 de septiembre de 2015
I cleared my PMP exam yesterday!!!
I am so glad to announce that i passed my PMP exam yesterday on my first try, a good gift for myself in my local city anniversary.I wouldn't success without the feedback received in this forum, all lesson learned inputs helped me a lot, so i will leave my personal experience here.
1. I read the PMBOK twice
2. I read in deep Rita prep book three times.
3. Answered hundred of online free tests (Most of them mentioned in his group, Thank you all..)
4. I took a preparation course some time ago with two excellent teachers, I want to special thank to Rocio Zelada and Cecilia Boggi for the classes.
5. I participated in one PMP prep experience session with my colleague Alvaro Pozo that help me to have the initial guide in how to prepare for this moment, Thank you Alvaro...
6. I prepared my self every day by two hours during 5 months, focusing in understanding all PMIs and trying not to memorize all basic concepts.
7. I reviewed Saket Bansal's videos very helpful for most of the concepts.
8. I reviewed as well Linda Fiorenzano's videos very direct concepts for PMP
9. I was selected by the audit which i know the majority had been selected last months, i just prepared and sent the required support docs and they approved it in the following 5 days, I want to special thanks to Lucia Argandona for helping me in this approach.
I want to advice to the people that are going to take the test not to stress to much, i couldn't sleep too much the day before the test so i arrived little sleepy to the test center and couldn't have the chance to bring with me coffee or candies (so take your previsions), the personal didn't have them in the center, and another thing was that they used to enter to the room every 15 min that distracted to me a little, the time i think was just enough to answer all questions with just 5 min left to review marked questions, the real exam was not so quite different from the tests i found, but most of them need to understand how to handled the scenarios more than answer general concepts.
1. I read the PMBOK twice
2. I read in deep Rita prep book three times.
3. Answered hundred of online free tests (Most of them mentioned in his group, Thank you all..)
4. I took a preparation course some time ago with two excellent teachers, I want to special thank to Rocio Zelada and Cecilia Boggi for the classes.
5. I participated in one PMP prep experience session with my colleague Alvaro Pozo that help me to have the initial guide in how to prepare for this moment, Thank you Alvaro...
6. I prepared my self every day by two hours during 5 months, focusing in understanding all PMIs and trying not to memorize all basic concepts.
7. I reviewed Saket Bansal's videos very helpful for most of the concepts.
8. I reviewed as well Linda Fiorenzano's videos very direct concepts for PMP
9. I was selected by the audit which i know the majority had been selected last months, i just prepared and sent the required support docs and they approved it in the following 5 days, I want to special thanks to Lucia Argandona for helping me in this approach.
I want to advice to the people that are going to take the test not to stress to much, i couldn't sleep too much the day before the test so i arrived little sleepy to the test center and couldn't have the chance to bring with me coffee or candies (so take your previsions), the personal didn't have them in the center, and another thing was that they used to enter to the room every 15 min that distracted to me a little, the time i think was just enough to answer all questions with just 5 min left to review marked questions, the real exam was not so quite different from the tests i found, but most of them need to understand how to handled the scenarios more than answer general concepts.
martes, 25 de noviembre de 2014
Daily standup meeting tips
I want to share some
tips for improving the daily meeting ceremony. I will start defining the three
basic rules.
- Every team member report what have being done yesterday
- What are you plan to during the day
- What is blocking your task progress
First my advice is to place the
daily meeting at the first hours of the work day, since we share our progress
and problems so all team can support and assist any team member. Every team
member should be at least 5 minutes before meeting starts, so we avoid interrupting
any member report. We have a 15 min time box for this meeting as maximum if
some specific issue is raised we should discuss it offline with only the
persons involved (time is gold and we don't want to waste the rest of the
team).
We also must follow an order for the
reports we can use the table place order starting from the right, when someone
starts should say his name and briefly the working progress (percentage of the
task) and when he/she expects to complete it, we must avoid being too general
or detailed, when he/she finish should say something like "That's it"
, "That's me" or "That would be my day" so remote people
can be aware that is his turn to continue.
One good practice is to review
during this meeting the task board, so we can have a clear picture of the
current work progress, we can display the burn down chart and review the
remaining sprint resources hours, then we can identify the people that needs
more help or if it would be necessary to notify some risk in order to complete
the committed user stories to stakeholders.
In my experience I think would be
great to include the PO in this meeting if it is possible so he/she is committed
as well with the team and known the current progress.
Hope this will be helpful for your teams.
Please don't hesitate to leave your comments/questions.
jueves, 6 de noviembre de 2014
Struggling with our Product Owner
I have been working for
many years in many software companies and I could realized that most of them
had the same issue with the Product Owners, I will list a few of them.
· Providing not much more
than a high level, ordered Backlog and availability to the team for
questions or clarification was extremely limited.
· User Stories were
developed, but were inconsistent and refined too late—often in the middle
of the Sprint.
· Backlog grooming
(maintenance) was inconsistently practiced, if practiced at all.
· The Backlogs themselves
were inconsistent across teams—making organizational strategic
planning and overall progress measurement very difficult.
· Forward-looking release
planning was nearly avoided.
· Little time was spent
‘connecting’ external stakeholders to the performance, efforts, and
dynamics of their teams.
Is all of the above
points seems familiar in your organization?. I will give some tips for
improving that issues so we can deliver a high product in schedule and budged.
I think one of the more
appreciated value that PO should has is the commitment with the team itself, I
know that many times PO has a lot of limited time since they have all day
meetings, but when the team needs him, he always should be available to respond
to it. One good practice I found for that approach was to set daily meetings
that we called collaboration meetings, in that slot of time we use to take all
possible advantage from our PO, like grooming the US, clarifying the acceptance
criteria, demo the feature progress (Dev & QA) so in that way we receive
the necessary feedback in time, so we don´t need to wait at the sprint review
every end of the sprint. If this is not possible for time availability reason,
we can set a different time for a couple of minutes with the PO for at least
demoing and review the team´s progress, for all the rest we can send him the
questions or clarifications requirement through email or im. If this really is
not possible we should escalate the problem with the PO´s chief.
So the key for having a
good communication and collaboration is to have our PO committed with the team,
as everyone knows that at final release all team (Scrum Master, Product Owner
and team members) is in play, everyone wins or everyone lose.
Hope this can help a
little in your current organization.
viernes, 24 de mayo de 2013
Diferencias entre Product Owner y/o Scrum Master y Project Manager
En realidad el
rol como tal de Project Manager no está considerado dentro de Scrum. Lo que reemplazaría
al rol de Project Manager seria en todo caso el Scrum Master y el Product
Owner, por su parte el scrum master tiene como principal función el de
identificar y mitigar los impedimentos del trabajo del equipo, en vez de tener
un perfil directivo mantiene un perfil colaborativo, se asegura que todo el
equipo siga de forma adecuada todas las ceremonias y directrices que conlleva
Scrum y por ultimo asegura que todos tengan buena comunicación y los
entregables se terminen a tiempo. Por su parte el Product owner se encarga de
crear el product backlog con todos los requerimientos ordenados y priorizados,
trabaja al lado de los stakeholders para poder aceptar y aprobar los
entregables de cada sprint. El Project Manager por su esencia abarca más áreas donde
controla todo el tiempo riesgos, alcance, costos, adjudicaciones, etc.
Recuerden que en Project Management se enfoca más en la planificación mientras
que en Scrum se tiene más en cuenta la respuesta al cambio constante donde se
trabaja de cerca con el cliente para poder acelerar la entrega final del
producto (en mi opinión una gran ventaja en especial en el área de desarrollo
de software).
Mi consejo para
las personas de desempeñan el rol de Scrum Master es que traten de hacer un mix
en sus proyectos, teniendo en cuenta la buena planificación así como
implementar Scrum para tener una respuesta al cambio eficiente, con personas
comprometidas en su trabajo (Autogestionados).
Si alguien tiene
un aporte no dude en escribirme o dejar sus comentarios, todos serán bienvenidos
para así poder enriquecer el conocimiento conjunto con experiencias rescatadas
en el mundo real.
miércoles, 6 de marzo de 2013
Scrum Bolivia Day 2013 Coming Soon
Segunda versión del Bolivia Scrum Day a llevarse a cabo el 30 de Marzo, en el Hotel Camino Real en la ciudad de Santa Cruz de la Sierra. Acá les dejo el contenido de las presentaciones y los nombres de los expositores:
Programa
Sábado 30 de marzo de 2013
8:00-8:30 Acreditación
8:30-9:30 Desafíos del manager en la era ágil - Federico Zuppa
9:30-10:30 Los 10 mandamientos de TDD – Hernan Wilkinson
10:30-11:00 Break
11:00-12:00 Good Practices in Software Test Automation – Camilo Ribeiro
12:00-14:30 Break
14:30-15:30 Craftsmanship – Desarrolladores ágiles, profesionales y responsables - Carlos Peix
15:30-16:30 Why do we use Scrum? – Juliano Ribeiro
16:30-17:00 Break
17:00-18:00 Disfunctions of Scrum: how to avoid them and extract the most from Scrum – Samuel Crescêncio
18:00-19:00 ¡No estimarás! – Thomas Wallet
A todas las personas que puedan asistir les recomiendo que sean puntuales. Solo un día al año podemos contar con la experiencia de profesionales con vasta experiencia en empresas de software en el exterior.
Para mayor información dirigirse al link http://scrumbolivia.com/
Programa
Sábado 30 de marzo de 2013
8:00-8:30 Acreditación
8:30-9:30 Desafíos del manager en la era ágil - Federico Zuppa
9:30-10:30 Los 10 mandamientos de TDD – Hernan Wilkinson
10:30-11:00 Break
11:00-12:00 Good Practices in Software Test Automation – Camilo Ribeiro
12:00-14:30 Break
14:30-15:30 Craftsmanship – Desarrolladores ágiles, profesionales y responsables - Carlos Peix
15:30-16:30 Why do we use Scrum? – Juliano Ribeiro
16:30-17:00 Break
17:00-18:00 Disfunctions of Scrum: how to avoid them and extract the most from Scrum – Samuel Crescêncio
18:00-19:00 ¡No estimarás! – Thomas Wallet
A todas las personas que puedan asistir les recomiendo que sean puntuales. Solo un día al año podemos contar con la experiencia de profesionales con vasta experiencia en empresas de software en el exterior.
Para mayor información dirigirse al link http://scrumbolivia.com/
Suscribirse a:
Entradas (Atom)