2021 Year End Review

Kapa’a, Hawaii photo by Rebecca

Here’s a quick recap of blog posts I wrote in 2021.

Agile Experience Reports

Juggling Multiple Scrum Teams I introduce Iuri Ilatanski’s experience report about life as a multi-tasking Scrum Master. Juggling involves meeting each team’s specific needs. I was Iuri’s “shepherd”—his sounding board and advocate—as he wrote this report presented at Agile 2021. Thank you, Iuri, for being so open to discussion, reflection, and the hard work of revising your writing.

Agile Experience Reports: A Fresh Look at Timeless Content I spent August organizing the vast Agile Alliance experience reports collection hosted on the Agile Alliance’s website. The collection includes reports from 2014 to 2021 as well five XP conferences. Experience reports are personal stories that pack a punch. There are many gems of wisdom here.

Domain Driven Design

Splitting a Domain Across Multiple Bounded Contexts Sometimes it can more productive to meet the specific needs of individual users rather than to spend the time designing common abstractions in support of a “unified” model.

Design and Reality We shouldn’t assume domain experts have all the language they need to describe their problem (and all that you need to do as a software designer is to “capture” that language and make those real-world concepts evident in your code).

Models and Metaphors Listening to the language people use in modeling discussions can lead to new insights. Sometimes we find metaphors, that when pushed on, lead to a clearer understanding of the problem and clarity in our design.

Decision Making

Noisy Decisions After reading Noise: A Flaw in Human Judgment by Daniel Kahneman, Olivier Sibony, and Cass Sunstein I wrote about noisy decisions in the context of software design and architecture. These authors define noise as undesirable variability in human judgment. Often, we want to reduce noise and there are ways we can do so, even in the context of software.

Is it Noise or Euphony? At other times, however, we desire variability in judgments. In these situations variability isn’t noise, but instead an opportunity for euphony. And if you leverage that variability, you just might turn up some unexpected, positive results.

Heuristics Revisited

Too Much Salt? We build a more powerful heuristic toolkit when we learn the reasons why (and when) particular heuristics work the way they do. I now think it is equally important to seek the why behind the what you are doing as you cultivate your personal heuristics.

Life in the Mob

The latest report in the Agile Experiences Program has just been published. It is a story by Jason Kerney about what it is like to join a Mob Programming Team.

Jason’s report started with a conversation over lunch at Agile 2014. Jason was sitting with his manager, Woody Zuill who reported on how mob programming was born and how it works in practice. Woody introduced Jason as the newest member of their mob.

Ever on the lookout for good stories (I’m Director of the Agile Experience Report Program), I asked Jason what it was like to join the mob. And thus began a conversation which after a lot of hard work by Jason turned into this latest report.

When he first joined the team, Jason was hyper vigilant. Not wanting to let his new team down, he found it hard to take any breaks. For the first few weeks he would go home from work exhausted. By accident one day he discovered that if he stepped away from the team for awhile, he could catch up in a just a few minutes. He had stumbled on a sustainable rhythm for mob programming and went home from work energized.

Jason’s initial hyper vigilance reminds me of my first two weeks on the job as a forest service lookout. I was constantly scanning for fires through my binoculars. I got eyestrain. After two weeks, I just couldn’t keep up my constant surveillance. So I backed off to looking for fires every 15 minutes. That was plenty of attention. No fire is going to explode and burn down the entire forest in 15 minutes.

Jason also shares a keen observation into the collective way his team dynamically works. He likens how they each pay attention to different things as being like a howling wolf pack (where no two wolves sing at the same frequency). Wolves just join in and find an agreeable pitch. Mob programmers who are paying attention to their teammates find a way to contribute what’s “missing”. Jason finds mob programming powerful because:

“In coding, there are a lot of things to think about, architecture, design, the problem at hand, coding standards, testing, deployment, business impact and security to name a few. I have found that our mob treats each of these like a wolves’ howling frequency. We each take one or a few and pay attention to those. If someone else appears to be covering it, we choose something else. None of this is an active decision, it just happens.”

Don’t dismiss Mob Programming as a simple variant of an XP programming team. There’s more to it.

If you have an itch to write and share your agile experiences, please feel free to contact me at rebecca at wirfs hypen brock dot com. I know that writing is hard work. I want to hear your intriguing stories and help you tease out your wisdom. I can help you find a voice in your writing. We learn from experience (especially when we reflect on it). And it’s a wondrous gift to share your experiences with others. Thanks for sharing, Jason.

Working–share your experience

One of my all time favorite books is Studs Terkel’s Working. In it, he captured people talking about what they do and how they feel about it. People tell amazing stories about hard work. The book is about, “ulcers as well as accidents, about shouting matches as well as fistfights, about nervous breakdowns as well as kicking the dog around.” I hope you don’t find software development so grim (I don’t ). But maybe you have an intriguing story to tell.

OOPSLA is soliciting Practitioner Reports. The submission deadline is just a short time away–March 19th. If you submit a report and it is accepted, Ralph Johnson or one on his committee will help you tell your story. There are many more interesting stories to be told and if you have one, please consider telling it at OOPSLA. Last year there was a really great story about how software objects finally made it to space in a JPL satellite through the persistence of a guy who really, really believed in the benefits of oo programming. A grad student at Portland State presented his experience exploring Traits–when he was an undergrad. I remember another report where a developer recounted his use of refactoring tools to write transformation rules to transmogrify a massive Smalltalk legacy application’s database access layer. And I recall another telling how a framework for scientific applications evolved. There are always interesting stories to tell; and OOPSLA is a place where you can tell them, whether they be about your latest adventures with web services, domain-driven design, aspects, agile or open source development, or the challenges of developing applications in distributed teams.