Agile Auditing. Raven Catlin
Чтение книги онлайн.
Читать онлайн книгу Agile Auditing - Raven Catlin страница 17
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.
Scrum/Agile Roles
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.
Product Owner
The Product Owner owns 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).
Scrum Master
The Scrum Master owns 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.