(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.
We construct a graph whose nodes are the groups in that have classified the identified problems and the edges are causal relationships (cause -> result) or interdependent relations (cause <-> cause) among these problems. It is possibly one of the best ways to give rise to a profitable retrospective and a technique effective improvement options. In a summary illustration, we could see as follows:
Each team member has to identify five problems in the project. It is important that each Scrum Team member complete the problem identification before to paste post-it on the board (in order to avoid anyone can asumme the the idea of those who have a greater weight in the team as the right one)
Once placed on the board, they are grouped by the criteria identified among the group. Here it is important the work of the ScrumMaster as a facilitator when the group is not able to identify grouping criteria that provide useful and valuable information context.
Once grouped the problems, we proceed to look for the root cause, identifying, for example, the Five Whys of these problems and include them in the corresponding groups, respecting the relationship root cause on the vertical axis. No need to set 5 steps on each problem, some will be a root cause originally, others will not take more than 3 steps and others will need the “Five Whys”. Also keep in mind that in a given link we find that the cause is already identified as problem above, may be causal chains that include elements considered as primary.
Once done this work, we review whether the elements of the causal chain are in the correct group, since it is possible that the cause of a problem, or one of the intermediate links in the causal chain is in a different group. (For example, we can identify a problem that is the unreliability of the estimates, but it may be because we don’t have technical skills on a particular tool. The first problem could be framed in the group of “scheduling problems”, but his next link causal would be that of “training issues”)
Now we set up a painting graph edges between groups or between problems of different groups (excluding the causal relationships of the Five Whys technique, they expressed precedence on the vertical axis)
Finally, each team member takes several post-it with a weight measure and assigns them to the issues he considers most relevant or have greater impact on the project. I usually use Fibonacci and use 2, 3, 5 and 8 so that there is bigger difference in the allocation of weights and more complicated that offset the lower value.
It should be more like this….
And now we would just start constructive part of the retrospective, which is really productive. But I think it’s important to have several tools to take advantage of Scrum or Agile frameworks in project management, beyond blackboards filled with colors and stickers.
Thank you for reading the full post, I am glad that has proved interesting enough to get this far. Please do not forget to share this and other post with those that you think may have a similar or who may be useful to them interest. The knowledge must be shared!