This article looks at the topic of Scrum in Audit from a high level. These include the roles, events and the artifacts of Scrum and how they might apply to audit. We also explore why Scrum might be applicable to you, raise questions to consider and tips for each of the Scrum elements.
Scrum is easy to learn but hard to master. (I will come back to this)
Possible problems you might be experiencing
Often, in my engagements, the issues that teams and leaders talk to me about are:
Heightened workload may be caused by:
Low morale may be caused by:
Audit Tool gripes:
There may be more symptoms, I’m just naming a few common ones we have seen.
When we look at the Scrum Guide (www.scrumguides.org) we’re met with the “easy to learn” (see disclaimer above) Framework of Scrum.
Scrum is beautiful in its simplicity and because of its low prescription approach to delivery, it lends itself wonderfully to audit delivery. It simplifies our approach to working together, helping us to breathe and try some new things. The framework offers three elements in order to proceed with work: 3 Roles (Product Owner, Development Team and Scrum Master)The simplicity of the roles gives us clear understanding of who owns and helps make vital decisions on value and priority (PO), who the skilled people carrying out the work are and determining how things are done (Development Team) and finally the person who is helping these roles flourish through coaching, mentoring, facilitating and teaching (Scrum Master).
Most importantly, this encourages a whole team approach, collectively known as the Scrum Team.
TIP: Have the whole team work together from beginning to the end of any piece of work. What currently stands in your way for achieving this? 5 Events (Sprint, Sprint Planning, Daily Scrum, Daily Retrospective)
The events primarily help audit teams to instil more focus into their work and understand priority. We have seen the use of a two-week sprint cycle benefit teams as they journey into agility using Scrum. Simply put, a two week lookahead seems long enough to achieve something tangible and short enough to learn lessons quickly and raise major impediments before they cause longer term problems.
Scrum events are all “real work” meetings that are all timeboxed, not more meetings to add onto your already busy lives. Scrum encompasses all the requirements to garner planning (Sprint planning), delivery (Daily Scrum) and feedback from both stakeholders (Sprint Review) and the team themselves (Sprint Retrospective). We see teams benefit from having the whole Scrum Team attend all these meetings; this continuous discussion and reflection has seen auditor morale increase exponentially in many of the teams we’ve worked with.
Scrum in Audit is amplifying the need for more regular retrospective (end of each Sprint instead of at the end of the audit or project) and daily interaction is increasing engagement, enthusiasm and transparency.
TIP: Explore what existing meetings you have that are already serviced by the Scrum Events and what meetings are just not needed. (Meeting purges are good fun) 3 Artifacts (Product Backlog, Sprint Backlog and the Increment)
The artifacts exist to help create transparency in your work. The product backlog works as an ordered list of requirements. A top to bottom approach has really helped those we have worked with. Highest value / priority items at the top and lowest at the bottom. The sprint backlog serves as the Development Team’s plan for the next two weeks (Sprint) and the work they have decided to concentrate and focus on as discussed in Sprint planning. The artifacts are usually physical items, regularly seen in the form of whiteboards and other visual indicators. The team can meet around these in the relevant Scrum events and plan and share explicit knowledge about their work. The visualisation of this work means anyone can understand progress or what might be impeding them. The items that reach the done column from audit sense tend to be DONE (truly done) items of work carried out throughout the sprint.
An example of this could perhaps be a control objective walked through, given an issue rating if unsatisfactory and documented in the appropriate tool with the right level of sign off to then take it to our stakeholders for discussion. Satisfactory rated items can be considered done in this way and made ready for review too – Positive assurance is equally valuable as it’s good to know where things are going well and can serve as reminders to keep doing the good things we’re doing.
TIP: Ensure you have a solid Definition of Done for what reaches the ‘done’ column on your Sprint Board. This can help to maintain or even enhance the quality of your work. Example:
Scrum flips the concept of delivering your audit at the very end of your project. In fact, I’ll go as far as putting a big challenge out to all audit departments on this very issue. If our purpose is to help our organisations mitigate risk, how is delivering our opinion after 3 – 6,7,8 months helpful?
With each incremental sprint, our goal is delivering value that is ready for consumption and feedback. That means every two weeks we are delivering our opinion on highest value themes, controls etc. This allows the auditee to act sooner and gives our audit committee greater comfort that we are challenging in a timely fashion. Working in each sprint and building our opinion as we go also leads to an interesting question, what is the purpose of the usually long and drawn out REPORTING phase?
That’s my opening intro to how Scrum may help your Audit Teams.
FINAL TIP: Give it a go, you can only learn by experimenting. If it doesn’t work, you’ve only lost two weeks! Thanks for reading. AndyDirector, Coach and Trainer with Agile In Audit
Please subscribe and become a member to access the entire Business Agility Library without restriction.