---
title: "Going Retro With Style"
description: "It isn't just engineers who have a lot to learn from agile retrospectives."
canonical: https://www.vidyasource.com/blog/going-retro-with-style/
type: article
published: 2016-11-05
author: "Neil Chaudhuri"
tags: ["Scrum", "Kanban", "Agile", "Project Management", "Software Engineering"]
image: https://www.vidyasource.com/img/blog/record.jpeg
---

# Going Retro With Style

> It isn't just engineers who have a lot to learn from agile retrospectives.

- Canonical page: https://www.vidyasource.com/blog/going-retro-with-style/
- Structured data (JSON-LD): https://www.vidyasource.com/blog/going-retro-with-style.json
- Published: 2016-11-05
- Author: Neil Chaudhuri
- Topics: Scrum, Kanban, Agile, Project Management, Software Engineering

I was recently at an event hosted by the [Agile Leadership Network of DC](http://www.meetup.com/Agile-Leadership-Network-ALN-Washington-DC-Area-Chapter/) (ALN)
called *Reflective Retrospectives To Build High Performing Teams.* It was an interesting presentation with
a highly credentialed speaker--Certified Agile Coach, ITIL, PMP/PMI-ACP Coach, [Protector of the Realm,
Breaker of Chains](http://gameofthrones.wikia.com/wiki/Daenerys_Targaryen), and so on--but what really
struck me that evening was a question from the audience.

The question came from a fellow software engineer, who began by noting that ALN events typically
engage executives and managers rather than engineers, and can be paraphrased this way:

> In our retrospectives the ScrumMaster and Product Owner always elevate themselves above the
rest of the team and demand from the developers that we account for why we were unable
to deliver as much and as quickly as they wanted. How can we change this?

The speaker and the audience had sympathy. Their comments more or less could be boiled down to
the assertions that this ScrumMaster is no [servant leader](https://www.scrumalliance.org/community/articles/2014/august/the-art-and-science-of-servant-leader)
and that the leadership needs to promote agile values better. While correct and well-meaning,
the answers felt like platitudes rather than actionable suggestions.

Meanwhile, I had *empathy*. As a fellow software engineer, I felt like I was one of maybe
a handful of people in the room who has some sense of what it is like to be singled out
by leadership and blamed for failure. It's usually inaccurate, and it's always unfair. The best thing
about agile isn't the development practices like unit testing and
automation; it's the culture elevating developers to first-class citizens whose
input and perspectives are deemed just as important as leadership's.

After all, we are the ones delivering the only thing of real value to the client--[working
software](http://www.agile-process.org/working.html).

The reality though is that few people with the titles of team lead/ScrumMaster and Product Owner truly
understand agile values, and sometimes we software engineers must work to gain the respect
agile development affords us. Of course, [getting respect isn't always so easy](https://www.youtube.com/watch?v=2X9E9n6GHC8).

I didn't say anything at the event because the emcee emphasized repeatedly that we were pressed for time,
so here are the *actionable* suggestions I would make to the software engineer who asked that question.

At your next retrospective, first acknowledge where you could have done better. Humility
is a good thing, and there is always something we could've done better. Leadership apparently
wants answers, and they will be happy to hear you acknowledge the problem and have
ideas for fixing it.

But then--and this is the critical part--use *objective metrics* to show where the lead/ScrumMaster
and Product Owner need to improve for velocity or cycle time to improve.

For example, you might point out that the Product Owner has been unavailable to answer critical questions.
You could use the number of meetings missed. You could work with the rest of the team to track how
many hours you all had to wait for answers by adding up the elapsed times between E-mails or chats
sent and received. That kind of delay is common, and it has a significant impact.

For another example, you might inform the lead/ScrumMaster that he or she isn't shielding you
enough from bureaucracy. The lead may have no idea that you devoted 23% of your apparent
[capacity](https://www.scrumalliance.org/community/articles/2007/august/perfect-planning) to
non-development activities. That too would have a significant impact.

The key thing here is that you have actual irrefutable data describing where
leadership--not just the developers--must improve if they want high-quality
software delivered fast.

Now I get this isn't so easy. Here you are already under fire from leadership for delays,
and now you're taking time out of development to keep score. It also won't be fun to confront
leadership; you will need to overcome any shyness or reservation by trusting your data. And of course
they may not have the humility or desire for self-improvement and could react quite
negatively. If so, this might be a team and perhaps even an organization you should leave immediately, but who
am I to say that? People with families and other responsibilities can't always leave their jobs--and
find better ones--so easily.

It is up to you to decide whether leadership will appreciate your candor and the data behind it
and whether this kind of team is where you want to work.

If I see the software engineer who asked this salient question at a future ALN event, I hope to
share these thoughts with him. If leadership has the willingness to improve and the
message is constructive and data-driven rather than disparaging and defensive, this approach will work.

Then again, if leadership really is perfect and there are no metrics suggesting otherwise, then your team
should consider signing up for some of our [courses](https://www.vidyasource.com/courses/).

---

Vidya is a certified small business in Northern Virginia that modernizes legacy systems, builds enterprise AI, and designs cloud and data architecture for commercial companies and federal agencies. Vidya documents its delivered engagements in case studies and publishes courses, tutorials, and articles for engineers and the people who lead them. The company name is Vidya. Its website is vidyasource.com. Start at https://www.vidyasource.com/llms.txt for the index of everything Vidya publishes, or https://www.vidyasource.com/contact/ to talk to Vidya.