Si trabajas en tu día a día cerca del desarrollo de software ágil, seguramente estés al tanto de la actualización recibida por la Guía Scrum el pasado mes de noviembre.

Con motivo de esta actualización, un compañero y amigo, Sergio Rodríguez de Scrumio me invitó a un interesante webinar el pasado martes. La idea no era otra que comentar los cambios introducidos en la guía y abrir debate, sin más.

En esa sesión, tuve a bien tomar algunas notas que hoy quiero compartir aquí. Si aun no te has leído la Guía Scrum 2020, te lo recomiendo, son solo 13 páginas que como poco, te servirán para hablar con conocimiento de causa sobre Scrum, porque Scrum es eso, ni más, ni menos.

Si duda, tanto la Guía, como este humilde artículo, te serán más interesante se tenías muy presente la Guía Scrum 2017, solo así verás la profundidad de los cambios, que esta vez, no son matices, la guía se ha reescrito.

Vamos con los cambios que a mí, personalmente, más me han llamado la atención:

Accountability

Me llama la atención la frecuencia de la palabra accountable/accountability. En la guía de 2017 solo aparecía 3 veces

• The Product Owner may do the above work, or have the Development Team do it. However, the Product Owner remains accountable.
• Individual Development Team members may have specialized skills and areas of focus, but accountability belongs to the Development Team as a whole.
• Scrum Master participates as a peer team member in the meeting from the accountability over the Scrum process.

En la guía de 2020 tenemos 9 referencias, algunas duplicada, pero deja ver, más accountability, más “rendir cuentas”

• The entire Scrum Team is accountable for creating a valuable, useful Increment every Sprint
• Scrum defines three specific accountabilities within the Scrum Team: the Developers, the Product Owner, and the Scrum Master.
• Developers are always accountable for:
  • Creating a plan for the Sprint, the Sprint Backlog;
  • Instilling quality by adhering to a Definition of Done;
  • Adapting their plan each day toward the Sprint Goal; and,
  • Holding each other accountable as professionals.
• The Product Owner is accountable for maximizing the value of the product 
• The Product Owner is also accountable for effective Product Backlog management
• The Product Owner may do the above work or may delegate the responsibility to others. Regardless, the Product Owner remains accountable.
• The Scrum Master is accountable for establishing Scrum as defined in the Scrum Guide.
• The Scrum Master is accountable for the Scrum Team’s effectiveness

Mejor guía:

Creo que esta guía es mejor (opinión personal) por:

• El Scrum Master es más Agile Coach
• Mas accountability
• Más ligera, menos prescriptiva
• Menos dividido (solo un Team)
• Más Sprint Goal (aún) ¿Para qué hacemos este Sprint?
• Más alcance (Product Goal)

Menos divisiones, menos roles, más responsabilidades.

Parece que a algunos les resultaba confuso eso de un Dev Team dentro del Scrum Team, podía dar lugar a pensar que eran dos equipos. Pues nada, fuera Dev Team, ahora son developers, y no como rol, sino con sus responsabilidades.

El equipo es uno, el Scrum Team, ya no hay Dev Team, sino desarrolladores dentro del Scrum Team. Esto en realidad ya era así, pero si has trabajado con equipos Scrum donde eso de que el equipo es solo uno no está asimilado, te resultará familiar eso de «ellos y nosotros»

Si gustaban poco los roles por la titulitis, pues quitamos los roles. Ahora importan las responsabilidades (accountability)

El compromiso sube de nivel

El compromiso se lleva a su máximo exponente, el compromiso no va asociado a la cantidad de trabajo a realizar sino al objetivo a alcanzar. (Outcome vs Output )

Cada artefacto lleva implícito un compromiso:

• Para el Product Backlog es Product Goal.
• Para el Sprint Backlog es el Sprint Goal.
• Para el Increment es el Definition of Done.

Product Goal

¿¿Por qué no Product Vision?? Es la primera pregunta que me hice.
Se introduce el Product Goal, con mucho peso (15 referencias en la guía), llega hasta a definir qué se entiende por producto, pero a la vez, se deja muy abierto:

Un producto es un vehículo para entregar valor. Tiene un límite claro, stakeholders conocidos, usuarios o clientes bien definidos. Un producto puede ser un servicio, un producto físico, o algo más abstracto

https://www.scrumguides.org/scrum-guide.html

Con esto, a mi entender, dependerá mucho del contexto. Productos pequeños igual pueden tangibilizar el Product Goal, en productos más grandes, entiendo que igual se torna más visión. Me parece muy interesante que se introduzca el concepto, estoy expectante por cómo lo asimilarán los equipos.

Esto del Product Goal es la forma que han encontrado para dar respuesta a una crítica muy recibida, que era esa de que Scrum ponía demasiado foco en el Sprint pero no miraba más allá. De hecho, he de confersar que yo en mi trabajo he buscado técnicas a al hora de gestionar el Product Bakclog para “poner las largas” a los equipos.

Scrum Master: True Lider

El Scrum Master, ahora no es Servant Leader sino “True Leader who serves”, un verdadero líder que sirve.

Esto es un matiz que igual es un poco forzado, pero igual, no son pocas las veces que se ven Scrum Master con papel de secretario, además, obligados a mediar y mediar y ser buena gente hasta con el diablo (así se ha entendido en muchas ocasiones un buen Scrum Master) Y esto visto desde arriba, no gusta, y se percibe como una persona que “no hace mucho”. Scrum siempre ha tenido claro la importancia y el peso del Scrum Master, pero en esta guía lo quiere hacer más explícito. Este matiz es lo de menos. Ahora existe una responsabilidad clara del Scrum Master y es la efectividad del equipo.
Además, por si a alguien no le quedaba claro la importancia del Scrum Master, en esta nueva Guía de 2020 la primera referencia al Scrum Master aparece en la propia definición de scrum.

Scrum es un framework ligero que ayuda a las personas, equipos y organizaciones a generar valor a través de soluciones adaptativas para problemas complejos.

En pocas palabras, Scrum requiere un Scrum Master para fomentar un entorno donde: …

https://www.scrumguides.org/scrum-guide.html

Más Sprint Goal

Topic nuevo en la Sprint Planning: ¿Porqué este sprint es valioso? ¿Para qué hacemos este sprint? Viene a decir…Empieza por el Sprint Goal. Tienes que tener claro para qué y porqué vas a currar este Sprint antes de empezar a coger y desarrollar Historias. Es muy común ver equipos que se acuerdan del Sprint Goal cuando lo pide Jira o la herramienta de turno.

¿Menos importancia para el refinamiento?

Se sigue mencionando el refinamiento, pero ya no se sugiere un tiempo por Sprint del 10% como se hacía en la anterior. Este es uno de los cambios que menos me ha gustado. Yo hubiese esperado incluir el refinamiento con más peso aún, no se si obligatorio, pero más peso, sin duda.

Sin output obligatorio de la Retro

Si antes era obligatorio llevar al Sprint Backlog un item de mejora que salía de la Retro, ya no. Ahora simplemente te dice que las mejoras más importantes que salgan de la Retro, las lleves a cabo lo antes posible. Nuevamente menos prescriptiva.

Sin tamaño mínimo

En esta nueva guía, ya no se menciona un tamaño mínimo de los equipos, solo se establece el máximo, que ahora son 10, parece que por redondear para el Scrum Team.

Pues hasta aquí mis notas, extendidas, de aquel interesante webinar. Os dejo también el enlace a un artículo que ya escribió Sergio sobre este mismo tema.

¿Y tu, ves mejoras en esta nueva Guía Scrum 2020?