# data[].attributes.attachment_link.readable_text
"En el mundo de los negocios, las cosas importantes no son hechas por una sola persona. Son hechas por un grupo de personas."
Si como para mí, a vosotros os es de lo más importantes conseguir equipos eficientes y de alto rendimiento, siguiendo una metodología ágil, en concreto Scrum, sabrás que la retrospectiva es una reunión clave para sacar acciones de mejora para los equipos.

Os paso un resumen de post que he escrito sobre retrospectivas o similar:

Además de otros posts, hablando de la motivación laboral, u otros temas que tienen que ver con la eficacia de los equipos.

Pues aquí va otro. Esta dinámica la encontré por internet, la vi interesante para enfocar o dar otra forma a las retros (aunque en el fondo el objetivo de las dinámicas es el mismo).

Me gusta mucho innovar, hacer cosas nuevas e investigar o crear dinámicas, nos ayudan a dar flexibilidad a nuestros cerebros (ya os hablaré de esto). Y ya no solo a mi, a nivel de aprendizaje y laboral, también a mis equipos. Hacer siempre lo mismo, acostumbras a los cerebros a responder simpre lo mismo, sin dar pie apenas a pensar de otro modo, y eso algo que no me gusta, o que vayan con una idea predefinida, y lo que me importa en estas reuniones es que salgan cosas nuevas e importantes.

Castillo, Casa Común, Casa de Paja y Lobo

La verdad, no he encontrado ningún nombre como tal de la dinámica. Castillo, casa común, casa de paja y lobo, son lo que se utiliza para saber sobre la situación actual del equipo.

La siguiente imagen es una foto de la dinámica una vez terminada.

Se trata de lo siguiente:

Castillo

Cada miembro del equipo, reconocerá individualmente (y luego se pondrá en común con el resto) cosas, prácticas, que han salido muy bien en el Sprint, y hay que seguir manteniéndolas.

Una de las cosas que más sale (en la experiencia que yo he tenido) es el compromiso de cada miembro del equipo, el trabajo tan minucioso que se hace, y el buen ambiente, el buen rollo, que hace que cada día, ir a trabajar no sea una amargura.

Casa común

De igual manera que para el castillo, cada miembro del equipo piensa en aquellas cosas que han ido bien en el Sprint (pero que aún no son prácticas del día a día pero que llevarlas a una rutina puede ayudar considerablemente al equipo a mejorar) y hay que empezar a integrarlas en el día a día hasta que pasen a castillo.

En esta parte, he visto mucho dar ideas de empezar a hacer más pair review, antes de las reviews para revisar el DoD. O pair programming para compartir conocimiento y aprender de los demás, algo por lo que la mayoría de las personas se sienten motivadas, por el aprendizaje.

Casa de Paja

En la casa de paja, se van a poner aquellas cosas que no han salido bien en el sprint, cosas que no hayan salido bien, y que hay que poner especial atención en mejorar.

Ejemplo de cosas que han salido aquí son en un sprint concreto dispersión, o una falta de organización ante algo nuevo, una mala gestión del tiempo, etc. Y a estas cosas hay que ponerlas remedio.

Lobo

Finalmente, en el lobo, se van a poner miedos, debilidades o riesgos que pueda haber.

Ejemplo de esta parte, alguna vez han puesto, la marcha de algún compañero fuerte, incertidumbre en el proyecto, etc.

Nota mental: mejorar en el dibujo =), que por cierto, el sábado 19 tengo el curso de facilitación gráfica, ya os contaré!

Tras la dinámica

Como en cada dinámica, hay que poner todo esto en común, que haya debate y que haya creatividad, ideas, y sacar planes de acción para poner en marcha en el siguiente Sprint a ver si se mejora en algo.

Pese a que una retrospectiva va dirigida a mejora del equipo, siempre saltan temas que no dependen de ellos o piensan que también tienen que mejorar otras partes. En este caso, cada dinámica se puede dividir en dos partes, una orientadas a la mejora del equipo y otra parte orientada a sugerencias, comentarios o mejoras a otros (arquitectura, Product Owner, dirección, testing, etc.).

Terminando...

Principalmente, estas reuniones están orientadas a mejorar como equipo. Suelen tratarse preguntas como las siguiente:

¿Qué cosas han funcionado correctamente?

¿Qué no ha funcionado?

¿Qué he aprendido?

¿Qué quiero hacer en el siguiente sprint?

¿Qué trabas o problemas me han surgido?

Dependiendo de Scrum Master y de dinámicas que se usen se enfocarán más o menos las preguntas anteriores o se hará más hincapié en otro tipo. No obstante, a groso modo se suele tratar temas que responden a las perguntas anteriores.

Para mí, estas son muy importantes para la mejora del equipo, y si hay una mejora en el equipo trabajarán mejor, de foma más eficaz y esto se verá reflejado en las entregas y en su calidad, por eso es tan importante cuidar a nuestras personas.

Espero que os siga dando más ideas para llevar a cabo, y os guste. Ya me contaréis si lleváis a cabo alguna a ver qué tal.

¡Feliz miércoles!

# data[].attributes.attachment_link.title
[Experiencia] Más ideas para retrospectivas

# data[].attributes.attachment_link.description
"En el mundo de los negocios, las cosas importantes no son hechas por una sola persona. Son hechas por un grupo de personas." Si como para mí, a vosotros os es de lo más importantes conseguir equipos eficientes y de alto rendimiento, siguiendo una metodología ágil, en concreto Scrum, sabrás que la retrospectiva es una reunión clave para sacar acciones de mejora para los equipos.

# data[].attributes.attachment_link.readable_text
Few weeks ago I started a series of posts dedicated to Scrum Events.I've already described the Sprint, Sprint Planning and Daily Scrum. In this post I would like to tell you more about Sprint Review.

DEFINITION AND LENGTH

To understand the Sprint Review, we need to start from the definition in the Scrum Guide:

A Sprint Review is held at the end of the Sprint to inspect the Increment and adapt the Product Backlog if needed. During the Sprint Review, the Scrum Team and stakeholders collaborate about what was done in the Sprint.

Inspection and adaptation are two of the three pillars of Empiricism (third one is transparency) which is the foundation of the Scrum. In empirical process control, knowledge comes from experience and that's exactly what is happening during the Sprint Review.

Scrum Team together with all stakeholders inspect the increment and decide what should be done next.

Maximum duration of the Sprint Review is four hours for one-month Sprint. Scrum Master needs to make sure that event takes place and all attendees are aware of the purpose and keep time limits.

If we continue the analogy to running, Sprint Review is like the finishing line. It is the moment when we verify how fast we were running, celebrate success and then based on this we can plan our running techniques for the next race.

COLLABORATION

One of the most important parts of Agile mindset is collaboration - with clients, development team and business. In my post The Relationship between Scrum and Agile you can read more about Agile and why it is strictly related to Scrum.

Sprint Review is focused on the collaboration of all stakeholders and Scrum Team. In the traditional product development the final result/product is presented to stakeholders at the end of the project. If it is a complex product it can take months or even years.

In Scrum, Ken Schwaber and Jeff Sutherland proposed different approach:

Frequent delivery of the increment (not fully completed product).

Collecting the stakeholders' feedback during development of the product.

Collaboration with all of them to optimize the value.

Collaboration with the customer is necessary to satisfy them and fulfill their needs. Moreover it saves a lot of Development Team's time, because they know the direction of the development and they adjust their work if needed. I believe that this approach is much more effective and valuable than traditional development of the products.

DONE & NOT DONE WORK EXPLAINED

Sprint Review is the time for the Product Owner to explain what has been "Done" during the Sprint and what has not been "Done". The Development Team should demonstrate "Done" work and answer all stakeholders' questions about the increment. That's the moment for stakeholders to play around with the product and check if all their needs and priorities are fulfilled.

It is important to mention that the Development Team should make sure that they present only "Done" work using the definition that they agreed for.

The Sprint Review event is also time for discussion about positive aspects of the Sprint (successes), issues that appeared and how they were solved. It can be a great opportunity to discuss communication between stakeholders and the Scrum Team and find the best solutions.

PRODUCT BACKLOG - NOW & THE FUTURE

Product Owner presents the current status of the Product Backlog and gives the estimation of delivery based on the team velocity. It's important to mention that it is just the prediction, not fixed dates. Specific plans for each Sprint are created by the Scrum Team during the Sprint Planning session.

All stakeholders and the Scrum Team should collaborate about priorities for the upcoming Sprint. They can be related to change in the marketplace or business strategy. It is important to analyze and decide what will deliver the maximum value to the business.

The outcome of the Sprint Review should be the revised Product Backlog that will include prioritized work items for the next Sprint. It will be used by the Scrum Team in the next Sprint Planning meeting.

SUMMARY

The most important information about Sprint Review meeting:

The maximum duration of the meeting is 4 hours for one month Sprint.

Participants: Scrum Team and stakeholders invited by Product Owner.

Collaboration is a crucial part of the meeting. It is time for collection of feedback and understanding stakeholders' needs.

The Product Owner should explain what was "Done" and not "Done" during the Sprint.

The Development Team demonstrates "Done" Increment.

It is also time for discussion about positive and negative aspects of the Sprint in order to create the best solution for the future.

During Sprint Review Product Backlog should be presented by the Product Owner with the estimated plan for the future.

All participants should collaborate to decide about work priorities and the direction for the next Sprint.

Sprint Review is a great tool for Scrum Team that helps to verify if stakeholders are happy about the increment and what is the most important work that needs to be included in the next iteration. This knowledge helps to plan the work and deliver business value.

# data[].attributes.attachment_link.title
Scrum Events #4 Sprint Review | Let's Scrum it!

# data[].attributes.attachment_link.description
Few weeks ago I started a series of posts dedicated to Scrum Events.I've already described the Sprint, Sprint Planning and Daily Scrum. In this post I would like to tell you more about Sprint Review.

# data[].attributes.attachment_link.readable_text
¿Qué beneficios tiene un Daily Scrum?

Gracias al daily scrum se elimina la necesidad de realizar otras reuniones innecesarias que antes realizaba el equipo.

Se identifican impedimentos a eliminar, que son relativos al progreso para conseguir el Sprint Goal.

Resalta y promueve la toma rápida de decisiones, porque están juntos las personas que van a tomarlas.

Mejora el nivel de conocimiento del equipo de desarrollo.

Mejora la colaboración del equipo.

Es una reunión clave de inspección y adaptación.

¿Por qué tenemos que hacerla en un tiempo máximo 15 minutos?

El timebox es la asignación de una unidad de tiempo fija y máxima a una actividad. El objetivo del timebox es definir y limitar la cantidad de tiempo dedicado a una actividad. Esto ayuda y anima a los equipos a empezar a trabajar rápidamente en los objetivos poniendo foco en lo que realmente importa en un momento dado. La teoría de la motivación temporal muestra que las limitaciones de tiempo son un componente crítico para hacer el trabajo eficientemente. En Scrum, cuanto antes puedas inspeccionar un entregable, antes podrás adaptarlo.

¿Quien participa en la Daily Scrum?

La daily es una reunión exclusiva del equipo de desarrollo. Solo ellos deben participar, de hecho si hay otras personas presentes en dicha reunión, el Scrum Master debe de asegurar que no interrumpan al equipo.

¿Por qué tiene que ser a la misma hora y en el mismo sitio?

Simplemente para reducir la complejidad, para que sea más sencillo para todo el equipo de desarrollo saber donde y cuando va a ocurrir y no tener que decidirlo cada día.

¿Quien facilita la Daily Scrum?

Mucha gente piensa que el Scrum Master tiene que facilitar la daily, de hecho muchos equipos no hacen la daily porque algunas veces no está el Scrum Master. Según mi opinión si esto sucede es que no se ha entendido bien el concepto de la daily que Scrum nos dice. Yo considero que es importante que al principio el Scrum Master ayude al equipo a entrar en la dinámica, pero conforme avance el equipo, él mismo debe coger las riendas de facilitar su propia daily. La labor del Scrum Master aquí es asegurar que este evento tenga lugar y que el equipo lo mantenga en el timebox, y sobre todo que el equipo de desarrollo entienda por qué este evento es importante para la consecución del Sprint Goal.

¿Cómo se facilita una Daily?

Muchos equipos suelen usar las tres típicas preguntas:

¿Qué hice ayer para ayudar al equipo para alcanzar el Sprint Goal?

¿Qué voy a hacer hoy para ayudar al equipo para alcanzar el Sprint Goal?

¿Cuáles son los impedimentos que tengo que me dificultan mi progreso para que el equipo alcance el Sprint Goal?

Pero es importante saber que es el equipo el encargado de establecer la estructura de la daily, ya que conforme su madurez aumenta pueden adoptar otro formato si así lo consideran.

Disfunciones en una Daily Scrum Meeting

A menudo los equipos me dicen:

"Nosotros hacemos la Daily Scrum una vez a la semana."

"Como tenemos que decir lo mismo que ayer entonces la hacemos solo dos veces a la semana."

"Vamos mal, pero no pasa nada; ya lo veremos en la Retrospectiva al final del Sprint."

Otros directamente: "hemos optado por no hacer la Daily y reemplazarla por una sincro de una hora a la semana, ya que perdemos mucho tiempo todos los días."

Antes de intentar buscar acciones para abordar estas situaciones estaría bien que reflexiones sobre unas cuestiones que te dejo a continuación:

¿Realmente los equipos entienden bien el objetivo de la daily?

¿Los equipos cumplen con estos objetivos?

¿Están claros los beneficios?

¿Nuestra daily está siendo productiva?

Algunas de estas reflexiones los equipos las pueden hacer durante el sprint o durante el evento de la retrospectiva, con el objetivo de inspeccionar y la adaptar los procesos que en este caso específico sería la daily. Es importante que los equipos entiendan que en Scrum se persigue la mejora continua, tanto a nivel de producto como a nivel de marco de trabajo.

Algunas ideas para afrontar estas disfunciones

Veamos algunos casos:

"Hacemos la daily pero nos lleva más de 15 minutos": en este caso debemos de reflexionar el porqué nos lleva más tiempo, a veces porque muchos equipos hablan de cosas que no tienen nada que ver con el objetivo del sprint.

"No tengo nada que decir, sigo con lo mismo que hace 4 días": es importante que trabajemos en pequeñas partes del trabajo, ya que nos ayudan a hacer un mejor seguimiento para alcanzar el objetivo del sprint y fomentar la colaboración y la identificación de cuellos de botella lo antes posible.

"Hago reporte a mis compañeros respondiendo las 3 preguntas (¿qué hice ayer? ¿qué haré hoy? y ¿qué problemas tengo?)": no se trata de hacer reporte a tus compañeros o al scrum master, sino de sincronizarnos e inspeccionar al plan para alcanzar el objetivo del sprint y adaptarlo si es preciso.

"Hoy hay muchos detalles que contar por unos problemas y nos llevará mucho tiempo": no pasa nada, al terminar la daily el equipo se reúne de nuevo (o las personas involucradas) para abordar los temas.

Lo que veo muy a menudo es que la gente tiende a considerar la daily como un simple reporte individual a sus compañeros. Eso en el mejor de los casos, en otros es al Scrum Master o al Product Owner. "Yo hice esto... y voy a hacer aquello...", uno por uno. Según comenta Jeff Sutherland en su libro " El nuevo y revolucionario modelo organizativo que cambiará tu vida ": El enfoque óptimo se parece más a lo que hacen los jugadores de rugby cuando hacen un corrillo para hablar. Uno puede decir: "A mí me está dando problemas tal defensa", a lo cual un delantero puede responder: "Yo me encargo de eso. Yo abro esa línea". Otro puede decir: "Nuestro juego de campo no funciona; sorprendámosles haciendo un pase por la izquierda".

Libros de interés sobre Scrum

# data[].attributes.attachment_link.title
▷ Daily Scrum ¿Qué es? - Youssef Oufaska

# data[].attributes.attachment_link.description
El Daily Scrum es uno de los eventos del marco de trabajo Scrum. La Daily consiste en reunirse todo el equipo de desarrollo todos los días 15 minutos como máximo para inspeccionar el Sprint Backlog, adaptar el plan y eliminar los impedimentos para progresar hacia la consecución del Sprint Goal.

# data[].attributes.body
Curso SCRUM // capacitaciones.agrocalidad.gob.ec/capacitaciones
youssefoufaska.com/daily-scrum/
letsscrumit.com/scrum-events-4-sprint-review
mariamorales.net/2018/05/16/experiencia-mas-ideas-para-retrospectivas/

# data[].attributes.headline
Encontrar puntos de mejora para iniciar pequeños cambios

# data[].attributes.subject
Encontrar puntos de mejora para iniciar pequeños cambios

# data[].attributes.headline
Scrum master debe ser en esta reunión un verdadero COACH

# data[].attributes.subject
Scrum master debe ser en esta reunión un verdadero COACH

# data[].attributes.body
Hacer diámicas
Se analiza al equipo, que se rompa el hielo, que se conozcan y empiecen a hablar

# data[].attributes.headline
Recolectar datos para mejorar en los próximos sprints

# data[].attributes.subject
Recolectar datos para mejorar en los próximos sprints

# data[].attributes.headline
El Sprint Review se hace al final de cada Sprint

# data[].attributes.subject
El Sprint Review se hace al final de cada Sprint

# data[].attributes.headline
En el review los stakeholders ven los avances

# data[].attributes.subject
En el review los stakeholders ven los avances

# data[].attributes.headline
En el review los stakeholders dan feedback

# data[].attributes.subject
En el review los stakeholders dan feedback

# data[].attributes.headline
En Sprint de 1 mes - review de 4 horas máximo de duración

# data[].attributes.subject
En Sprint de 1 mes - review de 4 horas máximo de duración

# data[].attributes.body
Transparencia
Inspección
Adaptación

# data[].attributes.headline
No mezclar sprint review con retrospectiva

# data[].attributes.subject
No mezclar sprint review con retrospectiva

# data[].attributes.body
¿Qué hice ayer?
¿Qué voy a hacer hoy?
¿Qué impedimentos hay?

# data[].attributes.body
Si hay dudas extras, realizarlas fuera del daily
Es mejor hacer el daily de pies
Hacer el daily junto al tablero del sprint
Si se acaba el tiempo, es mejor parar y continuar al siguiente día
Todos deben colaborar entre sí
Trabajar en equipo