Autor

Ingeniero de Telecomunicación, MBA y Master en Marketing Online y Comercio Electrónico. Pedro tiene una misión: lograr que Equipos de Alto Voltaje desarrollen productos digitales asombrosos. Optimista infatigable, le encanta trabajar duro con personas inteligentes. Como Scrum Master, le obsesiona conseguir que equipos felices entreguen el máximo Valor posible. Firme defensor de hábitos saludables, se pregunta por qué, a lo que parece, nadie sabe desayunar como es debido. Lema que le guía: "Talent wins games, but teamwork and intelligence win championships.”, Michael Jordan.

Redactor en

¿Cómo crear un Sprint Goal?

Si has trabajado con Scrum es muy probable que, en más de una ocasión, hayas tenido problemas para definir un Sprint Goal.

Quizás te hayas preguntado si el elemento más alto en el Product Backlog es teóricamente el más valioso, ¿debe ser la base para definir el Sprint Goal? o ¿qué hacemos cuando tenemos varios ítems en la parte alta pero no tienen correlación? ¿Formamos un Sprint Goal con “A”, “B” y “C”? ¿Puedo tener más de un Goal por Sprint?

En el anterior post El Poder del Sprint Goal, vimos la importancia de trabajar con Sprint Goals en Scrum. En este post veremos cuándo se crean, la principales técnicas que podemos usar para definirlos y distinguiremos algunas tipologías de Sprint Goals.

sigue leyendo…

El poder del Sprint Goal

“¿Es un Fortissio Lungo? Porque huele de maravilla”, me preguntó Gonzalo, Product Owner del Equipo Telcom, justo antes de comenzar el Sprint Review #4. Yo me había incorporado un par de días antes al equipo como Scrum Master y, en medio de la calma y el olor a café, no pude prever la tormenta que se avecinaba.

Habían transcurrido menos de 20 minutos cuando Alonso de Benavides, principal stakeholder y sponsor del proyecto, lanzó la pregunta que retumbó como un trueno en la sala: “Entonces, ¿se puede saber qué demonios habéis hecho en este Sprint?”.

A lo que Gonzalo respondió con voz trémula, no sin antes tragar saliva: “El equipo ha terminado los jiras TL-34 y TL-35, relativos al área de usuario, y también del TL-40 al TL-44, que han mejorado el tiempo de carga de las páginas del catálogo de productos”.

La cara de Alonso se volvía azul por momentos. En la sala todos le miraban, mientras contenían la respiración, sin llegar a entender por qué reaccionaba de esa manera.

Alonso, sometido a una gran presión desde hacía meses, se puso en pie, como si quisiera reforzar su mensaje, y añadió: “Os dije que era vital para la compañía poder vender el nuevo producto de TV-Streaming al final de este Sprint, ya que nuestra competencia nos está machacando desde que lo sacó al mercado hace dos meses”.

Gonzalo, que recordó vagamente haberlo mencionado al equipo durante el Sprint Planning, contestó, casi con la voz rota: “Me temo que al equipo no le dio tiempo de terminar los jiras para esa funcionalidad, se atascaron y decidieron continuar con otras cosas para completar más ítems del Backlog y no bajar la velocidad”.

Tras escuchar su respuesta, Alonso mostró una leve sonrisa, de esas en las que la boca hace una mueca rígida y el resto de la cara permanece inmóvil.

Después de unos segundos de silencio sepulcral, aseveró: “Me temo que no habéis entendido nada y es muy decepcionante. No habéis comprendido las prioridades del negocio, lo que aporta valor y nos hace sostener esta compañía. No sabéis distinguir lo importante de lo accesorio. Es una situación muy preocupante que espero resolváis en el próximo Sprint o tendré que tomar medidas”, al tiempo que abandonó la sala.

No pude evitar pensar que nada de esto habría ocurrido si el equipo Scrum hubiera aprendido el poder del Sprint Goal. La buena noticia, pensé por sacar algo positivo de la situación, es que teníamos una oportunidad para Inspeccionar-nos y Adaptar-nos en la próxima Retrospectiva. ¡A por ello!

sigue leyendo…

El Development Team, más que un equipo de “desarrolladores”

Si has trabajado con equipos Scrum, alguna vez te habrás preguntado quiénes forman parte del Development Team. Por ejemplo, ¿todos los desarrolladores que escriben código son el Development Team? ¿Qué sucede con los que no escriben código? ¿Son también “desarrolladores”?

De hecho, muchas veces me han hecho esta pregunta los propios miembros de equipos Scrum con los que he trabajado e incluso ha sido objeto de debate en la comunidad ágil de Paradigma. ¡Arrojemos luz sobre la cuestión!

sigue leyendo…

Los 5+1 valores de equipos Scrum altamente efectivos

Decía Stephen R. Covey, en su libro “The 7 Habits of Highly Effective People”, que las personas que centran su vida en torno a unos principios sólidos tienen una mayor probabilidad de alcanzar el crecimiento personal e interpersonal y, sencillamente, ser más felices.

Sin embargo, si los principios son el territorio, los valores representan el mapa con el que movernos por ese territorio. Los principios son externos y objetivos, son las leyes naturales que determinan las consecuencias de nuestros actos, mientras que los valores son internos y subjetivos, sirviéndonos de guía para nuestra conducta.

Si extrapolamos esta idea al concepto de equipo parece muy interesante preguntarse cuáles son los valores que pueden convertir a un equipo promedio en un equipo que sepa interpretar la realidad con un buen mapa, que les permita tomar la mejor decisión posible en cada momento y actuar en consecuencia. Así pues, ¿te gustaría conocer qué valores crean equipos altamente efectivos?

sigue leyendo…

Product Owner, ¿interno o del cliente?

Suele haber con frecuencia, en los equipos de trabajo del sector IT, un debate abierto sobre la figura del Product Owner. Este debate surge en los momentos en los que el Product Owner no cumple con lo que se espera de él.

En términos de Scrum, el rol de Product Owner tiene unas funciones claramente identificadas y su correcto desempeño es vital para el éxito del Producto.

Sin embargo, cuando el Product Owner proviene del cliente a veces nos resulta muy complicado conseguir que éste cumpla con lo esperado.

¿Qué hacemos en estos casos? ¿Sería mejor que el Product Owner fuera también de nuestra empresa?

sigue leyendo…

The Development Team, more than just a team of “developers”

If you’ve worked with Scrum teams, you have probably wondered who is part of the Development Team. For example, are all developers that write code in the Development Team? What happens to those who do not write code? Are they also “developers”?

In fact, I have often been asked this question by members of Scrum teams with whom I have worked and it has even been the subject of debate in the agile community of Paradigma. Let’s shed light on the question!

sigue leyendo…

The 5 + 1 values of highly effective Scrum teams

Stephen R. Covey, in his book “The 7 Habits of Highly Effective People”, said that people who focus their lives around solid principles are more likely to achieve personal and interpersonal growth and, simply, be happier.

However, if the principles are the territory, the values represent the map with which to move through that territory. The principles are external and objective, they are the natural laws that determine the consequences of our actions, while the values are internal and subjective, serving as a guide for our behavior.

sigue leyendo…

Product Owner, internal or client’s role?

There is often an open debate regarding the role of the Product Owner in IT sector teams. This debate sometimes comes up when the Product Owner does not comply with what is expected of them.

In terms of Scrum, the role of Product Owner has clearly identified functions and their correct performance is vital to the success of the Product.

However, when the Product Owner’r role comes from the customer, sometimes we find it very difficult to get them to meet expectations.

What do we do in these cases? Would it be more suitable if the Product Owner was someone from our company?

sigue leyendo…