Section 2: Agile Principles and the PMI-ACP Mindset

17. Defining Agile Values for Projects

Agile Values and Principles:
 Adopt a formal agile approach, designed and proven to achieve desired results.
 Implement changes to project practices in a manner that fits the project context to
achieve progress on a core value or principle.

18. Managing Knowledge-Work Projects

 Industrial work (defined process) requires up-front planning.
 Knowledge Work Projects (Empirical process).
Industrial projects Knowledge work projects
1 Visible Invisible
2 Stable Lots of Change
3 Running things Changing environment
4 Structure Less structure
5 Correct answers Lots of questions
6 Task driven Value-driven
7 Command and control Autonomy driven
8 Standards Innovation
9 Performance measurement Learning and teaching
10 Cost of workers for a task Workers are an asset not a cost

Agile is best suited for software development projects.

Definable work vs. High-Uncertainty Work

 Definable work projects have clear procedures that have proven successful.
 High-Uncertainty projects have high rates of: Change/Complexity/Risk

19. Comparing Empirical Processes and Defined Processes

Defined Process (Define all steps in advance)
 Repeatable process
 Do the work the same way each time
 Prescribed process of action
Empirical process: based on experience and observation.
1. Transparency 2. Inspection 3. Adaption
20. Exploring the Declaration of Interdependence
6 rules of interdependence:
1. Increase ROI
2. Deliver reliable results
3. Expect uncertainty
4. Unleash creativity and innovation
5. Boost performance
6. Improve effectiveness and reliability

20. Being Agile and Doing Agile

Agile mindset:
 Defined by rules
 Guided by principles
 Manifested through many different practices

22. Inverting the Triple Constraints

Inverted Triangle Model: Time/cost/scope
Scope →fixed→ Time and Cost
Time and Cost →varied based on→ Scope

23. Leading Organizational Agility

Individual—Team--Organization

24. Thinking About Agility Practices

Servant-leadership: Not command and control, but servant leadership!

25. Doing Agile Project Management

Doing Agile Being Agile
Agile practices: Iteration/Stand-up meeting Agile mindset
Embracing agile process
No agile Mindset
Tailor processes

26. Encouraging Others to Embrace Agile

Project management—Project team—Stakeholders
27. Reviewing the Agile Manifesto
The Four Values:
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

28. Individuals and Interactions over processes and tools

Focus on people first. People do knowledge work.

29. Working software over comprehensive documentation

 Agile projects need to deliver value.
 Documentation is barely sufficient.
 Documentation is done just in time – as the last responsible moment.
 Documentation might also be just because: Industry / Organizational Requirement
Documentation adds no value. Comments are okay, documentation is waste.

30. Customer collaboration over contract negotiation

 Agile is flexible, accommodating, and willing to change.
 Contracts are often rigid and uncooperative.
 Agile contracts must accommodate change.
 Difference between being right and doing the right things.
Agile is uncertain. Contracts are legal documents and want certainty.

31. Responding to change over following a plan

32. Twelve Principles of Agile
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, developers, 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 adjusts its behavior accordingly

33. Comparing Agile Project Management Approaches

Core Principles of Agile
Welcome change Work in small value-added increments
Use build and feedback loops Learn through discovery
Value-driven development Continuous delivery
Continuous improvement

Four Types of Life cycle:

Approach Requirement Activities Delivery Goal
Perform once for the
Predictive Fixed Single delivery Manage cost
entire project
Correctness
Iterative Dynamic Repeat until correct Single delivery
of solution
Incrementa Perform once for a Frequent smaller
Dynamic Speed
l given increment deliveries
Frequent small Customer
Agile Dynamic Repeat until correct
deliveries value

34. Introducing Scrum

Scrum framework is a set of practices, roles and responsibilities, events, artifacts and rules.
Scrum Pillars and Values:
 Transparency
 Inspection
 Adaption
Scrum Master + Product Owner + Development Team
Only the product owner may cancel a sprint.
 Product Backlog: source of all product requirements
 Sprint Backlog: subset of product backlog; goal of current iteration
35. All About Kanban
Kanban does not use time boxed iterations.
Principles of Kanban:
1. Visualize/Manage the workflow 2. Limit work in progress
3. Make process policies clear 4. Aim for collaborative improvements

36. Extreme Programming (XP)

XP is all about software development best practices.
Communication + Feedback + Courage + Respect
Coach + Customer (define) + Programmer + Testers
Release planning is the release of new functionality. (No more than 1 or 2 releases per year)
Test-driven Development / Simple Design / Pair Programming

37. Lean Product Development

Visual management tools
Seven Waste of Lean:
1. Partially done work
2. Extra processes
3. Extra features
4. Task switching
5. Waiting
6. Motion
7. Defects

38. Dynamic Systems Development Method (DSDM)

1. Focus on business need 2. Deliver on time
3. Collaborate 4. Never compromise quality
5. Built incrementally from foundations 6. Develop iteratively
7. Communicate continuously and clearly 8. Demonstrate control

39. Feature-Driven Development

Model – Feature list and Plan – Build direction – Designed and built by features
1. Domain object modeling 2. Developing by feature
3. Individual class code ownership 4. Feature teams
 5. Inspections 6. Configuration management
7. Regular builds 8. Visibility of progress and results

40. Introduction Crystal

Customized methodologies coded by color names.
Unique characteristics are driven by several factors such as team size, system criticality.
Different colors have signal that there are different tailoring of the processes, policies and
practices.

41. Leading an Agile Project

Product Vision (product owner) -- Product Roadmap (product owner) -- Release Planning –
Daily Scrum -- Iteration Planning (at the start of each Sprint) -- Sprint Review – Sprint
Retrospective (A look back at the last Sprint) – Release Product
Agile Roles:
 Cross-functional Team Members
 Product Owner
 Team Facilitator/Servant Leader
Management vs. Leadership (more soft skills)

42. Management and Leadership in Agile

 Management is about getting things done.
 Leadership is about getting people to want to do what needs to be done.
 Management is more concerned with task control command.
Servant Leadership Characteristics
1. Promoting self-awareness
2. Listening
3. Serving those on the team
4. Helping people grow
5. Coaching vs. controlling
6. Promoting safety, respect, and trust
7. Promoting the energy and intelligence of others

43. Serving as a Leader

45. Create a Safe and Trustful Team Environment
Truckman model: Forming – Storming – Norming – Performing/Adjourning
Agile Team: 3-9 people; self-management team

46. Encourage Emergent Leadership

Anyone can be a leader on a agile team; Understand roles and responsibilities.
 Section 3: Value-Driven Delivery
51. Delivering Value in Agile Projects
Projects: create business value
Value-Driven Business

52. Creating Value ASAP

Manager goal: increase value + reduce risk
Know what’s valuable for the customer, from stakeholders’ and customers’ perspective.

53. Removing Waste

Partially done work Extra process Extra processes
Extra features Task switching Waiting
Motion Defect
Identify waste: lurking; bottlenecks; escaped defects; what are waiting for?

54. Defining Value in Organizations

Organization strategy – customer value

55. Exploring the Time Value of Money

Present Value / Future Value / Net Present Value

56. Introduction Earned Value Management

Cost Variance = EV – AC (Actual Cost)
Schedule Variance = EV – PV (Planned Value)
CPI (Cost Performance Index) = EV/AC
SPI (Scheduled Performance Index) = EV/PV
Estimate at Completion = BAC/CPI
Estimate to Complete = EAC (Budget at Completion) - AC
TCPI (To-Complete Performance Index) = (BAC-EV) / (BAC-AC)
TCPI (To-Complete Performance Index) = (BAC-EV) / (EAC-AC)
TCPI: >1, hard to accomplish; =1, same level of efficiency; <1, easier to accomplish
SPI (Story Points Index) = EV/PV

57. Agile Project Accounting

MVP – Minimal Viable Product
Intermittent Releases and Value: Get quicker return on investment

58. Creating Key Performance Indicators

KPI: Rate of Progress / Remaining Work / Likely Completion Date / Likely Cost Remaining
 Predictive life cycle KPI: Performance measurement baseline/Scope/Schedule/Cost
 Agile life cycle KPI: All about getting things done/Likelihood of targets

59. Managing Risks in Agile Projects

60. Adhering to Regulatory Compliance in Agile
Regulations are requirements.

61. Prioritizing Value in Agile Projects

62. Deliver High-Value Requirements First
Simple Scheme: Priority 1/2/3, risk that everything is ranked as priority one.

63. Utilizing MoSCoW

MoSCoW: Must have/Should have/Could have/Would like to have, but not this time

64. Using Kano Analysis

5 Categories of Customer Preference:
1. Must-be quality (Ignored when met, dissatisfied when not met)
2. One-dimensional quality (Spoken attributes that are promises)
3. Attractive quality (Nice-to have features, but not necessarily required)
4. Indifferent quality (Customers are indifferent to the quality feature
5. Reverse quality (Some customers will love, others will hate the feature)
Kano Analysis: Delighters exciters / Satisfiers / Dissatisfiers / Indifferent
65. How to do Dot Voting
Colors of dots could represent opinion or stakeholder.
Dot Voting Risks:
 New features can’t be considered once voting begins.
 Review all features before voting – avoid too many options.
 Similar options are basically penalized.
 People follow crowd rather than consider options.

66. Spending Monopoly Money

Consider cost of:
1. User-suggested features 2. Rival product features
3. Research-based features 4. Market research-based features

67. Trying the 100-Point Method

Weighted distribution point: Spend on all 100 points on all the requirements.

68. Setting Requirements Prioritization

Use a scale of 1 to 9 to vote for: Benefit; Penalty; Cost; and Risk for every feature.

69. Relative Prioritization and Ranking

Prioritized Backlog:
 List of all requirements.
 Prioritized with product owner.
 Priorities can change with each grooming.
 Priorities don’t change during the iteration.

70. Delivering Value in Increments

Incremental Model: Many mini development projects/partial systems are built to produce the
final system.
 Pros: Defects identified; Allows more targeted testing of each element; Initial product
delivery is faster and costs less.
 Cons: Cost may exceed business value; Added functionality can reveal problems
related to system architecture which were not evident earlier.
71. Reviewing the Cost of Change
72. Creating the MVP
Complete enough to be useful. Small enough that it doesn’t represent the entire project.
Minimum Viable Product (MVP): Complete enough to be useful/Small enough that doesn’t
represent the entire project

73. Embracing Low-Tech / High Touch Tools (Agile Tooling)

Cards / Charts / Information radiator / Tools that promote communication and collaboration

74. Value and Validation:

Gulf of Evaluation: The difference between what is said/understood (often intangible
projects).
1. Frequent Verification and Validation
XP example: pair programming / unit testing / customer collaboration / stand up meeting /
acceptance testing / iteration demonstrations / product release
2. Exploratory Testing: play software and try everything (discover unexpected issues)
3. Usability Testing: under realistic condition, how easy a user to user a system and
make improvement
4. Continuous Integration: Source code control system-version control / Build tools-
compile the code / Test tools-ensure functionality operates as expected / Scheduler or
trigger-launched on a schedule or based on conditions / Notifications-message
reporting on the result
Continuous Integration Advantages: Early warning conflicts/Fix problems as
occur/Immediate feedback
Continuous Integration Disadvantages: Lengthy set up time/cost of a dedicated server/Time
for automatic tests

75. Creating Kanban Boards (Task Board)

76. Making a Task Board
Not co-located: use software.

77. Setting the WIP Limit

Work In Progress (WIP): risk / hide bottleneck / require investment / no return until work is
complete / need to be limited
Agile/Kanban boards can have WIP limits and try to reveal bottleneck

78. Exploring Little’s Law

Limit WIP – team complete work faster
More efficient to finish small amount of work at a time.

79. Working with Vendors in Agile Projects

RFP: Request for Proposal
Contract Considerations: Scope changes / Priorities / Time and cost
 Customer collaboration over contract negotiation.
 Customers are more involved than traditional projects.

80. Introducing DSDM Contracting

Dynamic Systems Development Method (DSDM):
Creates a fix schedule, cost and quality, follows agile framework.
 Grew out of RAD-Rapid Application Development-was not focus on quality
 Waterfall was too big, too slow-Control / Quality
DSDM wants a balance, it takes the best part of RAD and Waterfall.
RAD benefits 1. Communication 2. Stakeholder engagement 3. Transparency
Waterfall 1. Control 2. Quality

81. Graduated Fixed Price Contract

Both parties share some of the risk and reward.
 Vender delivers on-time – Get paid at their hourly rate
 Vender delivers early – Get paid at higher hourly rate
 Vender delivers late – Get paid at lower hourly rate
Benefits:
1. No sandbagging 2. Celebrate success for working smart
3. Initiative to work effetely 4. Focus on result, not hourly rate

82. Fix-Price Work Packages

 The price of work remains constant.
 Individual work packages are estimated for cost.
 Changes to the scope reflect a new estimate for those work packages.
Customize Contracts: Procurement is always tricky with agile projects.

83. Validating Value in Agile Projects (Gulf between say and understand)
84. Software Testing and Verification
Unit Testing: smallest testable portion of application code.
Acceptance Testing:
 Specific requirement
 Specification
 Contract requirements

85. Exploratory Testing

Aims to discover issues and unexpected behavior.

86. Usability Testing

Hallway testing – random people try the product.

87. Implementing Continuous Integration

Incorporate new and changed code into the code repository.
 Early warning a broken conflicting or incompatible code.
 Problems are fixed as they occur.
 Immediate feedback.
 Frequent unit testing defines issues quickly.
 Easy to reverse the code back to the last known well.
Disadvantages:
 Set up time is lengthy.
 Cost of a dedicated server.
 Time required to build a suite of automatic tests.

88. Working with Test-Driven Development (Test first, Red--Green--Clean/Refactor)

90. Acceptance Test-Driven Development
Testing focuses on business requirements; All about desired behavior
 Section 4: Stakeholder Engagement
94. Leading Stakeholder Stewardship
People and groups impacted by the project
1. Customers 2. Project sponsor 3. Project leaders
4. Development team 5. Vendors 6. End users
Keeping stakeholders engaged. / Stakeholders new to project need education.

95. Defining Stakeholder Value

All work is based on what the stakeholders value.
Principles of Stakeholder Engagement:
1. Get the right stakeholders.
2. Ensure a stakeholder participation.
3. Manage stakeholder interest.
4. Frequently discussed what done looks like.
5. Show progress to project stakeholders.
6. Openly discuss project estimates and projections.
96. Defining Community Values
97. Managing Stakeholder Engagement
PMBOK Guide Knowledge area:
 Stakeholder engagement plan
 Identify stakeholders
 Understand their needs / wants / concerns
 Document expectations
Conflict isn’t always bad – positive conflict creates solutions.

98. Identifying Project Stakeholders (ASAP)

Identify Stakeholder Tools and Techniques
Expert judgement
Data gathering: Data analysis:
 Questionaries and surveys  Stakeholder analysis
 Brainstorming  Documentation analysis
Data representation: Stakeholder mapping Meetings

99. Building Stakeholder Synergy

100. Keeping Stakeholder Involved
 Frame of adaptive approach
  Daily standups
 Working with project team
 Regular communication
 Following rules of project
Daily Stand-Up Meeting Rules:
1. Stand up
2. Three-question agenda
3. Have PM tools handy
4. Collaborate effort – speak to group
5. Develop a routine
Creating A Project Tweet: High-level description; Narrow down project; Goal

101. Leading Stakeholder Conversations

Push communication: email; Pull communication: stakeholder pull information from source

102. Sharing the Project Vision

Develop the project vision based on:
 Key goals
 Customer needs, wants and expectations
 Competition or similar products
Failing Fast: failing early and cheapy; good way to discover misunderstandings; ensure the
project team understanding

103. Creating the Project Charter

Agile charters authorize the project and the project manager.
Agile charters are from the project sponsor.
Could be lightweight or very detailed.
Acknowledge change is likely in the actual project.
Traditional charters Agile charters
Very specific Broad and high level

Agile Charter Elements:

1. Vision Statement 2. Team rules 3. Code of Conduct
4. Communication Rules 5. Definition of Done 6. Success factors
104. Defining Done in Agile Projects
Definition of Done (DOD): Everything is ready for release; Potentially shippable product
Finished feature: Coding; Testing; Product owner approval
DOD created by team!

105. Modeling an Agile Project

XP: Communication + Simplicity + Feedback + Courage + Humility (we don’t know every)

106. Use Case Diagrams

A set of actions, services, and functions
Model the functionality of a system using actors and use cases.
Use Case Diagram Components: System + Use Case + Actors + Relationships

107. Leveraging Data Models

How data flows through the system.
Considering Screen Designs:
 User interaction
 User stories are product focused
 Promote cooperation between team and product owner
 Avoid creep, design black holes

108. Knowing Wireframes

A way of showing, not telling!
It’s a quick mock-up of a product.
A form of low fidelity prototyping.

109. Meeting Personas

Biographical sketches of key shareholders; Description of product users
The idea of persona explains how people are going to interact.

110. Communicating with Stakeholders

Plan + Manage (Transparency) + Control
Sender Medium Receiver
Encoder Barrier Noise Decoder

111. Leading Face-to-Face Communication

Two-way Communication:
Dispatching model – top-down communication
Collaborative model – interactive communication

112. Sharing Knowledge with Stakeholders

Agile practices promote knowledge sharing:
Kanban boards Information radiators Personas Wireframes

113. Building an information Radiator (Visual Control)

Highly visible displays of information. (ZA dashboard)

Large graphs or charts that summarize project data. 包含人员，状况，风险，产出等因素

114. Collaborating with Stakeholders

Businesspeople and Developers must work together daily throughout the project.
Benefits of Collaboration:
1. Generates wise decisions 2. Promotes problem solving 3. Promotes action
4. Build social capital 6. Ownership of collective problems

115. Creating Green and Red Zones

116. Hosting a Workshop
Tips for a Great Workshop:
1. Have a diverse group of people
2. Facilitated for involvement
3. Get people involved early

117. Brainstorming Ideas

Quiet writing / Round robin / Free for all
118. Playing Collaboration Games
Remember the future / Prune the product tree / Speed boat (Sailboat: winds/anchors/rocks)

119. Defining Soft Skills for Agile Projects

Emotional intelligence Active listening Facilitation techniques
Negotiation Conflict resolution Participatory decision make
Root causes of emotions:
 Identify who you are
 Better interact with others

120. Basics of Emotional Intelligence

Self-management: Social skills:
 Self-control  Influence
 Conscientiousness  Inspirational leadership
 Adaptability  Developing others
 Drive and motivation  Teamwork and collaboration
Self-awareness: Social awareness:
 Self confidence  Empathy
 Emotional self-awareness  Organizational awareness
 Accurate self-assessment  Understanding the environment

121. How to Listen Actively and Effectively

 Internal Listening – Heard, but not very attentive
 Focus Listening – Speaker’s perspective; empathize; look for emotional indicators
 Global Listening – Higher level of awareness; develop a fuller context of message

122. Facilitating Meetings

4 Scrum Meetings:
1. Daily scrum – 15 min about status updates
2. Sprint planning meeting – product owner priorities
3. Sprint retrospective – discuss improvement for next point
4. Sprint review – discussion on actual work results from sprint

123. Negotiating with Stakeholders

Consider the priorities of user stories!
Healthy negotiations allow for give and take (trade-off), avoid zero-sum games!
  Accept – do nothing
 Avoid – create a work-around
 Ameliorate – reduce the impact
 Cover – make it invisible to the user
 Resolve – eliminate it once for all

124. Resolving Conflicts

1. Withdraw / Avoid 2. Smooth / Accommodate
3. Compromise / Reconcile 4. Force / Direct
5. Collaborate / Problem Solve

125. Making Good Project Decisions

 Participatory Decision Making
Authoritarian Participatory
o Dominates project o Team involvement
o Self-centered o Smaller team
o Control and command o Collaborative approach
o No questions o Influence over authority

126. Empowering the Project Team

 Convergent Collaboration: participating decision-making models in for conversions
for collective agreements
 Shared collaboration: share decision-making process fairly

127. Making Decisions as a Group

 Simple Voting
 Thumbs Up, Down, or Sideways
 Fist of Five Voting – Number of fingers indicates degree of support
 Highsmith Decision Spectrum – Place a checkmark on a spectrum (private + feeling)
 Section 5: Team Performance
132. Valuing People Over Processes
Develop and Support Self-organized Teams
Product owner + Customer + Proxy customer + Value management team

133. Defining the Delivering Team

Self-organized + self-directed
Delivery Team Responsibilities:
 Daily standup meetings
 Write acceptance tests
 Test and revise increments
 Product demonstrations
 Participate in retrospectives

134. Defining the Product Owner

 May change the product features and priorities
 Facilitate engagement of external project stakeholders
 Provide due date for the project
 Attend planning meetings reviews and retrospectives

135. Responsibilities of the Team Leader

136. Recognizing Project Sponsor
137. Forming the Agile Project Team
<= 12 people; complementary skills + generalizing specialists

138. Working with Generalizing Specialists

Serve in multiple roles + Switch between rules + Resolve bottlenecks

139. Building a High-Performing Team

<= 12 people; shared vision + realistic goals + strong leadership
 8 characteristics of High-Performing Team
Self-organizing Empowered
Believe they can solve any problem Committed to team success
Owns its decisions and commitments Motivated by trust
Consensus driven Participate in constructive disagreement

140. Developing the Project Team

 Self-organizing and self-directing teams are goals of agile projects.
 Teams usually do not to start as above, so they need coaching.

141. Leading the Project Team

Defining Emergent Leadership:
 Different people lead different initiatives
 High-performance teams allow multiple leaders
 No power struggle with leaders changes roles
 Leaders are self-selected not assigned

Adaptive Leadership:
Directing – happens o Team members may have low competence but high commitment
during team forming o Leaders offer high directive and low supportive behavior
Coaching – happens o Team members have some competence and low commitment
during storming o Leaders offer high directive and high supportive behavior
Supporting – happens o Team members have moderate competent and variable commitment
during norming o Leaders offer low directive and high supportive behavior
Delegating – happens o Team members have high competent and high commitment
during performing o Leaders offer low directive and low supportive behavior

142. Providing Motivation

Tuckman Model: Forming – Storming – Norming – Performing
Herzberg’s Theory of Motivation:
 Expected Hygiene Agents – Job safety / Working environment / Paycheck /
Relationship (must exist first)
 Motivating Agents – Opportunity / Responsibility / Appreciation / Recognition /
Education
143. Training the Project Team
o Training – teaching a skill or knowledge
o Coaching – a facilitated process to help individuals develop and improve performance
o Mentoring – professional relationship freer flowing
Dreyfus Model of Adult Skill Acquisition
 Novice → Advanced beginner → Competent → Proficient → Expert

Shu-Ha-Ri Model of Skill Mastery

 Shu – start by following the rules
 Ha – once the team has mastered the guidelines, they can move away from them and
work intuitively
 Ri – the team reaches full mastery and can transcend the rules

144. Coaching Team Members

Guidelines for One-on-one Coaching:
 Meet them a half a step ahead
 Guarantee safety
 Partner with managers
 Create positive regard

Encourage Constructive Disagreement!

Five Dysfunction of a Team:
1. Absence of Trust
2. Fear of Conflict
3. Lack of Commitment
4. Avoidance of Accountability
5. Inattention to results

145. Building a Collaborative Team Space

 Open floor plan
 Out of confined offices
 Two or more people over single offices
 Caves and Commons:
o Cave – Private areas for alone time, thinking
o Commons – Open areas for collaboration
146. Working with Co-Located Teams (<=33 feet or 10 meters)
147. Defining the Project Team Space
Tacit Knowledge (Large groups have more difficulty with tacit knowledge)
148. Identify Osmotic Communications
Learning by overhearing each other’s conversation. (Could be good or bad: rumor)

149. Managing Team Diversity

150. Working with Distributed Team (Virtual Team)
Distributed teams face more of a challenge in storming and norming.
Exam tips:
 Use frequent communication
 Intensified facilitation
 Use best practices for conference

151. Monitoring Team Performance

Agile measures what the team delivers, not what the team predicts it will deliver.
Agile teams limit their estimation to the next few weeks at the most.
 Small chunk of work

152. Building Burn Charts

Burn Up/Down Chart: Calculate story points

Features Chart: Remain + Complete + Total （三条线在同一副图）

153. Calculating Team Velocity / Capacity

Velocity is the measure of a team’s capacity for work per iteration.
Measure in the same unit that the team estimates the work.
Velocity very early and then stabilizes.
Velocity tends to plateau.
Could use velocity to predict how much work can be done in future iterations.
 Section 6: Adaptive Planning
157. Agile Planning Concepts
Sprint/Iteration Backlog:
 List of tasks for a team to create potentially shippable functionality.
 Sprint goal supports release goal.
 Create a boundary.
Increment:
o Doesn’t have to release every increment to customer.
o Each increment is ready to release once there is enough aggregated value.

158. Adaptive Planning

All about how we are going to get to done.
 Agile projects are value-driven, minimize non-value-added work.
 Plan to replan, uncertainty requires replanning.
 Early plans are necessary, but they are likely flawed.

159. Agile and Non-Agile Planning Activities

Agile projects do more planning than a predictive project.
 Changes to plan are normal.
 Knowledge work doesn’t follow a predictive plan.

160. Principles of Agile Planning

Plan at multiple levels Engage the team and customer in planning
Demonstrate progress in velocity Tailor processes for the project
Priorities will cause the plan to be updated Utilize estimate ranges
Base projections on completion rate Factor in diversions and outside work

161. Agile Discovery

Goal: Narrow the cone of uncertainty

162. Leading Progressive Elaboration 渐进式细化

 Progressive Elaboration: Incorporating new information into plans (Plan and build
small chunks of work)
 Rolling Wave Planning: Plan and execute iteration (Plan and do)
163. Value-Based Analysis
Value-based Decomposition:
1. Requirement elicitation
2. Grouping of like features
3. Breaking down of features
4. Ranking of requirements
5. Prioritize requirements into development

Create A Product Box: Top 3 features; Major function elements; Prioritization of features

Coarse Grained Requirements: 粗粒度要求

 Keeps the overall design balanced

 Delays decision on implementation details until the latest responsible moment.

164. Timeboxing Meetings and Events

 Daily standup meeting – 15min
 Retrospective – 2 hours
 Iterations and sprints – 1 to 4 weeks

Parkinson’s Law: Work expands to fill the time allotted to it. (negative)

165. Creating Estimate Ranges

Estimate Convergence Graph:
Initial estimates are flawed, more information → useable estimate (variance↓)

166. Working with Ideal Time

Decomposing Project Requirements
Epics – Feature – User story – Task

167. User Stories (written on index cards or sticky notes)

4-40 hours week
Who was asking for this?
Answer Software feature from end-user perspective
Why are we doing this?
  As a <role>, I want <feature> so that <reason/value>.

User Story Formats:

1. Given – the scenario for the story
2. When – the action that takes place
3. Then – the result of the action

Three C’s of User Stories:

1. Card – just enough text to identify the story
2. Conversation – details are communicated via a conversation between the customer
and the development team
3. Confirmation – customer confirmed the story has been implemented correctly

INVESTing in User Stories:

Independent Negotiable Valuable
Estimate Small Testable

Epics
o Big chunk of work with one common objective.
o Often too large to complete in one iteration.
o Epics are really placeholders of related user stories.
o Five or move related user stories should be an epic.
o Epics can span projects.

168. Creating the User Story Backlog (Product Backlog)

Decomposing stories = slicing

169. User Stories: Sizing, Estimating and Planning

Story Points: Unit of measure to estimate overall effect.

170. Breaking Down the Project

171. Grooming the Backlog

172. Utilizing Affinity Estimating 亲和力估计

Grouping items into similar categories or collections。

Group items based on story points.

Affinity estimating is like triangulation (size, risk, priority)
How to Do Affinity Estimating?
 Stories on sticky notes
 Compare to proven reference stories
 Match stories comparable reference stories (affinity)

173. Sizing T-shirts （User stories are assigned to T-shirt’s size)

174. Creating a Product Roadmap (High-level)

Big pictures views teams need to stay focused.

175. Using Wideband Delphi / Delphi Technique （基于共识的估计工作量技术）

Rounds of anonymous estimates 启动会议+估计会议

Help to build consensus

o Bandwagon effect – gathering around common viewpoint
o Highest-paid person’s opinion – HIPPO
o Groupthink – making decisions to maintain group harmony

176. Planning with Poker （同时展示数字以避免受到其他人的影响）

Cards with Fibonacci sequence

User stories review
Participants show their cards at the same time to score the user story
Planning Poker Info
 Usually after product backlog creation
 Web-based software for distributed teams
 Based on size, not hours

177. Creating Release and Iteration Plans

Iteration 0: prepare; no deliverables for customers
Iteration H:
Hardening sprint Wrap up sprint Used to stabilize the code
Document the product Compile final assembly Final testing

178. Using Spikes

Architectural Spikes: Proof of concept; Timeboxed effort to test the approach
Risk-based Spikes: Good for new technology and early in the project

179. Visioning the Releases

180. Planning for Releases
The goal is to find which stories will be done in which iterations for the release.
Also defines future iterations for future releases.

181. Planning Project Iterations

Confirms goal for the current iteration.

182. Completing Daily Stand-Ups

People with tasks must attend.
Only people who have tasks can talk.
No side conversations
Discuss issues after the stand up
 Section 7: Problem Detection and Resolution (Resolve threats and issues)
187. Controlling Project Problems
4 themes: Understand – Detect – Manage - Solve
An agile projects risk is always negative.
 Risk: uncertain events that have not yet happened
 Issues: risk events that have occurred

Problems can mushroom / have ripple effects. → secondary risk

188. Cost of Change

Longer defect unaddressed, more expensive it will be to fix.

189. Reviewing Technical Debt

Backlog of work caused by lack of regular clean-up maintenance and standardization.
Red-green-refactor
Can be caused by many factors:
o Poor upfront definition
o Pressure for value delivery
o Lack of documentation
o Parallel development

190. Creating a Safe and Open Environment

Brainstorming and retrospectives
Software development requires creativity
Culture of organization affects safety concept

191. Failure and Success Modes in a Project

192. Strategies for Success
 Balance disciplined with tolerance
 Start with something concrete and tangible
 Copy and alter
 Watch and listen
 Support both concentration and communication
193. Detecting Problems and Defects
 Escaped defects
 Fix defects upon discovery in each iteration
 Regression testing on all functionality – periodically
 Demonstrating user story solution
 UAT and end-to-end testing
 Goal: Discover and fix defects before release

194. Understanding Lead Time and Cycle Time

Lead Time (whole process) ----------subset--------- Cycle Time (part process)
 Lead Time: From Backlog to Deployment
 Cycle Time: From Development to Deployment
Productivity ≠ Efficiency
Defect cycle time is the amount of time between when the defect was discovered and when
the defect was fixed.
The longer the defect cycle time typically the more expensive the defect.

195. Completing Variance Analysis

What was planned minus what was experienced

196. Identifying Trends in a Project

Trend Analysis aims to predict performance or problems.
o Lagging Metrics: Measurement of past experiences
o Leading Metrics: Provide view to future

197. Setting Control Limits

Upper and Lower control limits
Set boundaries and expectations for performance.
WIP and Kanban are a form of control limits.

Assignable cause: Out of Control, there’s some reasons why we have this big variance.
Rule of Seven: Trend and Non-random, need more investigation why below mean.
198. Creating a Risk-Adjusted Backlog
Expected Monetary Value (EMV) = risk probability * risk impact

199. Determining Risk Severity

Risk impact: low/medium/high

200. Creating Risk Burndown Charts

Sprint increases, Exposure decreases.

201. What’s the Problem

202. Solving Problems in Agile Projects
Some problems can’t be solved  Work around these problems  Track and monitor the
problems

Negative Risk Response:

1. Mitigation
2. Transference
3. Avoidance
4. Acceptance
 Section 8: Continuous Improvement
207. Leading Continuous Improvement as a Process
Lesson Learned
o Lessons learned are captured in each iteration
o Allows lessons to be applied in next iteration
o Lessons are repeated until they are learned

Kaizen: meaning change for the better; small incremental steps for improvement
PDCA Cycle: Plan – Do – Check – Act

208. Tailoring Process

Adapting agile for your environment.
There is some risk with tailoring.
Risk and Reward of Process Tailoring
1. First, embrace traditional agile processes before tailoring.
2. Second, examine the motivation for changing processes.

209. Completing Systems Thinking

210. Participating in Process Analysis
Breakdown of the process flow.
Identify inputs, tools and techniques, outputs.
Understand how the process works.
Tools for Process Analysis:
 Flowcharts – illustrate flow of process
 Failure Mode Effects Analysis (FMEA) – identify and address all failures starting
with largest (Failure modes / causes / effects)
 Mistake-proofing process – balance of defect free and efficiency

211. Creating Value Stream Maps

A visual map of a process flow to identify delays, waste, and constraints.

212. Hosting a Project Pre-Mortem

Aims to find failure points before they happen.
o Imagine the failure.
o Generate the reason for failure.
o Consolidate the list.
o Revisit the plan.

213. Leading Product Review Sessions

PDCA Cycle: Plan – Do – Check – Act (Quality improvement and process improvement)

214. Examining a Product Feedback Loop

215. Understanding Approved Iterations
216. Leading a Retrospective
Why needs retrospective?
 Improve productivity
 Improve capabilities
 Quality improvement
 Capacity improvement

Explorer / Shopper / Vacationer / Prisoner

217. Completing Team Assessments

Use velocity to measure individual performance.
Team self-assessment scoring model
1. Thinking 2. Collaborating 3. Releasing
4. Planning 5. Developing