Agile Software Development

What this covers

Custom software is warranted when an agency's process is genuinely distinct or when commercial products do not fit. HQT builds custom applications using agile practices adapted to public-sector constraints, such as fixed budgets and formal acceptance.

Typical activities

• Discovery with users, including residents where the application is public-facing
• Backlog development and prioritization with the agency product owner
• Two-week iterations with demonstrations of working software
• Automated unit, integration, and end-to-end testing
• Accessibility and security checks within each iteration
• Documentation, training, and handover

What you receive

Working software delivered incrementally, source code in the agency's repository, test suites, deployment pipelines, and user and technical documentation.

Considerations for public agencies

Agile and fixed-price procurement can coexist. We scope releases as fixed-price increments with defined outcomes so that the agency has budget certainty and the team has room to adapt details.

Signals that custom development fits this process

Custom development is proposed more often than it is warranted, so test the case before writing a solicitation. The signals that point toward it are specific:

• The process runs on spreadsheets, a shared mailbox, or a desktop database that one employee understands, which concentrates the risk in that person.
• Every product you evaluated would require changing a step that statute, ordinance, or a court rule holds in place.
• A product vendor has quoted heavy configuration plus custom extensions, which is custom software the agency pays for without owning it.
• Nobody in the office describes the current process the same way twice, so requirements cannot be settled on paper before working software exists.
• A legislative change or grant period forces a usable release before the full scope can be built.

Counter-signals carry the same weight. Where the process is common across jurisdictions, such as permitting, licensing, or work orders, a configured product is usually cheaper across its life. Where no one in the program office can give the work regular time in every iteration, iterative delivery stalls regardless of who builds it.

What a healthy iteration looks like, and a failing one

In a healthy project, each demonstration shows the application running in an environment the agency controls rather than a slide deck or a clickable prototype. Acceptance criteria are written before the iteration starts, in language a program manager can read without a translator. The application is deployable from the early weeks even when it does almost nothing, and defects found in an iteration are fixed inside it rather than parked for later.

Failing projects look different, and the signs show up early:

• Demonstrations assembled from designs rather than running code
• A backlog only the vendor can interpret
• Velocity charts offered in place of features the agency has accepted
• A stabilization period that keeps growing as the deadline approaches
• Integration with other systems deferred to the last increment
• Test data that does not resemble production data in volume or in messiness
• A product owner who must carry every decision to a body that rarely meets

Any one of these is correctable on its own. Together they mean the agency will not see the true state of the system until it is nearly out of time.

What to put in the solicitation and the contract

• Commits landing in the agency repository throughout each iteration, with agency staff holding access, rather than a code drop at final acceptance
• A definition of done written into the contract, so that complete is a contract term rather than a vendor judgment
• The right to end the engagement at an increment boundary and keep everything produced to that point, including code, tests, pipelines, and environment definitions
• Named key personnel, with substitution only on written approval
• Deployment into an agency-controlled environment by a stated iteration, so operations and security staff meet the real system early
• A software bill of materials for each release and disclosure of open source license terms
• The accessibility standard named explicitly, chosen against the federal and state rules that apply to your entity rather than left to the vendor to select

Obligations run both ways. The agency owes a product owner with decision authority, subject matter experts on a schedule, representative test data, environment and identity access granted early, and a security review booked at kickoff instead of after the last increment.

Judging the result after the first release

Record a baseline before development starts, or there is nothing to compare the new application against. Useful program measures include the share of transactions completed without staff intervention, elapsed time from submission to decision, the rate of submissions returned for correction, call and counter volume, and staff hours spent on manual steps. Useful delivery measures include lead time from commit to production, the share of changes that require a fix afterward, and defects that reach users.

The measure that settles the question arrives after handover: what it takes in time and cost to make the first significant change without the original team. An application only its builders can change has traded one dependency for another.

Working with HQT on this

HQT scopes this kind of work as a fixed-price or time-and-materials engagement with a written statement of work, named staff, and a defined acceptance process. We are candid about what we can take on and prefer a well-run project to an oversized one. Contact us to discuss a requirement, a draft scope, or an upcoming solicitation.

Frequently asked questions