Product Owner's Temptations: 'Don't Rely Solely on Your Own Thinking' — Agile Lessons Learned Through Trial and Error

For the past year or two, I've become bad at reading books.
I used to buy technical books, business books, and of course agile-related books almost every month, reading them and trying things out, but that habit suddenly stopped.
The content I read wouldn't sink in, and I’d get tired immediately...
Had my concentration declined, or had I become mentally dull? Or had my motivation been siphoned off by the plastic model hobby I started about two years ago?

I had heard that reading on an LCD monitor makes it hard to absorb information, so I tried buying paper editions and an e-paper device. I even tested magnifying-lens glasses. However, none of these had much effect.

I replaced the room’s lighting with high-CRI fixtures of the appropriate size, but I couldn't confirm any benefit for reading. (It did accelerate my hobby of painting models, though.)

What proved effective was audiobooks. I was able to listen all the way through without giving up, the content stuck with me, and I found it interesting.

It seems my intellectual curiosity and brainpower weren’t as diminished as I'd feared.

After all that trial and error, the solution I arrived at was “glasses.”
I was already wearing glasses, but one day I accidentally realized that the tiny text in a smartphone manga was easier to read when I held it closer with my unaided eyes.

The two kanji “presbyopia” flashed through my mind.

I dashed into a local eyeglass shop (not a foreign discount chain or a trendy boutique, but one that also sells hearing aids) and explained my situation.
The middle-aged shop owner efficiently handed me sample glasses with different prescriptions and a copy of the newspaper’s TV listing.

...I can see, I truly can see...

When I tried it on the smartphone manga in my hand, it was perfectly clear.

Thus, my reading problem was successfully solved after several years.
Happily ever after… but that would end up being a promotion for reading glasses, irrelevant to agile or system development, so let’s get to the main topic.

When I shared this story at work, I learned that everyone my age or older uses presbyopia glasses or contacts.
The shop owner quickly deduced the perfect prescription from my complaints and the prescription of my current glasses.
I should have asked from the start.

The time I spent thinking, researching, and experimenting on my own ended up being a detour.
Of course, the real-world knowledge gained from that experience wasn't wasted. Even so, it took far too much time and money to arrive at the commonplace answer of “presbyopia.”

Don't Rely Solely on Your Own Thinking

However, the problem doesn't end there. Even if you realize you could have solved it quickly by asking people around you or experts, you may not have been able to access the right person for advice or discussion at the right time. Honestly, I have no recollection of that.

If I map this experience onto an everyday development setting, it looks something like this:

An engineer spends hours staring at the screen wrestling with an unknown error.
When they share it in the next morning’s stand-up, another engineer says, "Oh, I ran into that problem last week too, so I can fix it right away."

In other words, looking for someone to consult after a problem arises is too late. I felt keenly that it’s truly important to build a network of reliable contacts with whom you can casually consult in everyday practice.

Concrete actions for building this network include creating and updating a “skill map” and activities like “Find Your Neighbors (Project Community).”
These are not formalities to be drawn up once on an inception deck and then forgotten.

Just as I reached the quickest solution that day at the “local eyeglass shop,” it’s about creating an extremely practical safety net that allows our team to always find the fastest clue to solving problems.