Agile Auditing. Raven CatlinЧитать онлайн книгу.
four Agile Manifesto values set the basis for 12 principles as follows (Agile Alliance 2001):
1 Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
2 Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
3 Deliver working software frequently, from a couple of weeks to a couple of months, with a preference for the shorter timescale.
4 Business people and developers must work together daily throughout the project.
5 Build projects around motivated individuals. Give them the environment and support they need and trust them to get the job done.
6 The most efficient and effective method of conveying information to and within a development team is face‐to‐face conversation.
7 Working software is the primary measure of progress.
8 Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
9 Continuous attention to technical excellence and good design enhances agility.
10 Simplicity – the art of maximizing the amount of work not done – is essential.
11 The best architectures, requirements, and designs emerge from self‐managing teams.
12 At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
The values and principles discussed earlier in this chapter are essential ingredients of the Agile mindset and set the foundation of Agile frameworks.
AGILE FRAMEWORKS
Many Agile enthusiasts consider Agile to be an umbrella for other types of rapid development and delivery options that foster collaboration among cross‐functional teams as depicted in Figure 1.1. Agile software development advocates adaptive planning, evolutionary development, early delivery, and continual improvement, and it encourages flexible responses to change (Agile Alliance 2001). When Agile was born in 2001, other methods to achieve faster development were already in existence, including the following (note, parenthesis in each bullet indicates the creation year and the creator's last name):
FIGURE 1.1 Agile Umbrella
Source:Illustration by Carmen Catlin.
Scrum (1986, Takeuchi and Nonaka [concept]; 1995, Schwaber and Sutherland)
Extreme Programing (XP) (1996, Beck)
Kanban (1953, Toyota)
Rational Unified Process (RUP) (1987, Jacobson [concept]; 1996, Kruchten/IBM)
Crystal (1996, Cockburn)
Dynamic Systems Development Methodology (1995, DSDM Consortium)
Feature Driven Development (FDD) (1997, De Luca)
Rapid application development (1991, Martin)
Adaptive software development (1974, Edmonds [concept]; 1995, Highsmith and Bayer)
After the 2001 Agile Manifesto, Lean software development was introduced in 2003 by Harry and Tom Poppendieck. We discuss Lean auditing principles in Chapter 13, Lean and Agile Auditing. There are several Agile certifications available to demonstrate your competency with the various frameworks. While each of these methods is distinct, they all require constant communication and team collaboration. The following is a brief, high‐level description of some of these methods:
Scrum is a timebound Agile method where each task or activity is limited by a specified duration. Scrum is the most popular framework; we discuss it in more detail later in this chapter.
XP focuses on developing high‐quality software in a short period of time based on customer participation, rapid feedback, and subsequent planning and testing. It leverages four values: courage, simplicity, feedback, and communication.
Kanban focuses on productivity and flow when there are no “features” released to a customer. It works well for small teams and is typically used in manufacturing processes. Kanban is not time‐sensitive.
Crystal is a collection of Agile methodologies and recognizes that any project may need a unique set of practices. It focuses on early and regular product delivery by increasing user participation and eliminating bureaucracy, while reinforcing the need for communication, teamwork, and simplicity.
DSDM emphasizes business needs, active user participants, team empowerment, and constant delivery. Requirements are determined early in the project and refined as the project progresses.
In many projects, including those using Agile methods, effective communication often determines the success of the project. Each Agile method reinforces the importance of communication and most include more frequent meetings, such as daily meetings for Agile teams to coordinate activities. The daily meeting is a unique element of Agile project management for delivering results faster, correcting errors sooner, inspecting the project often, and overcoming obstacles before the obstacles become bottlenecks.
Raven's first introduction to the daily meeting was during a financial restatement project led by the chief administrative officer (CAO). To make sure participants didn't “get comfortable and talk too much,” the CAO literally removed all the chairs from the room. Each Team Member simply and quickly stated the completed activities from the previous day, the planned activities for that day, and identified any obstacles preventing moving forward with the project. We never skipped a daily meeting, someone was always present to discuss the work performed for each team, and it exceeded 15 minutes on only one occasion. In retrospect, the meeting was a Scrum of Scrums. A Scrum of Scrums is an Agile technique that integrates the work of multiple Scrum Teams. When there are many individuals in the team they are divided into smaller groups (usually five to nine members each), working on the same project. It allows the teams to communicate with each other to ensure that they are all working to accomplish the Product Goal. The output of each team is integrated with the output of all teams. This is vital in areas where there could be overlap or the sequencing of events is important. Ceciliana's first attempt to introduce the daily meetings and remove the chairs from the conference room during a project she was leading resulted in the participants becoming upset because they were going to have to limit the time they could speak and standing was not their preferred posture. After explaining that the reason for removing the chairs was to ensure a focused and speedy meeting, the team compromised, and the chairs were returned on a condition of brevity. This is a great “lessons learned” example regarding the importance of clear and timely communications. In this case, even after allowing chairs in the meeting, meeting time was reduced from approximately two hours to 30 minutes, on average, and communications were limited to actions needed to complete the project. In both examples, the daily meeting was essential in timely project completion and is thus one technique you can use today to be Agile.
There was one specific meeting that solidified the daily meeting's value for Raven, which is the main reason we adopted the daily meeting in our Agile framework. Something was said during one of the meetings that could have changed the successful outcome of the restatement project and would have undoubtedly led to bottlenecks to complete the restatement effort. A team leader presented the accounting manager's obstacle – the need to approve thousands of manual journal entries in a very short time frame. Another team lead suggested that the approval was “easy, just select all and click approve.”