Skip to main content
Ris Adams
Software Mentor
View all authors

Ever notice how the best Scrum Masters seem to have a sixth sense for what’s really going on in a team? Spoiler: it’s not magic, and it’s definitely not mind reading (though that would be a nice superpowerto have!). It’s effective listening—the kind that goes beyond nodding along and actually tunes into what’s said, unsaid, and everything in between.

Agile ceremonies can feel like navigating a social minefield when you're neurodivergent. The constant context switching, sensory overload, and unstructured discussions that energize neurotypical teammates might drain your focus and leave you feeling disconnected from the process.

But here's what I've learned from years of facilitating scrum events and working with brilliant neurodivergent developers: your brain isn't broken, and Agile ceremonies aren't fundamentally incompatible with how you think. You just need the right playbook.

Twenty years ago, being a Scrum Master meant you were the keeper of the framework—the person who made sure daily standups happened at 9 AM sharp and that retrospectives followed the prescribed format. Fast-forward to 2025, and if you're still just moving tickets in Jira and asking "What did you do yesterday?"—well, an AI probably does that better than you.

The role has fundamentally shifted, and honestly? It's about time. I've watched this evolution firsthand through economic downturns, remote work revolutions, and the rise of DevOps. The Scrum Masters who survived and thrived didn't just adapt—they transformed themselves into something the original Scrum Guide never envisioned: strategic business enablers who happen to know agile frameworks really well.

Unless you've won the lottery or have a trust fund that pays out in premium coffee beans, you probably have a job. Most days, you're likely fine with that arrangement—solving problems, sending emails, and optimizing workflows. But let's be real: even the best jobs come with moments that make you want to delete your professional identity and start fresh.

Your git commit history could be telling an epic tale of how your codebase evolved, or it could be a cryptic collection of "fixed stuff" and "updated things." The difference isn't just aesthetic—it's the line between a repository that teaches and one that confuses. Well-crafted commits don't just track changes; they document your code's journey in a way that helps your team and future you.

Every few days, I see another panicked headline about "skyrocketing autism rates" or well-meaning friends sharing concerns about an "autism epidemic." As someone who is autistic, and who has an autistic child, and has spent considerable time studying how systems evolve and improve diagnostics, I want to break down why this framing is both inaccurate and potentially harmful.

The increase in autism diagnoses isn't evidence of an epidemic—it's evidence of progress. Here's why.

I stumbled across Git Notes during a late-night debugging session last week, and honestly, I'm slightly annoyed that I hadn't been using this feature for years. If you've ever wanted to attach persistent metadata to commits without changing commit hashes (and who hasn't?), this hidden gem deserves your attention. And while we're exploring Git's underappreciated features, let's also look at Git trailers - another powerful tool for managing metadata in your repositories.

As a Scrum Master with years of experience facilitating retrospectives for development teams, I've discovered that the success of a retro hinges on thoughtful preparation. The right format, the right questions, and the right energy can transform a session from a routine meeting into a powerful tool for team growth and improvement.

In this post, I'll share the key questions I ask myself when planning a sprint retrospective that delivers real value and fosters meaningful change.

I still remember sitting cross-legged on the floor of my childhood living room, completely mesmerized as Madmartigan swung his sword across our family TV screen. Yesterday, on April 1, 2025, when I heard that Val Kilmer had passed away at 65 from pneumonia, it felt like losing an old friend who had been with me through every chapter of my life.

tributecelebrity2 min read

Joining an existing team as a new Scrum Master is like being dropped into the middle of a complex ecosystem with its own established patterns and invisible rules. You might be tempted to immediately start "fixing" things based on textbook Scrum implementations or previous experiences. Don't. Instead, invest time understanding the current landscape before making any changes. These teams have history, context, and reasons (good or otherwise) for how they operate. Your first job isn't to change—it's to comprehend.

Version control with Git offers developers multiple ways to integrate changes across branches, with merge and rebase standing as the two primary approaches. While both accomplish the same fundamental goal—incorporating changes from one branch into another—they do so through fundamentally different mechanisms, resulting in distinct commit histories and team workflows. Understanding when to use each strategy can significantly impact your project's history clarity, team collaboration, and conflict resolution process. In this deep dive, we'll explore how each option works under the hood, examine real-world usage patterns, and provide clear guidelines for choosing the right approach for your specific situation.