Digging In
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 to 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 to 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.
- Previous: Early Performance Testing at Agile 2015
- Next: On Thinking