"Agile" covers a lot of ground, and on its own it does not say much about what ships or when. Standups, a board and story points are useful tools, but they are not a commitment. So every engagement at Fostron goes through the same four phases: Scope, Build, Harden, Operate. Not because it makes a nice diagram, but because each one prevents a specific way projects go wrong.
Scope comes first, and it's written down
Before any code gets written, we turn the problem into a written scope document and an estimate, fixed-price or time-and-materials depending on how well-defined the work is. This takes three to ten days depending on complexity. It also means saying no to ambiguity: if we can't write down what "done" looks like, we haven't scoped it yet.
The failure mode this prevents is a common one: a project that has sprints but no written agreement on what the finished thing looks like, so scope drifts for months and nobody can point to a document that settles it.
Build means a demo every week, not a status update
Once scope is agreed, we build against a visible backlog with a working demo every week. Not a slide with percentages on it, an actual demo of running software. If a client can't see progress, we don't consider it progress.
This is also where direct access matters. You're talking to the engineer writing the code, not a project manager relaying your question and getting back to you tomorrow.
Harden is the phase most likely to get cut
This is the one that goes first under deadline pressure: load testing, a security review, and a pass through the edge cases that only show up under real usage. We treat this as a phase with its own deliverables, a load test report, a security checklist, a documented rollback plan, not an afterthought squeezed in before launch.
Skipping this phase is how software that looked fine in a demo falls over in production. Giving it its own deliverables is the only reliable way we have found to keep it from being squeezed out.
Operate is a commitment, not a hope
After launch, we stay on with an agreed response time for support and iteration. "We'll be around if you need us" isn't a plan. A defined incident response time and monthly iteration based on actual usage is.
Why we structure it this way
None of this is a rejection of iterative development, and we build and ship incrementally within the Build phase. The distinction we care about is that ceremony is not a substitute for the two things that carry a project: a written agreement on what is being built, and a hardening phase before it goes live. A standup will not catch a race condition under load. A load test will.