Читать книгу Agile Auditing - Raven Catlin - Страница 20

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.” Talk about correcting project errors sooner! Needless to say, the CAO took immediate notice of the obstacle and the potential risk and implemented corrective actions and safeguards against such behaviors and mindsets. One corrective action included adding additional journal entry approvers. As a result, accounting managers ceased the “select all and click approve” approach to approve manual journal entries. Additionally, the auditors monitored to ensure that this behavior did not recur by using the accounting system's embedded audit module. The auditors created a rule to alert them if one accounting manager, or any person with approval privileges, approved a certain number of manual journal entries within a limited time frame. If it weren't for the daily meeting to identify obstacles, there is a high probability that the two team leaders may have had a hallway conversation about the obstacle that week and the solution would have been “select all and click approve.” To a control fanatic, this is obviously the wrong solution. We found so much value in the daily meeting on that project that we started using it in other projects, not realizing at the time that it was an Agile technique.