{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "@id": "https://www.vidyasource.com/blog/going-retro-with-style/",
  "url": "https://www.vidyasource.com/blog/going-retro-with-style/",
  "mainEntityOfPage": "https://www.vidyasource.com/blog/going-retro-with-style/",
  "headline": "Going Retro With Style",
  "description": "It isn't just engineers who have a lot to learn from agile retrospectives.",
  "datePublished": "2016-11-05T00:00:00.000Z",
  "author": {
    "@type": "Person",
    "name": "Neil Chaudhuri",
    "jobTitle": "President",
    "url": "https://www.linkedin.com/in/neil-chaudhuri/",
    "sameAs": "https://www.linkedin.com/in/neil-chaudhuri/"
  },
  "publisher": {
    "@id": "https://www.vidyasource.com/#organization"
  },
  "image": "https://www.vidyasource.com/img/blog/record.jpeg",
  "keywords": [
    "Scrum",
    "Kanban",
    "Agile",
    "Project Management",
    "Software Engineering"
  ],
  "articleBody": "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)\ncalled *Reflective Retrospectives To Build High Performing Teams.* It was an interesting presentation with\na highly credentialed speaker--Certified Agile Coach, ITIL, PMP/PMI-ACP Coach, [Protector of the Realm,\nBreaker of Chains](http://gameofthrones.wikia.com/wiki/Daenerys_Targaryen), and so on--but what really\nstruck me that evening was a question from the audience.\n\nThe question came from a fellow software engineer, who began by noting that ALN events typically\nengage executives and managers rather than engineers, and can be paraphrased this way:\n\n> In our retrospectives the ScrumMaster and Product Owner always elevate themselves above the\nrest of the team and demand from the developers that we account for why we were unable\nto deliver as much and as quickly as they wanted. How can we change this?\n\nThe speaker and the audience had sympathy. Their comments more or less could be boiled down to\nthe assertions that this ScrumMaster is no [servant leader](https://www.scrumalliance.org/community/articles/2014/august/the-art-and-science-of-servant-leader)\nand that the leadership needs to promote agile values better. While correct and well-meaning,\nthe answers felt like platitudes rather than actionable suggestions.\n\nMeanwhile, I had *empathy*. As a fellow software engineer, I felt like I was one of maybe\na handful of people in the room who has some sense of what it is like to be singled out\nby leadership and blamed for failure. It's usually inaccurate, and it's always unfair. The best thing\nabout agile isn't the development practices like unit testing and\nautomation; it's the culture elevating developers to first-class citizens whose\ninput and perspectives are deemed just as important as leadership's.\n\nAfter all, we are the ones delivering the only thing of real value to the client--[working\nsoftware](http://www.agile-process.org/working.html).\n\nThe reality though is that few people with the titles of team lead/ScrumMaster and Product Owner truly\nunderstand agile values, and sometimes we software engineers must work to gain the respect\nagile development affords us. Of course, [getting respect isn't always so easy](https://www.youtube.com/watch?v=2X9E9n6GHC8).\n\nI didn't say anything at the event because the emcee emphasized repeatedly that we were pressed for time,\nso here are the *actionable* suggestions I would make to the software engineer who asked that question.\n\nAt your next retrospective, first acknowledge where you could have done better. Humility\nis a good thing, and there is always something we could've done better. Leadership apparently\nwants answers, and they will be happy to hear you acknowledge the problem and have\nideas for fixing it.\n\nBut then--and this is the critical part--use *objective metrics* to show where the lead/ScrumMaster\nand Product Owner need to improve for velocity or cycle time to improve.\n\nFor example, you might point out that the Product Owner has been unavailable to answer critical questions.\nYou could use the number of meetings missed. You could work with the rest of the team to track how\nmany hours you all had to wait for answers by adding up the elapsed times between E-mails or chats\nsent and received. That kind of delay is common, and it has a significant impact.\n\nFor another example, you might inform the lead/ScrumMaster that he or she isn't shielding you\nenough from bureaucracy. The lead may have no idea that you devoted 23% of your apparent\n[capacity](https://www.scrumalliance.org/community/articles/2007/august/perfect-planning) to\nnon-development activities. That too would have a significant impact.\n\nThe key thing here is that you have actual irrefutable data describing where\nleadership--not just the developers--must improve if they want high-quality\nsoftware delivered fast.\n\nNow I get this isn't so easy. Here you are already under fire from leadership for delays,\nand now you're taking time out of development to keep score. It also won't be fun to confront\nleadership; you will need to overcome any shyness or reservation by trusting your data. And of course\nthey may not have the humility or desire for self-improvement and could react quite\nnegatively. If so, this might be a team and perhaps even an organization you should leave immediately, but who\nam I to say that? People with families and other responsibilities can't always leave their jobs--and\nfind better ones--so easily.\n\nIt is up to you to decide whether leadership will appreciate your candor and the data behind it\nand whether this kind of team is where you want to work.\n\nIf I see the software engineer who asked this salient question at a future ALN event, I hope to\nshare these thoughts with him. If leadership has the willingness to improve and the\nmessage is constructive and data-driven rather than disparaging and defensive, this approach will work.\n\nThen again, if leadership really is perfect and there are no metrics suggesting otherwise, then your team\nshould consider signing up for some of our [courses](https://www.vidyasource.com/courses/)."
}