Preview Extract
Chapter 16 Introduction to Agile Project Management Chapter Outline 1. Traditional versus Agile methods 2. Agile PM 3. Agile PM in Action: Scrum A. Roles and Responsibilities i. Product Owner ii. Development Team iii. Scrum Master (aka Project Manager) B. Scrum Meetings i. Release Planning ii. Sprint Planning iii. Daily Scrum iv. Sprint Review v. Sprint Retrospective C. Product and Sprint Backlog D. Sprint and Release Burndown Charts 4. Applying Agile PM to Large Projects 5. Limitations and Concerns 6. Summary 7. Key Terms 8. Review Questions 9. Exercises 10. Case 16.1: Introducing Scrum at P2P Chapter Learning Objectives After reading this chapter you should be able to: LO 15- Recognize the conditions in which traditional project management versus agile project management should be used. LO 15- Understand the value of incremental, iterative development for creating new products. LO 15- Identify core Agile principles. LO 15- Understand the basic methodology used in Scrum. LO 15- Recognize the limitations of Agile project management. Review Questions 1. Why is the traditional project management approach less effective when project scope and technology are not well known? The traditional project management approach relies heavily on up-front planning. The rationale is that if you plan, execute the plan, and take corrective action the project will be successful. Planning requires a reasonable degree of predictability both in terms of project scope and technology. If you don’t know what you are trying to achieve or how to achieve it then it is impossible to come up with a detailed plan to manage the project. The plan would constantly have to be reformulated as questions regarding scope and technology become resolved. 2. What is iterative incremental development? Why is it useful for developing new products? The scope of the project evolves over time through a series of incremental iterations. Each iteration is a mini-project with the goal of creating workable product which satisfies one or more product features. At the end of each iteration the product is demonstrated to various stakeholders and adjustments are made. Each new iteration assumes the work of previous iterations and adds new capabilities to the evolving product. Three important advantages of IID have for creating new products are: Continuous integration, verification, and validation of the evolving product. Frequent demonstration of progress which increases the likelihood that the end product will satisfy customer needs. Early detection of defects and problems. 3. What are the advantages of Agile PM? What are the disadvantages of Agile PM? The key advantage of Agile PM is that it is a flexible, adaptive approach for completing projects with high levels of uncertainty. It simply works better for these kinds of projects than traditional PM. Specific advantages include those mentioned under IID as well as: Work is divided into smaller and smaller chunks that are more easily scheduled and controlled. Collaboration between the customer and design is increased leading to solid change control. Methods demand that features be tested and functional when completed. At first glance the disadvantages of Agile PM are readily apparent for predictable projects in which the scope and technology are well defined. Here flexibility can lead to excessive scope creep and costly delays. Other disadvantages include: It is difficult to apply Agile PM on large, complex projects involving many groups of professionals. (It should be noted that this is likely to be true for any project management approach.) Agile PM does not provide firm schedules and cost estimates. Agile PM is incongruent with many organizational cultures. Agile PM may suffer from inadequate customer involvement. 4. What similarities and differences exist between a traditional project manager and a Scrum master? Differences between the traditional project manager (PM) and Scrum master (SM) are pronounced. The SM role is limited to making sure that rules are adhered to and serving as a coach helping the development team solve problems. The PM role on a project is much more dominant. The PM formulates the project plan, and typically has direct authority over the work being accomplished. The PM is responsible for making trade-off decisions between time, cost, and scope as well as taking corrective action with progress deviates from the plan. It should be noted that many of traditional responsibilities of a PM such as representing the interests of the customer, prioritizing deliverables, and making cost/scope trade-offs are the responsibility of the Product Manager in Scrum. Similarities are less discernable. One would be that both SM and PM are to buffer the project team from external distractions. 5. What are the differences between a self-organizing team and a conventional project team? Both kinds of teams share a common goal and rely on collaboration to accomplish the project. The major difference is that in a traditional project team the project manager is responsible for planning, managing, and controlling work. In a self-organizing team, the members are collectively responsible for managing their own work as well problem solving and continuous improvement. The team not the manager decides amongst themselves what needs to be done and who should do it. 6. Why is it difficult to apply Agile PM to large-scale projects? Large scale projects require formal coordination mechanisms to direct and integrate the efforts of multiple teams. Mechanisms like detailed documentation, meetings, and central planning undermine the informal processes that Agile PM relies on to complete projects. Exercises 1. Break into small groups and identify at least two real-life examples of projects in which: The scope and technology are well known. The scope is well known but the technology is less well known. The scope is not well known but the technology is known. Neither the scope nor the technology is well known. Sure, here are real-life examples for each scenario: a. Scope and technology are well known: • Example: Construction of a high-rise building using traditional construction methods and materials. • Explanation: The scope of the project (construction of a high-rise building) and the technology (traditional construction methods and materials) are well established and widely used. b. Scope is well known but the technology is less well known: • Example: Implementation of blockchain technology in supply chain management. • Explanation: While the scope of the project (implementing blockchain in supply chain management) is well known, blockchain technology is relatively new and less well known, requiring specialized knowledge and expertise. c. Scope is not well known but the technology is known: • Example: Research and development of a new type of renewable energy technology. • Explanation: While the technology (renewable energy) is known, the specific scope of the project (developing a new type of renewable energy technology) may not be well defined at the outset and may require significant research and experimentation. d. Neither the scope nor the technology is well known: • Example: Exploratory space missions to study newly discovered celestial bodies. • Explanation: In exploratory space missions, the scope of the project (studying newly discovered celestial bodies) and the technology required (space exploration technology) may not be well known or fully understood at the outset, requiring significant research and development. These examples demonstrate different scenarios where the scope and technology of a project may vary in terms of their level of familiarity and complexity. 2. Break into small groups and discuss the following question: What organizational, group, individual, and project factors do you think would promote the successful adoption of Agile PM methodologies like Scrum? Why? Organization An organization with a history of poor project performance so that there is a high felt need for change. An organization in which top management does not demand firm schedules and budgets which Agile PM cannot provide. An organization in which management is comfortable relinquishing control and empowering development teams to manage themselves. Group A mature team, capable of self-management. A group that shares a common goal and a strong commitment to excellence. A group that values transparency, and the open sharing of good and bad news. Individual An individual who has a reasonably high tolerance for uncertainty. An individual who excels with autonomy. An individual with high level of self-discipline and a commitment to learning. Project A project with high degree of uncertainty regarding either scope and/or technology. A project that can be easily chunked into small pieces/features. A project in which customer interests can easily be represented. A project which can be done by a small project team. 3. Use a project you are currently working on to hold a Scrum meeting according to the steps outlined in Figure 16.5. Designate one member to act as the Scrum master and hold a standing meeting that lasts no longer than 15 minutes. Assess the value of such meetings. As the Scrum master for our project, I called for a Scrum meeting to discuss our progress and any potential obstacles. Here's how the meeting went: Scrum Meeting Agenda: 1. Quick updates (5 minutes): • Each team member gave a brief update on what they accomplished yesterday, what they plan to do today, and any obstacles they encountered. • John: "Yesterday, I completed the frontend design for the login page. Today, I'll start working on the user authentication functionality. No obstacles." • Sarah: "Yesterday, I finalized the database schema. Today, I'll begin coding the backend API. No obstacles." • Emma: "Yesterday, I conducted user research. Today, I'll analyze the feedback and start updating the UI design. No obstacles." 2. Identifying obstacles (5 minutes): • We discussed any obstacles or challenges that team members were facing. • John mentioned that he needed clarification on the authentication requirements, so we scheduled a quick meeting after the Scrum to address his questions. 3. Planning for the day (5 minutes): • We discussed our priorities for the day and made sure everyone was clear on what they needed to accomplish. • We decided to hold a design review session later in the afternoon to ensure that the frontend and backend components were aligned. Assessment of the value of the Scrum meeting: The Scrum meeting was highly valuable for our team for several reasons: 1. Improved communication: The meeting provided an opportunity for team members to share updates, identify obstacles, and plan for the day. This improved communication helped ensure that everyone was on the same page and working towards the same goals. 2. Increased accountability: By publicly stating our daily goals and progress, team members felt a greater sense of accountability and were more motivated to stay on track. 3. Quick problem-solving: The meeting allowed us to quickly identify any obstacles or challenges and address them in a timely manner. For example, John was able to get the clarification he needed on the authentication requirements, which prevented any delays in his work. 4. Better coordination: By discussing our priorities for the day, we were able to coordinate our efforts more effectively and ensure that we were making progress towards our project goals. Overall, the Scrum meeting was an invaluable tool for our team, helping us stay organized, focused, and productive. 4. Below are four mini-cases from practice. Break into small groups and (1) analyze the case and (2) provide five recommendations for the IT department. (Due to space considerations, only the first paragraph of each case is shown.) These mini-cases are based on actual scenarios in which Agile PM was being used. They serve as good discussion exercises to demonstrate some of the types of issues and problems encountered in Agile projects. What actually happened is provided. Project A You’ve just taken over a project from another project manager and have come back from a very uncomfortable meeting with your business sponsor. In the meeting, the sponsor told you how dissatisfied he is with the project’s performance to date and that he’s getting ready to pull the plug on the project entirely. Deadlines keep slipping, the application isn’t complete, and the sponsor feels like he can’t get in touch with anyone to give him an update on the project’s status and progress. Sample participant analysis comments: No communication plan for stakeholders—especially sponsor. Make one. Get requirement issue taken care of. Complete and set requirements again. Once set, have sponsor prioritize requirements. Seems as though team is working on things they are interested in. With requirements prioritized, team will have guidance on scheduling their tasks. When sponsor sets priorities, have team quickly demonstrate functionality of a few new features to gain sponsor’s confidence. Since project is time imposed, will scope have to be reduced? Resources added? What Actually Happened The new PM instituted a more robust, consistent communication strategy that kept the business sponsor informed about the project’s progress and status. He also arranged for an immediate demonstration of the application to the business, with a focus on the parts of the project where requirements had not been fully defined. The outcome of that meeting was a list of scope still to be completed. The conversation with the business sponsor turned to a look at the schedule remaining against that scope and together, they prioritized the list of scope, which the project team then worked toward. As the project team completed the scope, the PM and the business sponsor met regularly to walk through the application and confirm that the direction was correct. The business sponsor ultimately accepted the application on schedule, and began discussions for enhancements. Impact to CSP Cost on the project rose, because the new PM spent more time working on the project than the previous one did. Performance went down, because less scope than originally anticipated was actually completed. Schedule was maintained, because that was set outside the PM’s control. Project B Your project team has finished gathering the requirements and developing the solution design. Your team is broken into two main groups: The first group consists of the project manager, business analysts, and management and is located in the United States. The second group consists of the development and QA teams and they are located in India. Sample participant analysis comments: Too many projects are date driven. This is a perfect example. Real work being done in India. PM in US. Project manager needs to go to India and work with team to reset project scope, process, and schedule. Coordinate with US on new conditions for project. Given the problems, cost will go up unless scope is compromised. Project status indicates a problem—daily updates differ from monthly. Decide on design approach before going forward. Why was it changed? Setup revised WBS with estimated costs. Revise schedule. Report status against milestones, costs, and actual. Is there any give for trading off time and cost or scope? Clarify. What Actually Happened The management team decided that the best approach would be for the PM to go to India to manage the development team directly. Once the PM spent time with the development team listening to their concerns he found out that they understood that the expectations were to deliver the project at all costs, which meant not to bother management with any issues they were facing or any roadblocks they encountered. This resulted in the team struggling to make decisions on their own to meet the milestones, which took them off track. After further examination, the PM decided it was too late for the team to revert back to the original design without impacting the delivery of the project. Therefore, the changes in the design were communicated to the stakeholders and a new agreement was established to allow the team to move forward with the design approach they chose. In addition, expectations were set that as important it is to meet the deadline, it was more important for the team to report issues and concerns they might have about the progress of the project. The PM spent almost a month with the development team to establish a relationship that helped the team trust him as someone they can go to for help. Impact to CSP Cost rose, because at the end of trip the team decided that they needed more resources in order for them to meet the deadline. A new request was made to the stakeholders who approved the additional budget with the condition that no further requests will be made. Schedule and performance remained the same, as the development team stuck to their commitment in giving the PM accurate updates on progress and they took it as a challenge to work hard to deliver the project on time. The project was delivered successfully. Project C You have just taken over as the program manager of a large program with multiple tracks and a go-live scheduled in three months. At the first meeting with the project sponsors and key stakeholders, you find out that the business requirements are not complete and in some cases not started, project scope is not realistic to meet the upcoming go-live, and overall the project teams are confused due to lack of communication and understanding of priorities. Sample participant analysis comments: Time-driven project—3 months. Lack of communication. Set a communication plan for all stakeholders. Given the confusion on scope and requirements, declare project “breakdown.” Reset scope and requirements that are realistic with 3-month deadline and resources. Prioritize requirements for team. Demonstrate functionality of each requirement and feature so go-live has no flaws. Establish at least two status-gates to re-assess requirement completion status. If behind schedule, add resources or see if requirements can realistically be reduced. Consider Agile approach to finishing this project. Break into small pieces. What Actually Happened The program manager assembled a leadership team from the key areas of the organization and in collaboration with the project managers revised the project scope to include the bare minimum necessary to support the first go-live. The scope was organized in logical components of work and each project manager was responsible for working with their teams to complete the tasks for the scope they were responsible for. In addition, use of the agile methodology was implemented to allow requirements definition, development and testing to occur in an iterative fashion, thus speeding up the team’s ability to meet the upcoming deadline. At the end of the 3 months, the first go-live did occur as scheduled. Impact to CSP Although the scope of the project for the short-term was reduced, the cost of the project rose because a lot of the work needed to accomplish this scope was not complete and additional resources had to be added to the program to meet the deadline. Performance also went down because less scope than originally planned was completed. Schedule was maintained due to the decrease in scope. Project D You’ve just been assigned to take over a new project from an outgoing project manager. The project is a high-visibility project that is using a development methodology that is new to you and to your company. In your transition meetings with the outgoing project manager, he assures you that development is complete, and all you have to do is shepherd the project through acceptance testing and release. As a result, several project team members were released as scheduled. Sample participant analysis comments: Gap between requirements and acceptance (new functionality?) Release in stages—negotiate with customer, Deliver other stages later. Cut scope. Trade off features with time. Reset all with sponsor. Re-baseline project for time, scope, and cost. Project manager must be given control. PM must give project direction! Cost will go up. New Process. Bring back old team member who have experience with project activities. Training would take too long. Reset. Declare project breakdown. (Comment from other participant: “You need an open culture that allows such an approach.”) New functionality—how important is it? Change control. Get one. Make it work! We thought we had a clear, defined project. Now, we see requirements evolving. We have an Agile project. What is the business case? Project charter? Project priority? What Actually Happened The project manager conferred with the project’s business and technical leadership and confirmed that the “new” functionality was in scope. In order to accommodate the scope, the PM brought back the resources that had been released and the project team worked extended hours and weekends. The PM also extended the acceptance test period to allow the end users adequate time to review and test the application. To account for the additional testing time, the PM worked with the business leadership and QA teams to prioritize the defects and reduce the scope of bug-fixing to only very critical bugs. The business leadership team accepted this proposal, provided the project team completed a support release a short time later that addressed the de-prioritized bugs. As a result, the project was released on time with all of its functionality. Impact to CSP The project’s cost increased as a result of the extra hours and the additional resources that were brought back to the project. Performance went down because although the scope was maintained, quality was decreased. Schedule was maintained. Case 16.1 Introducing Scrum at P2P Kendra Hua had worked for six years as a software engineer in the IT department at Point 2 Point (P2P), a large freight moving company. She liked her job and the people she worked with. While she did some maintenance work, she worked primarily on projects, usually full time. Her work covered a wide range of projects including system upgrades, inventory control, GPS tracking, billing, and customer databases. These projects were typically able to meet project requirements but were consistently late. Within the IT department it was common practice for a betting pool to emerge regarding completion dates. The rule of thumb was to take the original schedule and multiply it by 1.5 and start guessing from then on. (Rest of case not shown due to length.) Part A 1. How well is Scrum working? The case is basically a tale of two sprints. During the first sprint, Scrum guidelines were adhered to and significant progress was made on the project. The team has evolved into self-organizing group and is energized. Unfortunately, during the second sprint, the project deviated from Scrum guidelines and the team seems less energized and productivity has declined. 2. What are the issues confronting the Big Foot project? In the second sprint, the process broke down when Prem stepped forward to “manage” the work and when Isaac added new features and eliminated existing feature the team was working on in the middle of a sprint. This seems to have broken the sprite of the team and their commitment to Scrum. At the end of the sprint, the feature demonstrations did not go well. The team did not take this well and blamed it on a lack of communication. 3. Assume you are Kendra. What would you want to say at the Retrospective? How would you say it? Kendra, as well as the other team members, are likely to want to call Prem out for violating the Scrum guidelines discussed above. She has tasted the benefits of Scrum and that taste is quickly vanishing after the second scrum. In particular, she is likely to want to talk about Prem’s transformation from Scrum Master to Task Master. The problem is how to raise this issue in a constructive manner. Prem is likely to act defensive if his shortcomings are pointed out. This is a delicate matter with no easy solution. One strategy would be to talk to Prem about the Scrum inconsistencies before the meeting so as to avoid a public spectacle. This would give him the opportunity to save face by taking the lead in returning the project back to Scrum principles. If this does not occur, Kendra needs to be careful to focus on the consequences of Prem’s behavior and not attack Prem for failing to perform his role as Scrum Master. Here, she could confess that she does not feel the same level of commitment when she is assigned a task instead of volunteering to do a task. 4. What improvements or changes need to be made? In theory, Prem should restore the methods used during the first sprint. He needs to relinquish his role as task master and manage just the process. He needs to reaffirm the rules that sprint deadlines cannot be extended or the goals changed once the sprint has started. He needs to work at being a coach to the team instead of a supervisor. 5. How would you assess Prem’s performance as a Scrum Master? Prem started off well but as soon as the project experienced trouble during the second sprint he resorted back to the traditional role of project manager as task master. Admittedly there is fine line between coaching and directing, but he needed to play a less assertive role in solving the integration problem. Here, instead of telling the team what to do, he could have poised questions that would have helped them to solve the problem themselves. This is a hard thing to do when you are under time pressure and you are confident you have the answer. He exacerbated the problem by taking control of the daily scrum away from the team. The synergy that had developed during the first sprint dissipated as team members no longer felt personally responsible for their tasks. Not only did motivation suffer, but the project likely suffered by not tapping into the collective expertise of the team. A second major issue is Prem acquiescing to Isaac’s request to change the work on the second sprint and extending the deadline. This violates one of Scrum’s cardinal rules: no changes are introduced once the sprint backlog has been set! Prem failed in his capacity of Scrum Master to ensure that the process is adhered to. This is the primary responsibility of a Scrum Master. Still on the surface Isaac appears to have justification for making changes if his assertions that much of Sprint 2 work would otherwise be a waste of time. This reflects a dilemma when using iterative methodologies like Scrum. On the one hand the purpose of locking in Sprint work is to provide focus and certainty so that the team can work uninterrupted on the project. On other hand, the Sprint Planning meeting is based on the best information available at that time, and what to do when contradictory information surfaces is problematic. Most Scrum advocates argue that both the Scrum Master and the Product Owner should decide whether to halt a sprint. However unlike in the case instead of modifying an on-going sprint, you should stop and hold a formal Sprint Planning meeting. Ultimately this is a judgment call, but such instances should be rare and clearly warranted. At first glance Prem’s violation of the Scrum rule that Sprint deadlines can not be changed seems minor compared to his other transgressions. Still this can quickly become a slippery slope if it becomes the norm rather the exception. The purpose of having set Sprint times is to take time out of trade-off equation. The team focuses only what it is capable of accomplishing given its resources within the sprint time frame. This forces the team to tackle tough questions early rather than later. Part B 1. How would you assess PSP effort at introducing Scrum? P2P should receive a failing grade in its effort to introduce Scrum on IT projects. By the end of the project all of the roles have been violated and the only gain is that the project is being done in increments with the opportunity for feedback and adjustments after each sprint. This is a significant improvement over the traditional waterfall method, but the emerging synergy within the team has been lost. 2. What challenges does an organization like P2P face when adopting an Agile approach like Scrum? The chief challenge is a culture one. For example, project managers are trained to develop and manage project plans. They are not accustomed to letting the project team manage themselves. It is not surprising that Prem assumed the role of task master since that is the traditional role of a project manager. A second related challenge is getting everyone to trust the process. Participants have to believe that in the long run the project will be better off if deadlines are not extended, changes are not introduced until after the sprint, and teams are given the freedom to manage themselves. 3. What could P2P have done to enhance success? P2P was naïve to assume that by simply sending a project team to a two day workshop would produce lasting change in behavior. It takes time to learn new ways of doing things. This is especially true when the behavior represents a radical departure, like Scrum, from how projects were completed in the past. People have a natural tendency to resort back to their old ways when encountering problems. Many organizations have found success in assigning Scrum experts as coaches to novice Scrum masters. While expensive, having an expert available to steer the Scrum master in the right direction can be critical to success. In the P2P case, such a coach could have worked with Prem on being more of a facilitator rather than task master during the critical Integration episode. One could also argue that P2P tried to do too much all at once. Instead of trying to institute the complete Scrum methodology, segments of Scrum could be introduced over time. For example, the concept of sprints could be introduced first, followed by the introduction of the daily scrum meetings, and so forth. Solution Manual for Project Management: The Managerial Process Erik Larson, Clifford F. Gray 9781259666094, 9780078096594
