Artisan Agility

Most business analysts are about to waste their scarcest asset on work a machine does better. Here's how to stop.

Not all requirement gaps are the same kind, and the difference now decides where you spend human attention.

Internal gaps are contradictions inside the spec itself. You said X here and not-X there. An undefined state. A field that can't hold the value you described. This is consistency-checking, and AI is genuinely better at it than you are — tireless, literal, never skims. Hand it over.

External gaps are different. Does this match the actual business? The regulation as it really operates? The exception that lives only in one operations manager's head and appears in no document? AI can't touch this, because the truth isn't in the artifact. It's in the world.

The failure mode is a BA burning hours proofreading a spec for contradictions the machine would flag for free — while the question of whether the system models the right business never gets asked.

So draw the line. Delegate internal consistency to the machine. Spend every scarce human cycle on the reality gap, where you're the only thing standing between a confident spec and a wrong one.

The skill isn't catching every gap anymore. It's knowing which gaps are yours.

The single most important question for senior IT leadership in 2026:

Is code your asset, or is it your output?

If it's your asset, your investment strategy is correct. Protect the repo. Hire production-capable developers. Optimize for shipping more code. The hierarchy that's been stable for sixty years still applies.

If it's your output, your investment strategy is upside-down. The asset is what produces the code. The repo is regenerable. The hires you need are different.

Almost every IT organization is still operating as if code is the asset, while the economic conditions that justified that assumption no longer exist.

The test is simple. If your codebase disappeared tomorrow, but your specifications, tests, and architectural decisions remained intact, could you regenerate it?

In 2024, the honest answer was no.

In 2026, the honest answer is yes. Time-consuming, yes. But yes.

That changes everything downstream. Your hiring, your tool spend, your training, your career ladders, your performance metrics — all designed for a world where code was the asset. Increasingly misaligned with reality.

The misalignment is invisible short term. Your team still ships code. Repo still exists. Dashboards still look right.

The misalignment compounds long term. Each quarter, the gap between what your organization protects and what actually produces value gets wider.

This calendar year is when senior IT leaders decide whether to recognize the shift or drift through it.

By the time someone says "I'm burned out," you're already months too late.
Scrum has no early-warning system for the humans doing the work.

You don't need a survey to see it coming — you need to watch three things: work-in-progress creeping up per person, activity drifting later into the evening, and carryover climbing sprint over sprint. If someone's juggling three or more active items, that's your cue to step in now, not next quarter.

Sierra watches those patterns for you — quietly, from real workflow data — so you can act while it's still a conversation, not a resignation letter.

See it on your team: email [email protected] for a free trial account.

Be honest: how many action items from your last retro actually shipped? Most teams run retros like a feelings dump with no follow-through. Same complaints, new sprint.

A rule that fixes most of it: leave every retro with exactly one change, written as a hypothesis — "we think X is slowing us; we'll try Y; we'll know by Z" — with a name on it, revisited first thing next retro. One owned experiment beats ten forgotten action items.

Sierra closes the loop for you: it tracks whether the change you committed to actually moved the signals that matter, so a retro becomes a decision, not a vent.
Try it free: email [email protected] for a trial account.

Stop measuring velocity in 2026.

I mean it. Stop. The metric is doing more harm than good.

For ten years, velocity was a reasonable proxy for value delivery. Faster development meant more features into a market that wanted them. The proxy worked because development was the bottleneck.

That world is over. Velocity now measures a thing that doesn't matter and obscures things that do.

Measure these instead.

Adoption rate. Of features shipped last quarter, what percentage have measurable usage? Under 50%, you have a velocity-versus-value problem.

Time to adoption. From "deployed" to "used by a meaningful population." If this rises while velocity rises, you're outrunning your absorption capacity.

Cost of removal. For features that turned out to be unwanted, can you remove them? How long? If you can't, your codebase is fossilizing.

Specification reuse. How often do you regenerate code from specifications versus modifying existing code? The trend tells you whether your assets are durable.

Team learning. Are estimates getting more accurate over time? Is the quality of architectural decisions improving? These compound when measured. They atrophy when ignored.

None of these are on your dashboard. All are more predictive of 2030 performance than velocity.

You measure what you optimize for. If you measure velocity, you optimize for velocity. In 2026, that's optimizing for the wrong thing.

Every senior developer used to do part of the BA's job for free. Nobody noticed, because it showed up as friction.

Here's the mechanism. A developer would get halfway into building, hit something the spec didn't cover — "wait, what happens if the customer has two accounts?" — and come back with the question. That question was interrogation.

The slow, grinding process of construction was constantly surfacing the gaps in the requirements, one confusion at a time, and there was time to fix them mid-build because building was slow.

That was the safety net. The build itself caught what the spec missed.

AI removes the net without telling you it's gone. It doesn't get confused. It doesn't come back with a question. It fills the gap with a confident, plausible assumption and generates working code on top of it — at full speed. The ambiguity gets resolved silently and wrong.

So the interrogation that used to happen during the build now has to happen before generation. There's no slow build phase left to catch anything. The gap that used to cost you a developer's question now costs you a release.

Requirements were never the deliverable. They were the net. Rebuild it on purpose, upstream, before the machine starts typing.

If your AI generated the code, your AI cannot also generate the tests.

That sentence will offend a lot of people doing exactly that right now. I don't care. The math is the math.

Tests exist to verify code does what it's supposed to do. The "supposed to" comes from a different place than the code itself. From the specification. From intent. From the user's actual need.

When you generate code and tests from the same prompt, you have two views of the same possibly-wrong understanding. The tests will pass. The code will work. They will agree with each other. They will share blind spots. They will not catch the cases the prompt didn't anticipate.

That is not verification. That is a tautology dressed up as quality assurance.

Real verification requires meaningful independence:

Generate tests from the specification using a different model than the one that generates code. Structural independence.

Have a human read the specification — not the code — and produce tests against intent. Cognitive independence.

Run adversarial generation. Different model, different prompt, instruction to break the code. Intentional independence.

What you cannot do: prompt "write code and tests for X" and trust the output. The tests in that scenario are part of the code's hallucination, not a check on it.

If your verification doesn't include explicit independence between code and tests, you are accelerating into a wall.

Your daily standup has quietly become a status meeting your manager happens to attend.

Three updates in, nobody's listening — they're rehearsing their own.

Try this tomorrow: walk the board, not the room. Start from the work closest to done and move left, and only stop on what's blocked or at risk. Drop the "what I did yesterday" roundtable — that's the part that turned standup into theater.

Sierra Agility can help identify theater like this: it reads what's actually moving and surfaces the one item worth the team's attention today.

Want it on your own team? Email [email protected] for a free trial account.

The junior developers your organization hired in 2025 may never become senior developers.

That sentence sounds dramatic. It is approximately correct, and almost nobody is doing anything about it.

For sixty years, software apprenticeship worked because seniors and juniors collaborated on real work, and the senior's thinking became visible. Code review. Pair programming. Debugging together. The senior's mental model got externalized for the junior to absorb.

When AI does the thinking-equivalent work, the senior's mental model never externalizes. The junior sees the output, not the path.

The specific failure mode: juniors develop reasonable taste — they can tell when something looks off — without developing generative capacity — they can't produce it themselves when AI fails. Effective when tools work. Helpless when they fail. No path to growing past it.

Multiply that across a generation entering the field after 2025. You have a pipeline problem that won't fully reveal itself for five years. By then it will be hard to undo.

The senior tier of 2035 comes from juniors in 2026. If those juniors are not developing the underlying capabilities now, your senior pipeline runs dry by 2032.

What works: deliberate AI-free zones for learning. AI as Socratic partner. Explanation as deliverable. Structured exposure to broken AI output.

None of this is at scale anywhere. The organizations that figure out training in the AI era will have a durable talent advantage.

Your stakeholders used to show up confused. Now they show up with a working prototype. That's worse, not better.

For decades the business analyst's job was fighting fog. Someone wanted something, couldn't articulate it, and the BA drew the real need out into the open.

Vagueness was the enemy — and vagueness at least announced itself.

AI changed the enemy. A stakeholder with a generation tool no longer arrives unsure. They arrive with a confident, detailed, plausible spec — or a clickable prototype — built in an afternoon. It looks finished. It looks thought-through. And underneath it sits an assumption nobody tested.

Call it counterfeit clarity. It has every surface feature of real clarity except the part that matters. And it's far more dangerous than fog, because the whole room mistakes it for the real thing and starts building.

The new core skill of the competent BA is detecting false resolution: the spec that looks complete and quietly encodes a guess. Fog, everyone can see. Counterfeit clarity only the trained eye catches — and AI is manufacturing it at industrial scale.

Stop rewarding the polished artifact. Start interrogating it.