One-off or pattern: where a lesson belongs

The problem didn't look like a problem

For a long stretch on Arc, nothing was obviously broken. Cards shipped. Sprints closed. But every so often a card would stop partway through. Either it needed investigation before anyone could finish it, or it turned out to be two pieces of work sharing one title.

In my experience, cards that needed investigation or had to be split were not always handled through the same process. Sometimes they followed different delivery methods. We sometimes had to revisit and realign completed work two sprints later.

What I had was a collection of one-offs, and none of them looked important enough to write a rule about. That was exactly the problem. When recurring problems are treated as unrelated one-offs, their shared cause can go unnoticed.

Two pressures pulling in opposite directions

The fix wasn't as simple as "standardize everything." I run more than one project, and they aren't alike. Arc spans mobile, web and a backend, with a full sprint pipeline, a staging environment, and several agents working in parallel. This website is a single deployment with no sprints at all. A rule that's right for one can be dead weight for the other.

So I needed two things at once:

• Room for each project to handle a situation its own way, and to say so openly when it departs from the shared method.
• A way to notice when the same situation keeps coming back, in one project or across several, and to decide once whether it should become a shared rule.

FLIP is how I hold both.

Capture it at the moment it happens

The first change was timing. FLIP starts the moment a card can't proceed as written: it's blocked, it needs a decision outside its authority, or it needs research before it can finish. The agent that hit the problem records it on the card right then: what triggered it, what happened, the evidence, and what the card assumed.

That mattered more than I expected. Capturing the finding at the stop helps preserve what the agent encountered, what it tried, and what the card assumed. Waiting until sprint review risks losing that context and relying on a reconstructed account.

Each finding also gets an ID that follows it everywhere: onto the spike card, the fix card, the review, and any rule change. That ID lets me answer a question I couldn't answer before: did we ever actually close this?

Some findings don't come from a stopped card at all. A process gap, or a request of mine that exposes a missing rule, gets logged the same way, just without a card.

Decide where the lesson belongs

Recording findings is the easy half. The harder half is the decision, and the decision isn't always "make a rule."

At each sprint review, every finding gets a disposition. It might become shared canon, or strengthen a rule that already exists but missed a case. It might become a card, or be worth watching for a second instance. Or it might be dropped, with a reason. There are nine outcomes in all, and only some of them add a rule.

I got this wrong in my early thinking. I used to say every failure becomes doctrine. It doesn't, and it shouldn't. A system that turns every bad afternoon into a permanent rule ends up with more process than work. The value is in deciding deliberately and writing the decision down.

Let projects keep their own way

When a lesson applies to only one project, it stays there. Each project keeps a record of its own decisions and of where it departs from the shared method, with the reason for each.

This site is an example. It has no staging environment and no release ceremony, which is a large departure from the shared release process, and it's written down as one. Recently I turned off automatic card closing on merge here, because on a site with no staging step, merged work isn't yet checked work. That setting is specific to this project's workflow, but it implements a shared requirement: cards must meet the verification requirements before they close.

The record of departures does a second job. When the same departure shows up in several projects, that isn't several projects being difficult. It's evidence the shared method is wrong.

Pass the pattern up

When a finding looks like it applies beyond its project, it goes up. At sprint close, the project's Lead sends those findings, in a standard format, to Chaise, the role that maintains the shared methodology. Counsel checks each one against existing canon: does it contradict something, fill a gap, or repeat a rule we already have? Then Chaise decides to accept it, ask for clarification, defer it, or disagree and send it back for local handling. Accepted findings go through the canon-change process. Once a change is published, projects pick it up through their next Cold Start check.

Projects don't wait for that decision. Work continues on the current rules while the decision is pending; published changes apply according to the canon's timing rules.

Two examples show how project findings have changed portfolio guidance. The first came through a Board escalation rather than a formal FLIP record.

• Who architects a small project. My smaller projects were set up with no architect role. The board handled everything. When this site's board hit two decisions it couldn't make, it escalated them straight to the portfolio level, so portfolio governance ended up making project decisions. Tracing it back, the "no architect" assumption came from a shared template and had been copied into three projects. That was one root cause in three places. The fix was a portfolio ruling: every project carries a Lead, whatever its size.
• What a role does with no sprint. My roles describe their work by sprint step. This site has no sprints, so its Lead had no defined position to work from. Instead of inventing one, it flagged the gap. The resulting ruling covers every project without sprints, not just this one.

FLIP improves itself the same way. In one Arc sprint, a finding got its number on a card but never made it into the sprint's record, and another was written on a card but never logged. Neither was caught at the time. The result was a daily check that every recorded stop is accounted for.

What changed

After roughly ten sprints of using feedback to adjust the delivery process, my observation was that we were identifying no more than one delivery-process adjustment per project per sprint. I read that as the process settling, not as proof that nothing goes wrong. Things still go wrong. The difference is that a one-off now gets recorded as one, and when it stops being a one-off, there's a defined path for it.

The lesson I'd pass on: don't try to prevent one-offs. Record them, let each project handle its own, and build a way to notice when the one-offs are really a pattern. That's where the shared rules should come from. Sometimes one finding is enough to expose a gap that affects several projects.