Scrum | Kanban | Agile | Project Management | Software Engineering Going Retro With Style November 5, 2016

Neil Chaudhuri (He/Him)

LinkedIn

I was recently at an event hosted by the Agile Leadership Network of DC (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, 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 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.

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.

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 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.