CHAPTER 1
Introduction
With the onset of personal computers in 1980s and becoming popular in 1990s, an urgent need to develop and implement software projects became a norm and a requirement. However, for many software developers and those who sought software programs, it is an unknown territory plagued with many unknowns and uncertainties. Neither the company seeking those services nor the project team members who were attempting to deliver those projects knew what processes to adapt for delivering requisite outcomes. Then, what persuaded organizations and software developers to run into this fast-paced situation of developing projects?
The following issues are addressed briefly in this chapter and with more details in the book.
1. Tell why organizations have turned to agile as a method of planning and managing their projects
2. Briefly describe major differences between plan-driven (traditional) and agile project management
3. Describe why agile is sometimes a more useful approach
4. Briefly define what be agile and do agile mean
The answer is simple. Personal computers and their applications presented many opportunities to improve productivity and generated many business opportunities to offer new products and services worldwide. Computerization attracted every industryâmanufacturing, production, engineering, health care, research and development, service sectorâand the like, you name it! Everyone was eager to adapt this technology, and you will find an enthusiastic customer for all these projects.
Further, the global economy and free market philosophy are compelling drastic changes in global competition with corresponding higher expectations from customers. These challenges and fluid situations demand agility. Agility is the ability to move quickly and easily responding to changing customer desires. An agile approach is a necessity, not an option. Obviously, this approach is necessary to manage projects, as some of the traditional approaches, designed for stable work culture, may not work. Creative and imaginative efforts of many led to the development of new approaches. Many of these fall under a broad umbrella called agile. Many projects in the current economy face a fluid situation and uncertainty that demands agility.
With so many playersâcustomer organizations and software development companiesâinvolved in rapid development of new applications and services, new inventions were emerging at a rapid pace. Obviously, change was becoming a norm; requirements for many projects were changing routinely. Some projects were canceling altogether, as their intended outcomes were becoming obsolete even before the delivery, as customers were redefining project objectives to catch up with competitors and market demand. Business was moving at fast pace. Consequently, traditional project management methods were set aside, as they mismatched the demands of these new projects. These projects were often referred to as application development by crisis. These hazy circumstances led to thinking of agility in planning and executing projects.
Around the same time, with the advent of information technology and its applications, business and customers alike were expecting products and services faster, better, and cheaper. Further, the information technology sector facilitated this change in mindset by explosion of information sharing and expansion of the market globally. A major change was also occurring in the IT worldâwhich is data management. Large subject databases were being implemented to manage data as a corporate asset. This meant that applications no longer had to create all their own data and manage it. Applications could now tap into high-quality data sources quickly. Therefore, the speed at which applications could be developed increased dramatically. People and organizations liked this opportunity and placed higher demands for quality products and services at an affordable rate. All these changes left no option for project managers but to consider agility in project planning and execution.
Traditional project management methods and tools were developed during the period prior to information age that was less chaotic. Project management, as a formal discipline, began in early 1950s, and proponents of the systemic approach developed traditional project management methodology. After the agile approach is developed, this traditional approach is often referred to as waterfall methodology and justifiably so. In this traditional or waterfall method, a project usually transitions from one phase to the next phase sequentially and usually after the previous phase is completed. For example, one must understand all the requirements that identify exclusions, inclusions, assumptions, specifications, and constraints associated with the project deliverable, and then the scope of a project is defined. Without scope definition, project plan activities cannot be initiated, and without developing a comprehensive project plan, we cannot move forward to the project execution phase. This traditional approach is systematic, logical, and makes sense when technology and engineering associated with these projects have been steady and changes are gradual. However, it is not true with information technology, which is changing by leaps and bounds.
Specifically, software development projects are faced with rapid and constant growth of technology and associated changes in customer demands. Clients often do not know what they want in a new system or product, and younger workers chafe at old command and control restrictions. At the best, a customer can explain the work process and flow (context of the project) and the desired functional outcomes expected from the project. In many cases, the software development effort takes a trial-and-error approach to identify features and use quality tests to ensure customer satisfaction. The critical challenge is to translate a need or requirement into a specification, which is not easy in this case. This is one of the main reasons why an agile approach is justified. Other reasons for employing agile methods are ambiguous and changing requirements of the project and compelling forces of global economy to deliver products and services faster, better, and cheaper.
In addition to the nature of changes to the projects and global economy, the U.S. government also permitted an iterative process of project planning and execution in 1990s. An iterative process is a method to plan the entire project at only a high level at the start and plan portions to be done soon in detail, updating plans as more becomes known. This was one of the main reasons why iterative project planning processes gained popularity, and one can see the number of applications. The agile (aka change-driven) methodology is a project method using iterative and continual processes and is guided by agile mindset described in the Agile Manifesto and elaborated by many sources. Agile found its acceptance among the project management professionals and in the corporate world.
The first agile method that became popular was scrum in 1990s. When developing new and complex products, the project team will be informed of the project objectives, and the team will have autonomy of actions to deliver these objectives. Subsequently, many other variations of the agile approach have evolved. One of the main purposes of this book is to identify concepts that various agile approaches advocate and assemble them into simple, but a comprehensive system. It is our intent to identify the most common and most useful agile mindset ideas and methods regardless of the approach, group them logically, and explain how to use them effectively.
When and Why Agile Should Be Used
One of the compelling reasons for the use of an agile method is the difficulty associated with defining requirements of a project. A requirement âis a condition or capability needed by a user to solve a problem or achieve an objective that satisfies a standard, a specification, or any other formally documented needâ (Kloppenborg, Anantatmula and Wells 2018; p. 212). Further, a requirement should unambiguous, complete, usable, and verifiable. Requirement definition and conditions associated with it cannot easily be defined in ...