Raven Catlin - Agile Auditing

The Product Ownerowns the “what” of the project. They create a prioritized list of all the things to need to get done ( Product Backlog). The Product Owner maximizes the value of the product being delivered (the audit). The Product Owner determines the priorities for Agile teams and decides when a product is complete by assessing value from the customer's perspective. In some Agile variants, the Product Owner is referred to as the “initiative owner” (Rigby, Sutherland, and Takeuchi 2016). The Product Owner is not typically the customer, but someone who represents the customer's interest, voice, and mindset during the project. The Product Owner must have the Agile mindset; this is a critical role. Agile Teams cannot select just any manager to serve as the Product Owner in the same way managers are currently selected to manage traditional teams and projects. Even if one is a highly competent manager, that does not mean they have the right mindset and skills to be a successful Product Owner. Choosing the right Product Owner is as important as selecting an Agile framework. In the words of J.J. Sutherland, “if you keep doing things the way you have always done you will get the results you always got before. Good Product Owners are the key to winning with Scrum” (Sutherland 2019).

The Product Owner must understand the customer and the customer's needs. The Product Owner owns the Product Backlog (also known as a “portfolio backlog”), which is a list of requirements and deliverables for a project. The Product Owner works directly with the business community, stakeholders, customers, and users to obtain an understanding of the community and user needs. “For Product Owners to succeed, the entire organization must respect their decisions. These decisions are visible in the content and ordering of the Product Backlog, and through the inspectable Increment at the Sprint Review” (Schwaber and Sutherland 2020). The Product Owner prioritizes the Product Backlog list (see Chapter 8, Implementing Agile Auditing: The Audit Planning Process for more details on Product Backlogs).

The Scrum Masterowns the process and is held accountable for enhancing team performance. The 2020 update to the Scrum Guide elevates the role of the Scrum Master from a servant leader to that of a true leader who serves the Scrum Team and the larger organization (Schwaber and Sutherland 2020). In the 2020 Guide, the switching around of the words from a “servant leader” to “a leader who serves” is intended to recognize that the Scrum Master helps focus on the leadership role of the Scrum Master to help achieve the project goals. The Scrum Master is accountable for the Scrum Team's effectiveness by enabling the Scrum Team to improve its practices, within the Scrum framework. Nonetheless, the Scrum Master is not a boss, a project manager, or a decision‐maker. The Scrum Master is a coach, facilitator, and an Agile champion. The Scrum Master is accountable for the Agile team happiness and why this is important. They remind the Agile team members of the benefits and value of the Agile approach whenever needed and encourage the right behaviors from the team members. For example, the Scrum Master may remind team members to be honest and transparent in their communications. The Scrum Master facilitates all meetings, including daily meetings. They coach the Agile team members in self‐management and cross‐functionality; help the team focus on creating high‐value increments that meet the Definition of Done; and facilitate the removal of impediments or roadblocks and obstacles to help the team progress and remain efficient in completing Sprints, ensuring that all Scrum events take place and are positive, productive, and kept within the timebox. A Sprintis a short, timebound cycle within which team members complete an increment of work to deliver products the customer needs based on whatever is most important to the customer at the time.

The Delivery TeamMembers own the “how.” They complete product tasks during Sprints. They are the individuals in the Agile team who are committed to creating any aspect of a usable Increment in each Sprint. They create a Sprint Backlog, a specific, focused list of tasks determined by the Delivery Team to complete an increment that guides their Sprint/increment work. An increment is a product deliverable, usually a small portion of the overall product. The Sprint Backlog is a specific, focused list of tasks determined by the Delivery Team Members to complete an increment. The 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. They are a cross‐functional, self‐managing group of autonomous individuals collectively possessing all the skills necessary to complete the Sprint backlog. In Scrum, Developers can be business developers, user experience researchers, customer experience specialists, mechanical engineers, lab technicians, doctors, nurses, carpenters, marketers, researchers, scientists, quality assurance specialists, and more.

We will review these roles, responsibilities, and options throughout the book. In Chapter 7, Implementing Agile Auditing: Deciding Your Approach and Your Agile Audit Project Roles, we will address the different roles of Product Backlog in an auditing context. In Chapter 9, Implementing Agile Auditing: Planning Agile Audit Engagements, we will apply Scrum concepts in an audit context, including the Product Owner, Scrum Master, Delivery Team, documents, and activities. Remember, Agile and Scrum are frameworks, and adaptations are expected; some Scrum implementations include additional roles.

Scrum Artifacts represent work value. Following are the three Artifacts, or documents, created in the Scrum framework (Sutherland and Sutherland 2014). Each of the three Scrum Artifacts has a corresponding commitment to drive focus and alignment. This commitment gives the teams a much better focus on the specific goals. The Artifacts are:

1 Product Backlog (see Chapter 8, Implementing Agile Auditing: The Audit Planning Process). The Product Backlog is a list of requirements and features for a project that is managed by the Product Owner in order of business priority. Product Backlogs include estimates on business value and development efforts. The commitment for Product Backlog is Product Goal.

2 Sprint Backlog (see Chapter 9, Implementing Agile Auditing: Planning Agile Audit Engagements). The Sprint Backlog is a specific, focused list of tasks the Delivery Team believes it can complete in a Sprint. It is created by the team members, using a pull approach to complete an increment. Contrasted with a push approach, where an input is pushed into a cycle in hopes that it can be used as it is pushed, or can wait until it is needed, a pull approach pulls inputs into the process or production line on demand, as needed. The push approach may result in excessive production and unused work, while the pull approach is quick and efficient. The commitment for Spring Backlog is Sprint Goal.

3 Increment. An increment is production output at the end of a timeboxed Sprint. The commitment for increment is the Definition of Done.

We acknowledge that some Scrum adaptations include up to six Artifacts, or documents. However, creating more Artifacts that do not add value or that are otherwise created simply for the sake of creating more Artifacts does not align with the Agile Manifesto value of “more working software, less documentation.”