Auditing Agile & Agile Auditing
Alison Booth and Mark Paton of Pelicam Assured Delivery discuss the unique set of challenges created by Agile methodologies.
It’s no secret that Agile work methodologies have become something of a must-have for many businesses over the last two decades. Particularly for companies in the technology space, the ability to build, release, measure and pivot product offerings quickly has become an important, if not essential, way of working. From an audit perspective, however, Agile methodologies have created a unique set of challenges which, if not properly dealt with, threaten not only to negate the benefits which Agile working can provide, but actually destabilise the business as a whole. This article will explore the factors which auditors need to be aware of when working within an Agile environment and suggest some practices and approaches which can ensure your auditing function is actually adding value to the agile process rather than detracting from it.
The advent of Agile
Agile working is generally considered to be the brain-child of tech start-up culture; companies like AirBnB and Uber are among the first names that come to mind when you start talking about Agile working. For start-ups, working with limited funding or resources and where the need to launch a product to market before the competition is critical, Agile product development provided a solution. Rather than working in a traditional “waterfall” approach where the project would be defined, built, tested and then released, these businesses opted for an iterative approach. These start-ups realised that by shortening their project life-cycle and building, launching and measuring the success of product or features “bit by bit” - they could go to market more quickly. Start-ups could launch a minimum viable product (MVP), start building a customer base and establishing their brand, and then continue to add to, or “iterate” on their offering.
Agile product development also had an additional benefit for start-ups which may be one of the reasons that so many more established companies suddenly wanted in. By shortening project life-cycles, start-ups reduced overall project risk. Rather than spending two years creating a product which didn’t work as well as expected, or for which there was no real market appetite, start-ups were able to learn from the real-world success of each iteration and change their offering accordingly. In the fast moving world of technology that ability was and still is priceless. Tech companies of all sizes now switch features on and off constantly, giving themselves the ability to optimise their user experience (and their revenues) at the flick of a switch. Venture capitalists were similarly comforted by the benefits of Agile working - the performance of their investment being apparent more quickly and their exposure reduced.
However, not all businesses are start-ups. As more and more established businesses underwent the “digital transformations” of the last two decades, Agile working found itself in unfamiliar surroundings. These businesses want the benefits of Agile working (including reduced risk, increased speed and the ability to attract tech talent) but alongside or within a legacy framework. If not managed properly that contrast can create tension and disconnection between tech or product teams and the rest of the business. This is often most apparent for Audit or risk functions whose responsibility it is to understand the bigger picture.
How can Audit help Agile? How can Agile help Audit?
For someone working in Internal Audit, that might sound like the perfect storm; a tech team responsible for the future of the business, working in a way which doesn't seem to be compatible with the rest of the business. Yet if it’s managed properly, the relationship between Agile and Audit can be a mutually beneficial one. For the Agile team, the Audit function can be the bridge between their projects and the stakeholders elsewhere in the business. Auditors can be the translators of Kanban boards and Jira tickets into documentation which others can easily digest. From an Audit perspective, Agile working need not be a nightmare proposition either. Once understood, shorter project cycles and quicker data and feedback can provide the opportunity to ensure project objectives are still front of mind.
Making that relationship work does require a different approach, and sometimes a different skill set, to that which you might use in a non-agile business. Understanding what that approach is will ensure that your organisation can enjoy all the benefits of Agile working without the perceived risks or shortfalls.
Auditing Agile; the approach and skill set
As an auditor, understanding the way in which the agile part of your organisation works is key to developing the approach and skill set you’ll need to effectively work alongside them. For some people that starts with getting to grips with the vocabulary of Agile; what’s a sprint, a stand-up, Kanban, MVP? For others it means understanding who does what within the team, and what do those job titles means in terms of responsibilities? Should you be working more closely with the scrum master or the product manager? Answering these questions is a good place to start when developing a strategy.
Once these foundations are established, the focus becomes timing and engagement. As you will have noticed, the pace of Agile development is one of its key strengths; ensuring you are in-step with the Agile process is a great way to create the sense of working with an Agile team rather than against them. In practice that means understanding the timing of their daily and weekly review meetings, the length of sprints and release schedules. By engaging with the right people, at the right time, you can ensure your audit reviews happen at a point which will be able to provide the most accurate and constructive insight for the wider business.
Similarly, understanding how the teams communicate and document their projects and workflow is essential. Where in more traditional “waterfall” type businesses a development team might bear the responsibility for documenting their work in a way which is logical for the board, that might not be the case in a business where Agile is working alongside non-Agile departments. For an outsider, documentation might seem hidden or non-existent (particularly in so-called “lean Agile” environments) - but in reality it often in a different format to the one you’re used to. The time required to document everything formally is often a barrier to the speed in which Agile teams are trying to work; you’re more likely to find the information you need on Kanban boards, post-it notes or digital “tickets” on something like Jira. Understanding what information you’re likely to find where is essential if you’re going to a) learn from that information, b) know when something’s been missed.
Effectively auditing Agile teams and processes also requires a level of creativity and flexibility which may not have been part of an auditors job description 10 or 20 years ago. Agile auditors need to be able to quickly switch between looking at the overall picture within the context of the business objectives, to looking at quite granular detail of specific sprint cycles. Understanding how lots of little issues on the granular scale might add up to a larger issue which should be reported to stakeholders is one of the unique challenges which agile auditors will come up against.
Communication is still key
It’s easy to think, having read all the above, that “Agile changes everything” and that the job of an auditor is now unrecognisable. The jargon and methodologies can seem intimidating but in our experience there is a constant theme which underpins all of the changes, and it’s one which auditors will know has been true long before Agile became a “thing”. Communication is still key. Finding the right person to talk to, asking them the right questions, at the right time, and then translating that into clear updates for board members or stakeholders. By doing so effectively you can satisfy the internal risk function of the business while also actually adding value for the Agile team. Communication from stakeholder level back down to the development team will help inform their next development cycle. Suddenly, as an auditor, you’re benefiting from the speed, dynamism and flexibility; from the agility, which made Agile workflows so popular to begin with.
Alison and Mark presented a free webinar on this topic for ACCA which is available on demand - register now.
Alison Booth is the Business Transformation Partner at Pelicam Assured Delivery
Mark Paton - Financial Services Partner at Pelicam Assured Delivery Mark Paton is the Financial Services Partner at Pelicam Assured Delivery