Jira Was Built for Scrum. We're Building for What Comes Next.

Every methodology answers a constraint. Scrum answered a simple one: humans write code slowly, change their minds often, and renegotiate scope every two weeks. Jira was built to administer that reality, tickets, points, standups, burndowns, the whole apparatus of managing human throughput.

That constraint is dissolving. When an agent can one-shot a well-specified change, building is no longer the slow part. The slow part is everything before the build: agreeing on a spec precise enough that nothing’s left to argue about, knowing who should own the work, and sharing the context to do it. The ceremony Scrum invented to manage typing speed is now overhead on a problem we no longer have.

Something quieter is happening too. As everyone gets their own agent, teams are drifting apart. Each person disappears into a private chat window, ships in isolation, and the connective tissue that made a team more than a pile of individuals starts to fray. Output per person climbs while the thing that actually compounds, a team thinking together, quietly erodes. We’re building Lightsprint to stop that.

Here’s what we believe. Five convictions, starting with the one that matters most.

1. There will be a new SDLC, and we’re building it: Spec-Driven Delivery

You don’t get a faster Scrum by bolting agents onto it. You get a different lifecycle with a different center of gravity. We call it Spec-Driven Delivery, and its unit of work isn’t the sprint. It’s the Lightsprint.

A Lightsprint inverts the sprint. Scrum front-loads loose planning and back-loads slow, uncertain execution. A Lightsprint front-loads what matters: pinning the spec down to design and architecture, then routing the work to the right owner. Once that’s done, the build is the cheap part. Scrum measured velocity in story points completed. Spec-Driven Delivery measures it in specs aligned and shipped clean on the first pass. The ceremony isn’t the standup. It’s the spec.

The roles shift to match. The scrum master, who kept humans unblocked and processes running, gives way to a router who makes sure every piece of work reaches the owner and the context to finish it. The PM stops writing tickets and starts writing specs precise enough for an agent to run. The engineer stops typing the code and starts owning the spec, the context, and the review.

Jira was built to administer Scrum. It’s Scrum frozen into software. We’re building Lightsprint to power Spec-Driven Delivery, without scattering the team into a dozen isolated agent sessions. The rest of this post is the four convictions that lifecycle stands on.

2. As models get better, the spec becomes the work

Here’s the counterintuitive part. The better the models get, the more the leverage moves to the thing in front of the build, not the build itself.

A weak model needs hand-holding through implementation. The human stays in the loop line by line, so the spec can stay loose. A strong model does the opposite. Hand it a vague intent and it’ll confidently build the wrong thing, beautifully. Hand it a spec pinned all the way down, the design, the architecture, the edge cases, the acceptance criteria, and it one-shots the right thing with no rework.

That moves the hard thinking. The valuable work isn’t executing the plan. It’s defining a plan precise enough to execute without negotiation. Alignment on the spec, down to the real design and real architecture, is what stands between you and a clean first pass. Rework stops being a code problem and becomes a spec problem, caught before a single line is written. The teams that win will be obsessive about getting the spec right, because for them the build is a formality.

3. Coordination is the new bottleneck, so routing has to be a first-class job

When one person could only do one thing at a time, coordination was cheap next to execution. You assigned a ticket, someone picked it up, it sat in their queue for a sprint. The wait was the work.

Drop execution cost to near zero and the math flips. The expensive question isn’t how to slice the work. It’s who needs to know. A change that touches the frontend, the API contract, and a migration is still one task. You don’t fragment it into three tickets with three owners and three reviewers. The agent that picks it up has full context and spawns its own subagents for each surface, frontend, contract, migration, without losing the thread that ties them together. Fragmenting the work is exactly what destroys that coherence, and it’s exactly what the old model forced on you.

Routing moves up a level, to the plan. When a plan forms, the system knows which surfaces it touches and tells the people who own them: your area is about to be affected. The frontend owner, the data model owner, the service owner all get informed before anything is built, not handed a sliced-off ticket after the fact. The work stays whole and the agent runs it end to end. The humans stay informed and aligned on the plan that drives it. Getting that wrong, building before the right people know their parts are in play, is now the most expensive mistake on the board, because the build is instant and the rework isn’t. The team that aligns fastest, not the one that types fastest, ships fastest.

4. Context is an organizational organ, and keeping it shared is how we keep the team together

Most teams store their real context in the worst possible place: individual heads, scattered Slack threads, and the muscle memory of whoever wrote the original code. It works until that person is on vacation, gets poached, or simply forgets. Scrum never solved this. It just scheduled meetings to paper over it. Agents make it worse, because now the context drains into a hundred private chat windows no one else can see.

In a world where agents do the building, context is the fuel. An agent is exactly as good as the context it’s handed. If the knowledge of how your auth flow works, why that gnarly module is shaped the way it is, and what “done” means for your product lives in one engineer’s head or one engineer’s agent session, then every other agent is running on empty and every human is a single point of failure.

Context has to become a shared organ of the company, a brain the whole team and every agent can read from and write to seamlessly. Conventions, architecture decisions, the reasoning behind past changes, the patterns that make your codebase yours, captured once and available to anyone, human or agent, the moment they pick up a task.

This is also where the team gets put back together. When context is shared instead of siloed, people aren’t off alone reinventing what a teammate already figured out. They build on each other, see each other’s work, compound instead of diverge. A great team beats a great individual because its ingenuity is collective. That collective intelligence is exactly what isolated agent use quietly destroys, and exactly what Lightsprint is built to protect.

5. Software development moves to the cloud, and that’s what makes it collaborative

There’s a reason this is finally possible: the work is leaving the laptop. For decades, building software meant a local environment, a checked-out repo, and a setup ritual that lived on one person’s machine. That model quietly decided who got to participate. If you couldn’t clone the repo and start the dev server, you weren’t really in the build. You were outside, sending requests in.

When development moves to the cloud, that wall comes down. The work stops hiding inside individual machines and lives in a shared place anyone can open. The ticket stops being a label pointing at where the real work happens somewhere else, and becomes the place the work actually happens. You hop into a ticket and the coding gets done right there, in the open, with the plan, the spec, the agent’s progress, and the live preview in one view. You see the status of every ticket in real time instead of waiting for a standup to find out.

This is the part that finally includes everyone. A PM, a designer, a support lead, a founder, none of them should need a local environment to help build the product, and historically that setup is exactly what shut them out. In the cloud, there’s nothing to install. They open the ticket, watch the change take shape, weigh in on the spec, watch the preview, and shape the outcome alongside the engineers. Software development stops being something a few people do behind a wall and becomes something the whole team does together.

This is the foundation everything else sits on. The spec, the plan-level routing, the shared context, all of it depends on the work being out in the open where the team can gather around it. The cloud is what turns a collection of people running separate agents into a team building one thing.

The old SDLC was built for the constraint of human throughput. That constraint is gone. What’s left to protect is the team itself, and the spec that lets it move as one. That’s what we’re building for.