Retrospecting (using head, not some "guide" ...)

Retrospecting (using head, not some "guide" ...)

This blog post is about: what's wrong with Scrum-ish retrospectives, what's the better alternative, why questioning yourself is nothing about self-doubt or slowing down the decision-making, is it necessary to abandon "retros" and why awareness leads to clarity (and what does it really mean).

Scrum was a great idea, invented by brilliant people, with great intentions in mind. No doubt about that. A shame it didn't work out ... One of its brightest spots was emphasizing the role of retrospecting over what went well & what could use some improvement - it has even got a dedicated ceremony: some even tend to say it's the most important one.

I tend to say: it's the first one to get rid off ;P

It's not the idea I condemn, but the form. Instead of scheduled, periodic "retrospectives" I prefer (by far) continuous "awareness":

  • questioning the work on-the-go ("am I doing it right? am I solving the real problem? are key questions being answered / key issues being addressed? is this the highest priority?")
  • sharing observations (by information radiation) as they appear
  • instantaneous feedback

That's how you build habitual Continuous Improvement.

What's wrong with "Retros"?

Time skews our perspective - it's not only that we forget our prior observations, we also downsize/exaggerate the importance of particular thoughts, we subliminally avoid traumas we're glad are over, we're already in a different mode - thinking about what comes next or recharging after crunching through tough problems.

That's why vast majority of Scrum-like Retrospectives I've ever attended were a total waste - regardless of team's quality & maturity, regardless of people experience & how "agile-infused" their mindsets were. Basically these were sessions full of:

  • (non-specific) information-barren shoulder-patting
  • non-actionable observations ("we like X" - "so what (do you want to do with that)?" - "ekhm... nothing")
  • ruinous empathy (in case of something didn't go as intended)

This ritual is frequently perceived as ...  a chill-out time-filler before next Sprint starts. The same (or very similar) observations are repeated over and over again, yet, even the simplest issue (e.g. people coming late to daily stand-ups) is pretty much unsolvable.

Continuous Awareness

This thing about good ideas (incl. optimization ones) is that you never know when they pop up. Sometimes on-the-go (while you work on something this idea is about), sometimes during slack time, vacation, shower, sleep, walk, run, state of flow, ... The only known thing here is that they can't be scheduled ;P Assuming they'll come by when it's time for your pre-scheduled Retrospective meeting is ... kinda naive (at best).

That's why my advice for you is:

  1. don't let good ideas get forgotten (ALWAYS. BE. NOTING.) - I use Otter & Notion for that
  2. even if they are just observations, share them with others in a non-intrusive, asynchronous pub-sub way (because they can provide additional insight or can come up with a solution)
  3. always question whatever you're doing (really, I'm serious here!)

I believe that it's the last point that requires some clarification. I'm certainly NOT encouraging you to be slow with the decision making - e.g. by doing SWOT analysis for every basic action or by always looking for 5 other people confirmations ... Quite the contrary - make fast decisions based on the actual data, but build-up high awareness of your work:

  • judge outcomes in contexts of decisions made earlier (to draw conclusions & provoke learning)
  • always look for value achieved by doing this particular piece of work (to confirm it was not a waste)
  • validate & shift priorities on continuous basis
  • carefully consider all kinds of "mechanical" work - the one which is being done because "we're doing it like this here since ever"
  • question the reality - don't accept deficiencies, imperfections or drawbacks just because they appear "natural" (if they are a real pain)

Abandon Retros?

It's not about banning the periodic meetings, really. They can be quite useful if you approach them sensibly, e.g.:

  1. they can be used to pick, plan & summarize experiments - there's no learning w/o experimentation, so team should pick 1-2 such items each Sprint (with a specified goal, time boundaries & validation method) & then re-evaluate the outcomes during the next meeting
  2. team can note things down (during normal work) for future elaboration - stuff that can't be addressed on the go, but is probably too important to ignore; you all can revisit this "parking lot" (sounds like a clear agenda ;>) every now & then or skip the meeting if the list is empty

If you decide to keep the meetings, I encourage you to:

  • strive to conclude noted items either with some decision ...
  • ... or at least SMART action-item(s) to perform

A Quest

OK, focus, here comes the most important part.

High self-awareness is not a purpose itself. It's a mean to reach CLARITY. Clarity regarding whatever you're doing. What I'm proud of is the fact that when I do things it's not because I've read it somewhere. Or because someone told me to. It's because I know that these are the very actions needed to fulfill my goals - and I understand why is that (how they contribute to the goal & why it's exactly THESE actions, not some other ones).

I hereby see the PATH (to my goal(s)).

You should always aim for maximized clarity (aka in-depth understanding). Without clarity, there's no MASTERY. And mastery (according to no-one else than famous Daniel Pink) is (together with autonomy & purpose) a key factor to achieve both high performance AND satisfaction from whatever you're doing.

Sebastian Gebski

About Sebastian Gebski

Geek, agilista, blogger, codefella, serial reader. In the daylight - I lead software delivery. #lean #dotnet #webdev #elixir. I speak here for myself only.

Comments