ISACA Journal - 2016 Volume 2

“We are running on Agile, so there is nothing to audit” is a refrain auditors hear all too often when attempting to audit clients who use Agile. For a profession rooted in plan-driven methodologies, from validating software development to documenting audit work papers, Agile presents a unique conundrum. 1

THE CASE AGAINST DOCUMENTATION

Conceived by 17 self-professed “organizational anarchists” in a Utah ski resort in 2001, the first two values of the Agile manifesto listed in figure

1 appear to clash with common audit constructs, as internal control design and validation are invariably predicated on process and procedural documentation. Furthermore, Scrum, a popular iterative Agile software development methodology, advocates for self-organizing, cross-functional teams, making audit challenging for auditors who are used to prescribed roles and responsibilities that have clearly demarcated segregation of duties (SoD) to mitigate the risk of wrongdoing or fraud.

Figure 1—Manifesto for Agile Software Development We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

• Individuals and interactions over processes and
tools

• Working software over comprehensive documentation

• Customer collaboration over contract negotiation

• Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more.

Source: agilemanifesto.org. Reprinted with permission.

To understand the evolution of Agile and
Scrum and identify related implications for
audit, it helps to go back to the inception of the
waterfall model, first proposed in 1970. Even
though the waterfall model defines distinct
phases for managing the development of large
software systems, it nonetheless acknowledges
the need for iteration. 2 Fast forward 30 years
and this acknowledgment would have been ideal
for proponents of Agile and Scrum, for whom
each two-week sprint would culminate in the
demonstration of working software. Beginning
with a bare bones skeleton and inheriting more
features with each successive sprint, the Scrum
team seeks to “burn down” the requirements
surfaced through the continual grooming of the
product backlog.

The waterfall model advocates for significant documentation throughout the development life cycle. Some documentation does help to avoid any miscommunication on what has been agreed upon. Yet, it is the very maintenance of significant documentation during the requirements phase that would, in turn, give rise to more documentation, in the form of change requests seeking authorization for variances to plan. Fundamentally, the Agile manifesto does not so much devalue documentation; rather, it values working software more. Agile focuses on having good enough documentation to initiate and sustain an open dialog among cross-functional team members. The premise behind having good enough, rather than comprehensive, documentation is that, at the start of a project, all that needs to be known is not yet known. A plethora of unanticipated outcomes can arise; for instance, customers can, and often do, change their minds on features, even as the software is being coded (64 percent of features developed never or rarely get used). 3 Therefore, having excessive documentation at the start and using it as a benchmark for downstream activities can seem counterintuitive.

Despite a lesser amount of documentation, Agile can actually create greater transparency on uncertainties that may not be otherwise visible during a project’s infancy. According to Jens Østergaard, founder of House of Scrum, the

Chong Ee, CISA, CGEIT, is a senior finance systems manager with Twilio, a cloud communications company based in San Francisco, California, USA. Ee is focused on optimizing the use and integration of financial cloud applications. Most recently, he implemented NetSuite and other Software as a Service solutions at Trulia to support the company’s growth from startup through initial public offering and then as a public company. Before this, Ee spent 13 years in various compliance, audit and consultant capacities for Big Four audit firms, Fortune