Agile retrospectives

What Hacker News says

1. jdlshoreJul 2021
   Six hours is longer than I would use for a regular retrospective, but 30 min is very short. The format you’ve described is fairly shallow. Check and Derby and Larsen’s Agile Retrospectives for ideas about what you might be missing.
   thread
2. merruaSep 2018
   I enjoyed all these. All of them are worth a read.

   Business / Tech Grit: The Power of Passion and Perseverance. Are Your Lights On?: How to Figure Out What the Problem Really Is. Managing Expectations: Working with People Who Want More: Working with People Who Want More, Better, Faster, Sooner, Now! Explore It!: Reduce Risk and Increase Confidence with Exploratory Testing. Spam Nation: The Inside Story of Organized Cybercrime-From Global Epidemic to Your Front Door. Weapons of Math Destruction: How Big Data Increases Inequality and Threatens Democracy. Badass: Making Users Awesome. Social Engineering in IT Security: Tools, Tactics, and Techniques. How to Make Sense of Any Mess: Information Architecture for Everybody. Agile Retrospectives: Making Good Teams Great. The Black Swan: The Impact of the Highly Improbable. The Global War for Internet Governance. Coding Freedom: The Ethics and Aesthetics of Hacking. Hate Crimes in Cyberspace. High Noon: The Inside Story of Scott McNealy and the Rise of Sun Microsystems. Mindset: The New Psychology of Success. Where Wizards Stay Up Late: The Origins of the Internet. The Soul of A New Machine. Hot Spots: Why Some Companies Buzz with Energy and Innovation - And Others Don't. A Computer Called LEO: Lyons Tea Shops and the World's First Office Computer. Power Failure: The Inside Story of the Collapse of Enron. The Mesh: Why the Future of Business is Sharing. What's Mine Is Yours: How Collaborative Consumption is Changing the Way We Live. Privacy in Context: Technology, Policy, and the Integrity of Social Life. Quiet: The Power of Introverts in a World That Can't Stop Talking. The Boy Kings: A Journey into the Heart of the Social Network. The Undersea Network (Sign, Storage, Transmission). Automating Inequality: How High-Tech Tools Profile, Police, and Punish the Poor. Meaningful: The Story of Ideas That Fly. Zero Bugs and Program Faster. Official Criticism Manual: Perfecting the Art of Giving and Receiving Criticism. Hacking Wireless Access Points: Cracking, Tracking, and Signal Jacking. Usability Testing Essentials: Ready, Set...Test! Behind Closed Doors: Secrets of Great Management. The Accidental Project Manager. Building Successful Communities of Practice. Card Sorting: Designing Usable Categories. More Fearless Change: Strategies for Making Your Ideas Happen. Security and Usability: Designing Secure Systems that People Can Use. Broad Band: The Untold Story of the Women Who Made the Internet. The Well: The Epic History of the First Online Community. Programmers at Work.

   Science The Theory That Would Not Die: How Bayes' Rule Cracked the Enigma Code, Hunted Down Russian Submarines, and Emerged Triumphant from Two Centuries of Controversy Darwin's Ghosts: In Search of the First Evolutionists The Dinosaur Hunters: A True Story of Scientific Rivalry and the Discovery of the Prehistoric World Chasing Venus: The Race to Measure the Heavens The Immortal Life of Henrietta Lacks. Hidden Figures Prometheans in the Lab: Chemistry and the Making of the Modern World Fixing My Gaze: A Scientist's Journey into Seeing in Three Dimensions The Sixth Extinction: An Unnatural History Knocking On Heaven's Door: How Physics and Scientific Thinking Illuminate our Universe Sightlines An Ocean of Air: A Natural History of the Atmosphere Snowball Earth: The Story of the Global Catastrophe That Spawned Life as We Know it Blood Work: A Tale of Medicine and Murder in the Scientific Revolution Being Wrong: Adventures in the Margin of Error: The Meaning of Error in an Age of Certainty Mycophilia Packing for Mars: The Curious Science Of Life In Space No Logo King of Infinite Space: Donald Coxeter, the Man Who Saved Geometry The Ghosts Of Evolution Nonsensical Fruit, Missing Partners, And Other Ecological Anachronisms Rosalind Franklin: The Dark Lady of DNA Growing Up Boeing: The Early Jet Age Through the Eyes of a Test Pilot's Daughter Soundings: The Story of the Remarkable Woman Who Mapped the Ocean Floor Moby-Duck: The True Story of 28,800 bath Toys Lost at Sea Naming Nature: The Clash Between Instinct and Science

   World / Politics / Other Drift: The Unmooring of American Military Power The New Jim Crow The Market for Force: The Consequences of Privatizing Security Imaginary Weapons: A Journey Through the Pentagon's Scientific Underworld Inside Scientology: The Story of America's Most Secretive Religion The irregulars : Roald Dahl and the British spy ring in wartime Washington Holy Sh*t: A Brief History of Swearing The Gift of Fear

   Show morethread
3. wpietriJul 2016
   Hopefully others will jump in with answers more relevant to your situation. I work mainly in a startup and small-company context because the customer and business realities are more prominent than the political situation. In my mind's eye, I see companies as opaque spheres of different sizes. The bigger they get, the farther the average person is from the external reality, and so the less that reality matters.

   I also think this is tied in with current American managerialist culture. The notion of controlling work by setting arbitrary hurdles and deadlines is so pervasive that many people can't imagine an alternative. This very easily turns into pure fantasy, even on the billion-dollar scale. [1] I expect that there are plenty of companies that would literally go out of business before they would change their ways.

   So in your shoes I'd take a hard look at your company and ask what its true values are. If they really value appearance over results, politics over substance, dominance over cooperation, then I don't think that's something you can change on your own. I'd personally try to find someplace better, and if I couldn't then I'd mainly play to survive, not to win.

   But if you think the company has its heart mostly in the right place, then in your shoes I'd start with weekly team retrospectives. [2] [3] Each week, you'll make note of problems and possible solutions. Each week you try to make things incrementally better. And gradually you'll build up solid data to say things like, "For the last quarter, the most common thing in team X's weekly top 3 productivity drains has been insufficient contiguous time to focus. If you want us to go faster, please help us to limit meetings and interruptions to the mornings for the next quarter as an experiment."

   If possible, I also strongly recommend finding ways to ship early and often. The longer managers go without experiencing actual progress, the crazier they get. If you release new business value at least weekly, then they'll focus much more on picking what's next then on yelling at people. At my last startup, even with a small team, we were releasing a few times a day. That meant that the CEO wanted something urgently, he could always get it soon just by telling us what thing currently in progress was less urgent. He always felt in control. It also meant that he was kept busy looking at new results and thinking about what came next; he didn't have time to fuss much with our work.

   Related to that is building cross-functional teams. To me, a team is a group of people that win and lose together, a group that can play the game basically on their own. So I'll try to put a few developers physically together with a designer and a product manager and whoever else is vital. If PMs think of themselves as their own team, then it's hard to counteract those bad incentives. But if the PM only wins when the project and the rest of the team wins, they'll be much more collaborative.

   And I'd also encourage you to make good use of every disaster that comes your way. The best luck I've had changing culture and process has always come when there's some mega-fuckup that's fresh in people's minds. That's especially true when you already have a successful small-scale example going. E.g., I remember one retrospective after a team spent 9 months building a big upgrade that was a flop. One of their peer teams was at that point releasing every few days and quickly responding to business data: killing bad ideas quickly, doubling down on the good ones. The pain of failure plus the envy of colleagues doing well was a powerful combination.

   Sorry for the ramble in reply, but basically my answer is: as problems present themselves, solve them in ways that move you toward greater agility. By which I mean more frequent releases, faster feedback loops, closer collaboration, less work in process, more responsive to business and customer needs. To it continuously on a small scale and regularly at the large. If you can make a 1% weekly improvement, things will be 68% better by the end of the year, and 181% better at two years.

   Does that help? If not, feel free to reply here or email me. Glad to help as I can.

   [1] For example, the dumbfounding mess in Mississippi, which we know about because of one stubbornly honest engineer: http://www.nytimes.com/2016/07/05/science/kemper-coal-missis...

   [2] A good book is Larsen and Derby's Agile Retrospectives: https://www.amazon.com/Agile-Retrospectives-Making-Teams-Gre...

   [3] Also handy is the Retromat: http://plans-for-retrospectives.com/

   Show morethread
4. jdlshoreMay 2022
   "You aren't doing it right" is a valid argument when "it" is well defined. No True Scotsman is a fallacy of ambiguity—it occurs when "Scotsman" isn't well defined, allowing somebody to continually move the goalposts in response to an argument.

   In the case of Agile, Scrum, and retrospectives, they all have published definitions, so No True Scotsman doesn't apply.

   Are you valuing processes and tools over individuals and interactions? You aren't doing Agile right. (Agile Manifesto)

   Does your team not consist of "one Scrum Master, one Product Owner, and Developers [with] no sub-teams or hierarchies [who] internally decide who does what, when, and how?" You aren't doing Scrum right. (Scrum Guide)

   Does your retrospective not include "Decide what to do?" You aren't doing retrospectives right. (Agile Retrospectives book.)

   In fairness hardly anybody does these things right, so it's tempting to lob No True Scotsman criticisms. But that's just as fallacious. A more accurate criticism might be to say that Agile & co. are too hard to do right, or to say that they require a business environment that doesn't exist in most companies.

   Show morethread
5. jdlshoreMay 2022
   Sure, I can see the irony. On the other hand, your interpretation of my argument is absolutely correct. I'm saying that people in this thread have gotten two things wrong:

   1) They don't understand Agile, Scrum, or retrospectives, each of which have authoritative definitions (which can be found at agilemanifesto.org, scrum.org, and in the Agile Retrospectives book).¹

   2) Furthermore, they don't understand the "No True Scotsman" fallacy.

   Correcting a misunderstanding is not "No True Scotsman." If somebody called a car a "horse," and you said, "that's not a horse—a horse has hooves, not wheels," would that be No True Scotsman?

   ¹You could argue that those definitions are overly broad, or fuzzy, or many other things. But that's not what people in this thread are doing. They're saying horses have wheels, then saying it means horses can't jump.

   Show morethread
6. burkemw3Aug 2015
   I agree with parent and siblings that retros are awesome!

   Initially, my team started by sitting around talking about work item by work item and other miscellaneous topics. Most of the time, this was cathartic but didn't lead to much change.

   Recently, we've had a facilitator lead us through activities to drive toward 1-2 actionable outputs to work on for the next sprint. This focus has helped the team actually improve things with our process.

   We've been using http://plans-for-retrospectives.com/ for ideas of the activities. A number of our Agile Coaches have recommended the "Agile Retrospectives: Making Good Teams Great" book (but I haven't read it myself).

   Show morethread