Learning How We Learn

Some years ago, I created a new product by running an experiment called Agile Nomad.It showed up briefly as an iOS app and was often described as a Scrum companion, though that description never quite captured the intent. Agile Nomad wasn’t built to help teams follow Scrum more closely. It was built to explore how teams think while working together.

This was a time before full remote work became the norm. Teams were largely co-located. Whiteboards, walls, and physical spaces played an important role in collaboration. Mobile devices were becoming capable of capturing more than text, but the technology was still early. What if collaboration wasn’t dominated by typing and reading, but by images, short audio recordings, quick dictation, and context captured in the moment?

Agile Nomad was an attempt to explore that question. It encouraged teams to move, to leave their chairs, to engage with their surroundings, and to capture thinking in forms that were faster, messier, and more human than carefully written notes. The intent was never efficiency or scale. It was learning through interaction.

Looking back, I can see how closely this experiment aligned with an Agile Manifesto value that continues to matter deeply to me: individuals and interactions over processes and tools. At the time, I wouldn’t have articulated it that way. But the instinct was there.

Agile Nomad didn’t gain traction. It failed. Teams asked for reports, estimation, backlog management, role clarity, browser access, cross-platform support. Those requests were reasonable. They reflected the reality most organizations were operating in. Agile Nomad wasn’t designed to support that reality. It wasn’t meant to become a system of record or a replacement for existing tools. It was meant to support thinking.

That distinction matters.

Around the same time, agile tooling was becoming more standardized. Tools began to carry not just work, but meaning. I often heard teams say, “We are an agile team. We are using Jira.” Without intent or malice, the tool had started to represent the process. In some cases, it became the process.

Agile Nomad didn’t fit into that world. It didn’t prescribe workflows or offer reassurance through structure. It asked teams to pause, observe, and reflect. That made it uncomfortable. And that discomfort was data.

What I learned from the experiment was not that the idea was necessarily wrong, but that supporting a thinking process is fundamentally harder than supporting an agile team following a process. Organizations adopt processes readily. Learning requires patience, uncertainty, and reflection.

That learning stayed with me.

Years later, with the emergence of Agile Kata, the connection became clearer. Agile Kata is not a framework and not a tool. It is a thinking pattern that helps individuals and teams learn their way through uncertainty. It asks different questions. It values experiments over certainty and reflection over compliance.

Interestingly, I encountered tools like Google Keep much later, not through agile work at all, but while researching tools for my personal journaling. Journaling, at its core, is about capturing experience and noticing learning over time. It is not documentation. It is sense-making.

What struck me was not the tool itself, but how much the technology had evolved. Today, a photo of a scribble on a whiteboard can be taken in seconds and the text becomes searchable through OCR. An audio note can be recorded casually and instantly transcribed, making spoken observations as searchable as written ones. Images, audio, and text are no longer separate islands. They become part of a single, searchable thinking space.

This is a remarkable shift.

What once required deliberate structure, discipline, and manual translation now happens quietly in the background. Learning artifacts no longer need to be standardized up front. Teams don’t have to agree on labels, formats, or categories before they can begin. Meaning can emerge later, through reflection.

This isn’t an argument for one tool over another. In fact, it’s the opposite. Some of the most useful tools for kata-based learning are not labeled as such, are not part of large product suites, and make no claims about how work should be done. They simply support capturing experience and revisiting it as learning unfolds.

In that sense, Agile Nomad didn’t fail. It completed its experiment. It surfaced an important truth early, before the technology was fully ready to support it.

Agility doesn’t emerge from better tools or more sophisticated processes. It emerges from how well individuals and teams are supported in learning. Agile Kata gives us the pattern for that learning. Today’s technology finally makes supporting it easier.

That insight continues to shape how I think about Agile Kata.