Agile Internal Auditing – The Case Back To Normal

Agility

While agility is often described as a personal mindset, its organizational manifestation can be defined as the organizational capability to rapidly and pro-actively adapt to a VUCA world and changing customer needs (Schmitz, 2018).

This adaptive power is very core to IA. All ten Core Principles for the Professional Practice of Internal Auditing (The IIA, 2017a), which define IA effectiveness, require agility (Wilhelm, 2019a). Agile auditing is a set of practices that helps IA functions in meeting their objectives in a more wholesome manner, it is a mindset adopted by an IA team to focus on stakeholder needs, drive timely insights, accelerate audit cycles, generate less documentation and reduce wasted effort (Foo & Bhattacharya, 2017b).

According to practitioners, agility in IA processes has explicit manifestations (Wilhelm, 2019b), which are summarized in Table 01 . The table shows: agility in IA is not just a new buzzword but affects the core of IA work processes.

While these manifestations of agility in IA have been described by practitioners (Coleman & Kasahara, 2019; Herbert, 2019; Pundmann et al., 2018; Wilhelm, 2019a; Wilhelm, 2019b), the academic research into agile IA practices is very thin. To date, there is only one academic case-study to this topic (Foo & Bhattacharya, 2017a), which shows the need for studies like the present one.

The following sections analyse agile frameworks which are most relevant for IA work processes.

Kaizen and Kanban

The most widespread agile framework in IA work processes today is Kaizen (Japanese for: change to the better). Its basic ideas were conceived as the Plan-Do-Study-Act-Cycle by US professor Walter Andrew Shewhart, and his student and later professor William Edwards Deming (Moen & Norman, 2010). Their ideas spread rapidly in Japan, where industrial companies like Toyota agilized standardized mass production in the 1950s.

The basic idea of Kaizen is to establish and live a culture of continuous improvement, especially by reducing the three main inefficiencies of a process to make it “lean”: overcharging a process or a system beyond its capacity (“muri”), inconsistency in performance (“mura”), and wastes within the process (“muda”). Kaizen is translated into different schools of thought, such as Lean & Total Quality Management, Six Sigma or ultimately also the industrial norms of the ISO 9000 family of standards.

Kaizen is very often combined with Kanban (Japanese for: visual signal), a visual pull-system for just-in-time production which was first introduced by Toyota in the 1940s. In Kanban, workflows are visualized on boards with cards in columns, where each column represents a workflow step and cards represent tasks with a focus on the flow of work. According to the “muri”-principle, the maximum number of items in each workflow step are limited, the so-called work in progress (WIP) limit (Baig, 2019).

In IA, the Kaizen ideas of continuous improvement and waste elimination are well established. The IIA’s International Professional Practices Framework requires a quality assurance and improvement process (QAIP) for all IA functions (The IIA, 2017c). IA practitioners have long applied “muda” principles to their own work processes (see Table 02 ).

The first book on lean internal auditing was published in 2014 (Paterson, 2014), while research on the application of different schools of thought of Kaizen in IA has been published already before. The role of IA in the implementation of total quality management systems, including an empirical survey on how audit work processes apply TQM principles, was a research topic already in 1998 (Wilhelm, 1998). The topic how the work processes of IA can be compatible to certification according to the family of norms ISO 9000 was explored in 2011 (Wilhelm & Wasmer, 2011).

Scrum

The most recent and most fundamental agile framework that has been applied to IA work processes is Scrum. The expression Scrum and the underlying approach was invented by the two Japanese professors Hirotaka Takeuchi and Ikujiro Nonaka when they conducted a research study of new product development processes. They found out that successful companies in their study no longer use a sequential approach but employ a holistic method with a built-in instability, self-organizing project teams, overlapping development phases, multilearning, subtle control, and organizational transfer of learning (Takeuchi & Nonaka, 1986). This approach was first applied to software development in 1990 (DeGrace & Hulet, 1990) and became very popular after 1995, when the two US software developers Jeff Sutherland and Ken Schwaber codified Scrum as agile framework for software development and marketed it all over the world (Rigby et al., 2016).

Scrum is, in short, a set of rules which organizes work processes in loops of improving trials and errors (so-called Sprints), running in largely self-organized teams with daily transparent progress updates (Daily Scrum). It allows to deal with complex, adaptive problems and fosters continuous learning and naturally adjusting to changing conditions (Wilhelm, 2019a). Scrum incorporates aspects of Kaizen because its rules demand a regular inspection of the work done (Sprint Review) and a regular brainstorming on what went well and what needs to be improved (Sprint Retrospective). It implies aspects of Kanban as it works with a task board, on which the overall list of tasks to-do (Product Backlog), the list of tasks to-do during the next sprint (Sprint Backlog), as well as tasks in progress (Doing) and finished tasks (Done) are visually tracked. In contrast to Kanban, Scrum has specific roles, namely a keeper of the rules (Scrum Master), a person who is responsible for the emerging product, prioritizes the Product Backlog and links to the customer (Product Owner), as well as a self-organized project team which does the work (Scrum Team). Scrum does not know an explicit limit for work-in-progress as Kanban does but has its Scrum Team, jointly with the Product Owner, estimate its capacity and the amount of work to be done in the next sprint. Scrum has more elaborate rules, which is why Kanban is easier and faster to implement and can be applied more widely. Scrum has more disruptive power and can unleash more agile potential (Wilhelm, 2019b).

The first research endeavour to mention Scrum in relation to auditing was published in 2014 (Wright, 2014). The book is written as an overview for auditors and agile teams over agile governance and audit. It bridges the knowledge gap between agile software development teams and auditors (internal and external) because back then auditors and agile teams knew little about each other’s work practices, goals and concerns. While its foreword mentions a number of (external?) audit teams looking at agile techniques and tools to plan and undertake their own audit work, the book focuses on the governance and audit of agile software development processes and does not deal with how agile frameworks can be applied to IA work processes.

The first documented application of Scrum in IA work processes happened at the IA department of the Swiss Accident Insurance Trust Suva in March 2015, the start of a full-fledged implementation of Scrum to all IA work processes (Wilhelm, 2017a, 2017b). Since then, the number of IA functions that “went agile” has proliferated. Practitioners have recently picked up the topic, with the first practical guide on how to do lean and agile auditing published this year (Coleman & Kasahara, 2019). Also, external service providers (Pundmann et al., 2018) and software companies (Herbert, 2019) have started to position themselves in anticipation of the rapidly growing market of agile IA transformations.

Standard academic books of IA are already mentioning the term “agile”, which appears nine times in the IIA Research Foundation’s standard book Sawyer’s Internal Auditing (Clayton, 2019). However, the advice there is that internal auditors should follow their agile organizations and build up knowledge of agile frameworks in order to be able to audit them. The books do not yet mention or advise on the implementation of agile IA work processes. The first research study on Scrum in IA is a case-study on the IA function of DBS Bank in Singapore (Foo & Bhattacharya, 2017a). In the case-study, DBS IA implements Scrum in pilot audit projects. A Sprint Team comprised the usual Scrum roles Scrum Master and Product Owner and only one auditor plus members from all stakeholder teams, namely also process improvement executives, user representatives, and project managers from line management (Foo & Bhattacharya, 2017a).

According to that case-study, DBS IA has adopted their agile approach to avoid the disruptive effects of a full-scale agile adoption. Speaking in the classification of agile IA approaches summarized in Table 03 , the DBS case-study exemplifies an IA Project Scrum, where the agile approach is limited to single audit projects and is not comprising all IA activities.

Problem Statement

The application of agile frameworks, especially Scrum, in IA work processes is a relatively new phenomenon which has not yet been adequately covered by academic research. Specifically, there is up to date no research study which has analysed an IA function that lives a full-fledged agile approach, an IA Function Scrum, for all its IA work processes. This appears to be the more urgent, the more agile IA work processes get adopted throughout the world of IA, as it is currently the case.

How can the change of an IA function related to agile IA work processes be influenced?

Ontological, epistemological, and methodological position

This research project assumes a post positivistic ontological position, in other words it takes it for granted that reality exists in a complex nature that cannot be fully understood by the limited human mind. As a consequence, the best way to understand reality is to critically examine claims about it. As epistemological position, which concerns the nature of the relationship between researchers and their knowledge about reality, this project accepts the existence of dependence between researcher and research object but upholds objectivity of the researcher as ideal that must be controlled by means of critical questioning or peer review. This is especially important as the author is also an IA practitioner with a large experience and personal convictions about the IA profession and the present case. Methodologically, the study applies modified experimental and manipulative methodologies which are supported by triangulation of perspectives and are based on empirically grounded data derived from natural, situational settings. Research projects with a post positivistic position see theory construction as scientifically equal to theory testing, consider empirically grounded contextual variables and focus also on human behaviour and its aspects, thus trying to bridge the gap between individual cases and generalizations (Guba & Lincoln, 1994).

Single case-study research design

This study chooses a single case-study research design in its attempt to answer the research question of a case with an unusual outcome, which underlines the suitability of this design (Ragin, 2000). Such a case-study research design starts with data collection, namely writing a case-study on an IA function that has pioneered the implementation of IA Function Scrum in its IA work processes. It aims at developing explanations by finding general patterns in the case observations, which are considered in their context and are obtained and described with the help of interviewed respondents who provide also clues about the meaning of behaviour.

Grounded case-study approach for within-case analysis

Within-case analysis of the data was done following the methodological procedures of the grounded case-study approach by Wilhelm (Wilhelm, 2005), adapted for the single case-study approach of this study. It starts with data collection in semi-structured, problem-centered interviews, which are methods of data collection that are suitable for case-specific complexity.

The case of an IA department going agile and returning back to regular work processes was selected because of its obvious fit to the research question. Table 04 summarizes key criteria for the initial selection.

Data collection is based on two interviews of 90 and 76 minutes length, covering the IA Scrum roles Scrum Master and Team Member. The interviews were recorded and transcribed, entered into a case-study database and are turned into a grounded case summary with the help of summarizing content analysis.

Background and change process

Before going agile, FICO’s IA employed a classical audit approach where an annual plan was established, decided for each year, then worked off in individual black-box audit projects. The way how agile work process were implemented played an important role. Mental speed has already been IA’s key success factor and has allowed it to successfully overcome organizational hostility during the past seven years. The CAE and his team had already implemented several innovations such as dedicated consulting and data analytics teams or a database of findings and recommendations replacing traditional audit reports. After years of trying out in vain audit work process software solutions to find satisfactory IA work processes, the CAE brought forward his agile idea. His five-person team’s reaction reached from change fatigue to deep interest in a new potential solution. What followed was a time of intensive reading by those interested. The CAE communicated his wish to give the idea a try and gave every member of his audit team the chance to veto against it – which nobody did. In March 2015, they decided to go agile. They organized a training workshop for agile methodologies and their implementation in IA to get the knowledge about agile work. The workshop was given by a Tunisian agile coach experienced with software development. It introduced agile frameworks and Scrum, had practical exercises to strengthen the knowledge, and placed its focus on finding a solution on how to adapt agile to IA. Having a professional coach saved a lot of time because of his idea of agile opportunities. He helped to structure the discussions and represented ideas visually. As the coach knew only agile software development, he did not speak the language of internal auditors and therefore the IA team autonomously transferred his ideas into the IA world. At the end of this two-day workshop, every IA team member became certified as Certified ScrumMaster. Whereas several team members were initially rather sceptical, the course sparked their enthusiasm and willingness to try living Scrum. The IA team had decided to use Scrum for all IA processes because also support processes and links to other processes like planning, education or data analytics are relevant for the core audit processes. They felt that the more pervasive Scrum was applied, the better will be the prioritization of tasks. What follows was a period until June 2016 in which the IA team used trial and error and cut its annual plan into pieces until manageable tasks were found as items on the Product Backlog.

In this initial phase, Scrum met much resistance within the IA team. People were used to know in the beginning of a year what audits they will perform. The idea to meet every day and every two weeks to plan anew how little chunks of work can be done took away planning security for the individual auditor. Astonishingly, people with a very structured accounting profile who appeared to be rather inflexible coped with the change process very well whereas other team members had severe concerns and, at one time, tried even to work out an alternative work model which followed a waterfall project method. In intensive team discussions and with the strong dedication of the CAE, the IA team tried to find “their Scrum” and the right aggregation of tasks. Very quickly, working with Scrum became the normality for FICO’s IA team. The agile method lost its initial attraction and became routine. The IA team started to feel well with this new way to work. In this phase, instead of individual motivation the strong structures of Scrum carried the system forward: the sequence of institutionalized exchanges in daily and bi-weekly meetings and the included continuous improvement process. When the CAE left the company, a new CAE was appointed out of the IA team, who happened to be a proponent of the waterfall project and lean management methods. The new CAE aimed at making the Scrum work process leaner, which is why – after a transition phase of one year – he eventually changed the IA Scrum work processes back to a regular IA approach with a Kanban board in 2018.

Agile method, audit planning, and innovation

In the Scrum approach, especially the definition of work packages proofed to be difficult. A too fine-grained planning of Scrum tasks consumes a lot of preparation time and is felt by some auditors as pressure. Due to the interdependencies outside of IA’s control, it often turns out to be in vain. Agile audit gets more transparent but often not much quicker when the auditee and data access do not work in an agile way.

One and a half years after FICO’s IA had fully implemented Scrum, the new CAE abolished the regular team meetings, the role of a Scrum Master and self-organization of the audit team. Instead, there were biweekly regular team meetings without an agile rule setup. A conventional Kanban board as a general to-do list, a special to-do-list for the next two weeks as well as columns with “doing” and “done” were retained. The process became leaner but also less agile as fast changes were no longer done and team members did no longer bring in new requests in an agile way. During the Scrum approach, IA had still kept the traditional annual planning process where the AC decides on a yearly plan. This was a trade-off made to develop IA Scrum in an incubator mode without AC involvement. The new CAE arranged with the AC to introduce a half-yearly planning. As a consequence, the audit plan was executed closer to its initial risk assessment. Also, according to the regular audit approach, internal auditors were no longer multi-tasking in several audits but worked at one audit at a time. Audit planning became more rigid as the audits had to be finished punctually twice a year instead of once a year. Given the fixed end dates and less flexibility of a one-auditor-one-audit approach, agility inside individual time-boxed audit projects became more difficult because many auditees were rather inflexible and favoured a planned inflexible audit approach whereas agile auditing would have required quick access and quickly scheduled interviews during the time-boxed audits.

Regardless of the audit approach, where an audit is broken down into tasks there is the risk to intellectualize the audit work – it is already difficult to formulate a good task but it takes an enormous planning effort and has doubtful chances for success to plan the ideal backlog first and then implement it as it is.

FICO’s IA team had always spent a lot of time for innovation. The introduction of Scrum has supported this innovative spirit because in an IA Function Scrum innovation was treated as a normal task and there was no difference between innovative tasks and regular work tasks. Both types of tasks were included in the normal work process, which was very helpful. The team managed to develop an agile mindset which led to more discussions and innovation debates compared to before the introduction of Scrum. This mindset stayed also after the restitution of a regular work process and was nourished by a constant inner urge to be agile and to stay innovative, no matter if agile was lived or not in the work process.

Organization of teamwork

In the Scrum and the conventional Kanban approach, the decision what the end result must be is taken top-down. The CAE is the place, irrespective of the approach, where the full responsibility remains.

Before FICO’s IA changed to Scrum, the individual auditors had limited contact with each other. Once the annual audit plan was decided, the projects were distributed by the CAE and if no urgent question or resistance came up, the auditor could execute the whole allocated audit project without any contact to the team or the CAE. This was satisfying for individual experts and granted them a lot of freedom. Teamwork, transparency and sharing knowledge were limited.

When FICO’s IA changed to Scrum, a self-organized team gained the freedom of implementation and could freely decide who does what task and how. The individual auditors had their specializations which played a large role on the choice of tasks each one made. Each auditor worked together with other auditors and according to the circumstances there were mixed and changing teams within a single audit. Auditors were multi-tasking in several audits and tasks of other IA processes such as education, management or quality improvement. Most audit projects were completely unique green field approaches, derived solely out of the IA team’s risk assessment. Every second week, the IA team critically discussed its active projects and decided if action should be taken and if the initial goals were still justified.

When FICO’s IA changed back to a conventional Kanban work process, the auditors could pronounce their work preferences in a meeting but the CAE decided over the distribution of labour. With a lean approach in mind, the new CAE strived for a strong standardization of the audit process. Templates with process and content checklists were introduced that had to be closely followed in each audit, with any deviation to be explained in detail. One team member was appointed as quality controller to make sure the templates were filled in and the individual steps were all kept in every audit project. It stayed in the discretion of the individual auditor to add additional content, however due to the time-boxed setup working off the checklists had the priority. Fulfilling the audit plan became the priority whereas reaching unique value added used to be the priority before. The Scrum Master’s usual role is to take away impediments so that the development team can concentrate on their work. Most impediments in IA stem from sources external to the IA function, which is why the possibilities of a Scrum Master as regular IA team member are limited. If the team members are not content with the work approach, the Scrum Master frequently receives negative feedback and is in a double role in between the CAE and the team. After the FICO’s IA changed back to a conventional Kanban work process, the Scrum Master role was abolished.

Communication and customer focus

For FICO’s IA team, the customer focus remained constant irrespective of the work approach because it is linked to the proactiveness of every individual auditor. The relation to auditees was coined by interviews and feedback questions, no matter if the audit approach was agile or not. With Scrum, the communication became more structured and daily communication routines were formalized. The team members knew that they will see each other in and around the next daily Scrum meeting so they tended to use the formal time to exchange instead of spontaneous office visits. Inside the audit team, discussions were very intensive, before, during and after Scrum. The intensive exchanges in formal Scrum meetings made especially sense when every team member felt as real part of the project. In the IA Function Scrum, the team often talked every day about very different topics. In such a situation, the limited mutual influence of team members on each other turns the exchange less vital. In contrast, in an environment where one task influences the other and where there is real collaboration, feedback from colleagues is more interesting and the formal meetings allow to share topical knowledge and not only to gain insight into the work of the team in terms of organizational information about where a colleague is and what he does. Before Scrum, FICO’s IA had already replaced their formal IA report with a database of findings and recommendation and kept formal presentations to a minimum, therefore Scrum did not have a large impact on reporting. However, the IA team had decided to balance the speed of quick reports with the need to wait until interrelated findings can be linked, which may appear during different phases of the audit. In addition, having too frequent reports carries the risk of confusion and a loss of time due to avoidable discussions with auditees.