AGILE

PROJECT
MANAGEMENT
Instructor: Barb Waters, MBA, PMP
Session 1

Class will begin at 11:00 am Eastern Time

Live Bootcamp
Session 1: Introduction to the Agile Principles and Mindset
Session 2: Stakeholder Engagement and Value-driven Delivery
Session 3: Product Backlog Prioritization and Agile Teams and Tools
Session 4: Adaptive Planning, Problem Detection, and Continuous Improvement
Bootcamp
Online Coursework
Encore
 Project Characteristics
• Temporary
• Unique product, service, or result
• Fulfills a purpose
• Requires dedicated resources

Different than Operational Work

• Ongoing
• Repetitive
• Often the result of a project handoff
 Predictive Agile
• Waterfall methodology • Iterative
• Plan-driven • Incremental
• Traditional • Adaptive
• Stakeholder involvement

New
Requirement
functionality
Design
Test
Development

Testing Iteration
features Develop
Deployment Requirement
& design

Prioritized feature list

 Sequential
• Sequential
Good: Reduces uncertainty
• Good: Reduces uncertainty Bad: Limits schedule compression
• Bad: Limits schedule compression
Phase 3
Phase 2
Phase 1

• Overlapping Overlapping
• Good: Allows for schedule compression
Good: Allows for schedule compression (fast tracking)
(fast tracking) Bad: Increases risk of rework
• Bad: Increases risk of rework

Phase 3
Phase 2
Phase 1
Iterative and Incremental
• Project phases intentionally repeat Feedback
• Iterations develop the product through repeated cycles Feedback
• A high-level vision is developed but the detailed scope is Cycle
elaborated one iteration at a time
• Good when there will be many changes to objectives and scope or
when partial delivery of a product is beneficial
Cycle
• Risk is reduced by allowing the team to incorporate feedback
between iterations
Cycle

Agile Feedback
• Rapid iterations (2-4 weeks)
• Ongoing stakeholder involvement
• Scope is decomposed into requirements
• Work is referred to as the product backlog
• Product is demonstrated after each sprint
• Work is reprioritized after each sprint
AGILE CHARACTERISTIC: INCREMENTAL

Requirements Requirements Requirements Requirements

Design Design Design Design

Development Development Development Development

Testing Testing Testing Testing

Delivery Delivery Delivery Delivery

AGILE CHARACTERISTIC:
ITERATIVE
• Opportunity to make changes
• Add features with each iteration
AGILE AND
EMPIRICISM
Based on evidence
• Metrics and observation
Real results
• We have delivered a minimum viable
product
Not just a plan
• Example: We should finish on time
 CHARACTERISTICS OF PROJECT LIFE CYCLES

Approach Scope Activities Delivery Goal

Traditional Well-known Performed once for the Once at the end Manage schedule and
entire project budget

Iterative Evolving Iterated until correct Once at the end Correctness of

deliverable
Incremental Evolving Performed once for each Frequently Speed
increment

Agile Evolving Iterated until correct Frequently Customer satisfaction via

frequent delivery and
feedback
 • Predictive life cycles. Take advantage of things that are known
and proven. This reduced uncertainty and complexity allows
teams to segment work into a sequence of predictable
High groupings.
Incremental Agile • Iterative life cycles. Allow feedback on partially completed or
Frequency of Delivery

unfinished work to improve and modify that work.

• Incremental life cycles. Provide finished deliverables that the
customer may be able to use immediately.
• Agile life cycles. Leverage both the aspects of iterative and
incremental characteristics. When teams use agile
approaches, they iterate over the product to create finished
deliverables. The team gains early feedback and provides
customer visibility, confidence, and control of the product.
Low Predictive Iterative Because the team can release earlier, the project may provide
Low High an earlier return on investment because the team delivers the
Degree of Change highest value work first.

Figure 3-1 The Continuum of Life Cycles from the Agile Practice Guide, © PMI
THE AGILE INVERTED TRIANGLE

AGILE

Cost Time

Scope
AGILE VALUE PROPOSITION
Visibility Adaptability

Agile

Traditional

Business Value Risk

 THE AGILE MANIFESTO
In 2001, seventeen software developers met at a resort in Snowbird, Utah to
discuss existing software development methods, among others Jeff Sutherland,
Ken Schwaber, Jim Highsmith, Alistair Cockburn, and Bob Martin. Together they
published the Manifesto for Agile Software Development.

The Four Values of the Agile Manifesto

We are uncovering better ways of developing software by doing it
and helping others to do it. Through this work we have come to
value:

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 There is value in these items, but we value the
items in red more.

© 2001, the Agile Manifesto authors

 THE 12 CLARIFYING PRINCIPLES
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 to the
shorter timescale.
4. Businesspeople 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, developer, 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 adjust its behavior
accordingly.
AGILE TEAM
CHARACTERISTICS

• People over processes

• The team decides on the processes and
tools
• High-performing teams = project success
• “Being” agile vs. “doing” agile
 ORGANIZATIONAL AGILITY
• Is your organization agile, or ready for agile?
• Perform assessments
• An Organizational Transformation Checklist, by Agile Alliance
https://www.agilealliance.org/wp-content/uploads/2016/02/An_Organizational_Transformation_Checklist.pdf

• Seven Questions to Determine if Your Organization is Agile Ready, by the Project Management Institute
https://www.pmi.org/learning/library/determine-organization-agile-scrum-ready-6129
• There are over a dozen agile methodologies
• No single right way
• Can be tailored once a team is experienced
• Most common
• Scrum (really a framework)
• Extreme Programming (XP)
• Lean product development
• Kanban
• Feature-driven development (FDD)
• Dynamic Systems Development Method (DSDM)
• Crystal
• Transparency
• Discuss product requirements
• Establish shared product vision
• Create a Definition of Done
• Inspection
• Assess productivity during Daily Scrum
• Burn-down chart
• Demonstrate product increment during Sprint Review
• Objective assessment based on Acceptance Criteria
and Definition of Done
• Adaptation
• Welcome change
• React quickly to variance in order to meet Sprint goal
• Sprint Retrospective promotes continuous
improvement
 COURAGE

FOCUS

COMMITMENT

RESPECT

SCRUM VALUES OPENNESS

 • Framework rather than a methodology
• Scrum is one of many Agile approaches
• Can be applied to any industry
• Employs various techniques
• High-performing cross functional teams
• Iterative, incremental approach
• Iterations are known as “Sprints”

The term “Scrum” comes from rugby.

A scrum (short for scrummage) is a method of restarting play. The
players pack closely together with their heads down and attempt to
gain possession of the ball.
 Includes:
Developers
Developers
Scrum Master
Product Owner

Scrum Master Product Owner

Develops product vision
Product Owner
Serves as voice of the stakeholders (liaison)
Collects and prioritizes requirements
Controls budget
Oversees return on investment
Determines value of features
Validates product quality

Stakeholders
Servant leader to the developers
Ensures adherence to Scrum framework
Facilitates meetings
Removes impediments (roadblocks, blockers)
Serves as a buffer to prevent interruptions
Provides essential resources
• Tools
• Resources
• Rewards
• Encouragement
Coaches team members
Assists product owner with managing backlog
Serves as Scrum “ambassador” to the organization
• Also know as the “Development Team”
• Not necessarily a technical role
• Self-organized
• Build the product increments during each sprint
• Estimate the work
• Decide what can be done during each sprint
• Cross-functional
• Every necessary skillset is represented
 THE SCRUM FRAMEWORK
Inputs from Executives, Team, Stakeholders,
Customers, and Users

Burndown/up
charts

Daily Scrum
meeting

Every
24 hours

Scrum
Product Owner The Developers 1-4 week
Master Sprint Review
sprint
Task
A breakout
Team selects as
F
many items as it
R can commit Sprint end date and
Sprint Finished work
C to deliver by Team deliverable
end of sprint Backlog do not change
J
B
Product Backlog Sprint planning meeting Sprint Retrospective
Product Vision

Product Roadmap

Release Planning

Iteration Planning

Daily
Planning
 SPRINT PLANNING
Participants
Product Backlog
• Scrum Team
• Product Owner A
• Developers
• Scrum Master F
Actions C
• Product Owner presents the updated
backlog J
• Team members pull from the product
D
backlog
• Team commits to a set of deliverables H
for the sprint
• Establish “Definition of Done”
Typically 2 hours per week of sprint
Occurs during the sprint
Participants
• Developers
• Scrum Master
• Product Owner may observe
Three main questions
• What have I done since the last stand-up?
• What do I plan on doing today?
• Do I have any roadblocks or impediments?
Typically 15 minutes or less
Reserve off-topic subjects for a separate discussion
 SCRUM OF SCRUMS

Used to scale Agile

• When teams are >12 members Team B Team C
Team A
• Each team selects an ambassador
Report on
• Completions
• Next steps
• Impediments Ambassador Ambassador Ambassador
Resolve coordination challenges between
teams
Scrum of scrums has its own backlog of these There is also a scrum of
items scrum of scrums!

May meet a few times per week

SPRINT REVIEW
Occurs at the end of a sprint
Participants
• Developers
• Scrum Master
• Product Owner
• Stakeholders (potentially)
Developers demo the product to Product Owner and
possibly stakeholders
Product Owner inspects deliverables
Elicit feedback and foster collaboration
Product Owner adapts product backlog if necessary
 SPRINT RETROSPECTIVE

Participants
• The Scrum Team
• Developers
• Scrum Master
• Product Owner
Evaluate the last sprint
• People
• Processes
• Tools
Plan improvements for next iteration
Typically .75 hours per week of sprint
Prioritized list of everything that is needed Backlog Product
in the product increment
Single source of product requirements A
Always changing F
Items are added, dropped, and
C
reprioritized based on value
The product is built incrementally based J
on work selected from the backlog
D
H
 SPRINT BACKLOG
Sprint Backlog
Belongs to the developers
Developers

}
Subset of the product backlog
A
Goal for the current sprint
Highly detailed and visible F
C
J
D
H
C The result of the latest sprint
J Demo during sprint review

D Must meet the “definition of done”

established during planning
H
EXTREME PROGRAMMING (XP)

Characteristics
• Focuses on productivity and software quality
• Quick releases, with a recommended two
week iteration
• Each iteration results in production-ready
code
• Highly productive, self-organized teams
INTERCHANGEABLE TERMINOLOGY

SCRUM Extreme Programming (XP)

Product Owner Customer
Scrum Master Coach
Sprint Iteration
XP CORE VALUES
Communication: all team members know expectations
and what other members are doing
Simplicity: reduce complexity, waste, and non-value
added features
Feedback: fail fast, get reactions early
Respect: value differences, everyone is accountable
for results
Courage: allow visibility, share code, make decisions
and changes
XP TEAM ROLES AND PRACTICES
Roles
• Coach
• Customer
• Programmers
• Testers

Practices
• “Whole Team”
• Collocated
• Generalists, not specialists
• Optimize resources
• Assume various roles
• Customer is available at all times, and communication is ongoing
XP CORE PRACTICES: PLANNING GAMES
• Release planning
• Push new functionality to the user
• A group of iterations that creates a
deliverable
• Iteration planning
• Occurs before each iteration
• Customer chooses functionality
• Developers break functionality into tasks
and estimate work
• Iterations are generally 2 weeks

Functionality is expressed through “user stories”

XP CORE PRACTICES: SUSTAINABLE PACE

• Optimizes long-term value

• People perform their best when rested
• Repeated overtime is ultimately not
productive
XP CORE PRACTICES
• Small releases
• Pair programming
• Test-driven Development (TDD)
• Customer tests
• Continuous integration
• Refactoring
• Code ownership
• Code standards
• Metaphor
The main difference between Scrum and XP is that XP contains many practices that are specifically for
programming, such as Test-driven Development (TDD), continuous integration, and pair programming.
PAIR PROGRAMMING
• Two programmers sit next to each other
• One enters the code
• The other ensures that the code is
accurate
• Periodically switch roles
• Communication is face to face
• Information is free-flowing
• Rapport and trust is essential
SMALL RELEASES

Demonstrates progress
Increases visibility to the customer
Smaller increments means rapid deployments
Iteration 1 Iteration 3 Release

Iteration 2 Iteration 4
 TEST-DRIVEN DEVELOPMENT
CUSTOMER TESTS
• Test-driven Development
• Team writes acceptance tests before
developing code
• Initial code will purposely fail because it is
incomplete
• Code will pass when correct
• Short cycles = early feedback
• Customer Tests
• Customer describes test criteria
• Team builds tests to prove software meets
criteria
 TEST-DRIVEN DEVELOPMENT (TDD) EXAMPLE

• When an item is sold out, the customer should not

be able to add it to their cart.
• At first the test will fail because the logic has not
been programmed yet
• You can add a sold-out item to the cart
• Once the code is implemented, the test will pass
• You cannot add a sold-out item to the cart
• Red, Green, Refactor
• Red: the test fails
• Green: the test passes
• Refactor: make it better so the code doesn’t “break”
• Can I reduce duplication and dependencies (coupling) in my
code?
• Can it be more organized (cohesive) with the existing code?
• Can I implement it more efficiently?
• Can it run faster?
 CONTINUOUS INTEGRATION

• Compile code
• Make sure it works
• Identify problems early
• Reduce rework
• Integration Tests
• Check code into a repository
several times a day
• Automated
 CODE OWNERSHIP AND CODE STANDARDS
• Collective Code Ownership
• Anyone can improve or amend code
• More people looking at code
• Reveal defects
• Shared knowledge

• Code Standards
• Consistency among programmers
• Uses best practices
• Requires fewer code comments
 SIMPLE DESIGN

“Is there a simpler way to introduce this functionality?”

• Adequate for what is needed now
• Adapt as necessary
• Revisit as needed
 METAPHOR

• Shared technical vision

• How the system should work
• Common vocabulary
• All stakeholders understand

“This music app will be like a

mind-reader. It will know which
song you would like to listen to
without having to ask you.”

“This exercise bike will make

you feel like you are in your
own private fitness studio.”
 LEAN PRODUCT DEVELOPMENT
• Lean is not an Agile methodology, but
there are similar approaches Lean
• Adapted from Toyota’s lean production
improvement principles Thinking
• Three principles
• Learning and continuous improvement
• Identify what the customer values Lean product Kanban
• Visual tools development
• Key concepts
Various Agile
• Eliminate waste
methodologies
• Pull systems
• Value stream mapping
• Work in Progress (WIP)
 LEAN CORE CONCEPTS
Adapted from Toyota lean manufacturing and production principles

Eliminate waste Amplify learning Defer decisions Deliver fast

Empower the team Build quality in Optimize the whole

 LEAN WASTES

• Muda is the Japanese term

for waste
• Waste does not add value,
but does add cost
LEAN WASTES
Waiting Task-switching Extra processes Motion

Extra features Defects Partially done work

Lean experts, Mary and Tom Poppendieck adapted these wastes from the original manufacturing wastes.
 KANBAN BOARD

• Originated in manufacturing as part of

the Toyota Production System
• Comes from Lean
• Kanban is Japanese term for “signboard”
$
• Generic term is “task board”
• Five Principles
• Workflow is highly visible
• Workflow is closely managed
• Work in Progress (WIP) is limited
• Process policies are clear
• Team collaborates to make
improvements together
 KANBAN PULL SYSTEM
• Different than pre-planned timeboxed iterations of Scrum or other Agile methods
• Customer demand creates pull
• No stock on hand
• Work is continuous

$
 CRYSTAL METHODOLOGY
Criticality Crystal Crystal Crystal Crystal Crystal
Clear Yellow Orange Red Magenta

• Named after colors of crystals of Life (L) L6 L20 L40 L100 L200
different hardness
• Family of methodologies coded by Essential Funds (E) E6 E20 E40 E100 E200
color
Discretionary Funds D6 D20 D40 D100 D200
• Size and criticality of the project (D)
determines methodology
• Crystal clear (low-criticality) to Comfort (C) C6 C20 C40 C100 C200
crystal magenta (high-criticality)
Team Size 1-6 7-20 21-40 41-100 101-200
 FEATURE-DRIVEN DEVELOPMENT

• Model-driven process
• Feature is a client-valued piece
of functionality
• Example, “validate the user
password”
• Meta-process model
FEATURE-DRIVEN DEVELOPMENT PROCESS
 FEATURE-DRIVEN DEVELOPMENT
BEST PRACTICES
• Domain object modeling - exploring and explaining the domain of the problem to be solved. The
resulting domain object model provides a framework in which to add features
• Developing by features - any function that's too complex to be implemented within two weeks is
broken down into smaller functions until each of those problems is small enough to be called a
feature
• Individual class ownership - distinct pieces of code are assigned to a single owner. The owner is
responsible for the consistency and performance of that code or that class
• Feature team - small, dynamically formed team that develops a small activity
• Inspections - carried out to ensure good quality design and good source code. Works to find defects
in the design, and in the code
• Configuration management - identifying the source code for all features that have been completed
and maintaining a history of changes to classes as features enhance them, or change them, or
improve them
• Regular builds - ensure that there's always an up-to-date system that can be shown to the client and
help integration errors of source code
• Visibility of progress and results - frequent reporting at all levels inside and outside the project
based on work that's been completed
 DYNAMIC SYSTEMS DEVELOPMENT METHOD

First released in 1994 (before the Agile Manifesto)

Eight principles:
1. focus on business need
2. deliver on time
3. collaborate
4. never compromise quality
5. build incrementally from firm foundations
6. develop iteratively
7. communicate continuously and clearly, and
8. demonstrate control
 DAILY BOOTCAMP SURVEY

At the end of each Bootcamp session please let us know how we are doing.
Your feedback helps us to offer the best possible Bootcamp experience.

Please share your thoughts.