Agile Governance and Audit

Agile Governance and Audit: An overview for auditors and agile teams

CHRISTOPHER WRIGHT
Copyright Date: 2014
Published by: IT Governance Publishing
Pages: 111
https://www.jstor.org/stable/j.ctt7zsx7z
  • Cite this Item
  • Book Info
    Agile Governance and Audit
    Book Description:

    The Agile auditing challengeMany auditors are now encountering Agile management methodologies for the first time. In some cases, this can cause problems for the audit process because the methodology is very different from traditional approaches. Aside from the difficulties faced by the auditor, an ineffective audit can have a negative effect on an Agile project by giving a false impression of its progress. It might even harm the final project outcome.

    Bridging the gap between Agile teams and AuditorsWritten for auditors and Agile managers, Agile Governance and Audit bridges the gap between traditional auditing approaches and the requirements of Agile methodologies. It provides an overview of Agile for auditors and other risk professionals who have not encountered the approach before. The book also tells Agile teams what auditors and risk professionals need, and the sort of questions they are likely to ask.

    Essential reading for anyone involved in an Agile auditEach chapter includes hints and tips for auditors, and a selection of case studies is included to illustrate the practical issues involved in auditing Agile projects. This makes it an ideal book for any auditor encountering the Agile methodology, and any Agile teams preparing for a management audit.

    This book will enable you to:

    understand the principles of Agileappreciate how it might be effectively auditedimprove communication between the auditor and the Agile team.

    Read this book to understand how to get the most out of Agile audits, whatever your role.

    eISBN: 978-1-84928-588-9
    Subjects: Technology

Table of Contents

  1. Front Matter
    (pp. 2-4)
  2. FOREWORD
    (pp. 5-8)

    Why am I writing this book?

    A very good question and one I have often asked myself in the middle of the night when the blank page beckoned and deadlines loomed. Then I realised writing a book is very much like running or auditing a project. When you start out you have an idea what you will end up with, but you cannot be certain of the final product. It’s exciting, challenging and you hope it will produce something useful and worthwhile. At the same time it can also be scary and alarming; daunting even when you look at the...

  3. PREFACE
    (pp. 9-9)
  4. ABOUT THE AUTHOR
    (pp. 10-10)
  5. ACKNOWLEDGEMENTS
    (pp. 11-11)
  6. Table of Contents
    (pp. 12-14)
  7. CHAPTER 1: INTRODUCTION TO AGILE
    (pp. 15-31)

    Before we consider Agile governance and audit we need a common understanding of the history of Agile and how it is defined. The dictionary definition of Agile is ‘nimble, mentally quick or acute’. The thesaurus adds words such as active, lively, prompt, quick, sharp and sprightly. These are not words usually associated with IT programmes and projects!

    Many organisations have their own terminology and definitions – of varying accuracy and validity. This also causes some confusion, so throughout this book I rely upon the following widely accepted structures:

    Agile definition

    Agile Manifesto

    Agile principles

    Agile 3 pillars of control.

    An understanding...

  8. CHAPTER 2: AGILE VERSUS WATERFALL
    (pp. 32-40)

    Having looked at the definitions and background for Agile, it is now useful to compare and contrast the technical and governance aspects of Agile and the more traditional waterfall approaches to projects. In this chapter we will:

    Compare and contrast Agile and traditional waterfall approaches for each project phase.

    Look at the risks and governance for Agile projects and consider how to audit Agile. This will include some typical audit objectives for reviewing the approach an organisation may take on an Agile project.

    The Agile Manifesto provides a useful comparison to the more traditional project approaches, and we have considered...

  9. CHAPTER 3: WHY DOESN’T MY AUDITOR/AGILE PROJECT TEAM UNDERSTAND ME?
    (pp. 41-46)

    I can be rude about auditors – I am one. As a Certified ScrumMaster I can also be rude about Agile project teams. Having been in meetings where both of these tribes meet, it strikes me that there can be mistrust and a lot of misunderstanding between the two. In this chapter we will consider:

    audit and Agile cultures.

    how can we have a successful audit?

    Conclusion.

    The overall purpose of a project audit, including Agile project audits, is to provide independent assurance to management that:

    the project is being run with appropriate governance to mitigate the risk of cost or...

  10. CHAPTER 4: PROJECT INITIATION AND RISK ASSESSMENT
    (pp. 47-56)

    The initial phases of any project, waterfall or Agile, are important to set the scope of the project and ensure commitment from all concerned to achieve the desired outcomes. For Agile projects these project initiation and risk assessment phases are likely to be less formal than for waterfall, with the aim of achieving quick decisions and getting started on product development rather than documentation delivery. However, it is still necessary to ensure the project is desirable and will meet specific business needs. Given the use of Agile for cost reduction it is more important than ever to ensure the project...

  11. CHAPTER 5: CASE STUDY PID & RISK ASSESSMENT
    (pp. 57-62)

    The following case study is designed to help you focus on risk assessment for a project. While some of the risks will be the same for a waterfall or Agile-based project the case study also includes some specific Agile issues for you to consider.

    You should review the material and identify the key risks that will need to be addressed for the system, and during the project, using the guidance in the previous chapter.

    As with all case studies there is no right or wrong answer – instead the aim is for you to consider your response to the previously mentioned...

  12. CHAPTER 6: HIGH-LEVEL REQUIREMENTS
    (pp. 63-70)

    Agile projects still need user requirements before we can progress with development. But unlike waterfall projects it is accepted that this will be high level at the start of a project. There will be a general understanding of what the business needs from the project. Using Agile, we accept that this may change as the project develops; for example, due to other business or external changes. The full involvement of the business as a key part of the project also allows flexibility in the definition of requirements as more detail can be added as the project progresses.

    In this chapter...

  13. CHAPTER 7: CASE STUDY FOR HIGH-LEVEL REQUIREMENTS
    (pp. 71-78)

    I have seen a number of styles and formats for high-level requirements. This section provides some examples for you to consider and recommend how you would improve them. There are no correct answers, but I have included some comments at the end of the section. A further hint is that you might like to follow the INVEST principles described in the last chapter. Background information is the same as the case study material inChapter 5.

    There are a number of challenges that will need to be addressed as the project continues. While in an Agile project many of these...

  14. CHAPTER 8: BUILDING AND TESTING
    (pp. 79-87)

    So our project has identified and agreed a need and we have specified high-level requirements. All that remains is to build and test and then the product can be delivered to the users. This phase is often referred to as ‘Realization.

    It is always cheaper and simpler to rectify faults immediately rather than at the end of the project. We need to ensure, therefore, the product is built to requirements and will meet changing business needs and user expectations. In Agile the involvement of the users in the build and test stage, and the flexibility to meet changing requirements, should...

  15. CHAPTER 9: HANDOVER TO THE BUSINESS
    (pp. 88-96)

    In this chapter we will consider the process for finalising deliverables and handing them over to the business. When an Agile product is delivered it needs to be implemented and used. One project I looked at, a hospital catering system, had been completed for two years and was not being used. The software had been purchased and installed using capital budget remaining at the year end. To be used, it needed further revenue expenditure to enable the catering department to input recipes and menus. They did not have the resources to be able to do this and so the system...

  16. CHAPTER 10: DOCUMENTATION FOR GOVERNANCE AND AUDIT
    (pp. 97-104)

    In this chapter we will:

    consider the objectives and principles of Agile governance.

    review documentation required to achieve these principles.

    provide an overview internal audit programme for governance review.

    conclusion.

    Governance of projects is the control mechanism used by the organisation’s senior management to ensure:

    The investments of time, money and technology into the project generate real business value.

    There are no undesired outcomes from the project or its products (e.g., major disruption to customer services, adverse publicity).

    The project can respond effectively to changing circumstances (e.g., technological advances, market or regulatory changes) while the project is in progress.

    The...

  17. CHAPTER 11: TOP TIPS TO TAKE-AWAY
    (pp. 105-105)

    When I learned lawn bowls I was told it would take minutes to learn the basics but a lifetime to perfect the details. The same is true of Agile. The best way of learning in Agile is through doing – being brave enough to make mistakes and willing to change for future improvement. There are five main take-aways that will help the auditor get started on their first Agile Audit:

    1. Auditors cannot stop Agile – instead they need to adapt their approach and look at the benefits that Agile can bring.

    2. Don’t try to perform a standard project audit on...

  18. FURTHER RESOURCES
    (pp. 106-107)
  19. ITG RESOURCES
    (pp. 108-111)