Increasingly, as organisations enter the Fourth Industrial Revolution, they must develop innovative digital solutions to keep ahead of their competitors. New ways of working, practices and methodologies, such as Agile, can accelerate software delivery, raise IT productivity, improve software quality, increase customer and employee satisfaction, and help organisations quickly adapt technology as business priorities change.1
Yet, despite business and IT embracing Agile, many organisations haven’t fully considered or embedded risk, compliance, and assurance functions in its implementation, resulting in non-controlled, non-compliant and less effective adoption. Trying to retrofit old project delivery and control frameworks to the new world can lead to legacy thinking that erodes the value of iterative development.
But it doesn’t have to be this way. Through understanding some of the nuances and misconceptions, risk teams can offer valuable ongoing feedback and support as an organisation takes the plunge into Agile.
Stories abound of renegade teams using their Agile approach as justification for a lack of formality or discipline. For example, teams may forgo mandatory project documentation or bypass required approvals in the name of speedy, continuous integration or delivery.
These tales tend to accumulate into a broader myth that for risk management, Agile is unsuitable in a mature internal controls environment or, for engineers, translates to ‘you’re slowing me down from doing my job’. And indeed, when an organisation has successfully gone Agile, there are often times when compliance functions attempt to rapidly retrofit old-school controls into the development cycle which can lead to an erosion of Agile productivity gains.
However, if designed and implemented well, Agile methodologies, along with DevOps tools and processes, can address risk control objectives in a lean and efficient manner and enhance the overall control environment. This means businesses must have an eye to scalability and sustainability, and use the full power of tools and functions at their disposal.
It is important that big picture controls and standards requirements are integrated into an Agile environment, such as quality and control standards or operational and risk reporting.
But businesses should also think about the areas where governance, new processes and controls will need to be placed within their organisation. For the leadership team, an Agile organisation will mean different visibility than they may be used to — progress, risk, setbacks, alignment with objectives and ROI will potentially be harder to see than in traditional linear production. It will also be up to leadership to address legacy technology that could bottleneck the continuous development promised by Agile.
For the project management office, understanding how to budget for production where expectations change and evolve will be crucial and task management processes that occur in a linear, sequential order, must be changed to accomodate iterative development. Challenges also exist around reporting mechanisms and how the accurate status of a project can be communicated to all project stakeholders. In particular, this can be an issue for organisations running both agile and traditional projects at the same time.
Risk and audit personnel tasked with ensuring that organisational systems are stable, compliant and secure, will need controls to protect investment value and exposure to operational risks, enacted without slowing down the delivery. Silos will need to be broken down in order to collaborate with teams during the delivery process (rather than at the end with a completed product). With new ways of working, and the quickening pace of delivery, these teams will need to be able to adapt just as quickly to ensure that technology, risk avoidance and security all keep in step with production.
Effective controls may be embedded in an organisation’s Agile delivery frameworks, playbooks and/or by using Agile/DevOps tools. For example, to make certain that there is segregation of duties (as work could overlap or happen concurrently) it may make sense to ensure production code changes can only be made by automated tools with built in testing processes — configurable only by approved administrators. Or, to ensure the accountability of activities without the need for comprehensive documentation (often seen as counter to Agile) the business could use tools that track the process (such as Agile ‘epics,’ ‘features’ or ‘stories’) and include approvals, testing and release information.
Each organisation should consider the specific controls and activities it requires. Fortunately, many mature controls frameworks (eg. COBIT5) already embrace Agile principles. If unsure where to begin, Agile, risk, compliance and assurance teams can use the following as a guideline:
As design and implementation steps are executed, organisations should integrate leading practices wherever possible. These help to design effective and cost-efficient controls and to sustain them over time.
These include launching initiatives to develop Agile capabilities and teams that oversee its adoption and improvement and the use of enterprise playbooks which document methods, protocols and approved tools. Where possible controls should also be automated (rather than manual), preventative (rather than detective) and integrated into natural business processes, rather than being an ‘extra’ requirement.
Mature Agile organisations tend to be ones that are auditable, so some thought should go to ensuring that controls are evident and documented. Further, while this piece talks about controls for development and maintenance processes, businesses should also incorporate security and application controls. Finally, it’s important to note that project quality evaluation should place more emphasis on observing Agile roles, behaviors, and practices in action rather than assessing documentation after the fact.
As the use of Agile becomes pervasive, all risk, compliance, and assurance executives need to embrace how these methods can co-exist with effective controls. With a sufficient understanding of the Agile environment and leading controls development practices, risk professionals can take the right steps to protect against risk and non-compliance without compromising agility.
To find out more on assurance processes for new ways of working, explore the United States or Australian transformation assurance sites. You may also like to take our DevOps diagnostic self assessment for a high level report on the trustworthiness of your own DevOps implementation.
© 2017 - 2022 PwC. All rights reserved. PwC refers to the PwC network and/or one or more of its member firms, each of which is a separate legal entity. Please see www.pwc.com/structure for further details. Liability limited by a scheme approved under Professional Standards Legislation.