Development is all about feedback loops. We use analytics and AB tests to see how people respond to new features and design changes, and we tighten feedback loops within our teams with co-located workspaces, daily standups, and other tricks.
These techniques, however, are for the most part geared toward feedback about what we are building, rather than how we are building it. The latter, I think, is a much more powerful question.
One way we monitor our process is with regular retrospectives, where teams reflect on the period since the last retro and decide on things to improve. The interval between retros varies from team to team, but we typically aim for once a week.
A week is a long time, though. Compare the feedback loops we aim for in development: with a sufficiently tight continuous-integration cycle, you can be getting user feedback about features within days, and an ideal product manager/developer feedback loop takes from a few minutes to a few seconds. Conferring with my product manager just once a week would drive me crazy.
What if we established similarly quick feedback loops around process?
The experiment:
For the past few months, my pairing partners and I have been ending our day with a quick ‘plus/delta’ conversation. The ritual typically goes thusly:
- Push the day’s work to origin.
- Open an email. Cc myself and my pair, subject [plus/delta]
- Jot down observations about the day. “Pluses” are anything that went well, that we’d want to see more of. “Deltas” are anything that could have gone better, that we’d like to change (hence, ‘delta’). They can be things that one of us did, things we did together, environmental factors, etc. If it aids clarity, we’ll prefix items with the initials of the speaker, but most are statements we make as a pair.
- Send
The resulting email tends to look something like this (by me and my fictional pair, FP):
+ Really liked the query object we used for the filter story. Show it around at next dev meeting?
+ Liked how we checked ourselves frequently to keep from getting off track with refactors
+ Learned some cool RubyMine tricks! Glad we slowed down to figure those out, saved a lot of time
Δ DE: Caught myself zoning out mid afternoon, should try to drive more tomorrow
Δ Let’s not do logic puzzles during breaks anymore, those were exhausting
Δ Working through the database migration for the filter story was painful. Should ask about it tomorrow at stand-up.
Δ FP: There were a few times when I couldn’t tell how you felt about the approach we were taking, so I wasn’t sure how to proceed.
Δ DE: Be more vocal about when I haven’t yet formed an opinion, see if that helps
The results:
The conversation tended to take about 5-10 minutes, depending on how much energy we had after programming all day. The email made for a nice artifact; I can filter my inbox on the tag and scan through looking for recurring themes or changes over time. But the best part was the live conversations I had with my pair.
Often, we talked about way more than what made it into the email. I could ask questions (“Was I over-explaining the single responsibility thing? Is this editor working for you?”), and track changes (“We had a delta to balance driving and navigating more, was today better?”).
Making the conversation an established “thing” made it easier to voice criticism. I didn’t have to wait until an issue got bad enough for a, “Hey, um, before you go, I need to talk to you about something” intervention. The daily plus/delta provided a non-hostile forum for my thoughts. Having a designated time to reflect also helped me remember observations I would have forgotten without prompting.
Sometimes my pair and I shared the email just between the two of us, but usually we cc’d other people, like our project anchor. Even when my pair was out and I was working solo, I wrote up a plus/delta on the day and sent it to my anchor and manager. That sparked some great conversations.
Tips and tricks:
- On a Mac, alt+j types a delta symbol. Δ Δ Δ
- All comments are valid. Never explain away comments your pair makes, even if you don’t agree with them. Write them down, see where the conversation goes. Listen.
- Share the keyboard, paraphrase only with permission. People can feel shut down if you frequently re-word their comments. Taking your hands off the keyboard is a subtle way to balance the conversation.
- It’s okay to be unactionable. When something sucky happens, even if you can’t do anything about it, sometimes it feels nice just to acknowledge it was there. (“Delta: the construction noise across the street was pretty awful.” “Yeah, that was rough.”)
Conclusions:
It’s been very cool collecting these over time, seeing the way they’ve expedited conversations with my pair and produced visible, fine-grained improvements in how I work. While whole-team retros are great for prompting change at the project level, having small-scope conversations about a much smaller time frame has yielded a new kind of insight into what I do. I look forward to experimenting further!
About the Author
