Revived from a two-part 2021 series and updated. Buyers still ask us whether we are “agile.” The honest answer takes a few paragraphs.
Fred Brooks wrote in 1975 that adding developers to a late software project makes it later. It sounds wrong until you have lived through one. Fifty years on, software projects are still notoriously late and over budget, and the reasons Brooks named, complexity, unclear requirements, and teams that do not talk to the people who will use the system, are still the reasons. Projects become late, he said, one day at a time.
Methodologies have proliferated in response. Two matter: waterfall and agile. Here is what each was trying to fix, why almost nobody practices either one as written, and what we actually do.
Waterfall
Waterfall comes from manufacturing. You spend a long time up front making sure the design is right, because changing the tooling later is ruinously expensive. Applied to software it became a sequence of phases: requirements, analysis, design, coding, testing, operation, each handed to the next team when finished.
The irony is that the paper usually credited with inventing it, Winston Royce’s 1970 essay, was arguing against exactly that. Royce described the sequence and then warned that without iteration it was “risky and invites failure.” The industry kept the diagram and dropped the warning.
Waterfall’s real problems are two. Requirements written before anyone has built anything are guesses, and a long requirements phase produces analysis paralysis and a bloated feature list, because nobody yet knows which twenty percent of the features will produce eighty percent of the value. And every handoff between specialists loses information. The analyst who wrote the requirement does not know how hard it is. The developer who discovers it is hard cannot find the designer, who rolled off the project two months ago.
It still has a place. When requirements are fixed, well documented, and clear, the technology is mature, and the project is short, waterfall gives you a more predictable budget, timeline, and scope than anything else. That describes very few custom software projects.
Agile
Agile was written in 2001 by practitioners, not managers, as a reaction to the documentation-heavy process above. Its core fits on a napkin: build small pieces of working software, put them in front of real people, learn, and adjust. The team is cross-functional and self-organizing, and it values working software over documentation, collaboration over contract negotiation, and responding to change over following a plan.
The reason it caught on is a truth every product person knows: users do not know what they want until they see it. Spend a year eliciting requirements and you will build the faster horse. Show someone a working screen in week three and they will tell you what they actually need.
The reason it disappointed so many companies is that agile as written is rarely practiced. Prioritizing people over process is hard to sell. Working software is harder to produce than plans. Collaboration requires trust that is not always present between a client and a vendor. And executives legitimately need long-range plans. So “agile” became a label, then a marketing term, and in many shops it became an excuse for chaos: no plan, no accountability, and a launch nobody can explain.
What we actually do
We are an agile shop in the sense that matters and not in the sense that generates certifications. Four things from the manifesto are load-bearing on every project. The rest we use when it helps and skip when it does not.
Cross-functional ownership. One team, yours and ours, owns the solution from start to finish: strategy, design, engineering, and the people who will use the system, together. Fewer handoffs, more buy-in, faster decisions. This is the single biggest fix for the information loss that sinks waterfall projects.
Working software every cycle. Short cycles, two weeks or so, each ending in something you can use rather than a status report. You see progress, and you can change course while it is still cheap to.
Recurring prioritization. Every week we decide together what is most valuable next. On a fixed budget with controlled scope, this is how the budget holds while the scope flexes.
Rapid testing of assumptions. Prototypes, click-through mockups, and small releases exist to find out whether we are right before the expensive part. That is also why every new build starts with a VDP Sprint: it is the part of the project where a wrong assumption costs a conversation instead of a quarter.
What we deliberately do not do is pretend a methodology substitutes for judgment. Some clients need more documentation because their industry demands it. Some need a firmer plan because a board is waiting. A process that cannot bend to the client is a process that serves the vendor.
The one-line answer
Are we agile? We foster agility. We plan enough to know what we are doing and where the money is going, we build in short cycles so you see real software early, and we change the plan when the facts change. If you want to see what that looks like from your side of the table, how we run the work spells it out.