Day 193 – Get Out of the Clams

I wrote my first computer program on a TRS-80 Radio Shack computer connected to my parents’ living room TV in the 1980s. I was not really watching the exciting new developments in computer science until around 1992. From that point on, monitoring trends and innovations became part of my job. In all that time, a few major events stick out. The one I remember most was the day the website agilemanifesto.org came out in 2001.

You can still visit that website today. It has been there since 2001. The story is that a group of people got together around a whiteboard and decided to change the software development world. This meeting was the birthplace of what we call Agile. One of the original signers of the Manifesto was Alistair Cockburn. He is still alive today and pretty active from what I can tell.

I enjoyed many of his books and ideas, but the thing that always stuck with me was his Cloud, Kite, Sea, Fish, and Clam use case levels. It is a way to talk about the scope and level of detail of requirements or use cases in software work. I use it all the time, not just in my software world. “Honey, explain this to me at the Cloud level, let’s not get down into the clams just yet.” Just kidding, I would not actually say that to my wife.

The basic idea is that teams often talk past each other because one person is speaking at a very high level and another is speaking at an implementation detail level. Cockburn’s model gives names to those levels so people can align on altitude before discussing a feature.

Cloud is the very high level business goal or vision. Kite is a major business process or capability. Sea is the user goal level, usually the right level for a normal use case. Fish is a subfunction or supporting task. Clam is a very small internal step or implementation detail.

The metaphor is about altitude. Cloud is far above the ground. Sea is where normal users operate. Fish and clam are underwater details.

When someone says, “That’s a fish level discussion” or “Let’s stay at sea level,” they mean let’s align on the right level of abstraction before we go deeper. I personally find the metaphor a great way to recognize that you are not having a conversation with someone at the same altitude.

“Teams often talk past each other because one person is speaking at a very high level and another is speaking at an implementation detail level.”

I still use this framework today. It helps me notice when a conversation is drifting into the weeds or floating too far above the ground. The simple act of naming the altitude changes the dynamic. You can adjust. You can meet the other person where they are, or you can ask them to come to where you are.

The next time you feel like you are talking past someone, ask yourself what altitude you are at. Then adjust.

Subscribe
Notify of
guest
0 Comments
Inline Feedbacks
View all comments
Share the Post:

Recent Blogs

Day 339 – Story Telling is Our Stewardship

The author reflects on the importance of storytelling after witnessing his daughter receive an award for her perseverance. He argues that stories are crucial for passing down wisdom and experience across generations, preventing the loss of valuable lessons learned through life’s challenges.

Read More

Day 338 – What Is Humility?

Humility is often misunderstood as self-abasement, but it’s actually the ability to accurately perceive oneself, including strengths, weaknesses, and dependence on others. This perspective allows for easier learning, improved judgment, and better interpersonal relationships. Humble leaders foster open communication, and embracing humility can be incredibly freeing.

Read More

Day 337 – Principle Artifact Confusion

The author draws a parallel between the barefoot running craze and the current hype around AI coding tools, highlighting the danger of “Principle–Artifact Confusion.” This occurs when a sophisticated practice is reduced to a product, and the product is then mistaken for the underlying principle that made the original practice successful. The article emphasizes that AI should amplify good fundamentals, not replace them.

Read More

Day 336 – Your Presenteeism is Not Useful

This article challenges the common belief that simply being present at work, even when performing suboptimally, is beneficial. It argues that ‘presenteeism’ can lead to decreased output, increased mistakes, and prolonged recovery, ultimately creating a ‘recovery debt.’ The piece advocates for deliberate rest as an investment in future productivity, emphasizing that true recovery involves activities like sleep, proper nutrition, and disconnecting from work, rather than passive leisure.

Read More
0
Would love your thoughts, please comment.x
()
x