PROJECT EXECUTION, CONTROL, AND CLOSURE STRATEGIES
TW7809
Larson8e_CH15_PowerPoint_Accessible.pptxChapter Fifteen
Agile Project Management
© 2021 McGraw Hill. All rights reserved. Authorized only for instructor use in the classroom.
No reproduction or further distribution permitted without the prior written consent of McGraw Hill.
Because learning changes everything.®
Where We Are Now
© McGraw Hill
‹#›
2
Learning Objectives
15-1 Recognize the conditions in which traditional project management versus Agile Project Management should be used.
15-2 Understand the value of iterative, incremental development for creating new products.
15-3 Identify core Agile principles.
15-4 Understand the basic methodology used in Scrum.
15-5 Understand the basic methodology used by Extreme programming.
15-6 Know how to create and use a Kanban board.
15-7 Recognize the limitations of Agile Project Management.
© McGraw Hill
‹#›
Chapter Outline
15.1 Traditional versus Agile Methods
15.2 Agile PM
15.3 Agile PM in Action: Scrum
15.4 Extreme Programming and Kanban
15.5 Applying Agile PM to Large Projects
15.6 Limitations and Concerns
15.7 Hybrid Models
© McGraw Hill
‹#›
15.1 Traditional versus Agile Methods
Traditional Project Management Approach
Concentrates on thorough, up front planning of the entire project.
Requires a high degree of predictability to be effective.
Agile Project Management (Agile PM)
Relies on iterative, incremental development (IID).
Is ideal for exploratory projects in which requirements need to be discovered and new technology tested.
Focuses on active collaboration between the project team and customers representatives, breaking projects into small, functional pieces and adapting to changing requirements.
© McGraw Hill
‹#›
The Waterfall Approach to Software Development
FIGURE 15.1
© McGraw Hill
‹#›
A Set of 12 Guiding Principles for Agile PM
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.
© McGraw Hill
‹#›
Project Uncertainty
FIGURE 15.2
© McGraw Hill
‹#›
Traditional Project Management versus Agile Project Management
| Traditional | Agile |
| Design up front | Continuous design |
| Fixed scope | Flexible scope |
| Deliverables | Features/requirements |
| Freeze design as early as possible | Freeze design as late as possible |
| Low uncertainty | High uncertainty |
| Avoid change | Embrace change |
| Low customer interaction | High customer interaction |
| Conventional project teams | Self-organized project teams |
TABLE 15.1
© McGraw Hill
‹#›
15.2 Agile PM
Utilizes a rolling wave planning and scheduling project methodology.
Is continuously developed through a series of incremental iterations over time.
Iterations are short time frames (“time boxes”).
The goal of each iteration is to develop a workable product that satisfies one or more desired product features to demonstrate to the customer and other key stakeholders.
At the end of each iteration, stakeholders and customers review progress and re-evaluate priorities to ensure alignment with customer needs and company goals.
Each new iteration subsumes the work of the previous iterations and adds new capabilities to the evolving product.
© McGraw Hill
‹#›
Iterative, Incremental Product Development
FIGURE 15.3
© McGraw Hill
‹#›
Advantages of Iterative Development Process
Continuous integration, verification, and validation of the evolving product.
Frequent demonstration of progress to increase the likelihood that the end product will satisfy customer needs.
Early detection of defects and problems.
© McGraw Hill
‹#›
Other Methodologies Responding to the Challenges of Unpredictable Projects
Scrum
Extreme Programming (XP)
Agile Modeling Lean Development
RUP (Rational Unified Process)
Crystal Clear
Dynamic Systems Development Method (DSDM)
Rapid Product Development (RPD)
© McGraw Hill
‹#›
Agile Principles
Focus on customer value
Iterative and incremental delivery
Experimentation and adaptation
Self-organization
Servant leadership
Continuous improvement
© McGraw Hill
‹#›
15.3 Agile PM in Action: Scrum
Scrum
Is a holistic approach to developing new products, where the whole team “tries to go the distance as a unit, passing the ball back and forth.”
Begins with a high-level scope definition and ballpark time and cost estimates for the project.
Use product features as deliverables.
A feature is defined as a piece of a product that delivers some useful functionality to a customer.
The project team tackles the highest-priority feasible feature first.
Priorities are re-evaluated after each iteration.
Iterations are called sprints and should last no longer than four weeks.
The goal of each sprint is to produce fully functional features.
Specific features are created according to four distinct phases: analysis, design, build, and test.
© McGraw Hill
‹#›
Scrum Development Process
FIGURE 15.4
© McGraw Hill
‹#›
Key Roles and Responsibilities in the Scrum Process
Product Owner
Acts on behalf of customers/end users to represent their interests.
Works with the development team to refine features through stories and end users cases.
Ensures that the development team focuses their efforts on developing a product that will fulfill the business objective of the project.
Development Team
Is responsible for delivering the product.
Is typically made up of five to nine people with cross-functional skill sets.
Scrum Master (Project Manager)
Facilitates the scrum process and resolves impediments at the team and organization levels.
Acts as buffer between the team and outside interference but not the leader of team (the team leads itself!)
Helps the product owner with planning and try to keep the team energized.
© McGraw Hill
‹#›
Scrum Meetings
FIGURE 15.5
© McGraw Hill
‹#›
Partial Product Backlog
FIGURE 15.6
© McGraw Hill
‹#›
Partial Sprint Backlog
FIGURE 15.7
© McGraw Hill
‹#›
Sprint Burndown Chart
FIGURE 15.8
© McGraw Hill
‹#›
Release Burndown Chart after Six Sprints
FIGURE 15.9
© McGraw Hill
‹#›
15.4 Extreme Programming and Kanban
Extreme Programming (XP)
Is a more aggressive form of Scrum that organizes people to produce higher-quality software more efficiently.
Considers change a natural, even desirable aspect of software development projects and should be planned for, instead of eliminated.
Are test-driven development and paired programming.
Is founded on five values: communication, simplicity, feedback, courage and respect.
Kanban
Is a lean management methodology that has been adapted by Agile practitioners to help manage project work flow.
Consists of a whiteboard divided into three columns: Planned, Work in Progress, and Done.
Is based on the idea of a pull system—signaling when the team is ready for more work.
Helps the team visualize the work flow on the project and focus their attention on the most critical work.
© McGraw Hill
‹#›
15.5 Applying Agile PM to Large Projects
Scaling
Involves several teams working on different features at the same time.
Needs to make sure that the different features being created work in harmony with each other—integration.
Staging
Requires significant up-front planning to manage the interdependences of different features that will be developed.
Involves developing protocols and defining roles for coordinating efforts and assuring compatibility.
© McGraw Hill
‹#›
Hub Project Management Structure
FIGURE 15.10
© McGraw Hill
‹#›
15.6 Limitations and Concerns
Agile PM is not a simple methodology. Adoption tends to evolve over time.
Many of the Agile principles, including self-organizing teams and intense collaboration, are incompatible with corporate cultures.
Agile PM does not satisfy top management’s need for control.
Agile skeptics warn that evolving requirements contribute to scope creep.
Agile PM requires active customer involvement.
© McGraw Hill
‹#›
15.7 Hybrid Models
Agile PM is used up front to resolve key scope questions and define requirements. Then traditional PM is applied to complete the project.
Incremental, experimentation is used to resolve technical issues, allowing for a formal implementation plan.
Many companies use hybrid models on large projects that combine waterfall and Agile methods.
Teams use Agile techniques on plan-driven projects. Teams use shorter iterations and retrospectives to get critical customer feedback.
Kanban methods are used by traditional teams to visualize work and identify bottlenecks in the project schedule.
© McGraw Hill
‹#›
Key Terms
Agile Project Management
Extreme Programming
Feature
Hybrid model
Iterative, incremental development (IID)
Kanban
Product backlog
Product owner
Release burndown chart
Scaling
Scrum master
Self-organizing team
Sprint backlog
Sprint burndown chart
Waterfall method
© McGraw Hill
‹#›
End of Main Content
© 2021 McGraw Hill. All rights reserved. Authorized only for instructor use in the classroom.
No reproduction or further distribution permitted without the prior written consent of McGraw Hill.
Because learning changes everything.®
www.mheducation.com
Accessibility Content: Text Alternatives for Images
© McGraw Hill
‹#›
The Waterfall Approach to Software Development - Text Alternative
Return to parent-slide containing images.
The waterfall approach to software development is shown as a series of downward-sloping steps, beginning with the Concept phase then proceeding through the Requirements phase, Design phase, Construct phase, Test phase, and Deploy phase.
© McGraw Hill
‹#›
Project Uncertainty - Text Alternative
Return to parent-slide containing images.
A graph plots Technology (How) to Project scope (What). When both Technology and the Project scope are known and stable, the project has a fairly high degree of predictability. The more either Technology or Project Scope become unknown, the more unpredictable the project becomes.
© McGraw Hill
‹#›
Iterative, Incremental Product Development - Text Alternative
Return to parent-slide containing images.
This diagram begins with project initiation. Then there are a series of 5 arrows all pointing to the right, but with a second arrow that branches off and cycles back to the beginning of that iteration. At the end of the 5 iterations is the closeout. Below this is a small burst, which becomes a bigger burst, which becomes a primative wheel, which becomes an old-fashioned wheel, which becomes a modern day tire on a rim. This is the path from a new product to customer acceptance.
© McGraw Hill
‹#›
Scrum Development Process - Text Alternative
Return to parent-slide containing images.
The four phases of the scrum development process are analysis, design, build, and test. These phases flow from the daily scrum meetings and result in a new iteration of the feature. At the end of each sprint, the functional features are demonstrated.
Within this sprint framework of 3 to 4 weeks, scrum relies on specific roles, meetings, and documents/logs to manage the project.
© McGraw Hill
‹#›
Scrum Meetings - Text Alternative
Return to parent-slide containing images.
Scrum Meetings
Release Planning leads to the Sprint planning meeting, which leads to the Daily scrum meetings (these occur every 24 hours). At the end of each sprint, a Sprint review meeting occurs, which is followed by a Sprint retrospective meeting.
Then the process begins again with a Sprint planning meeting.
© McGraw Hill
‹#›
Partial Product Backlog - Text Alternative
Return to parent-slide containing images.
| A | B | C | D | E | F | G | |
| 1 | Phone-In Prescription Software Project | ||||||
| 2 | Product Backlog | ||||||
| 3 | |||||||
| 4 | ID | Product | Priority | Status | Estimate | Actual | |
| 5 | Hours | Hours | |||||
| 6 | |||||||
| 7 | 1 | Customer Information | 2 | Complete | 100 | 90 | |
| 8 | 2 | Insurance Information | 1 | Complete | 160 | 180 | |
| 9 | 3 | Drug Information | 3 | Started | 80 | ||
| 10 | 4 | Doctor Information | 5 | Not Started | 40 | ||
| 11 | 5 | Inventory Status | 4 | Started | 120 | ||
| 12 |
© McGraw Hill
‹#›
Partial Sprint Backlog - Text Alternative
Return to parent-slide containing images.
| A | B | C | D | E | F | G | H | I | |
| 1 | Phone-In Prescription Software Project | ||||||||
| 2 | Sprint Backing | ||||||||
| 3 | |||||||||
| 4 | Spring Description | Responsible | Actual | Remaining | Defined | In | Tested | Accepted | |
| 5 | Hours | Hours | Progress | ||||||
| 6 | |||||||||
| 7 | Drug categories | RT | 16 | 0 | X | X | X | [check] | |
| 8 | Generics | CG | 32 | 0 | X | X | X | [check] | |
| 9 | Branded | AL | 24 | 8 | X | X | X | ||
| 10 | |||||||||
| 11 | |||||||||
| 12 | Design drug inventory system | EL | 40 | 0 | X | X | X | [check] | |
| 13 | Code inventory availability | CE | 32 | ||||||
| 14 | Code manufacture order | MC | 32 | ||||||
| 15 | Integrate all inventory systems | LE | 4 | 16 | X | ||||
| 16 |
© McGraw Hill
‹#›
Sprint Burndown Chart - Text Alternative
Return to parent-slide containing images.
A graph plots Sprint Timeline (days) to Remaining Effort (days). One line, Ideal Remaining Effort, begins at data points (0,28) and slopes down at a 45-degree angle to end at data points (20,0). Another line, Actual Remaining Effort, begins at data points (0,28) and slopes below the Ideal Remaining Effort line for a time before intersecting it at data points (10,15). From that point, the Actual Remaining Effort line is above the Ideal Remaining Effort line, ending at data points (20,14).
The area to the left/below the Ideal Remaining Effort line represents “Ahead of Schedule” and the area to the right/above the line represents “Behind Schedule.”
Note: Data points are approximations.
© McGraw Hill
‹#›
Release Burndown Chart after Six Sprints - Text Alternative
Return to parent-slide containing images.
A graph plots Sprint to Days of Work Remaining. Data point 8 on the horizontal axis (Sprint) is labeled “Original Completion Date”; data point 10 is labeled “Revised Completion Date.”
A line is shown connecting the following data points: (0,100), (1,83), (2,75), (3,65), (4,55), (5,48), (6,40), (7,35), (8,20), (9,10), (10,0). A vertical line is shown extending from the horizontal axis up to data point (6,40). Note: Data points are approximate.
© McGraw Hill
‹#›
Hub Project Management Structure - Text Alternative
Return to parent-slide containing images.
In the hub project management structure, there are several feature development teams (Teams A-Z), each with team leads. There is also a separate integration and build team, consisting of part-time members of each feature team. To coordinate the multi-team structure, a central project management team is created with a project manager and product manager and leads from the feature development teams. The project management team provides coordination and facilitation between and among the other teams.
© McGraw Hill
‹#›
