{"id":365,"date":"2022-08-18T12:49:52","date_gmt":"2022-08-18T12:49:52","guid":{"rendered":"https:\/\/pressbooks.ulib.csuohio.edu\/projectmanagement2ndedition\/chapter\/12-1-introduction-to-agile\/"},"modified":"2025-01-12T04:36:54","modified_gmt":"2025-01-12T04:36:54","slug":"12-1-introduction-to-agile","status":"publish","type":"chapter","link":"https:\/\/pressbooks.ulib.csuohio.edu\/projectmanagement2ndedition\/chapter\/12-1-introduction-to-agile\/","title":{"rendered":"12.1 Introduction to Agile"},"content":{"raw":"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[footnote]Rothman, J. (2017). Create Your Successful Agile Project: Collaborate, Measure, Estimate, Deliver. Pragmatic Bookshelf.[\/footnote]. 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[footnote]Cobb, C. G. (2015). The project manager's guide to mastering Agile: Principles and practices for an adaptive approach. John Wiley & Sons.[\/footnote]. Furthermore, Kanban, a process improvement method in manufacturing, was adapted to the software development life cycle.\r\n\r\nAs 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[footnote]Martin, J. (1991). Rapid application development. Macmillan Publishing Co., Inc.[\/footnote]. 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.\r\n\r\n[caption id=\"attachment_361\" align=\"aligncenter\" width=\"976\"]\"A<\/a> Figure 12.1.1: Rapid Application Development (RAD)[\/caption]\r\n

[footnote]Adapted from Martin, J. (1991). Rapid application development. Macmillan Publishing Co., Inc.[\/footnote]<\/p>\r\nThere 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 \u201cAgile\u201d in 2001 with the \u201cAgile Manifesto.\u201d\r\n

12.1.1 <\/strong>Agile Manifesto<\/strong><\/h2>\r\n17 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[footnote]. Retrieved from https:\/\/agilemanifesto.org\/history.html<\/a>.<\/span>[\/footnote]. 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 \u201cAgile Manifesto\u201d that embodied the values they all believed in and a set of guiding principles (Figure 12.1.2)[footnote]Retrieved from https:\/\/agilemanifesto.org\/<\/a>.[\/footnote]. Thus, the Agile Alliance was born[footnote]Visit https:\/\/www.agilealliance.org\/<\/a> for more information.[\/footnote].\r\n\r\n[caption id=\"attachment_626\" align=\"aligncenter\" width=\"835\"]\"The<\/a> Figure 12.1.2: Agile Manifesto[\/caption]\r\n\r\nTwelve Agile Principles behind the Agile Manifesto are listed below[footnote]Retrieved from https:\/\/agilemanifesto.org\/principles.html<\/a>.[\/footnote]:\r\n
    \r\n \t
  1. Our highest priority is to satisfy the customer<\/strong><\/span> through early<\/strong><\/span> and continuous<\/strong> delivery<\/strong><\/span> of valuable software<\/strong><\/span>.<\/li>\r\n \t
  2. Welcome changing requirements<\/strong><\/span>, even late in development. Agile processes harness change for the customer\u2019s competitive advantage.<\/li>\r\n \t
  3. Deliver working software<\/strong> frequently<\/strong><\/span>, from a couple of weeks to a couple of months, with a preference for the shorter timescale.<\/li>\r\n \t
  4. Business<\/strong><\/span> people and developers<\/strong><\/span> must work together<\/strong> daily<\/strong><\/span> throughout the project.<\/li>\r\n \t
  5. Build projects around motivated<\/strong><\/span> individuals. Give them the environment<\/strong><\/span> and support<\/strong><\/span> they need, and trust<\/strong> them to get the job done.<\/li>\r\n \t
  6. The most efficient and effective method of conveying information<\/strong><\/span> to and within a development team is face-to-face conversation<\/strong><\/span>.<\/li>\r\n \t
  7. Working software <\/strong><\/span>is the primary measure of progress<\/strong><\/span>.<\/li>\r\n \t
  8. Agile processes promote sustainable development<\/strong><\/span>. The sponsors, developers and users should be able to maintain a constant pace <\/strong>indefinitely.<\/li>\r\n \t
  9. Continuous attention<\/strong><\/span> to technical excellence<\/strong><\/span> and good design<\/strong><\/span> enhances agility.<\/li>\r\n \t
  10. Simplicity<\/strong> <\/span>\u2013 the art of maximizing the amount of work not done \u2013 is essential.<\/li>\r\n \t
  11. The best architectures, requirements and designs, emerge from self-organizing teams<\/strong><\/span>.<\/li>\r\n \t
  12. At regular intervals<\/strong><\/span>, the team reflects<\/strong><\/span> on how to become more effective, then tunes and adjusts <\/strong><\/span>its behavior<\/strong><\/span> accordingly.<\/li>\r\n<\/ol>\r\n

    12.1.2 <\/strong>Differences between Waterfall and Agile Methods<\/strong><\/h2>\r\nAs 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.\r\n\r\n[caption id=\"attachment_363\" align=\"aligncenter\" width=\"979\"]\"The Figure 12.1.3: Waterfall Project Management[\/caption]\r\n\r\n \r\n\r\n[caption id=\"attachment_364\" align=\"aligncenter\" width=\"979\"]\"The Figure 12.1.4: Agile Project Management[\/caption]\r\n\r\nThe 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:\r\n