2021 Year End Review

Posted on December 30, 2021 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.

It’s Not That Simple: The Interplay Between Fast and Slow Thinking

Posted on May 10, 2016 by Rebecca

Our system 2 thinking observes and constantly monitors our actions and thoughts (unless it is tired or compromised). It helps regulate our behavior and to:

Control impulses and stop doing something that we consider inappropriate (such as eating that second piece of pie) or do something, even if we don’t like it (such as not rising to the bait in a political discussion);
Manage our energy, emotions, attention and behavior in socially acceptable ways to achieve our goals;
Stay calm, focused, and alert; and
Deal with daily stresses such as noise, fatigue, challenging situations or tasks, or distractions.

System 2 thinking doesn’t merely look over your shoulder to “correct” illogical system 1 thinking. The interplay between these two systems is much more complex. The two systems have deep connections and influence each other.

Emotions generated by fast thinking affect logical system 2 thinking. And fast thinking, when it doesn’t find meaningful associations that fit the current context calls upon the logical system 2 for help to interpret what is going on.

I had an opportunity to experience this interplay sitting in a bar talking with Linda Rising at an agile conference. A loud angry voice coming from the lobby abruptly interrupted our conversation. Initially, I was frightened. Then annoyed. Then irritated. (My emotional system 1 thinking kicked in). The yelling didn’t stop. Did someone need help? Why was the yelling man so upset? (Again, my system 1 was trying to connect yelling with some reason to be yelling). But I couldn’t understand what the yelling was about. And then, seemingly out of the blue (system 2 thinking coming to the rescue) I remembered that there was also a conference in the hotel on Tourette’s syndrome. That loud angry voice now made sense. It was the voice of someone with Tourette’s.

It is too simple to say that our brain is either emotional and associative (fast thinking) or logical (slow thinking).

We don’t get to choose which form of thinking we use.

The two systems interact…and that’s where it gets really interesting. Being aware of how my brain works hasn’t stopped me from being swayed by my emotions. But it has made me more aware of thinking dynamics. I may not be able to stop my knee-jerk reactions, but I am aware now that my delayed reactions and thoughts might also be helpful, if I give them enough time to surface.

Digging In

Posted on September 9, 2015 by Rebecca

As it transitions from summer to fall here in Oregon, clouds are hanging around in the morning. It’s harder for me to get up early because sunrise is closing in on 7 a.m. I get up at the crack of dawn; it’s dawn that is dragging its feet. With cooling weather and shorter days I tangibly feel the lively, easy time of the year slipping away.

I have to remind myself to put in extra effort and energy to maintain the status quo: keep up my jogging schedule, get to work early enough on the hard stuff so that I can get done what I want to before my energy is spent… I’ve got to dig in and fight the urge to curl up in a ball and hibernate for the winter.

Agile teams have to fight inertia, and dig in to overcome challenges and to sustain their progress, too.

Agile experience report authors, if not prompted, tend to forget those little details, too. When basking in their current success it is easy to overlook those seemingly unimportant actions that over time contributed to that success.

That’s why I think any experience report worth its salt needs to be shepherded. A shepherd works with the author to draws out their insights. A shepherd’s job is to help the author find their voice and dig into their experiences and find those insights. Being a shepherd is not like being an editor or a reviewer (I’ve played all these roles over the years). A shepherd, like a reporter, wants to get to the bottom of the experience—to find the things that worked, and the things that didn’t. They want the reader understand the struggle. Most shepherds I know find it deeply rewarding to draw out little tidbits from the author and help the author weave a more nuanced narrative.

For example, I know that sustaining improvements requires concerted effort and constant attention.

So when Patkós Csaba proposed to write about how his team at Syneto achieved one bug a month, I was thrilled to be his shepherd. I wanted to get to the bottom line: how did they really get there? What did it take?

I was happy when he didn’t gloss over how his manager gradually and steadily introduced new practices into the team. In my role of shepherd I asked him to make the timeline more clear—hey, it really took months before they got to that rate of one bug a month. I also recognized that it was important for him to tell about how staying in that “zone” proved elusive. Indeed, he did have a story to share about how things slipped when they stopped using a physical board and went to an online tool. The team stopped monitoring so closely what was going on and what was blocked. (Was it really too difficult for team members to open up the online tool and check progress? No, but they weren’t in the habit. Out of sight proved to be out of mind.)

To fix this, they installed a large screen that visibly displayed their work in progress in the online tool. Once in sight again, progress (or lack thereof) was visible to the whole team. And things improved again.

As their team composition changed, they found that what were unstated good practices weren’t commonly known by new team members. They had to be explicitly introduced. They had to dig in and write down some things that previously were implicitly understood.

When I met Patkós at Agile 2015, he graciously shared with me that his team had recently regressed to a few bugs a month. Now he is one of the old timers on his team. He feels deeply responsible for his team’s continued progress. Indeed they continue on their journey.

So when you read about any experience, I urge you to appreciate the effort it takes to get to that, “smooth, steady, productive, exciting state.” And more important, the effort it takes to sustain it.

It is a precious and special time when you are in the flow, when work goes smoothly, when everything is clicking and it feels easy. That’s what people like hear. It is exciting and cool to have achieved something special.

But I am inspired even more when I read about the effort, energy, and persistence it takes to keep things working smoothly. I like it when I read experience reports where people reflect, readjust what they’re doing, perform experiments (sometimes unsuccessful ones), and work to get back on track. It’s all part of digging in and getting the job done.

Shift Left: Testing Earlier in Development

Posted on June 18, 2015 by Rebecca

One candidate for best experience report at XP 2015 was “High Level Test Driven Development – Shift Left” by Kristian Bjerek-Gustuen, Emil Wiik Larsen, Tor Stålhane, and Torgeir Dingsøyr. Their report describes testing strategies and tactics used on a large-scale IT development project in Norway. These authors called it “shifting left” because they wanted to move testing to as early as possible in development.

Their project was complex along several dimensions.

Coordinated work among independent teams: Several vendors were simultaneously developing and delivering systems that communicated with each other via service interfaces. Vendors did detailed design and development including unit, integration and sprint system testing of their deliverables. This work had to be integrated by the company. They performed acceptance testing after every sprint, system integration testing which ran in parallel with the vendors’ sprint system tests, as well user acceptance testing.

Significant coding and testing effort: Over 100,000 hours of testing and development went into the release.

Time pressure and project criticality: The delivery date was fixed. The system was an extension of an existing system for processing payments. It had to be delivered on time and with high quality.

The duration of the project they described was roughly 40 weeks, if I read the report correctly: 12 3-week sprints followed by 6 weeks of system testing. Faced with a time crunch, an existing group of 3 maintenance scrum teams were scaled up to 11 teams over four months. The customer who was receiving the software system didn’t have fulltime resources to dedicate to the scrum teams who were comprised of these roles: scrum master, developer, functional architect, technical architect, and QA/tester. My guess is that the customer was called upon as needed to provide clarifications, offer feedback at sprint demos, and to do all necessary testing and integration testing.

To ensure that each team had efficient and sufficient testing and quality assurance, a dedicated QA person/tester was assigned to each team. This reminds me of Stephanie Savoia’s experience report at Marchex where they embedded testers into their dev teams.

In the case of this Shift left report, the dedicated QA person (I prefer the term quality advocate) seemed very busy and vital: they ensured the quality of design documentation; decided whether the implementation was testable; prepared test data; worked with devs and the Scrum master to ensure high quality code. They also made sure test activities were performed as early as possible and that the customer provided necessary clarifications to the dev team.

Bridge, go-between, quality advocate, tester extraordinaire!

During sprint demos, in addition to demonstrating new functionality, teams also provided information on how testing was performed and any issues they had encountered in testing the implemented functionality.

There is more in the report about how they managed testing and dependencies between teams, identified and tracked high-risk modules changes and defects to aid test and development planning, and introduced exploratory testing using interdisciplinary teams. But I digress.

Back to those busy QA advocates. Not surprisingly, the experience reporters mentioned in passing that the dedicated QA advocate became one of the most central resources for the teams.

It seems that they were deeply appreciated by the whole team. That’s important. Where they ever overwhelmed by their responsibilities? Were they overworked?

Any experience report never answers all questions I have. I still find them thought provoking. Even though I’d love to sit down and talk with experience reporters and ask them more questions.

One pattern Joe Yoder and I have written about in our Shifting From QA to AQ pattern collection is called Pair With A Quality Advocate. If you purposefully pair up devs or other folks with a QA advocate, their expertise can “rub off” on less skilled/experienced testers and developers. Steadily (and sometimes stealthily), a quality mindset gets infused into the entire team. You still need quality advocates, but everyone takes on more responsibility for quality. And that’s a good thing.

Future Commitment

Posted on June 16, 2015 by Rebecca

In early April, I spent a fun weekend at Pace University with Allen Wirfs-Brock and Mary Lynn Manns speaking with students of Pace University’s Doctor of Professional Studies in Computing program.

Mary Lynn Manns

It was a good opportunity to reconnect with Mary Lynn and to hear about new patterns in her latest book, More Fearless Change: Strategies for Making Your Ideas Happen.

Mary Lynn and Linda Rising have been working on these patterns for over a dozen years. They aren’t finished (curating long-lived patterns is an ongoing task). They continue to collect and write patterns for those who want to initiate, inspire, and sustain change in organizations they are part of or in their personal or professional life.

There isn’t one magic thing to do to institute change. Mary Lynn and Linda advise,

“You are working with humans, often in complex organizations, so results are rarely straightforward and the emergent behavior might be totally unexpected. Therefore, upfront detailed planning is rarely effective. Instead, take one small step toward your goal and see what happens. You will inevitably encounter missteps and failures along the way….uneven progress can be discouraging but may also teach you about the idea, about the organization, and, most of all, about yourself.”

Significant change often includes performing an ongoing series of experiments.

One new pattern (or strategy) in their book is Future Commitment. This one has hooked me many times.

Instead of asking a busy person for immediate help, ask them do something you need later and then wait for them to commit. Don’t worry about trying to get them to agree right away. Be patient. Keep in touch. Provide them regular information that encourages them to become more interested in your change initiative. Don’t be a pest.

Once they agree to help, solidify their commitment by recording the date and sending it in writing (along with gentle reminders so they are kept aware of their commitment). Reminders can be annoying. So include an update of what is happening and how their contribution will fit as part of a reminder. Have an alternate lined up in case that busy person can’t commit. There’s more to this strategy and the psychology behind how people commit (along with 14 other new strategies) in their book.

Like Mary Lynn and Linda, I don’t view change patterns as evil or manipulative. They are simply tools, that once aware of, you can use to engage people and get them to help you make changes.

And so here’s a future commitment if you have an urge to write about your agile experiences: We need experience reports for Agile 2016. Submit a proposal to the Agile Experience Report program. Do it soon. Within the next 30 days.

You don’t have to start writing now, but if you send in a proposal to me, it will grab my attention. Even better, if you are attending Agile 2015, we can also talk over your proposal. We ask that you write up a proposal so you get in the practice of collecting and communicating your thoughts in written form.

You could wait and submit your experience report idea via the Agile conference submission system in November. If you do, your chance of it being selected is limited. The format of the submission system makes it difficult to include details or have an ongoing conversation to sharpen your ideas. This year we had maybe 100 submissions from which we selected 20.

If you wait to submit your proposal via the conference system, it will have to really stand out from the crowd to grab our attention.

Instead, if you submit your proposal to the Agile Experience Program, it will be carefully read as soon as we receive it. If selected, we will work with you throughout the coming year. You don’t have to start writing immediately. You will get help from a shepherd as you write. As soon as you finish, your work will be published on the Agile Alliance website. You will be also invited to present your report at a future Agile conference.

I’m ready to help you write about your experience if you are ready to make a future commitment to writing. It all starts with your proposal.

Mob Programming: The Unruly Experience

Posted on June 5, 2015 by Rebecca

This year 11 experience reports were presented at XP 2015. As co-chair of Experience Reports, along with Ken Power, one of my last tasks was to select a best experience paper. That was hard. We had several good experiences to choose from (I’ll report on more of them in future blog posts).

Ken Power and I independently read and reviewed each paper. At the conference we compared notes and agreed on 3 papers we would consider for this award. We also reviewed the authors’ presentations before making our final determination.

The best experience paper was awarded to Alexander Wilson for his report, Mob Programming – What Works, What Doesn’t. One thing that made this paper stand out, was its balanced view. Alex is clear about things you need to watch out for when and if you try mobbing—don’t be lulled into groupthink and be aware of overly dominant personalities.

Alex Wilson telling us about Mob Programming at XP 2015

He also gave us a close look into his company’s mob programming experience.

Mob programming is where a team of programmers swarm on a problem. They work together instead of pairing or individually writing code. One person is at the keyboard, the rest of the team helps navigate. They pay attention and guide the person at the keyboard. Team members take turns at the keyboard. When mobbing, there are more eyes on the code and more minds focused on the problem you are trying to solve.

Folks at Unruly were inspired to try mobbing after Woody Zuill talk at JavaOne in late 2014. Woody also spoke about Mob Programming at Agile 2014. You can read Woody’s experience report here.

Developers at Unruly were seasoned XPers accustomed to pair programming and test-driven development. They are responsible for the entire lifecycle of their product, from research to operational support. They are in constant touch with problems and ongoing sustainability of code they write.

They decided to form a mob to work on performance enhancements to their existing product. This involved refactoring and reworking critical code. If they made mistakes, it could result in lost data and have serious financial impacts. Mobbing for them wasn’t just a casual experiment.

After mobbing one day per week for a couple of months they found, in general, that they were pretty happy with their results. After 5 months they concluded that they don’t prefer mob programming for all user stories. They do find mobbing beneficial for complex work (where there is the potential for errors) over complicated work (where the solution is known, but is merely time consuming). They also find that tasks that are dull or repetitive were likely to cause their mob to dissolve. They only mob one day a week, unlike Woody’s team who mobs every day.

Unruly settled on a rhythm of periodic mobbing that worked for them. That’s what I like about Alex’s report. He tells us: here is what worked, here is where we tripped up, here is how we adapted our practices, and here is what we’re doing now.

Teams in learning organizations perform ongoing experiments. While they settle on a core set of practices, they also try to build upon them. They keep innovating, improving, and reflecting. And how they work continues to evolve.

Life in the Mob

Posted on May 12, 2015 by Rebecca

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.

The Responsible Designer

Don't you want to take responsibility for your designs?

Category Archives: Agile Experiences