We'll respond shortly.
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 at Pivotal 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?
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:
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 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:
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!