(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”.
Really looks like
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.