Raven Catlin - Agile Auditing

A key concept under Scrum is that a project's time and cost are set early in the project and scope is modified as new information and client needs are determined.

A key concept under Scrum is that a project's time and cost are set early in the project and scope is modified as new information and client needs are determined. Applying this concept to the rugby Scrum, each game (or project) lasts 80 minutes – the time – and each half (or increment) is limited to 40 minutes – the time. [As a side note, there are even some who believe that the Scrum time itself should be limited, as long Scrums are a “waste of time and increase chances of player injuries.” Luckily in Scrum project management, the Scrum time is already limited to one to four weeks. One could say that by limiting the Scrum time in Agile/Scrum project management, we are reducing waste and risk to the organization.] The number of players on the field – the cost – is limited. The scope, or how many points the rugby team will score, and how they will actually maneuver to score points/goals are fluid during the game. Depending on the other team and the environment – this is usually the customer's role in a Scrum – the team adapts its scope and method during play. Additionally, depending on the strengths, weaknesses, and availabilities of the team members, the project scope and methods evolve throughout the game. Usually, the team that adapts the best, wins!

Ken Schwaber and Jeff Sutherland, co‐creators of The Scrum Guide: The Definitive Guide to Scrum: The Rules of the Game , updated the guide in November 2020. According to the co‐creators, “The 2020 version aimed to bring Scrum back to being a minimally sufficient framework by removing or softening prescriptive language” (Schwaber and Sutherland 2020). While developing our Agile auditing framework and writing this book, we refer to the 2017 version. However, although we have endeavored to incorporate the changes as reflected in the November 2020 update, you will notice references to both versions. This has no substantive effect on our framework; the essence of Scrum has not changed; Scrum is still Scrum. The latest update nonetheless makes Scrum more adaptable to all disciplines, not only software development, and continues to become more streamlined, lighter, and easier to understand. It is one team approach working together towards one Product Goal. As Jeff Sutherland says, “Scrum works best when it is fast, easy, and fun.” Following is a summary of the differences between the 2017 and 2020 versions (Scrum Guides.org2020):

The 2020 version aimed to bring Scrum back to being a minimally sufficient framework by removing or softening prescriptive language.

One Team, focused on one Product. There is just one Scrum Team focused on the same objective, with three different roles or sets of accountabilities: Project Owner, Scrum Master, and Developers (i.e., individuals performing the audit work). You will note that in this book we use the word “Roles” to denote the different team functions. However, within the Scrum Team, there are no subteams or hierarchies. It is a cohesive unit of professionals focused on one objective at a time, the Product Goal. The 2020 updated Scrum Guide no longer refers to roles but rather to “Team.”

A Product Goal. The 2020 Scrum Guide introduces the concept of a Product Goal to provide focus for the Scrum Team toward a larger valuable objective. A Product Goal provides focus for the Scrum Team toward a larger valuable objective. Each Sprint should bring the product closer to the overall Product Goal.

Sprint Goal, Definition of Done, and Product Goal. Previous Scrum Guides described Sprint Goal and Definition of Done without really giving them an identity. They were not quite Artifacts but were somewhat attached to Artifacts. With the addition of Product Goal, the 2020 version provides more clarity around this. Each of the three Artifacts now contain “commitments” to them. For the Product Backlog the commitment is the Product Goal, the Sprint Backlog commitment is the Sprint Goal, and the Increment commitment is the Definition of Done. They exist to bring transparency and focus toward the progress of each artifact.

Self‐managing over self‐organizing. The 2020 version emphasizes a self‐managing Scrum Team, choosing who, how, and what to work on.

Three Sprint Planning Topics. In addition to the Sprint Planning topics of “What” and “How,” the 2020 Scrum Guide places emphasis on a third topic, “Why,” referring to the Sprint Goal.

Overall simplification of language for a wider audience. The 2020 Scrum Guide has placed an emphasis on eliminating redundant and complex statements as well as removing any remaining inference to IT work (e.g., testing, system, design, requirement, etc.).

For the most part, the concepts listed in the summary of differences between the 2020 and 2017 Scrum Guide versions were already embedded in our Agile auditing framework. When they were not, efforts have been made to include the most current updates. We appreciate these changes as they simplify the job of implementing an Agile auditing framework, especially focusing on one goal and the removal of inferences to IT work. As auditors we can and will continue to strive for better communications and greater efficiencies eliminating redundant and complex language and minimizing the use of audit jargon in all of our communications.

Ken Schwaber and Jeff Sutherland identify three pillars of the Scrum framework that facilitate collaborative work environments (Schwaber and Sutherland 2020):

Transparency. When a Team Member says something is done, it is really done. Finished. No loose ends. Transparency enables inspection. Inspection without transparency is misleading and wasteful.

Inspection. A check on progress. An opportunity to identify problems and potential problems. Inspection enables adaptation. Inspection without adaptation is considered pointless. Scrum events are designed to provoke change.

Adaptation. Implementing changes based on inspection. A Scrum Team is expected to adapt the moment it learns anything new through inspection.

Additionally, there are five Scrum values (Scrum Alliance 2015). “These values give direction to the Scrum Team with regard to their work, actions, and behavior. The decisions that are made, the steps taken, and the way Scrum is used should reinforce these values, not diminish or undermine them… . When these values are embodied by the Scrum Team and the people they work with, the empirical Scrum pillars of transparency, inspection, and adaptation come to life building trust” (Schwaber and Sutherland 2020).

1 Commitment

2 Courage

3 Focus

4 Openness

5 Respect

The three pillars of the Scrum framework (transparency, inspection, adaptation) facilitate collaborative work environments and the five values (commitment, courage, focus, openness, respect) give direction to the Scrum Team with regard to their work, actions, and behavior. When these five values are embodied by the Scrum Team and the people they work with, the Scrum pillars of transparency, inspection, and adaptation come to life building trust.

(Schwaber and Sutherland 2020)

Each Team Member must demonstrate these pillars and values in the execution of their roles during the project.

In Scrum project management, there are only three recognized roles: one Scrum Master, one Product Owner, and various Developers. (The 2020 Scrum Guide explains that “Developer” does not mean software developers exclusively; it is intended to be an inclusive term. It refers to the members of the Scrum Team who are doing the work or developing the product. In this book we refer to a “Developer” as a “Delivery Team Member,” which we have found more acceptable and more in alignment with audit terminology.) Collectively, those serving in these three roles create the Agile team (the equivalent to a Scrum Team). The Agile team members are self‐organizing, to ensure the best complement of skills, knowledge, and capabilities, and self‐managing, to increase accountability and workability of the team without the need for a manager, or, worse, a micromanager. There are no subteams or hierarchies. The team is a cohesive unit of professionals focused on one objective at a time, the Product Goal. The Agile team has total authority on the exact approach to get their work done, estimate how long work will take, create their schedule, and manage their own time. The Agile team is small enough to remain nimble and large enough to complete significant work within a Sprint. Most Agile teams have three to nine members. The Agile team is accountable for all aspects of the work (Rigby, Sutherland, and Takeuchi 2016). Following is a brief description of each role.