Chapter 12. Agile (Adaptive) Project Management

12.1 Introduction to Agile

In the 1980s and 1990s, software development teams started to have serious problems with developing and finishing their software projects, which were getting more complex with more computer power and digitalization of businesses and organizations[1]. Project managers and developers faced more problems using the traditional waterfall approach (Figure 12.1.3). The development of software necessitated more collaboration among the project manager, developers, testers, and users, as well as constant feedback from the users. Besides, new requirements were emerging while the software was being developed, and the client and end users were not always happy with the final product when they had the chance to see it after some time passed. Therefore, new methods emerged among software developers leading this type of project. The “Lean” methodology, created by Toyota for its production system and utilized by many manufacturers, inspired many software developers. In addition to the lean manufacturing process, the just-in-time process and total quality management movement were other influencers of agile project management[2]. Furthermore, Kanban, a process improvement method in manufacturing, was adapted to the software development life cycle.

As indicated above, new methods emerged in the 1980s, mostly in the 1990s, as a response to some of the challenges developers faced when using a waterfall approach. One of the first to become popular was Rapid Application Development (RAD). James Martin, an IT consultant, developed an approach through which he divided the process into four distinct phases, namely, (1) requirements planning phase, (2) user design phase, (3) construction phase, and (4) cutover phase[3]. It involved creating prototypes and using them to elicit requirements, validate designs, and evolve toward usable solutions (Figure 12.1.1). RAD itself led to the development of alternative approaches as well.

A diagram representing a four-phase process in a project lifecycle. The phases are depicted as boxes connected by arrows, moving sequentially:Requirements Planning (leftmost box): Includes "Agreed upon business needs, project scope, and system requirements." Connected to the next phase by an arrow labeled "Authorization." User Design (next box to the right): Features "Continuous interaction with users," "Build prototypes," and "JAD (Joint Application Development) meetings." Connected to the next phase by a bidirectional arrow. Construction (next box): Highlights "Develop and code" and "Testing." Connected to the next phase by an arrow. Cutover (rightmost box): Lists "Data conversion," "Final overall tests," "User training," and "System changeover." Includes a green box attached to it that says "Deploy the working product." The arrows show the progression and interaction between the phases.
Figure 12.1.1: Rapid Application Development (RAD)

[4]

There has been a diversification of agile methods, called lightweight methods, compared to the heavyweight waterfall models. The most popular methods were Crystal methods (1992), Dynamic Systems Development Model (DSDM) (1995), Scrum (1995), Feature Driven Development (FDD) (1997), Extreme Programming (XP) (1999), and Adaptive Software Development (ASD) (2000). Through the 1990s, several alternative ways to organize and structure the development of software products emerged, as mentioned above, and they eventually were nested under “Agile” in 2001 with the “Agile Manifesto.”

12.1.1 Agile Manifesto

17 people, the pioneers of agile methods, met in 2001 at Snowbird Ski Resort in Utah to talk, ski, relax, and try to find common ground between their thoughts on software development[5]. They represented the leading thinkers from XP, Scrum, DSDM, ASD, Crystal, FDD, Pragmatic Programming, and others who wanted a viable alternative to traditional heavyweight and documentation-driven development processes. They published the “Agile Manifesto” that embodied the values they all believed in and a set of guiding principles (Figure 12.1.2)[6]. Thus, the Agile Alliance was born[7].

The image presents the Manifesto for Agile Software Development, with a background of people in a collaborative discussion. The text at the top introduces the manifesto, stating:"We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:" Four core values are listed in bold, emphasizing the priorities of Agile principles: Individuals and interactions over processes and tools. Working software over comprehensive documentation. Customer collaboration over contract negotiation. Responding to change over following a plan. Below these values, a note clarifies: "That is, while there is value in the items on the right, we value the items on the left more." At the bottom, the names of the 17 authors who created the Agile Manifesto are listed: Kent Beck Mike Beedle Arie van Bennekum Alistair Cockburn Ward Cunningham Martin Fowler James Grenning Jim Highsmith Andrew Hunt Ron Jeffries Jon Kern Brian Marick Robert C. Martin Steve Mellor Ken Schwaber Jeff Sutherland Dave Thomas This image reflects the collaborative and foundational nature of Agile principles.
Figure 12.1.2: Agile Manifesto

Twelve Agile Principles behind the Agile Manifesto are listed below[8]:

  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-organizing teams.
  12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

12.1.2 Differences between Waterfall and Agile Methods

As shown in Figure 12.1.3, the process is linear and sequential in the waterfall (predictive, traditional) project management approach. Project teams should finish one stage to proceed with the following stage. As seen in Figure 12.1.4, the agile (adaptive) project management approach compresses the sequential phases in small timeboxes. Therefore, agile teams work on a limited number of requirements (i.e., user stories) at a time, and they can receive frequent stakeholder feedback at the end of each timebox when they create a partial working product.

The image depicts the traditional Waterfall Project Management model, represented as a linear sequence of steps cascading downwards, like a staircase. Each step in the process is contained in a rectangular box, linked by arrows pointing to the next step, showing the sequential flow of tasks. The steps are as follows:Eliciting requirements – Gathering and understanding the project requirements from stakeholders. Planning all the activities – Creating a detailed plan for project execution, including timelines, resources, and milestones. Designing the system – Developing the architecture and design of the system based on requirements. Building the system – Writing the code and constructing the system according to the design specifications. Testing the system – Verifying and validating the system to ensure it meets the specified requirements and functions as intended. Deploying the system – Delivering the completed system to users and integrating it into the operational environment. The figure emphasizes the rigid, non-iterative nature of the Waterfall model, where each phase must be completed before proceeding to the next.
Figure 12.1.3: Waterfall Project Management

 

The image illustrates the Agile Project Management model, highlighting its iterative and incremental approach to project development. The diagram is divided into three sequential cycles: First Cycle, Second Cycle, and Last Cycle, showing how work progresses in iterations.Each cycle follows the same steps, depicted in a flowchart format with rectangular boxes connected by arrows to indicate progression. The steps include: Requirements – Gathering and refining the requirements for the specific iteration. Plan – Planning the tasks and deliverables for the iteration based on the requirements. Design – Creating designs or prototypes for the features to be developed. Build – Developing and coding the increment. Test – Testing the increment to ensure quality and functionality. Deploy the Increment – Delivering the tested increment to stakeholders or the production environment. Between cycles, a red arrow indicates the transition from one iteration to the next, emphasizing continuous feedback and adaptation. This process repeats until the Last Cycle, which concludes the development with the final increment deployed. The figure highlights Agile’s focus on delivering small, functional increments at regular intervals, enabling flexibility and responsiveness to change.
Figure 12.1.4: Agile Project Management

The frequent interaction with the client and stakeholders offers an environment where the frustration level of stakeholders is minimized. Nevertheless, agile methods may not be appropriate for all projects. The waterfall project approach may work better when:

  • Requirements are very well understood and can be fixed before the implementation begins.
  • Expectations of clients or customers from the product are stable, and substantial changes can be avoided.
  • The stakeholders understand the technology and the tools utilized very well, and changes that may affect the project’s progress are not expected.
  • The duration of the project is relatively short.
  • The uncertainty is at a low level.
  • Resources are available and easy to acquire.

Therefore, we can implement a waterfall project when we expect low uncertainty and easily define the project scope, product scope, and project constraints with unambiguous procedures. The production domain and processes involved are usually well understood, and there are typically low levels of execution uncertainty and risk[9]. However, if we cannot define the product scope and the uncertainty level is high, an agile approach would be better to move gradually by clarifying the requirements and uncertainties with the active involvement of clients and stakeholders.

In agile projects, client and stakeholder involvement can be provided constantly since product owners are a part of the team, and the increments are reviewed by the product owner and the client frequently. In waterfall projects, the interaction with the client is deferred to the end of a phase, for instance, when the software coding and testing are complete. However, in real-life projects, teams often implement a hybrid approach, which blends the waterfall approach and some agile principles, such as client involvement and feedback.

Grocery LLC Decides on the Project Approach for the “Self-Checkout Stations Project”

As discussed in section 1.2, the grocery chain Grocery LLC is considering establishing self-checkout station areas in all fifty branches to find a solution to long lines in front of the current checkout stations where the cashiers work. The project selection committee discussed the solution and decided to implement this project. The business analysis team surveyed managers and employees and interviewed customers as part of requirements elicitation. Besides, the team visited the competitors’ markets and did market research to understand possible solutions in the market better. The team concluded that self-checkout has been increasingly deployed in many grocery store and pharmacy chains (e.g., Walmart, Target, CVS) across the United States, and the manufacturers and service providers are experienced. Therefore, the sponsor, project manager, and relevant departments met to discuss the project management approach. They decided to implement a waterfall approach supported by continuous stakeholder interaction, as with agile methods.

  • Managers, employees, and customers conveyed their requirements. The analysis revealed that requirements are consistent with the current implementations and the research consultancy company’s report. Therefore, it was concluded that requirements are very well understood and can be fixed to a large extent before the implementation begins. However, to keep up with technological advancements and to be prepared for risks such as new waves of pandemic, it was decided to establish a continuous interaction and feedback system with the stakeholders.
  • Experienced companies provide competitive prices to acquire systems. They have implemented numerous projects across the United States and have comprehensive knowledge of current and upcoming technologies.
  • The duration of the project is eight months.

 

Grocery LLC Decides on the Project Approach for the “M-Commerce Project”.

As discussed in section 1.2, the grocery chain Grocery LLC considers having a better online presence by creating a mobile app and optimizing the website for mobile devices in particular due to the negative effects of pandemic on the number of in-store customers, hence significantly decreased revenue and profit. In the initiation stage, the project manager prepared a report justifying the need for conducting an agile methodology, i.e., Scrum, during this project to accelerate the pace and achieve the outcome in a relatively shorter time, receive constant and timely feedback from the employees and customers, keep a healthy interaction with the stakeholders, and adjust the specifications to the fast and unprecedented changing technologies and socioeconomic conditions. Since it was not easy for the project manager and the team to oversee the near future in a turbulent environment (e.g., COVID cases and hospitalizations rocketing to the peak in a very short time), the sponsor and the project steering committee supported the project manager’s decision to implement an agile method. The Scrum cycles (sprints) were set as two weeks so that a working app and mobile website could be developed gradually with some of the requirements and functions at each sprint’s end, allowing frequent end-user feedback and interaction.

  1. Rothman, J. (2017). Create Your Successful Agile Project: Collaborate, Measure, Estimate, Deliver. Pragmatic Bookshelf. ↵
  2. Cobb, C. G. (2015). The project manager's guide to mastering Agile: Principles and practices for an adaptive approach. John Wiley & Sons. ↵
  3. Martin, J. (1991). Rapid application development. Macmillan Publishing Co., Inc. ↵
  4. Adapted from Martin, J. (1991). Rapid application development. Macmillan Publishing Co., Inc. ↵
  5. . Retrieved from https://agilemanifesto.org/history.html. ↵
  6. Retrieved from https://agilemanifesto.org/. ↵
  7. Visit https://www.agilealliance.org/ for more information. ↵
  8. Retrieved from https://agilemanifesto.org/principles.html. ↵
  9. Project Management Institute. (2017). Agile Practice Guide. Project Management Institute. ↵

License

Icon for the Creative Commons Attribution-NonCommercial 4.0 International License

Project Management, 2nd Edition by Abdullah Oguz, Ph.D., PMP® is licensed under a Creative Commons Attribution-NonCommercial 4.0 International License, except where otherwise noted.

Share This Book