How I Work About James Case Studies Insights
Orchiture

Making technology teams work better

Insights

If you recognise the problem, start here.

These articles start from the problems, the ones that show up in conversations with CTOs, founders and heads of engineering. Find the one that fits your situation.

Practitioner Insights
Performative Scrum Syndrome

"The standups happen. The board gets updated. None of this is the same as delivering predictably."

Performative Scrum Syndrome: when the ceremonies run but the team does not.

When Scrum is running but delivery confidence is not improving, the instinct is to look at the ceremonies: to run them better, more carefully, more consistently. The article names a different problem: the structural conditions that Scrum assumes are absent, and the ceremonies cannot create the conditions they depend on.

Six Scrum principles. Three recurring failure patterns. Six diagnostic questions that almost always surface the cause before a process audit has begun. The first article in the Performative Scrum Syndrome series.

Point of View Process Team structure 20 min read Read the article →

"The velocity chart is full. The sprint review produces a demo. Nobody has asked which half of the backlog actually matters."

Performative Scrum Syndrome: when you measure activity instead of value.

Velocity rising is not the same as value delivered. When the backlog is a sequenced delivery plan rather than a live prioritisation instrument, the team completes every sprint and the business still does not get what it most needs. The ceremonies run. The gap widens, invisibly.

Sprint goals written as story lists rather than outcomes. Backlogs ordered by delivery sequence rather than business value. Product owners who hold the title but not the authority to act on it. Three patterns that signal Value-Based Prioritisation has been adopted in name but not in practice.

Point of View Process Value delivery 24 min read Read the article →
Scaling

"We hired. We scaled. And somewhere in that growth, the thing that made us fast quietly stopped working."

The structure that made your engineering team fast is making it slow.

At fifteen engineers, the team self-organises. At fifty, that same informality collapses — and the coordination machinery installed to replace it consumes the time it was meant to protect. The problem isn't the people or the process. It's the structure nobody redesigned when the headcount doubled.

The article sets out what to look for and why the instinct to add more coordination almost always makes it worse. The diagnostic conversation is where the practical detail starts.

Point of View Scaling Team structure Evidence-led · structured diagnostic 7 min read Read the article →

These articles start on LinkedIn.

Shorter versions of each piece appear on LinkedIn first — the problem, in a post. If you find yourself nodding, the full article is here. Follow for the problem-first content that comes before this page.

Recognise the pattern in your own team?

The Signal is a free 15 to 18 question diagnostic that identifies which structural conditions are most likely active in your engineering organisation. It takes around ten minutes and produces a named diagnosis with a written explanation. No account required.

Recognise the problem? Let's talk about the fix.

Most conversations start with one of the pain points above. Most of them end with a clearer picture of what's actually going on.

Start a Conversation