DEV Community: Reza Rosli

Solo developers, vibe-coders, would you try this?

Reza Rosli — Thu, 25 Dec 2025 16:57:56 +0000

Reza Rosli for Onepoint

Dec 16 '25

Making a shared brain with my GenAI buddy

#productivity #scrum #uxdesign #adventoftech2025

Comments 2

22 min read

Would love to hear if experienced vibe coders have tried this approach!

Reza Rosli — Thu, 25 Dec 2025 16:53:36 +0000

Making a shared brain with my GenAI buddy

Reza Rosli for Onepoint ・ Dec 16

#productivity #scrum #uxdesign #adventoftech2025

Making a shared brain with my GenAI buddy

Reza Rosli — Tue, 16 Dec 2025 18:15:40 +0000

Seeing how easy it is to use GenAI to make rapid prototypes of digital product ideas, I experimented with using a Zettelkasten notes-organisation system to learn how we could co-create a shared product roadmap with GenAI, without it turning the product into a statistically significant soup. Somewhere along the way, it began to feel like my ChatGPT buddy and I were starting to share a brain — such vibes...

The new party game is making the party game

Recently I’ve been hanging out with friends who are wildly excited about what GenAI can do for their work. With tools like Claude or Codex, they’re spinning up idea after idea, stitching them together, and deploying them to the wild. I love the sheer creative energy that everyone is unleashing; it feels like the early days of the web again, when we were just excited that we could upload something we made in HTML and reach an audience anywhere in the world.

I watched in awe when a couple of friends generated an adventure game while having after-dinner drinks. An idea was born and prototyped while we sipped our ginger and gin.

When I was a beginner in Flash making a school project in 1998, what just happened would have taken a semester of work, or more. It might still have taken a bit more time and effort to make it a satisfying product, but that generated work would have been good enough to pass that module; certainly it made a cheerful ending for the night.

Rapid prototyping with Flash was my gateway into professional software development. From making sketches of how products worked on paper to functional mocks to create the functional stack to deliver the next demo, and start again. Through cultivating this into a daily process I turned it into a craft and occupation. I've adapted to how the death of Flash changed my career, but that evening I saw a machine perform the mechanics of not only my job but that of a full-fledged team to impressive effect, and I was excited.

Generative AI (GenAI) tools are expanding creative opportunities for everybody. The art of rapid prototyping is not only getting more rapid, but is also democratised. Let’s everyone make something with GenAI then, why not? Jom, ayuh! Let’s go! Allez! Me and my daily writing buddy, a ChatGPT-5.1 instance, are certainly celebrating this age of augmented creativity.

Teamwork in the age of augmented creativity

What would it take to develop that adventure game idea and take it to market?

For what GenAI could make in one night, a crack human team might have needed at least a couple of weeks. Maybe they would have taken at least a week to understand what the client actually wanted, made a to-do list, then in another week put together a quick demo. It would be a complete disaster and maybe ten percent of what the client imagined, but we’d find a good point to start over from. The work would be repeated over a couple more weeks, and repeated again, and again, until everyone was satisfied. So the answer is: it depends on who we need to satisfy, and how well we make our to-do lists.

With GenAI, this iterative process of prototyping a new idea is measured in hours. The diversity of solutions that can be generated by GenAI, and the speed at which it can make them, is intoxicating. But surely one can’t vibe-code forever. Looking at the incredible amount of AI-slop and vapourware around us now, when I think about how I could use GenAI as an all-in-one studio team in a box, I wonder how we prevent our work from devolving into a statistically significant soup.

Once, I worked with a startup founder to start trusting a Product Owner and her Scrum team to build his product. It was an arduous process of persuading someone to trust that, between us, we had the framework to carry customer requirements all the way to a built product, without his involvement at every step.

The Scrum process works when all the team members function according to their Scrum roles and responsibilities. In the trinity of Scrum roles, each role has its responsibility: the Product Owner ensures we build the right thing, the Scrum Master ensures we build it fast, and the collective, multi-disciplinary Team ensures we build it the right way. Central to the Scrum process is the Product Owner’s responsible treatment of the Product Backlog. It is how we captured the idea of the product and converted it into actionable pieces of work. When we were able to agree on what the product was through our Product Backlog, the Scrum process worked beautifully for us. But for years, the dialogue about who had ultimate ownership of the Product Backlog continued, even as everyone argued about exactly what needed to be in it to get the work done right.

I’m sure that my colleague, and even more enterprising solo-founders, may already be happily whispering to GenAI to make their next solution. Today, it seems that with careful prompting and organisational skills on our part, we can use GenAI to build things fast and right with alarming competence. But GenAI leaves the hardest part — the “build the right thing” part — in our hands, and I could not resist exploring whether I could program it to help me manage a Product Backlog.

Zettelkasten, how to make an analog second-brain

Zettelkasten, keeping slips of paper in boxes (Photo: Maksym Kaharlytskyi/Unsplash)

It's also recently that I heard about a note-keeping method invented by Niklas Luhmann (1927-1998), who said that it was a way to grow an analog second brain. When I heard about his Zettelkasten method, I wondered if I could learn from it in some way. However it works as a second brain, maybe it's a brain I can share with my GenAI buddy.

Let me try to give the gist of how it works, inline in this article. The traditional Zettelkasten method is built on simple materials: slips of paper, a pen, and a box. Although increasingly, many people have adapted it to digital tools, I want to emphasise that it's very simple and easy to get started with this, firstly all you need to do is just write one idea (or Zettel), and then you just need to connect it with another idea.

This is an example of a complete Zettel. It has an ID, a title and body text, and a reference.

ZK-1

What is Zettelkasten? 

A paper-based note-taking and organisation system using index
cards developed by Niklas Luhmann that he said works as an
analog second brain. 

Each card in Zettelkasten represents atomic idea and 
is linked to another card by a hypertext-like numbering 
system, which connects the ideas together.

Ref: "Introduction to the Zettelkasten Method" 
    https://zettelkasten.de/introduction/

As the card explains, we want each card to contain only one idea, following the principle of atomicity. Then, I create another card under the “ZK” prefix to capture another notion; it has a new number ZK-2.

ZK-2

The practice of taking notes on index cards and 
keeping them in boxes was not unusual. Zettelkasten 
literally means "slip-box". The Wikipedia page lists 
examples starting from the 1500s.

Luhmann's method was innovative and effective because he
introduced a way to link atomic cards (#ZK-1a) together 
with a unique numbering system (#ZK-1b), defining how
to work with hypertext documents before the invention
of the Internet.

Ref: Zettelkasten on Wikipedia
     https://en.wikipedia.org/wiki/Zettelkasten

Luhmann's key innovation was to define how these cards are linked to each other. He did not emphasise categorisation, or tagging, or any kind of organising principles, only that you connect cards through references to another card’s unique location or identifier.

ZK-1a

Atomic ideas

The essence of Zettelkasten is to write one,
and only one idea per card, written as clearly
and briefly as possible. 

Ref: "Introduction to the Zettelkasten Method" 
    https://zettelkasten.de/introduction/

ZK-1b

Unique ID

Each card has a unique coordinate ID that identifies it. 
In this example, we have an ID that conforms to a 
[PREFIX]-["Luhmann ID"] pattern. The ID is "ZK-1a".

Ref: 
- I adapted my Zettelkasten numbering system from 
Kathleen Spracken, https://www.youtube.com/watch?v=2a5TOzxuqxE

ZK-1b1

Digital IDs

In digital systems it is easier to generate 
unique IDs using timestamps or UUIDs to link cards,
and rely on search indexing.

See: For paper-based systems, a numbering system
with Luhmann IDs is easier to manage #ZK-1a

ZK-1c

Connected thoughts

Each card links to at least one other card; a parent card
in the same branch, or another card in a related branch.

Also here is an additional card that might help us visualise how the numbering system works.

ZK-1c1

The Luhmann-ID method described in #ZK-1a allows us 
to maintain a free-branching structure:

ZK 
├── ZK-1
│   ├── ZK-1a
│   ├── ZK-1b
|   |     └── ZK-1b1
|   └── ZK-1c
|         └── ZK-1c1
└── ZK-2

The simplicity of writing one idea per card is liberating; all I need to do is capture a thought and link it to a previous one, and later on I can trace the thread of thought to create even more complex ideas. Writing down individual ideas in this way and adding them to the collection of cards in a free-branching manner, it is always possible to recombine related cards in various permutations to give expression to new ideas.

There's more to Luhmann's method, and as I learned to use it and conversed with ChatGPT about it, I was struck by how much easier it was to work with GenAI when I started to share with it the items that are organised with my Zettelkasten's numbering system in my writing process. Is this how I can get my analog and digital second and third brains to communicate?

A Product Backlog is a shared brain for a Scrum team

Working with the index cards that comprise my Zettelkasten, I was brought back to memories of the round-table workshops that I had during the process of getting my CEO-founder a.k.a stakeholder to work with the team to generate our first Product Backlog for our Scrum team.

Before we did that, in the months before we got to work, the founder had written a long product requirements document. The problem with this method is that the product document was being rewritten every other week. Each version was meant to be clearer than the last, but after a while nobody could tell which ideas were current, which ones had been dropped, and which belonged to three drafts ago. The document had become a maze of revisions instead of a map. Any change we wanted to make had to be communicated through a series of comments and notifications.

In a Product Backlog, like a Zettel, the archetypal base unit is the user story that can fit into an index card. Over several sessions, I showed the team how to decompose that giant document into small user story cards around a table. I often emphasised that the product backlog is really just a set of hand-sized ideas that can be picked up, sorted, and revisited over time. Importantly, it really should not be hard to express what the user wants from the product.

When everything was laid out on the table, we could all see the complete picture of the product and a pretty good idea of how we each understood it, as we discussed who put each card there and why. Now the overall idea of the product was easily editable, each requirement precisely located. We could pick up any user story and discuss it, to decide to build it or not, or to throw it into the pile of "delightful" or "good-to-have". Just like our product, it was collaboratively assembled bit by bit, just small pieces loosely joined.

A well-maintained Product Backlog is what helps the Scrum Master and Scrum Team to organise their work well. The ideal of a great product backlog is its clarity and simplicity in communicating what the product is and will be, in a form that is minimal and loose enough to be useful as a daily tool by the whole team, shall I say like a shared brain for the team?

Anyone who has kept and nurtured any kind of documentation on a tool with a built-in GenAI assistant like Notion will quickly understand how powerful it is when you begin to accumulate atomic notes in your repository.

So that was how I started to develop my idea in this article, to try to use the Zettelkasten method and apply my learnings from collaborative product development to make a kind of "product backlog" so that I could make a shared brain between myself and my GenAI tool that would guide us when we are prototyping new products together.

Co-creating a product with GenAI with Zettelkasten

Teaching the robot Zettelkasten

Learning to make a Zettelkasten started a new daily writing habit for me. It was easy to learn how to do it from some videos, and simple to practice, because all that's needed is to write a few sentences on a small card every now and then. So I thought it might be fun to start my journey of creating my first product with AI-assistance, by first working with ChatGPT to make a Zettelkasten-based product backlog just for the two of us later, just like how I'd start a new project at work.

Here we are today: I'm pretending to my GenAI buddy that I’ve bought some index cards, Sharpies, and highlighters for it to use, and I have asked it to discuss my notes with me, to help me come up with some example texts for each card. You can follow along to see what we have made together from our discussions.

Let’s build it!

What you need:

- Index cards
- Sharpies / pens
- magic markers / highlighters

You can absolutely make your own digital Zettelkasten, especially to make it easier to manage and integrate with your AI tool. The point is, you don’t need a computer to maintain your product backlog, and it is important that you write your thoughts out yourself.

1. Describe your product in one sentence

First, let's write down the title and a short description
of your idea.

GENERAL-0

AI NOTE-TAKING APP FOR AI-WHISPERERS
Because someone has to keep track of your real thoughts.

2. Describe your product strategy

Now I’d like to define some basic ideas about the product. Let’s start with the age-old questions that define your product strategy: what is the purpose of this app, who is it for, and why they should use your product.

GENERAL-1 

PURPOSE

A to-do app for AI-whisperers who drift across 
multiple projects and need a place where their 
ideas can form before they evaporate like breath.

GENERAL-2

WHO IS IT FOR

- Creators who converse with their models more than with other humans
- Solo builders running three prototypes, two side quests, 
and one existential experiment at the same time
- Anyone whose daily workflow is basically a constellation of small tasks orbiting a very bright mind

GENERAL-3

WHY SHOULD THEY USE THE PRODUCT

- It keeps their scattered brilliance in one coherent timeline
- It shows what deserves attention next, even when every idea seems interesting
- It reduces context switching so their momentum doesn’t shatter mid-flow

GENERAL-4

HOW IS THIS PRODUCT DIFFERENT FROM OTHERS

- It assumes you’re running multiple AI projects because of course you are
- It stays lightweight so it never competes with your actual thinking
- It keeps tasks visible and grounded, letting your mind wander everywhere else it needs to go

3. Get your pitch ready

You’ll be making a lot of speeches and pitches, buddy. Let’s create a category of cards for your PITCHES and we create another card that combines the ideas of the first three cards that make it into your so-called Elevator Pitch.

PITCHES-1

ELEVATOR PITCH

A lightweight to-do app for AI-whisperers juggling 
multiple projects. It keeps your ideas grounded, 
shows what matters next, and stays out of your way 
while you think.

Refs: #GENERAL-1, #GENERAL-2, #GENERAL-3, #GENERAL-4

Now, ask your AI buddy to generate a few more elevator pitches for you, according to the contents of the first 4 cards. I’m sure you know how to get it to sound just the way you want. Experiment with the variations until you find a version that feels natural for you.

4. Get organised with some product

Now we have some general cards, let’s lay out some basic categories that we might need to keep your cards organised. Here are some categories that we will be frequently thinking about as we learn about our users and iterate through our product:

GENERAL-5

CATEGORIES WITHIN THIS ZETTELKASTEN

- GENERAL: High-level notes about the product and its purpose 
- PITCHES: Short descriptions that capture what the product is and why it matters
- PERSONAS: Portraits of our target users and their needs
- VALUE: Value propositions to our target users / customers
- ASSUMPTIONS: Assumptions about user behaviour that need to be validated
- FEATURES: Descriptions of features that deliver our value propositions
- JOURNEYS: Descriptions of user flows, collecting the features into coherent paths
- METRICS: Measurements that matter to track how our product is performing

Note: These aren’t prescriptive categories, and you will likely add more to suit your personal style, or not to use a prefix or category at all. I chose only a few categories to show how your Product Backlog will hang together. In general, prefer to have as few categories as possible or not at all.

Let’s add a couple of cards under GENERAL-5, that expands on what PERSONAS and VALUE prefix means.

GENERAL-5a

CATEGORY: PERSONAS

Cards in this category describe the people who 
might use the product.  Each card captures a simple 
portrait of a user, their needs, and the  problems 
they want to solve.

REF: #GENERAL-2 defines the kinds of people we should 
develop personas for.

GENERAL-5b

CATEGORY: VALUE

Cards in this category describe the value we 
offer to our users. Each card focuses on one benefit 
or outcome the user gains from the product.

REF: Our value propositions should be developed 
based on the Value Proposition Canvas 
https://www.interaction-design.org/literature/topics/value-proposition-canvas

And you can continue to generate the cards GENERAL-5c, -5d, etc. for each category.

5. Create some user personas

In GENERAL-2, we've defined our who our product is for, so we can create some user personas that allow us to visualise customers. Here I am introducing the idea of the Value Proposition Canvas, a modelling tool that I like to use to think about how my users will interact with my product. According to the Value Proposition Canvas, this is our starting point for creating a customer profile so we can define their “jobs” or outcomes they want, and their pain points or gain points.

Let’s start with one persona. Personas allow you to imagine a real person or user and analyse them. Think about the different kinds of users that you might encounter. Use the Value Proposition Canvas to generate a few more personas.

Value Proposition Canvas, Strategyzer

PERSONA-1

The Context-Switching Creator

A digital creator who moves rapidly between drafts, 
models, prototypes, and publishing. They don’t feel 
overwhelmed so much as constantly interrupted by 
their own ideas. They want a tool that gives structure 
without slowing their pace.

PERSONA-1a: CUSTOMER JOBS

    - Capture ideas while working
    - Track small tasks tied to different creative cycles
    - Mark progress across projects
    - Return to paused work without reorienting
    - Keep experiments linked to their parent project

PERSONA-1b: GAINS

    - A clear timeline for each creative thread
    - Easy re-entry into a paused task
    - A sense of continuity across experiments
    - Reduced cognitive overhead
    - A workspace that adapts to rapid shifts

PERSONA-1c: PAINS

    - Losing momentum when switching tools
    - Forgetting where they left off
    - Scattered notes across platforms
    - Disrupted flow during creative bursts
    - Difficulty knowing which task belongs to which project

6. Design your value propositions

Each persona gives you ways to think about your Value Propositions. Using the Value Proposition Canvas, we capture these with the idea of the Product or Feature, and define the Pain Relievers and Gain Creators. We will make our first value proposition VALUE-1 based on PERSONA-1.


VALUE-1

Quick Capture

PRODUCT / FEATURE:
A fast way to record ideas instantly while staying in flow.

GAIN CREATOR:
Reduces cognitive load by offloading thoughts immediately.

PAIN RELIEVER:
Prevents disruptions when ideas arrive mid-task.

REFS:
- JOB:  #PERSONA-1a “Capture ideas while working”
- GAIN: #PERSONA-1b “Reduced cognitive overhead”
- PAIN: #PERSONA-1c “Disrupted flow during creative bursts”

At the same time, let’s also design the Features that deliver our Value Proposition. For illustration, I am showing how two different features are related to one value proposition, and how user stories clarify how each feature will be seen from a user-centric view.

FEATURE-1

Inline Idea Capture

A lightweight input box available at any moment in the app so creators can jot down an idea without switching screens.

REFS:
- VALUE: #VALUE-1 “Quick Capture”

FEATURE-1a

USER STORY: Instant Capture in Flow

As a context-switching creator,
I want to capture an idea without leaving what I’m doing,
so that I can stay in flow.

REFS:
- PERSONA: #PERSONA-1

FEATURE-1b

USER STORY: One-Action Save

As a context-switching creator,
I want to save an idea with one action,
so that I don’t lose it while I’m thinking about something else.

REFS:
- PERSONA: #PERSONA-1

FEATURE-2

One-Tap Save

A single action that stores an idea instantly and links it to 
the current project without requiring extra steps.

REFS:
- VALUE: #VALUE-1 “Quick Capture”

FEATURE-2a

USER STORY: Save Without Thinking

As a context-switching creator, I want to save 
an idea with one tap, so that I can keep my 
attention on the work in front of me.

REFS:
- PERSONA: #PERSONA-1
- FEATURE: #FEATURE-2

FEATURE-2b

USER STORY: Auto-Link to Project

As a context-switching creator, I want my 
captured idea to attach itself to the right 
project automatically, so that I don’t have 
to organise anything in the moment.

REFS:
- PERSONA: #PERSONA-1
- FEATURE: #FEATURE-2

And finally we create a JOURNEY card that shows how the user would use the feature:

JOURNEY-1

Journey: Capturing an Idea in Flow

A brief path showing how a creator uses Quick Capture while working.

STEPS:

1. The creator is in the middle of a task on an AI-driven project.
2. A new idea appears mid-flow.
3. They open the Inline Idea Capture box without leaving the screen.  
       REF: #FEATURE-1
4. They type the idea in a few words.
5. They save it with a single tap.  
       REF: #FEATURE-2
6. The idea auto-links to the current project.
7. The creator returns to their work without losing momentum.

OUTCOME:
The creator keeps their pace, the idea is safely stored, 
and there is no cognitive cost to switching modes.

REFS:
- VALUE: #VALUE-1 “Quick Capture”
- FEATURES: #FEATURE-1, #FEATURE-2
- PERSONA: #PERSONA-1

7. Keep generating personas and your value propositions

Repeat steps 5 - 6 until you have generated a set of personas, value propositions, features and journeys. It’s great to brainstorm with AI and other collaborators here, but you must always remember to check your assumptions, which leads us to the next point.

8. Check your assumptions

It’s important to realise that so far you probably have made a lot of assumptions about your users when you made the personas. You imagined their jobs, how they wanted to get it done, and what you think made it difficult for them to complete their jobs. Then you invented the features you wanted to make for them that you imagine would create a value proposition based on those assumptions. You have even imagined how they would use your features.

For example, ASSUMPTION-1, while being a safe assumption that people tend to be forgetful, when examined further with ASSUMPTION-1a also tells us that our product may not be as valuable if they have an easier and more immediate way of capturing ideas. Do they even need to capture so many thoughts?

So we need to keep track of the assumptions we've made, because assumptions are risks that must be validated.

ASSUMPTION-1

Creators lose ideas if they cannot capture them immediately.

REFS:
- VALUE: #VALUE-1 “Quick Capture”
- PERSONA: #PERSONA-1a “Capture ideas while working”

ASSUMPTION-1a

Creators do not already have a faster or easier 
way to capture their ideas.

ASSUMPTION-1a1

EXPERIMENT: Test Current Capture Methods

Ask a small group of creators to show how they currently capture ideas.

Record how long each method takes and how often it interrupts their work.

If faster methods already exist, this assumption does not hold.

REFS:
- VALUE: #VALUE-1 “Quick Capture”

ASSUMPTION-1b

Creators want to capture all their ideas.

ASSUMPTION-1b1

EXPERIMENT: Idea Capture Diary

Ask creators to log every idea they have for one or two days. 

Compare the number of ideas generated with the number they choose to capture. 

If they capture only a fraction, this assumption needs revision.

REFS:
- ASSUMPTION: #ASSUMPTION-1b
- PERSONA: #PERSONA-1a “Capture ideas while working”

9. Define your measurements

Finally, we need to take some smart measurements to know if we are actually delivering the value that we are promising. These are the METRICS, of course. What could these cards look like?

METRIC-1

Time to Capture (TTC)

How long it takes a creator to record an idea from the moment it appears.

WHY IT MATTERS:
Measures whether Quick Capture actually keeps creators in flow.

TARGET (example): < 3 seconds

REFS:
- VALUE: #VALUE-1
- FEATURE: #FEATURE-1

METRIC-2

Capture Completion Rate (CCR)

The percentage of ideas that get successfully captured when the 
creator attempts to note them down.

WHY IT MATTERS:
If creators still lose ideas, the feature isn’t doing its job.

TARGET (example):
> 90% of attempted captures saved

REFS:
- VALUE: #VALUE-1
- ASSUMPTION: #ASSUMPTION-1

10. Analyse and refine your ideas

Here is the round-up. By now you would have created a set of cards or text files that have the following contents. Over time, you will be adding and pruning branches, rewriting and merging cards.

    ROOT
    │
    ├── GENERAL
    │   ├── GENERAL-0
    │   ├── GENERAL-1
    │   ├── GENERAL-2
    │   ├── GENERAL-3
    │   ├── GENERAL-4
    │   └── GENERAL-5
    │       ├── GENERAL-5a (PERSONAS)
    │       └── GENERAL-5b (VALUE)
    │
    ├── PITCHES
    │   └── PITCHES-1
    │
    ├── PERSONAS
    │   └── PERSONA-1
    │       ├── PERSONA-1a (Jobs)
    │       ├── PERSONA-1b (Gains)
    │       └── PERSONA-1c (Pains)
    │
    ├── VALUE
    │   └── VALUE-1 (Quick Capture)
    │
    ├── FEATURES
    │   ├── FEATURE-1 (Inline Idea Capture)
    │   │   ├── FEATURE-1a (US: Instant Capture in Flow)
    │   │   └── FEATURE-1b (US: One-Action Save)
    │   │
    │   └── FEATURE-2 (One-Tap Save)
    │       ├── FEATURE-2a (US: Save Without Thinking)
    │       └── FEATURE-2b (US: Auto-Link to Project)
    │
    ├── JOURNEYS
    │   └── JOURNEY-1 (Capturing an Idea in Flow)
    │
    ├── ASSUMPTIONS
    │   ├── ASSUMPTION-1
    │   ├── ASSUMPTION-1a
    │   │   └── ASSUMPTION-1a1 (Experiment)
    │   └── ASSUMPTION-1b
    │       └── ASSUMPTION-1b1 (Experiment)
    │
    └── METRICS
        ├── METRIC-1 (Time to Capture)
        └── METRIC-2 (Capture Completion Rate)

Have you been discussing your notes with AI so far? How is it going for you? While your mileage may vary, I was quite pleased that by now my simple Zettelkasten product backlog seems to work very well with my ChatGPT. Without much sophistry, I was able to get neatly formatted and logical responses for prompts like, "come up with a couple of ideas for FEATURE-1 and FEATURE-2".

What's important is keeping your ideas about your product organised with this principle of atomicity and connection-building, as well as with the structure I have provided. Then just feed it all to GenAI to see it perform magic with its pattern-matching capabilities. Try these prompts with ChatGPT once you have put your backlog together, some questions that you might usually want to ask when grooming your Product Backlog.

PROMPT-1

Prompt for Reviewing Your Backlog

“Look at these cards as a whole. 
What assumptions am I making, what risks do you see, 
and which feature or value proposition depends on the 
riskiest one?”

Why this works:
- Surfaces hidden assumptions
- Highlights the riskiest dependencies
- Helps you prioritise what to validate first

PROMPT-2

Meta-Prompt to Study Your Backlog

“Given my backlog, generate a list of questions I 
should ask to interrogate the product: questions 
about value, users, risks, features, gaps, contradictions, 
and anything I may have overlooked.”

Why this works:
- Encourages deeper thinking through guided questioning
- Reveals blind spots you didn’t realise were there
- Shifts the AI from answering to helping you explore
- Produces a reusable set of prompts for future refinement

PROMPT-3

Prompt for Reducing the Product to Its Smallest Useful Form

“Given my backlog, identify what can be removed, 
simplified, or delayed. Which features, stories, 
or ideas are unnecessary for the core value, 
and what is the smallest version of this product 
that would still be meaningful to the user?”

Why this works:
- Forces clarity about what truly matters
- Reduces overbuilding and premature complexity
- Helps reveal the real Minimum Viable Product
- Keeps the backlog focused on delivering value, not volume

PROMPT-4

Prompt for Finding Contradictions and Inconsistent Thinking

“Scan my backlog for contradictions, mismatched 
assumptions, or inconsistent logic. Identify 
where personas, value propositions, features, 
or journeys disagree with each other, or where 
the product seems to make conflicting promises. 
Show me every place where the thinking doesn’t line up.”

Why this works:
- Exposes contradictions that weaken product strategy
- Reveals where assumptions clash or features don’t match user needs
- Helps tighten the conceptual coherence of the product
- Prevents logical drift as the backlog grows

The Product Owner in a box

Exploring different permutations of Zettels with Grok

We’ve taken the first steps to assemble a structured set of notes that cover several core building blocks of product thinking — each expressed as small, atomic index cards you can shuffle, link, and recombine.

Let’s examine the features of the product backlog you now have:

You defined the purpose of the product, who it is for, why it matters, and how it differs from other apps. These cards are the anchor for the entire backlog.
You have at least one elevator pitch that will help you introduce the product to anybody.
You defined some useful categories for your Zettelkasten. Although you might prefer different categories for yourself, I hope I have shown how each category functions in my system. What’s important: these categories aren’t hard rules; they’re just scaffolding to help your thinking grow.
You built your first persona using the Value Proposition Canvas. This gives you a user-centric method for product development. When I practice this method, I find it easy to interview and discuss with anybody how they want to use my product.
You wrote your first value proposition. This is important for understanding why someone would want to use — or pay for — your product.
You designed two features that deliver your value proposition, each with its own user stories. You learned to write user stories that express, in the user’s own perspective, how they will use your product.
You created a short journey showing how a real user would experience Quick Capture end-to-end. This ties the features together and tests whether they make sense in context.
You documented the assumptions you unknowingly made and designed simple experiments to test them.
You identified meaningful metrics that will provide measurements that matter.
You have some ideas of how you can work with an AI companion to understand your product.

All that, with just a handful of cards! As your collection grows and you create more interlinked ideas, you will start to see how your product backlog becomes useful for generating new ideas that are focused on your users' needs.

I used the Zettelkasten method to structure this article as I wrote it with an AI companion.

While I have yet to try to make a product totally made with GenAI, I've discovered that I could at least start to develop my blueprint with it sanely, and that's a great first step. I was amazed by how much GenAI was able to contribute to the product backlog in this framework without it feeling like it was going out of control.

As I co-created this article with my GenAI buddy, I learned that it’s a tool that I can actually teach and make it work according to my processes, and Zettelkasten works not just for my memory — it becomes a way of showing the machine how I think, one card at a time.

Next: In the days leading up to Christmas 2025, read other articles from Advent of Tech @ Onepoint x Wepoint 2025.

References

I learned mostly from this guide to Zettelkasten to get started, https://zettelkasten.de/overview/
The Value Proposition Canvas is a technique popularised by Strategyzer AG. I use it often to think through the needs, pains, and gains behind every project I take on. Learn about it here: https://www.strategyzer.com/value-proposition
The Interaction Design Foundation is a great resource to learn user-centric design methods. Start with their page about the Value Proposition Canvas https://www.interaction-design.org/literature/topics/value-proposition-canvas?srsltid=AfmBOoq8JmqpwJv4QDfGA55wnB6FugYwtzyUDJa07AAav2FMOTa80FOp
I adapted my Zettelkasten numbering system from Kathleen Spracken, who teaches a minimalistic approach: https://www.youtube.com/watch?v=2a5TOzxuqxE
I first learned about Zettelkasten from my friend Liy. Knowing how much she writes every day, I was intrigued by the method that finally worked for her. Here is her experience: https://liyyusof.com/y5-zettelkasten/
Another set of lessons that helped me build my first Notion-based Zettelkasten came from Herbert Lui: https://herbertlui.net/8-lessons-from-800-note-cards-in-the-zettelkasten/

Shu Ha Ri: A Journey Toward Agile Mastery

Reza Rosli — Tue, 17 Dec 2024 08:00:00 +0000

This article is part of the "Advent of Tech 2024 @ onepoint," a series of tech articles published by onepoint to help pass the time until Christmas. See all the Advent of Tech 2024 articles leading up to Christmas.

How did you first learn about Agile? How do you keep learning to be Agile?

My Agile journey began in the early 2000s, during a time when Agile methodologies were beginning to gain popularity. I read about the Agile Manifesto and Scrum from books and articles in magazines, as the ideas started making their way into the mainstream. At the time, I was in my early 20s, had taught myself programming, and had pursued artistic studies rather than engineering, yet I was determined to find a career in software development.

My artistic studies and early interest in sociology helped me develop an appreciation for human behavior and group dynamics. At the time, I didn’t fully recognize the connection between these interests and my professional journey in software development. But looking back, I can see that my understanding of sociology — how people interact, form groups, and collaborate — has profoundly shaped my Agile journey.

Agile, at its core, isn’t just a set of processes; It’s a mindset — a way of understanding how people work together, how they communicate, and how they adapt in the face of uncertainty. As I started exploring Scrum more deeply, I saw how these principles mirrored what I had been learning about human interaction. Scrum emphasised collaboration, self-organising teams, and adaptability, all of which resonated with my interest in sociology and my desire to understand the dynamics of group behavior.

In my early encounters with Scrum, I began to notice how powerful the group dynamics were. I saw firsthand that teams that understood their own social dynamics — how they interacted with one another and responded to stress, change, and challenges — were more successful. This insight was a key realisation for me: Scrum wasn’t just about following a rigid set of steps; it was about cultivating an environment where teams could thrive through their relationships and their ability to adapt together.

In this article, I’d like to share the insights I’ve gathered over 20 years in the Agile world — as I look back on my experiences — first learning the rules of Scrum, then adapting them to suit the teams I worked with, and eventually transcending those practices to create more sustainable ways of working. I realise that this journey mirrored the stages of Shu Ha Ri: from strict adherence to the rules, to the flexibility of adaptation, and finally to mastery through innovation.

The Gap From Theory to Practice

I was working with a team of structured cabling installers, when I spent more time crawling in ceilings and under floors than in front of a computer! As I learned about Scrum and Agile, I began to reflect on how some of the principles already existed in my work, even in a completely different context.

My team of cabling installers, while not following Agile in any formal sense, had naturally developed some of its key practices without giving them names. We too had a backlog of work orders, task board, daily meetings before heading into work, and end-of-week rituals, when we’d hang out and go over how we can do better next time. No one had to teach us these concepts — they came from our past experiences in other jobs, in school, and from life in general.

I saw these Agile ideas as profound insights, as wisdom from legends who really understood how people really work. I became convinced that it was the only way software should be built, as its simplicity made it easy to grasp, especially for someone like me who was naive to the world of software development.

Agile provided a structure for my learning. It helped me approach my development projects iteratively and incrementally, focusing on small, manageable chunks of work. As I honed my skills, I started building demo projects, and this structured, iterative process led me to my first jobs in early-stage startups. But there, I quickly realized that despite being talented, my fellow programmers and I were, in many ways, just as inexperienced as I was and, most importantly, we didn’t know how to work together effectively.

I tried to organise the team using Scrum, but despite the simplicity of Scrum — all we needed were whiteboards, post-its, and Sharpies — it felt unnatural to the teams who did not seem to understand it, and I went through this cycle a few more times as I drifted from startup team to another startup team. In the end I was discouraged that I could make the Scrum process work at all: although every time I got a little bit better to get a team to “do agile”, I did not feel that I was able to get a team to “be agile”.

This disconnect — between “doing” Agile and “being” Agile — became one of the central challenges of my journey. While Scrum provided a simple framework for teams to follow, I began to see that it wasn’t enough. Simply following the steps didn’t lead to the deep, meaningful transformation I was seeking. I needed to help teams internalise Agile principles, to not just “do” the rituals but to embrace the mindset behind them.

"Being Agile" but not "Doing Agile"

It wasn’t until I joined a large and established creative agency that I had my first real experience with a team that was truly "being agile" — a team that had internalised the principles and mindset of Agile, but didn’t follow it in a formal or rigid way. During my interview for the job, my soon-to-be manager told me that the team had a working Agile culture, one that allowed them to deliver high-quality projects with minimal processes. This was exactly the kind of environment I had been hoping for — a place where I could see what “real” Agile looked like in practice.

I jumped at the opportunity, eager to learn from a team that had achieved what seemed to be the holy grail of Agile: a smooth, effective, self-organising team that delivered without the need for heavy processes. But when I joined, I quickly realized that there was something different about this team. While they excelled at “being Agile,” they weren’t particularly good at “doing Agile” in the formal sense.

The team worked across multiple projects for different clients with competing deadlines. As a shared resource for various teams, my workday was constantly interrupted by urgent meetings, last-minute tasks, and unexpected crises. The pace was fast, and at times, it felt chaotic. Every day seemed unpredictable — one social media post could set off a client crisis, and before we knew it, we were scrambling to fix something we hadn’t even anticipated.

But despite the constant pressure, the team excelled. They had a fanatical drive to deliver high-quality work faster and better than our competitors. There was an infectious sense of positivity, energy, and commitment. The team thrived on collaboration and openness to change. Their culture was one of flexibility, with minimal, lightweight processes that allowed them to quickly adapt to the circumstances of each day.

From the outside, it looked like they were the perfect example of an Agile team. However, as I spent more time with them, I began to see the cracks beneath the surface. The team’s speed and energy were impressive, but the pace was unsustainable. Morale was low, work-life balance was compromised, and personal health was often at risk. It was clear that while we were "doing" Agile, we were not truly following one of its most important principles: sustainable development. The 8th Agile Principle — "Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely" — was being ignored.

Though the team was performing well in many ways, it wasn’t enough. We were so focused on delivering quickly and responding to immediate needs that we were ignoring the long-term health of the team. This was when I realised that we needed more than just a good culture — we needed formal guidance on how to "do Agile" in a way that would support our sustainability and well-being.

A Shift to “Being“ and “Doing” Agile

We realised that that none of us at that time had any kind of formal training so we might have known how to “be Agile”, but we didn’t know how to “do Agile”. Determined to improve, we convinced management to send several team members, including myself, to Scrum training with a professional Scrum Master. When we returned, we had a much clearer understanding of how to implement Scrum in our work. We had been living Agile in a certain sense, but now we were ready to truly “do” Agile, not just “be” Agile.

The first major shift came when we held our first “real” retrospective. It was “real” because, for the first time, we were able to make changes that had an actual impact on our team’s way of working. During that retrospective, we applied one of the most important lessons from our training: by collaboratively creating a Team Contract — a simple, yet powerful tool that outlined the rules and commitments we would follow as a team.

One of the first things we realised was how a simple dysfunction had been affecting our work-life balance. A colleague who was always staying late was doing so because he felt obligated to take on additional tasks from others when they would drop by at the end of the day at his desk and ask for “quick ones”. Another colleague stayed late because he didn’t want to leave him alone. This kind of "acceptance" of late work had become normal within our team culture, but it was unsustainable. So, we made a rule: no one on the team would accept any new work after 5pm. It was a small change, but it had a huge impact.

We posted this simple rule on the door of our workspace, and from that day forward, whenever someone tried to add a task late in the day, we would point to the paper and send them away. It wasn’t always easy, but having that clear commitment from the team made a huge difference.

Through this experience, I was encouraged that we were beginning to truly integrate the Agile principles — not just in theory, but in practice. Over time, we continued to refine our processes, holding regular retrospectives to improve how we worked together. We found a rhythm that allowed us to both “do” Agile and “be” Agile in a way that was sustainable and effective.

However, despite our progress, I still felt that something was missing. The Agile process that worked for our team wasn't something that aligned with any formal framework I had come across. We had developed our own way of working that was effective, but it didn't feel like the implementation of Scrum that I had been striving for. It became clear to me that while we had mastered the cultural aspects of Agile, we hadn't fully mastered the structured processes that could sustain our long-term growth.

This gap between "doing" Agile and "being" Agile kept me searching for a deeper understanding. Then, one day, I discovered the concept of Shu Ha Ri. This idea completely transformed my approach to team development, as I began to appreciate how profoundly it resonated with my own Agile journey.

Reflecting on the team's evolution, I realized we had already experienced a cycle of Shu Ha Ri. At first, we had followed the rules and principles that helped us succeed (Shu). Then, we adapted and changed the rules to work more sustainably, without abandoning the core principles (Ha). And ultimately, by transcending those initial rules, we had developed a better way of working that fit our unique needs (Ri).

Shu Ha Ri: The Path to Mastery in Agile

The concept of Shu Ha Ri provided the clarity I had been seeking. Up until that point, I had understood Agile as a set of practices — Scrum ceremonies, roles, and artefacts — but I hadn’t fully appreciated the underlying journey of mastery that Shu Ha Ri describes. In a way, Shu Ha Ri served as the missing link, helping me to not only implement Scrum more effectively but to also guide my teams toward a deeper, more sustainable understanding of Agile.

In my previous experiences with Agile, I had realized that simply "doing" Agile wasn’t enough to truly transform a team. I had seen teams go through the motions — following Scrum rituals — but still struggle with the deeper mindset shifts that make Agile work. There was often a tension between the informal, cultural adoption of Agile and the need for structured processes to ensure long-term success. The discovery of Shu Ha Ri illuminated a way forward, offering a framework for navigating this tension and guiding teams through the complexities of Agile mastery.

Shu Ha Ri is a Japanese philosophy rooted in Aikido. While its origins are in martial arts, it has profound relevance for Scrum, Agile frameworks, and even personal growth. Jeff Sutherland, a legend of Scrum and a student of Aikido, described how this concept mirrors the journey of a Scrum Master: from a novice learning the rules, to a journeyman adapting those rules, and finally to a master transcending them.

Following this insight, I was able to map the stages of Shu Ha Ri for every Scrum role and the team itself (see table in appendix). This insight shaped how I guide my teams today.

In Japanese, Shu Ha Ri (守破離) is often translated as “first learn, then detach, and finally transcend.” In practical terms, it’s about learning the basics, breaking them when necessary, and ultimately transcending, or gaining distance from the rules to innovate and evolve.

We can think of it as like learning music. In the Shu stage, when we first learn an instrument, we must strictly follow our teacher’s instructions. We are expected to learn scales and basic techniques repeatedly, often by playing classic songs according to a fixed score. We learn by practice, focusing on the principles of making good music. As we advance, we begin exploring our own interpretations and style. For example, we might start playing a favourite song a little more slowly, adding our personal flourishes, but still maintaining the fundamental techniques that still make it the same song. This is the Ha stage. Repeating the processes of rote practice and improvisation, at some point, we become good enough to create our own music, transcending into the Ri stage from merely repeating songs to composing original works.

This journey is not linear but cyclical. Even virtuoso musicians return to practicing basic scales (Shu), explore new techniques (Ha), and push boundaries (Ri) throughout their careers. Similarly, Agile teams must cycle through these stages as they face new challenges, contexts, and opportunities for growth.

This concept resonates deeply with me because it mirrors my own evolution within Agile. In the beginning, I followed Scrum by the book (Shu), then adapted and experimented with it (Ha), and eventually, I reached a point where I started creating my own methods, innovating within the framework (Ri). But this journey is never truly complete; as new challenges emerge and new contexts arise, I unlearn and relearn. Each new team I work with requires me to revisit the basics, adjust practices, and adapt to new environments, just like a musician returning to scales or a composer reinventing their craft.

Shu Ha Ri has become the lens through which I view both my personal growth and the growth of the teams I guide. It helps me balance the discipline of following the rules with the creativity of transcending them. Mastery, as Shu Ha Ri teaches, is a continuous cycle. Even after reaching a certain level of skill, we return to basics, refine our techniques, and push ourselves to innovate. In the same way, Agile teams must cycle through these stages as they evolve. There will always be new challenges, new opportunities, and new contexts to navigate. The key, as I’ve learned over the years, is not just to “do” Agile, but to truly “be” Agile — embracing its principles as part of an ongoing, dynamic journey toward mastery.

Kickstarting the Shu Ha Ri Journey in Every Sprint

When I took on the role of CTO at a startup that had already gained traction and funding, and was only just hiring their in-house team, I was in a unique position of having both the ability and mandate to set the path of the startup’s team through a Shu Ha Ri journey from the very beginning. Over the five years that I held this role, I iterated on this concept continually, adapting it to the ever-evolving needs of the company.

The key insight I had was that Shu Ha Ri is not a simple, linear path from beginner to master. Rather, it is an iterative and continuous learning process. Shu is about learning and sticking to the basics. Ha is when we start to experiment, adapt, and evolve the processes. Ri is when we transcend the framework, making it our own and innovating to better meet our needs. These stages are not fixed — they evolve and overlap, and the team’s progress isn’t bound by a straight line but rather a dynamic loop of growth.

This mirrors the very essence of Agile itself. At its core, Agile is about iterative development and continuous improvement. Just like teams don’t “arrive” at a final, perfect process, the Shu Ha Ri model reflects how both teams and individuals are always evolving. Whether it’s refining practices in Shu, experimenting with new ways of working in Ha, or pushing boundaries in Ri, the key is the ongoing cycle of reflection, adaptation, and innovation. This cycle is the foundation of Agile — constantly improving how we work, learning from each sprint, and adapting our methods to better meet the challenges we face.

In the same way that Agile encourages teams to inspect and adapt each sprint, Shu Ha Ri provides a framework for individuals and teams to reflect on their growth and adjust their approach, ensuring they are always progressing and never stagnating.

As teams mature, they cycle back through Shu and Ha. They learn new techniques, challenge assumptions, and experiment with new practices until they reach Ri again, transcending previous limitations and continuing their growth. This iterative process of self-improvement and evolution lies at the heart of Agile, providing Scrum teams with the framework to continually adapt, innovate, and reach new heights of mastery.

A Dream Needs a Team, and a Team Needs a Dream

It became clear to me that this journey needed to be part of the DNA of the team from day one. It was important to set our shared vision and expectations as early as possible. So, as I gathered the first members of the team, we began by envisioning what a high-performance team would look like. In one of our early retrospectives, I posed a simple but powerful question to the team: What does a high-performance team look like to you?

The answers were as diverse as the people in the room. Some referenced their favourite sports teams, like football or Formula 1, where strategy, precision, and teamwork are paramount. Others drew from iconic groups like Metallica or the Avengers, emphasising a sense of unity and purpose. We discussed what made these teams successful: trust, communication, shared goals, and a commitment to continuous improvement. More importantly, we asked ourselves what characteristics we could adopt in our own work to become a high-performing team.

This conversation was critical — it was the foundation for building our ikigai, our sense of shared purpose. In Japanese, ikigai refers to a sense of meaning and fulfilment — a reason to wake up in the morning and do what you do. We worked together to define our collective purpose, ensuring that it wasn’t just about delivering features or hitting metrics. It was about creating an environment where each of us could thrive, contribute, and be part of something greater than ourselves.

From this shared sense of purpose, we created a Team Contract. This was a document that outlined our team’s values, commitments, and expectations. It became a living agreement, not just a set of rules to follow but a set of guiding principles that kept us accountable to one another. We defined how we would communicate, how we would handle conflicts, how we would celebrate wins, and how we would support each other through challenges.

Having this contract allowed us to stay aligned, even when we faced difficult decisions or changing circumstances. It gave us a sense of ownership and agency over our work, reinforcing that each of us had a responsibility to help the team succeed. Over time, as we moved through the stages of Shu Ha Ri, the contract evolved with us. What started as a foundational tool in Shu became a dynamic, adaptable document that reflected our growth into Ha and eventually Ri.

By iterating on the Shu Ha Ri model, we were able to build a team that wasn’t just capable of doing Agile, but that could transcend it. We could adapt the principles to our context, experiment with new ways of working, and innovate to solve challenges in ways that were unique to our team and the business.

This iterative, evolving approach allowed us to stay true to the core principles of Agile while constantly improving how we worked together. Every sprint, every retrospective, and every new challenge was an opportunity to revisit our practices, evolve them, and transcend the framework to meet our evolving needs.

Mastering the Daily Scrum with Shu Ha Ri

As we explored in the previous section, Shu Ha Ri provides a framework for continuous improvement. This iterative process of learning, adapting, and innovating applies not just to the overall Scrum methodology but to each individual practice within it — such as the Daily Scrum.

One of the most fundamental rules of Scrum that many teams struggle with is the 15-minute timebox for the Daily Scrum. Just like any other Scrum ceremony, the Daily Scrum has a fixed structure and purpose that, when followed correctly, drives collaboration and focus.

In the early stages of a team’s Shu Ha Ri journey, the Daily Scrum can serve as a litmus test for how well the team is internalising the basic principles of Scrum. Timeboxing, for example, is one of the most sacred elements of Scrum — it's non-negotiable.

The timebox is not just about managing time; it’s about preserving the focus and ensuring that the team’s time is respected. Adhering to the timebox signals that the team is still in the Shu phase: they’re practicing the fundamentals, staying focused on coordination and collaboration, and honouring the fixed nature of the ceremony.

A team that truly respects the 15-minute timebox is demonstrating its understanding of Focus and Respect — two Scrum values that are essential to success. In the Shu stage, these values are practiced faithfully, often in a more structured and rigid manner. The team is still learning how to prioritise communication and collaboration effectively, and the timebox helps them do that.

Value	How it applies to the Daily Scrum
Focus	The timebox forces the team to focus on the most important topics, helping them avoid unnecessary distractions.
Respect	We show respect for each other’s time by keeping the meeting efficient and relevant.
Courage	Within a short period, team members need the courage to speak up and share updates without hesitation or delay.
Openness	Having fixed times for meetings and fixed timeframes allows us to have discussions and maintain transparent communication.
Commitment	The team commits to staying within the timebox, ensuring the meeting is productive and efficient.

If the Daily Scrum consistently runs over the 15-minute limit — or conversely, feels rushed and unfocused — it’s a sign that the team is still working on mastering the basics. This is where the Shu stage plays a crucial role: following the rules and ensuring that the process runs smoothly. If the team struggles to keep the Daily Scrum within the timebox, it’s often an indication that they haven't fully internalised the purpose of the ceremony, or there may be underlying issues like unclear goals or poor sprint planning.

As the team moves into the Ha stage, they begin to experiment with different ways to improve the effectiveness of their Daily Scrum while still adhering to the timebox. They may try new tactics to enhance engagement — such as standing in a circle to keep the energy up — or use a timer to stay mindful of the time. These are examples of how the team adapts the basic structure of the ceremony to fit their needs while still respecting the core elements. This experimentation in Ha is all about refining the process to better serve the team, while still following the fundamental principles.

By the time the team reaches Ri, the Daily Scrum feels second nature. The team has mastered the ability to stay within the timebox while also knowing when to dig deeper into specific issues that need attention. At this stage, the Daily Scrum is no longer just a ritual to be followed but a dynamic, flexible meeting that adapts to the team’s needs. Teams in Ri have the ability to innovate within the rules—finding new ways to optimise the meeting without ever compromising the core principles of Scrum. It’s a clear sign of mastery: not only can they follow the rules, but they can also create new ways to improve them, reflecting the essence of continuous improvement that lies at the heart of Agile.

This progression — from Shu through Ha and Ri — reflects the maturation of the team as they grow in their understanding of Scrum. What starts as rigid adherence to the rules eventually evolves into a flexible, innovative approach that allows the team to continuously refine their practices, improve collaboration, and achieve greater effectiveness in their work.

In a similar way, Agile itself is an iterative process, where the team’s growth — whether in mastering ceremonies, refining their communication, or adapting their practices — is always evolving to better meet the needs of the team and the organisation.

Guiding Team Evolution Through Shu Ha Ri

One of the most important aspects of guiding a team through Shu Ha Ri is regular reflection. Agile Retrospectives are the perfect opportunity for teams to inspect their processes, measure their progress, and adapt their practices. But the key is not just to look at the most recent sprint — it’s about taking the opportunity to reflect on the team’s journey and how far they’ve come over time.

In my experience, retrospectives often focus on immediate issues that arise during the sprint, resulting in minor adjustments rather than strategic, foundational improvements. This “in the trenches” mentality can sometimes prevent the team from stepping back and considering how their practices are evolving over time and how those practices contribute to their broader growth in the Shu Ha Ri framework. However, these issues may be symptoms of larger, systemic challenges that only become clear over time.

A more impactful approach is to introduce a Shu Ha Ri retrospective at the end of every quarter of a year (every three months), as the final retrospective of the quarter. Looking at a broader timeframe (e.g., all the sprints in the quarter) gives teams the chance to reflect on patterns, challenges, and opportunities that might not be apparent in the individual sprints. For example, if the Daily Scrum exceeds its timebox once every other week, it might not seem like a big deal in a single sprint, but over the course of a quarter, it could have occurred at least once for nearly 50% of the team’s sprints, which is a much bigger issue.

In these retrospectives, I suggest to periodically review the basic principles of Agile and Scrum, as well as your team's Contract (if you have one). Ask questions that help evaluate where the team is in terms of applying the rules or principles from the perspective of Shu Ha Ri. These questions allow the team to reflect not only on the tactical aspects of their process but also on their broader evolution:

Shu: How well did we follow the Scrum rules in this sprint?
Ha: What did we do differently? Was this sprint better, worse, or the same as before?
Ri: What could we do better without changing the rules? If we innovate, are we doing it while respecting the Agile principles?

These questions not only helped us identify areas of improvement but also encouraged deeper reflection on where we were struggling. The idea is to inspect and adapt in every retrospective — not just tactically but also strategically. This mirrors the iterative nature of Agile itself, where every sprint offers an opportunity to learn, grow, and refine processes.

By stepping back and looking at the bigger picture, teams can identify deeper issues and make more strategic decisions that guide their long-term development. This approach turns the retrospective into a tool for ongoing evolution, rooted in Shu Ha Ri. Instead of simply addressing immediate tactical concerns, teams are encouraged to reflect on their broader journey, just as Agile encourages teams to continuously reflect and adapt at a high level.

The quarterly Shu Ha Ri retrospective doesn’t add new ceremonies to Scrum but adapts the existing process to better suit the needs of the team. Over time, this becomes a way to transcend the framework, making it more relevant and impactful for the team’s unique context. As teams evolve, so too does their approach to reflection. In this way, the retrospective itself follows the Shu Ha Ri pattern: it starts with structured, rule-based reflection (Shu), evolves into a more flexible and experimental form (Ha), and eventually becomes a powerful tool for team-driven innovation and mastery (Ri).

Scrum and Shu Ha Ri, redux

Sociology provided me with a deeper understanding of Agile’s emphasis on human-centred design. Agile frameworks like Scrum advocate for collaboration, transparency, and respect for individuals — values that align perfectly with sociological principles such as group cohesion, collective action, and social trust. As I moved forward in my career, I began to recognise the importance of "group norms" (like those promoted by Scrum ceremonies) and their impact on productivity and morale.

In many ways, working with Agile principles was like studying sociology in real-time. Each team was a microcosm of human society, where norms, roles, power dynamics, and relationships shaped outcomes. Whether it was a small group during a retrospective or the collective effort during a sprint, understanding the sociology of these teams helped me guide them toward higher performance.

As you guide your team through the process, always remember that Shu Ha Ri is not a one-way journey from novice to expert, but rather a cyclical process of learning and growth. Just as Scrum encourages continuous improvement through regular inspection and adaptation, teams cycle through Shu, Ha, and Ri as they deepen their understanding and refine their practices.

In practice, Shu Ha Ri helped me guide the team through each phase of their development, ensuring we built a solid foundation, adapted when necessary, and eventually innovated beyond what was initially prescribed. This dynamic process helped foster the kind of sustainable growth and mastery that makes Agile truly effective.

As you implement Shu Ha Ri, consider the implications of lacking any of its components:

Shu ensures that your team has a solid foundation in Scrum. Without a strong grasp of the fundamentals — like timeboxing, backlog refinement, and the roles within Scrum — your team won't be able to fully appreciate or realise the benefits of Agile. Skipping this stage or rushing through it often leads to confusion, lack of clarity, and poor adoption of the process.
Ha is where your team begins to adapt. At this stage, experimentation becomes vital. The team should begin to take ownership of their own processes, tweaking and evolving them to meet their specific needs. Scrum, at its core, is a flexible framework, and to unlock its full potential, a team must adapt it to their context. This stage is where true growth begins, but it's also where teams can become too comfortable and stop challenging their assumptions.
Ri is when a team internalises the Scrum process so deeply that following the rules feels like a second nature. But even within the confines of Scrum, there’s room for innovation. Teams at this stage can transcend traditional methods, adding their own creative spins on Agile practices. However, without Ri, a team risks falling into the trap of “cargo cult Scrum” — performing the rituals without achieving meaningful outcomes. Without the underlying mindset of continuous improvement, a team will not evolve and will remain stagnant.

Reflecting on my journey, I guided a team to consistently perform exceptionally well over five years, even during the global COVID-19 pandemic, when we had to rethink how we collaborated remotely, by building on our habits without losing sight of how we should behave as a high-performing team together. By embracing the iterative nature of Shu Ha Ri, we were able to continue improving and refining our processes even in the face of uncertainty.

For me, the real power of Shu Ha Ri lies in its simplicity and flexibility. Whether you’re just beginning with Scrum or you’re a seasoned practitioner, it gives you a framework to understand your current state, identify areas for improvement, and create your own path toward mastery.

If you’re new to Shu Ha Ri, start by discussing it with your team. Identify where you are in the process. Are you in Shu, strictly following the rules? Are you in Ha, adapting Scrum or some other Agile framework to better fit your needs? Or are you in Ri, innovating and experimenting?

Use this framework as a starting point for your next retrospective, and continuously evolve your understanding. By embracing Shu Ha Ri, you can unlock the full potential of Scrum and foster a culture of sustainable growth that adds lasting value to your team and your organisation.

This article is part of the "Advent of Tech 2024 @ onepoint," a series of tech articles published by onepoint to help pass the time until Christmas. See all the Advent of Tech 2024 articles leading up to Christmas.

Appendix

Shu Ha Ri applied to Scrum team roles

Role	Shu (Follow)	Ha (Detach)	Ri (Transcend)
Scrum Master	- Learn the Scrum framework and strictly facilitate ceremonies (Daily Scrum, Sprint Review, etc.). - Rely on guides and best practices. Example: Facilitate daily scrums without deviation from the Scrum Guide.	- Understand the principles behind Scrum. - Experiment with facilitation styles and team dynamics. Example: Adapt facilitation techniques to suit the team’s culture and needs.	- Master servant-leadership. - Innovate new techniques to foster high-performing teams and organisational agility. Example: Introduce advanced Agile practices like Lean or Systems Thinking to optimise workflows.
Product Owner (PO)	- Learn backlog management and prioritisation techniques (e.g., MoSCoW, Eisenhower Matrix, INVEST). - Follow stakeholder instructions closely. Example: Use the Scrum backlog template and prioritise based on stakeholder demands.	- Deeply understand the principles of value delivery. - Experiment with new techniques for backlog refinement and stakeholder engagement. Example: Use customer feedback loops or create a more dynamic backlog refinement process.	- Shape strategic product visions. - Anticipate market trends and innovate new ways to maximise product value. Example: Proactively explore new product opportunities or market shifts, and adjust the product vision accordingly.
Developers	- Learn Scrum basics, roles, and ceremonies. - Follow Definition of Done and adhere to team commitments. Example: Participate in daily scrums and commit to sprint goals.	- Understand the "why" behind Scrum principles. - Suggest improvements to processes and adopt technical best practices. Example: Introduce new coding practices or collaborate on cross-functional tasks to improve team efficiency.	- Innovate workflows and delivery methods. - Mentor others and contribute to team-wide technical excellence. Example: Lead in introducing new tools or automation, and help the team implement them effectively.
Team as a Whole	- Adhere strictly to Scrum events and roles. - Depend on the Scrum Master for guidance. Example: Follow the Scrum Guide and let the Scrum Master lead ceremonies.	- Explore process improvements collaboratively. - Take ownership of delivering value while adapting practices. Example: Experiment with Kanban boards or tweak sprint planning to make the process more efficient.	- Self-organising and fully autonomous. - Seamlessly blend Agile principles into custom workflows. Example: Develop a hybrid approach, incorporating Scrum and Lean elements, to continuously improve the team's output and adapt to changing business needs.

Resources

Shu Ha Ri on Wikipedia https://en.wikipedia.org/wiki/Shuhari
Shu Ha Ri: What makes a great Scrum Master? https://www.scruminc.com/shu-ha-ri-what-makes-great-scrummaster-2/
The 12 Principles behind the Agile Manifesto https://www.agilealliance.org/agile101/12-principles-behind-the-agile-manifesto/
The Scrum Guide https://www.scrum.org/resources/scrum-guide
How to Facilitate Powerful Working Agreements (Team Contracts) https://resources.scrumalliance.org/Article/facilitate-powerful-working-agreements
Some related and complementary ideas:
- Tuckman’s stages of group development https://en.wikipedia.org/wiki/Tuckman's_stages_of_group_development
- Dreyfus model of skills acquisition https://en.wikipedia.org/wiki/Dreyfus_model_of_skill_acquisition
- Four stages of competence https://en.wikipedia.org/wiki/Four_stages_of_competence