In my trainings I usually ask the students to agree that we are going to look at Scrum as a methodology, because it is a technique that involves "posture" in front of the method. Believe it or not, this agreement greatly facilitates training and understanding of the different project management techniques that exist in the market, and highlights the importance of which is, in my opinion, the most important of the scrum rituals: the Sprint Retrospective.
The logic behind the concept is relatively simple, and equally powerful: while most techniques on the market are frameworks or methods that either tell you what you can do, or how you can do it, methodologies explain why you should do it, giving you a posture to follow: a clear purpose.
The purpose of the scrum is to respond to changes in project environments, especially when the scope is variable, so it makes so much sense for environments where these changes are inherent in the nature of the project, such as software projects, consulting projects, or capital projects where the investment is long term, and the adaptation to changes in the environment is inherent to the construction.
Understanding the reasons for each methodology makes it easy to understand when and where to apply them, not only that: it is easy to understand that the ceremonies, the artifacts, the tools involved converge for the same purpose. Thus, it is essential that we have moments in our daily lives to remind us of this purpose, and see if we are on the right path. Hence the importance of the sprint retrospective.
Traditional methodologies focus on resource management, people and stakeholder management and even communication management, but they do not create a specific moment for the improvement of these fronts, leaving them to be worked on throughout the project. Which is correct, were it not for the fact that routines usually engulf members in thousands of tasks, and there's hardly any time for the team to think about itself.
That's why the retrospective is such an important moment, that's when the team will look at itself and identify where it can improve. It's a moment of breathing and also a moment of union, the perfect time for team-building practices, for feedback, and also to revisit some agreements that were made in the past and that maybe don't make sense anymore. It's not the only time we're going to look at people, but it's the cornerstone of the entire human development of the project.
I like to leave a retrospective with some well-defined notions, they are:
what went well
what can we improve
Our recommendations.
You can also opt for a more traditional approach:
What we like;
What we hate;
What should we start doing;
What should we keep doing;
What should we stop doing;
It works the same, but for most of the dynamics we do with the team, it's easier to identify these three starting points. It's also important to try to leave a positive mood, so it's good to avoid words that can trigger negativity triggers.
Still, it is common for teams to leave the retrospective aside, focusing more on planning and daily. But managing projects is managing people, is practicing active communication and for that, if I can give you some advice: start with hindsight. Create a moment in it for the team to discuss the pains that exist, throughout the sprints the need for the other ceremonies will be clear, and you will have started with the one that has more value, practicing what you preach.
Comments