Retros aren't just an Agile thing, they're a critical way to empower engineers and enable them to be in charge of their own improvement.
Many engineers have a distrust for management and (especially) managers who aren't like them (as few are actually managed by fellow engineers).
One developer on Quora put it this way, “managers [who don’t get them] tend to treat engineers as ‘resources’ and not humans.” So this affects how they view new tools like retros—seeing them as another silly thing management is imposing.
However, done correctly and with the right approach, retros can be a game changer: engineer-led and genuinely empowering.
So let’s get into the importance of retros for engineer enablement.
But before then, let's talk about:
The truth is, engineers are the most likely to know what is beneficial to them.
This is why enabling them to create action items from retros they run themselves and setting trackable team-level improvement goals in the process is a major step in the right direction. This way, engineers (and their needs) can be adequately understood without the frustrations and hitches of being managed by someone who isn't an engineer.
In any case, the most empowering retros function continuously, allowing the thoughts of all engineers to be captured throughout the delivery period. So, the team must be comfortable sharing ideas and feedback when necessary without fearing it may haunt them.
If a manager senses something is wrong, instead of dictating what they view as a solution, they can support their team by setting up a different time with their direct report, the team, the product owner, or Scrum Master to discuss their concerns.
An effective manager should accept differences in roles, respect team boundaries and allow everyone to grow and learn. They should ask and expect teams to improve within the possibilities and limitations of the organization, providing the freedom for engineers to choose to improve immediately or not, depending on factors the engineers themselves best understand.
When a manager empowers his engineers with retros, they run themselves, respects their judgments, and relies on their skills and professionalism; the manager goes from being a just distributor of tasks and writer of performance reviews to being a builder/nurturer of talent and facilitator of progress—both of which are essential (human) resources for every organization.
That said, let’s get into it.
Retros are a rare place for the engineers (including the introverted ones) to get candid with each other, discuss roadblocks, workflow issues, and complex team dynamics, celebrate milestones and colleagues, and discuss how successes can be replicated.
During retrospective meetings, your engineering team can evaluate code reviews and analysis, QA, CI/CD, user feedback, test automation, and so forth, making it perfect for highlighting the areas where problems exist and improving your work environment.
Besides, your team can benefit even more from sharing retrospective examples with other teams. This cross-pollination can then help managers in the organization identify patterns and insights that can benefit the whole organization.
Just make sure your retros ensure holistic and objective tolerance of all parties. You don't want your engineers to have big ambitions or bring up great ideas only to have them deflated and rejected when those ideas go nowhere.
In addition, never let retros feel like a one-person show where just one or two people highlight issues important to them and propose only solutions that work in their favor. Otherwise, you'd miss out on excellent ideas from other team members who may have been (inadvertently) forced to be quiet.
Engineers want to be heard and appreciated, so taking time out via retros to listen to their opinions regularly will help create and foster their interests in your organization.
For example, your engineering team may already share feedback at the end of your meetings. Still, with only five minutes left at the end of a meeting, it doesn't exactly communicate the worthwhileness and value of the feedback. Not to mention the fact that anyone contributing is delaying the end of the meeting everyone is likely waiting for.
Besides, it may be pretty hard for engineers to make and convey meaningful contributions when they are put on the spot, making retros an excellent option for generating and gathering insights to improve workflow efficiency that can be tried and tested immediately. Eventually, those improvements extend to the organization at large.
Furthermore, retros are an avenue to reflect with your team; a vital catalyst for fast improvements in any organization.
Without taking the time to reflect, some issues won't be highlighted as soon as they should be. Others may never come up at all. If either scenario happens, you risk becoming ignorant of critical organizational problems. However, by inserting a feedback loop into your team's work process, you can detect problems, learn, and improve.
Frequent retros with an action plan lead to sustainable impacts on productivity and growth, as engineers can hold themselves accountable and quickly reassesses the impact of the action items in the last retrospective.
Several topics and action elements are also given maximum attention with actionable steps that will yield the results outlined.
The T-E-D mnemonic (Tell, Explain, Describe) is a great way to ensure that issues aren't just raised but acted on. With this method, when items or issues are highlighted, you can ask open-ended questions such as "tell me what we could do to resolve this" or "explain the steps we could take to improve this" and create a plan for solving the issues right there.
Because retros are an excellent avenue to highlight hurdles and offer solutions while enabling the involvement of every engineer, they make their lives and work process much easier and more efficient.
By leveraging ScatterSpoke for your team’s retrospectives, you empower your team with AI that spot patterns and trends.
Plus, leadership can stay in sync with what’s working and not working for the team without getting in the way. They can see what your engineering team thinks is important, so they can fix what should be fixed.
Additionally, with ScatterSpoke, your team can easily provide (anonymous) feedback with everyday communication tools like Slack or Teams even before the retro begins. This way, everyone’s voice is heard.
What can you actually do to make effective retro a reality? The good news is, it’s not as difficult as you might think. We’ve broken it down into 5 elements to make it as easy as possible to massively improve your sprint retrospectives.
Most engineering managers instinctively think of productivity as complex processes like workflows, solutions, and deliverables expressed in purely quantitative terms. The result is a dynamic that’s usually counterproductive. But there is another way.
Often that dynamic plays out in metrics and misguided attempts at fostering engineer productivity, usually by measuring the wrong things and offering the wrong incentives. Fortunately, there are better ways to use metrics to genuinely empower engineers to accomplish more.