Agile techniques in retrospective meetings

(Este artículo es traducción de otro en español. Puedes leer el original pinchando aquí)

«We all have to identify options for improvement, and not the obvious ones, but make a detailed analysis of feasibility study proposals, positive or negative impact, restrictions that might result, margin improvement and quantify the benefit»

What I’ve been finding almost always thinking of an agile project retrospective meeting is that we are somehow «corseted» by the de facto standards of Scrum Framework or the Scrum Masters. However I think our obligation is to take one of the bastions of agility as our logo and flag, the continuous improvement, and not simply apply the framework and walk the steps other marked us before.

Before discussing the technical proposal of retrospective meeting, we must identify the context in which we move.

(It’s interesting to visit the website of Scrum Alliance for those who don’t have familiarity with agile project management and specifically with Scrum, (I think it’s the reference in CSM or CPO certifications). You can read a quick guide on the following link: https://www.scrumalliance.org/why-scrum/scrum-guide)

On the one hand we have the goal of retrospective meeting is:

  • Inspect how the last Sprint went with regards to people, relationships, process, and tools;
  • Identify and order the major items that went well and potential improvements;
  • Create a plan for implementing improvements to the way the Scrum Team does its work.

If we translate to a more understandable language, basically we are answering three basic questions:

  • What went well during the sprint?
  • What has gone wrong during the sprint?
  • How can we improve in the next iteration?

And here comes the decisive role of a good Scrum Master. Has an obligation (yes, it is the Scrum Master obligation) to persuade, encourage, facilitate and promote within the Scrum Team to identify issues and options for improvement. And not the obvious ones, but make a detailed analysis of feasibility study proposals, positive or negative impact, restrictions that might result, margin improvement and quantify the benefit.
Scrum is a very serious framework, not by the use of colored pens and post-its roses it is a game. Actually if the team is mature, the margin for improvement is overwhelming, but risk analysis must be taken seriously, impact analysis, analysis of stakeholders and their needs, the viability resources (time, cost and restrictions) the technological impact, technical feasibility or the study of return on investment in those improvements with a great impact in the project, etc.

If you have familiarity with the context, you know that basically what we will find in the vast majority of occasions is the classic «starfish».

Image obtained from http://www.javiergarzas.com/2013/01/retrospectiva-software-agil.html

Really looks like

Starfish retrospective blackboard

Image obtained from http://scrum.menzinsky.com/2015/11/hay-alguna-tecnica-de-retrospectiva-que.html

And it certainly is a very suitable technique and has great potential when acting as a catalyst for generating enhancement options, to change the mindset of the team and give a positive and constructive meeting orientation. The main risk in this technique is that retrospectives usually are not as productive as espected. No options for improvement are identified but it identifies problems to avoid (rather than «how» avoid them). It is the duty of Scrum Master (Yes, again, it is Scrum Master duty) to get the team build options for improvement from a SMART perspective (Specific, Measurable, Assignable, Realistic, Time-related), the same concept we are familiarized in the objectives management. It is important to note that the improvement options are goals to improve project implementation.

But the goodness of the technique that accounts for 90% of the retrospectives becomes more times than we think in their main enemy. We move so far away from identifying problems to build options for improvement that we don’t comprehensively evaluate these same problems we want to solve. For me, there shouldn’t exist a «starfish» without a corresponding graph problem analysis. This technique consists of the following.

Sigue leyendo

Técnicas ágiles para las reuniones de retrospectiva

(This article is the translation of the english version. You can read the original in this link)

«Hay que identificar las opciones de mejora, y no las obvias, sino hacer un análisis en detalle de estudio de viabilidad de propuestas, impacto positivo o negativo, restricciones que pueden derivarse, cuantificar el margen de mejora, cuantificar el beneficio»

Lo que me he ido encontrando casi siempre que pensamos en realizar una retrospectiva de una iteración en un proyecto ágil es que estamos en cierta manera “encorsetados” por el estándar de facto que nos marca Scrum y los Scrum Master de referencia, pero creo que nuestra obligación es tomar uno de los bastiones de la agilidad como bandera, la mejora continua, y no quedarnos simplemente en aplicar el framework y andar los pasos que otros, más intrépidos, nos marcaron.

Antes de exponer la técnica propuesta de retrospectiva, identifiquemos el contexto en el que nos movemos.

(Creo que es interesante, para aquellos que no tengáis una cierta familiaridad con la gestión ágil de proyectos y más concretamente con Scrum, hacer una visita a la Web de Scrum Alliance, para mí la referencia a la hora de certificaciones CSM o CPO en la que podéis leer una guía rápida en el siguiente enlace: https://www.scrumalliance.org/why-scrum/scrum-guide )

Sigue leyendo