Agile development addresses project failure risk, say panelists

Tools

Anyone who thinks Agile Development for federal software projects is a riskier proposition than traditional, waterfall methods "is just wrong," said a senior federal technologist Thursday.

Mark Schwartz, chief information officer at the U.S. Citizenship and Immigration Services – and a well-known proponent of Agile – told a Washington, D.C., audience of federal acquisition workers and contractors that Agile is seen is risky mostly because it's new.

"New things that aren't well known are perceived as more risky," he said during a panel of the ACT-IAC Acquisition Excellence conference.

The reverse is in fact true, Schwartz added – traditional development whereby requirements are defined before the start of work and deviations from them require contract modifications more often than not end in project failure.

The onus of requirements at inception also ends up creating a surfeit on software features, Schwartz said, citing research showing that about two-thirds of features on major, traditional software projects end up going mostly or completely unused.

"Requirements risk is one of the biggest categories we have in our programs, and Agile approaches are designed to mitigate that risk," he added. USCIS has an Agile-only policy for software development, he said.

Under a common version of Agile known as "scrum," programmers work for a short, set period amounting to weeks with the goal of putting into production new functionality by the end of the period. If a function exceeds the team's capacity to code it during that period, it gets carried forward or is dropped – an attribute of scrum that critics say lends itself to a pilling up of difficult programming tasks. Proponents argue that good program management prevents that from occurring.

Traditional software projects often unintentionally end up adopting the Agile paradigm as time and money run out, said Jeff Kachik, senior Agile lead at the Veterans Affairs Acquisition Academy. Program managers begin to focus resources on high priority functions doable within the remaining allotted schedule.

"Agile stays that way, whereas waterfall projects end that way," he said.

Agile can be difficult to get through the contracting officer, panelists acknowledged. The federal acquisition system is typically geared to executing against set requirements – but it's a mistake to say that requirements don't exist under Agile, said Jonathan Mostowski, a National Geospatial Intelligence Agency contracting officer who's also certified in Agile.

"It's a different interpretation of the word 'requirements,'" he said.

"The requirement is the process," he said, stating that program offices can contract for Agile services on the basis of set period of computer programming work.

Related Articles: 
Agile Development isn't undisciplined, says panel of federal CIOs
DHS incremental IT development should be matched by better outcome reporting, says GAO official
Agile Development requires agile oversight, says U.K. government office