Most software does not get built once. It gets built, shipped, used, and then changed—for years. The frameworks the industry has relied on—Scrum and Kanban—were designed for prototyping, exploration, and iteration that can be reset at the end of a sprint. Applied to a system that must keep running, keep evolving, and keep absorbing new requirements for years, they reach their limits—not because teams implement them badly, but because their design assumptions belong to a different kind of work.
The Albatross Method is the next step. It is built around the fact that software is a long-lived asset that must be improved continuously, and its nine phases are arranged so that agility becomes a built-in property of the process, in every phase. In this post, I want to walk through the nine phases and then show why the Albatross Method holds remarkably high agility—and why it carries the Agile idea forward into the long run.
Albatross is not a rejection of Agile. It is what Agile becomes when it is designed for the long run.
Part 1: The Nine Phases of the Albatross Method
Phase 1: Planning
Development begins with a request. A product owner or client asks for a new feature. That request does not immediately interfere with ongoing development work. It enters the backlog and waits for consolidation.
The product owner is responsible for making clear what the feature actually wants to provide, what problems it is meant to solve, and what value it is expected to deliver. During this process, the product owner may discuss with the dev team—mainly the manager—to explore alternative solutions and feasibilities. The product owner can also get a rough sense of the feature’s scale.
If the feature’s main points are fixed and it is considered valuable, the process moves to the next phase.
This is the first point of agility. A candidate feature that fails to convey its value is dropped immediately, before it has consumed any development effort. The cost of saying no here is measured in conversation, not in code.
Phase 2: Rough Estimation
A rough estimation is a quick tool for evaluating the cost of a feature. It comes out as a range—lower-bounded by the optimistic estimate, upper-bounded by the pessimistic estimate. With that range in hand, the product owner can evaluate the worth of the feature and its risk with concrete numbers rather than intuition.
The rough estimation is usually limited to no more than half a man-day. It is rough, but it undergoes story listing, influence searching, risk predicting, and value summation after calm thinking.
This makes it more reliable than the quick, informal estimation practices that many teams rely on—hand-raising exercises such as planning poker, or statistical prediction from historical cycle times. Neither of those practices is unreasonable in itself. The problem is when they are applied: they estimate before the design work has removed the uncertainty, which makes estimation unreliable in the first place. Hand-raising compresses a spread of private guesses into a single consensus number, and consensus is not the same as accuracy. Statistical prediction assumes the future will resemble the recorded past—but in long-run software, the team, the codebase, the priorities, and the tooling all keep changing, so the past distribution is a moving target. Both methods produce a number. Neither of them produces the understanding that a calm, structured estimate does.
If the product owner still approves the feature, the process moves forward.
This is the second point of agility. A feature whose value does not justify its cost or its risk is cut off early—again, before any real work has begun.
Phase 3: UI Design
The UI design is the intent lock. Before UI design, both the product owner and the dev team hold only imprecise ideas. UI design visualizes those ideas and presents the visualization in front of both parties at once, so their understanding of the feature can be matched.
At this stage, any missing points from the user’s point of view can be checked. Feasibility of the UI can be checked. User experience can be imagined. User cases can be simulated.
UI design is cheap. It is often just screenshots and wireframes marked with UI events and actions—far cheaper than deploying a working prototype. It also lets people work to their strengths: a web designer who is an expert in aesthetics is often not a great programmer, and a programmer is often not great at aesthetics. UI design is where the aesthetics expert can play at full power.
If the product owner and the dev team agree on the UI design, the process proceeds.
This is the third point of agility. The product owner and the dev team align their understandings at very low cost, before any construction begins.
Phase 4: The Overlooking System Design
System design is the important analysis work that must happen before team collaboration. The whole feature to be built is mapped onto components in the wider software: some components to create, some to modify, some to remove. Their relationships are depicted as data flows among them, with the affected data items revealed.
The result of a system design is a clear view of the part of the software relevant to the feature.
A good system design helps the team find an alternate, better implementation; identify duplicates; decide which debts to repay; recognize the correct scope of development; understand development risks; and identify all dependencies—inside the software or with outside entities.
It is called an overlooking system design because the components are relatively big. The designer does not map detailed functions to components. Instead, the components map to abstract ideas of tasks. A component says, for example, what it takes as input and what it outputs or stores somewhere—it does not detail how to decompose the function, or whether the function executes sequentially or recursively.
A higher level of abstraction makes the design clean. And when the system design is fixed, an accurate work amount can be estimated.
Crucially, tech debt repayment is taken into account here. The dev team has a separate backlog for technical amendments to the software. The team spontaneously adds these amendments into the system design when it is convenient. Each technical amendment is a repayment for some tech debt. This is where continuous improvement of the software actually gets scheduled—not deferred, not argued about sprint after sprint, but folded into the structural work of the feature at hand.
Phase 5: Detailed Estimation
In this phase, dependency is not so important—as long as the deadline is not the first priority. Because UI design and system design have ruled out uncertainty, the detailed estimation can be quite accurate on work amount. And because it works from a fixed design, the estimator’s judgment is structured rather than a private guess.
Each component’s work amount is estimated individually, and then all components’ work amounts are summed to yield a total.
The estimator is usually a single member of the team. He must think seriously about the work amounts, because his estimation will be applied to other members. If he estimates too high, the actually-assigned member will get too much free time, and the manager will notice the bad estimate. If he estimates too low, the assigned member may challenge it—”No way, you do it!”—and the manager will notice that too. After an estimate is submitted, the manager reviews it, or asks another member to review it.
The detailed estimation is then submitted to the product owner. The product owner gets a chance to reject further development if the accurate cost is too high. This is also important for the dev team: the inaccurate estimate from the rough estimation phase gets a chance to be corrected, so the team can later work on a genuine schedule rather than be pressed to match an unreasonable deadline.
Phase 6: Scheduling
Scheduling takes component dependency into account. It is effectively a topological sort. Components are added to the schedule one by one, in topological order, as members become available.
Each component becomes a task. Every member’s workload is controlled so that each member holds only one task at a time—no simultaneous workloads.
The dev team can adjust the length of each task according to each member’s skill level. This constitutes a natural work-in-progress control. The end of development is well predicted, and critical paths become visible. The team can make adjustments to resolve the critical path.
As a result, the product owner, the dev team, and even sales and customers can obtain a clear expectation of when development will end. This is a major managerial benefit.
Later, if an urgent task is inserted, the schedule is adjusted to reflect the insertion. The inserted task may or may not delay the release. Because a well-functioning schedule exists, a member not on the critical path can be reassigned, and delay-or-not can be well predicted. Stakeholders’ expectations are then updated if necessary.
Phase 7: Component-wise Implementation, Deployment & Testing
Implementation proceeds component by component. As each component is developed, it is tested, reviewed, and delivered—so other members can pull the component and integrate it into their own work.
When a component brings visual changes, or anything else the product owner can verify, the product owner is also involved in verifying the component. This gives an early loop back to the product owner, so any misunderstanding gets another early chance to be fixed. The product owner is not waiting until the whole feature is assembled to see whether it matches what they meant; they see the parts as they come together.
At the same time, the testers join. They examine the UI design and prepare further tests. In doing so, they ask a great many questions about the UI design, which often exposes missing and unclear points. Whenever these are found, a backtrace confirmation is triggered. For points the manager can decide, the manager settles them. For points that need the product owner, the confirmation traces back to the product owner.
The strategy pays off because it identifies concrete potential problems early—not so early that problem identification would be wasted if the feature were cancelled, and not so late that component development must be reworked.
The problems the testers find at this stage are usually small ones—a missing edge case, an unclear label, an inconsistent behavior on an unusual input, a boundary that was never specified. The large problems have already been exposed in the UI design and system design phases. Whether the feature does the right thing, whether it belongs in the right place in the software, whether its data flows are sound, whether it duplicates something that already exists—all of that was settled before a single line of code was written. By the time the testers arrive, the questions of what to build and how it fits are closed. The testers are not discovering that the feature is wrong; they are discovering the details that no design can fully anticipate, and those details are cheap to fix at this stage precisely because they are small.
Only very occasionally, a tester’s question reveals something more serious—a real design flaw that slipped through. This is possible; no work can be perfect. But even then, it is still good for the process. The later a flaw is found, the higher the cost the team will have to pay. A flaw caught here, during component-wise development, costs a conversation, a reconsideration of the design, and perhaps a rework of one component. The same flaw caught after release costs rework, retesting, redeployment, and possibly damage to users in production. The testers’ questions are a cheap early-warning system—and even their rare serious finding arrives far earlier, and far cheaper, than it otherwise would.
If the testers have unused capacity, they can even join the test work in this phase as well. Testers usually cover more extraordinary cases than a programmer does.
Phase 8: System Test
Before the whole feature is released to production, it must be well tested in an environment that emulates real users’ use. This is the system test: the feature is released to a dedicated test environment, multiple end-to-end tests are run, and then even random tests are performed.
Many people argue that if all components were well tested during delivery, the system test is unnecessary. Practice says the contrary. Many bugs are identified during the system test, found by testers. It is seldom the case that programmers let the testers find nothing.
Phase 9: Release
This is the into-production phase. Not much to say.
Part 2: The Agility of the Albatross Method
What Agility Actually Means
Before claiming agility, we need to define it. Agility means the ability to adjust toward requirement adjustments. Not the ability to hold a daily stand-up. Not the ability to say “we respond to change” while quietly absorbing the cost. The ability to actually adjust—and to do so without wasting work, without corrupting the schedule, and without shifting the cost of change onto people who are not positioned to carry it.
Measured against that definition, the Albatross Method is highly agile—and it is agile in a way that extends, rather than rejects, the Agile tradition. Here is why.
Uncertainty Falls as Cost Rises
The Albatross phases flow from large uncertainty to small uncertainty.
- The planning phase holds the largest uncertainty. It is also where the dev team’s effort is smallest. This is entirely reasonable: working hard on a feature that may be thrown away is pure waste. Even if you have a pipeline that can generate a running prototype quickly, it still costs various fees—and now, with AI at our disposal, token consumption adds to the cost.
- The UI design and system design phases work at a high level of abstraction. There is no detailed implementation, so cost remains low—though higher than planning.
- After the scheduling phase, development fully starts and should not stop. A stop during these phases means very heavy waste, and it must be avoided.
The Funnel: Where Agility Actually Lives
If you view the process from high altitude, an important feature reveals itself:
- The planning phase discards unqualified candidate features.
- The rough estimation discards candidate features that are too expensive or too risky.
- The candidate features that pass the detailed estimation phase run to the end.
Heavier work is postponed until it is required. Waste of work is reduced to its minimum. This is agility in its fullest sense—not only the ability to pivot after building the wrong thing, but the ability to not build the wrong thing in the first place, cheaply and often.
Requirement Changes Are Put on the Table
When a requirement changes, the Albatross Method does not take it silently. A change is put on the table, then on the schedule. A straight discussion is held between the product owner and the dev team, and they re-agree on the adjusted design and schedule explicitly.
The dev team is never pushed toward an unrealistic goal. All components are done at their natural boundaries. No debt is deliberately left behind for a calendar reason. This addresses a well-known weakness of Scrum and Kanban when they are used for long-run software: change is often absorbed silently, and the accumulated cost—technical debt, eroded quality, exhausted teams—only becomes visible years later.
The Team’s Own Backlog Is the Continuous Improvement Engine
The dev team has the agility to add technical amendments at the team’s own conscientious discretion. Of course, the team can only do this when the development period is approvable by the product owner. But this agility is extremely important for long-run software.
This is where Albatross extends the Agile tradition beyond Scrum and Kanban. In Scrum, the Product Owner owns the schedule and is measured on feature value. Debt repayment produces no visible feature value, so it consistently loses the prioritization debate. In Kanban, debt is not a card, so it never enters the queue at all. Making debt visible does not give anyone a reason to repay it.
Albatross gives the dev team its own backlog, independent of the product owner’s. Because the team has the freedom to make improvements, that backlog is at the team’s disposal. It is where debt gets a position on the schedule—folded into the system design of the feature at hand, repaid as part of the structural work rather than deferred indefinitely.
That is what continuous improvement actually requires. A visibility dashboard and a “tech debt” column are useful, but not sufficient. What continuous improvement requires is a place in the plan by default, a location for each debt, and a horizon that outlasts a sprint. Albatross supplies all three.
Why Albatross Is the Next Step for Agile
Scrum and Kanban let structure emerge from construction. That approach served the industry well for the kind of work they were designed for—prototyping, exploration, and short-cycle iteration that can be reset at the end of a sprint. In that setting, letting structure emerge from the act of building is not a weakness; it is the point. The work is exploratory, the code is disposable, and the next sprint can begin fresh.
Long-run software development is a different kind of work. A living codebase must absorb change for years—across many teams, many priorities, many market shifts—without collapsing under its own accumulated debt. For that work, letting structure emerge from construction means structure is discovered late, debt is never given a place on the schedule, and change is absorbed silently until the cost becomes visible years later.
This gap has existed for as long as Scrum and Kanban have been applied to long-lived software. It was there before AI, and it is the reason Agile has often worked well on new products and struggled on mature ones. The frameworks are not badly implemented; they are simply designed for a different kind of work than the one long-run software asks of them.
AI does not create this need. It only adds urgency. As Part 2 noted, AI raises the price of wasted early work—token consumption is a real cost. But the deeper effect is that when code can be generated faster than it can be designed, decomposed, owned, and verified, the consequences of letting structure emerge from construction arrive sooner and cost more. The team runs much faster into the state every long-lived system eventually reaches if structure is neglected—a codebase where fixing it has become more expensive than replacing it. The bottleneck moves visibly to design, decomposition, ownership, and verification—the exact places where Albatross does its work before construction begins.
As we said at the start, Albatross is what Agile becomes when it is designed for the long run. That is true with or without AI. AI simply makes the transition harder to postpone.
The Albatross Method was designed for exactly that world. It:
- Discards cheaply and early, so most bad ideas never consume real effort.
- Locks intent before construction, so the product owner and the team cannot drift apart into expensive misunderstanding.
- Maps the feature onto the living system, so the software’s structure is improved, not eroded, with every change.
- Gives debt a scheduled home, so continuous improvement is a property of the process rather than a heroic exception.
- Keeps the schedule honest, so change is negotiated explicitly instead of absorbed invisibly.
- Ends cleanly at natural component boundaries, so nothing is left half-done for a deadline.
That is a high-agility process. Not because it moves fast in the narrow sense of shipping features quickly, but because it moves correctly—adjusting to requirement changes without waste, without debt, and without shifting the cost onto people who are not positioned to carry it.
In the long run, agility—the ability to adjust toward requirement adjustments—is not only the ability to change your mind. It is the ability to change your mind without paying for it twice.
Scrum and Kanban brought agility to a new project. Albatross brings agility to the software’s whole life.