Scrum Therapy and Medium Clickbait!
In Scrum, we’re forced to confront our successes and failures at the end of every sprint. On the list of my many recurring calendar invites, this ranks near the bottom for me. However, unfortunately (for my ego) I am also forced to confront that this meeting has the potential to be the most valuable part of the entire methodology. This is true only if we genuinely reflect, however. And daggum-it, we aren’t giraffes that fall six feet out of our mother’s wombs and can walk on our gangly legs within minutes— that is, reflection is not something we humans (and especially we programmers) are already good at. The hardest part is making sure we don’t spare our own egos in the process.
I recently gave feedback to someone and I accidentally said something pretty good-sounding (quite unlike the phrase “good-sounding”). So good-sounding that I’m going to assume I accidentally found it elsewhere. Consider this an APA-style attribution to Anonymous.
“Look for opportunity to grow, not opportunity to prove you’re right.”
Someone famous said something like this, right? My Googling is failing me.
Sprint retrospectives are intended to provide a safe space for us to put this into action, collectively. To look for opportunity to grow. Great project leadership can take this intention and make it reality, as it’s hard to make people feel safe enough to talk collectively through failure. What’s more— and I can’t believe I’m saying this — I think we can actually learn something from Scrum and apply it more generally.
Blech. Even typing this sentence leaves a bad taste in my mouth.
You see, Scrum’s recurring retrospective meeting is a model for constructive, recurring, individual retrospective too—and again, like sprint retros, they are valuable only if we take the time to genuinely reflect.
For the last couple of years, I’ve made it a point that when I come across a substantial win or loss, I open up NeverNote and start thinking back through what the heck just happened.
For example, last time I had to let go of someone, I took at least a full hour after the dust settled to go over slack messages, emails, and timelines. This was honestly a painful time, but I needed to spend time lost in the forest, following the footsteps. I already intimately knew the feedback items for this particular person, but I needed to generate and understand the feedback items for myself. I wrote a synopsis and some succinct takeaways for myself. Relational stress is seldom one-sided, and this absolutely includes a manager’s relationship with their reports.
Poking through my old notes, I also have one analyzing a specific bug in production that had, unbeknownst to us, been affecting our analytics collection for several months. A retro of live ops catastrophes is already a core part of any effective methodology, but I apparently needed to dive deeper on my own. I also needed to let it sit in the back of my mind for a bit — I needed to not think about it for awhile. Not everything can be retro’d immediately, and this gap time allowed me to come up with some useful self-feedback that would not have come up in a directed, team setting.
I often apply this approach after “intense meetings” too. You know the ones I mean. Did somebody get heated? Was that somebody you? I’ve even — GASP! — skipped the next meeting I had to continue unpacking the previous meeting in which I became irate. Hey, come on, what do you want from me? This stuff is important! More often than not, I come to the conclusion that, yet again, an apology is in order. Good grief (I could probably write a book on how important open and honest apologies are for managers). Skipping the “I screwed up” part gives your reports license to also be jerks. When you’re clearly, openly at fault, it also gives your reports evidence to doubt you next time. “He didn’t admit his mistake last time —so he’s not going to this time either.” That’s a toxic place to be.
Finally: a retro for this post (isn’t this meta?). I know, I know, I could have made this article shorter (people don’t like words) and like the greyhound, more pointy — bullet-pointy (see what I did there?). This is the unspoken decree from the Medium gods. I suppose I could have burned more incense. And for more Medium views I probably should have named it something insipid like “7 Reasons Elon Musk Hates Docker.” Aieee, what is wrong with our brains.
I suppose I’ll close with an apology: sorry for — of all things, thinking about Scrum.
