Topical question from Chapter 15: Discuss agile project management and the differences between the traditional project management and agile project management.
Please be thorough and comprehensive in your response to this topical question. Your discussion post should be at least 500 words. Please be thorough and comprehensive in your response to this topical question.
Use a MINIMUM OF 3 AUTHORITATIVE RESOURCES ON YOUR REFERENCES LIST (one of which will be the textbook). USE PARENTHETICAL CITATIONS THROUGHOUT YOUR POST at the point at which you use materials (quoted or paraphrased) from your sources. Label your list of resources as the “References” list.
The proper Reference for the textbook for your References list:
Larson, E. W., & Gray, C. F. (2021). Project management: the managerial process. McGraw-Hill Education.
The correct parenthetical citation is: (Larson & Gray, 2021) for paraphrased materials or (Larson & Gray, 2021, p. 123) for a direct quote from a specific page.
MAIN RESOURCE:
When software products burst on the commercial scene in the 1980s, the traditional plan-driven management approach was applied to their development. This resulted in what is commonly referred to as the “waterfall” approach to software development. The waterfall method features a series of logical phases in which progress flows from one phase to the next until completion. The key assumption is that essential requirements can be defined up front so the software can be designed, built, tested, and released. Software projects are completed in a linear, plan-driven fashion, like any other project. People soon found that software projects were not like other projects and the results proved it. For example, the Standish group reported in 1995 that 31 percent of software projects are canceled each year and only 16 percent are completed on time and budget (The Standish Group International, 1995).
Frustrated by poor results, software engineers began to experiment with more flexible, “agile” approaches to managing software projects. Tensions arose between management who mandated the use of standard templates, and the waterfall method, and the project managers who saw it as a hindrance to their work. This tension is reflected in a story a project manager told the authors. She worked in the IT Department for a large, multinational, high-tech firm that had spent five years institutionalizing a set of project management policies and procedures. Despite their best efforts, her software projects consistently came in late with several cancellations. Her engineers complained that the schedules were unrealistic and requirements too unstable to commit to a plan. Out of desperation she started secretly using agile methods on software projects. Her teams began to not only meet but at times beat the project schedule. When top management confronted her for not conforming to procedure, she pointed to her recent success to defend being left alone. Ultimately top management couldn’t argue with success and she was allowed to expand her efforts. A grass roots revolution broke out within the software industry. Several key advocates for change formed the Agile Alliance and published the Agile Manifesto in 2001. The manifesto affirmed a radically different set of values than those being applied by management to projects they were working on: 1. Individuals and interactions over processes and tools. 2. Working software over comprehensive documentation. 3. Customer collaboration over contract negotiation. 4. Responding to change over following a plan.
These four values were expanded upon by a set of 12 guiding principles:
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
Welcome changing requirements, even late in development.
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
Businesspeople and developers must work together daily throughout the project.
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. Working software is the primary measure of progress. Agile processes promote sustainable development. Continuous attention to technical excellence and good design enhances agility. Simplicity—the art of maximizing the amount of work not done—is essential. The best architectures, requirements, and designs emerge from self-organizing teams. At regular intervals, the team reflects on how to become more effective, then turns and adjusts its behavior accordingly.
The manifesto is a testament for the socio-technical approach to project management. Notice how many of the values and principles relate to the people doing the work. They are a response to an overly controlling, technical approach to software development mandated by the waterfall approach that neither matches the needs of the programmers nor the reality of the work. Furthermore, the manifesto reflects a “mindset,” not an elaborate set of tools or procedures. This mindset reflects a culture that values collaboration, trust, embracing change, and customer satisfaction.
To put Agile PM in the proper context, let’s revisit the project uncertainty diagram (see Figure 15.2) introduced in Chapter 1. The key point is that traditional project management methods were developed to operate in the predictable zone where the scope is fairly well established and the technology is known. Agile lives in the unpredictable zone. It represents a fundamental shift away from the traditional, plan-driven approach by adopting a more experimental and adaptive approach to managing projects. Projects evolve, rather than are executed. Solutions are discovered, not implemented. Some of the differences between Agile PM and traditional project management are displayed in Table 15.1.