2. 2
Based on Geoffrey Moore’s Technology Adoption Life Cycle Curve
PMI-ACP AND ADOPTION CURVE
The
chasm
PMPACP
We are
here!
3. 3
KNOWLEDGE & SKILLS (50% OF EXAM)
Percentage of Knowledge and Skill Content / % of Exam
Level 1 (66% / 33%)
(18 knowledge/skills)
Level 2 (24% / 12%)
(12 knowledge/skills)
Level 3 (10% / 5%)
(13 knowledge/skills)
Active listening Agile frameworks and terminology Agile contracting methods
Agile Manifesto values & principles Building high-performance teams Agile project accounting principles
Assessing and incorporating community and
stakeholder values
Business case development Applying new Agile practices
Brainstorming techniques Colocation (geographic proximity)/distributed
teams
Compliance (organization)
Building empowered teams Continuous improvement processes Control limits for Agile projects
Coaching and mentoring within teams Elements of a project charter for an Agile project Failure modes and alternatives
Communications management Facilitation methods Globalization, culture, and team diversity
Feedback techniques for product (e.g.,
prototyping, simulation, demonstrations,
evaluations)
Participatory decision models (e.g., input based,
shared collaboration, command)
Innovation games
Incremental delivery PMI's Code of Ethics and Professional Conduct Principles of systems thinking (e.g., complex
adaptive, chaos)
Knowledge sharing Process analysis techniques Regulatory compliance
Leadership tools and techniques Self assessment Variance and trend analysis
Prioritization Value-base analysis Variations in Agile methods and approaches
Problem-solving strategies, tools, and techniques Vendor management
Project and quality standards for Agile projects
Stakeholder management
Team motivation
Time, budget, and cost estimation
Value-based decomposition and prioritization
4. 4
TOOLS & TECHNIQUES (50% OF EXAM)
Communications
•information radiator, team space, agile
tooling, osmotic communications for
colocated and/or distributed teams,
daily stand-ups
Planning, monitoring, and
adapting
•retrospectives, task/Kanban boards,
timeboxing, iteration and release
planning, WIP limits, burn down/up
charts, cumulative flow diagrams,
process tailoring
Agile estimation
•relative sizing/story points, wide band
Delphi/planning poker, affinity
estimating, ideal time
Agile analysis and design
•product roadmap, user stories/backlog,
story maps, progressive elaboration,
wireframes, chartering, personas, agile
modeling
Product quality
•frequent verification and validation,
test-driven development/test first
development, acceptance test-driven
development, definition of done,
continuous integration
Soft skills negotiation
•emotional intelligence, collaboration,
adaptive leadership, negotiation,
conflict resolution, servant leadership
Value-based prioritization
•return on investment (ROI)/net present
value (NPV)/internal rate of return (IRR),
compliance, customer-valued
prioritization, minimally marketable
feature (MMF), relative
prioritization/ranking
Risk management Metrics
•risk- adjusted backlog, risk burn down
graphs, risk-based spike Metrics
Including but not limited to: velocity,
cycle time, earned value management
(EVM) for agile projects, escaped defects
Value stream analysis
•value stream mapping
6. 7
• ON FEBRUARY 11-13, 2001, AT SNOWBIRD SKI RESORT, SEVENTEEN
PEOPLE MET TO TALK, SKI, RELAX, AND TRY TO FIND COMMON GROUND.
• REPRESENTATIVES FROM EXTREME PROGRAMMING, SCRUM, DSDM,
ADAPTIVE SOFTWARE DEVELOPMENT, CRYSTAL, FEATURE-DRIVEN
DEVELOPMENT, PRAGMATIC PROGRAMMING, AND OTHERS SYMPATHETIC
TO THE NEED FOR AN ALTERNATIVE TO DOCUMENTATION DRIVEN,
HEAVYWEIGHT SOFTWARE DEVELOPMENT PROCESSES CONVENED.
• WHAT EMERGED FROM THIS MEETING WAS A SYMBOLIC MANIFESTO FOR
AGILE SOFTWARE DEVELOPMENT, SIGNED BY ALL PARTICIPANTS.
AGILE MANIFESTO
7. 8
AGILE IS NOT NEW
1943
1950
-
1960
s
198
5
199
0
199
5
199
6
199
7
199
8
200
0
200
1
USAF & NASA
X-15 hypersonic jet
Iterative
Incremental Delivery
Hirotaka Takeuchi
& Ikujiro Nonaka
The New New
Product
Development Game
1990 - Sutherland
& Schwaber
Scrum Framework
DSDN Consortium
Dynamic System
Development
Method
1996 - Beck,
Cunningham,
Jeffries
Extreme
Programming
Jeff de Luca
Feature
Driven
Development
Alistair Cockburn
Crystal
Methodologies
Robert Charette
Lean
Development
Agile
Manifesto
Taiichi Ohno
Toyota Production
System
Kanban
Hardware Software
9. 10
AGILE TOOLS
Process Tools
VersionOne
Rally Software
JIRA + GreenHopper
Team Foundation Server
Excel
Kanban
AgileZen
LeanKit Kanban
Kanbanery
Engineering Tools
Continuous Integration
http://jenkins-ci.org/
http://hudson-ci.org/
http://cruisecontrol.sourceforge.net
/
Engineering Tools
Ruby
Cucumber for
ATDD/BDD: http://cukes.info/
RSpec: http://rspec.info/
Java
http://www.junit.org/
http://www.jmock.org/
.Net
http://www.nunit.org/
BDD for .NET:
http://www.specflow.org/
http://www.nmock.org/
10. 11
AGILE MANIFESTO VALUES
Individuals &
interactions
Processes & toolsover
Working software
Comprehensive
documentation
over
Customer
collaboration
Contract negotiationover
Responding to change Following a planover
That is, while there is value in the items on
the right, we value the items on the left
more.
We are uncovering better ways of developing software by doing
it and helping others do it. Through this work we have come to
value:
Source:
www.agilemanifesto.org
11. 12
AGILE MANIFESTO PRINCIPLES
Satisfy the
Customer
Welcome
Change
Deliver
Frequently
Collaborate
Daily
Support & Trust
Motivated
Teams
Promote
Face-to-Face
Conversations
Deliver Working
Software
Promote
Sustainable
Pace
Promote
Technical
Excellence
Maximize
Through
Simplicity
Have
Self-Organized
Teams
Reflect & Adjust
Regularly
Source:
www.agilemanifesto.org
13. 14
FLIPPING THE IRON TRIANGLE
Features Cost Date
Cost
Dat
e
Features
Source: DSDM
Plan-
Driven
Value-
Driven
$
14. 15
AGILE METHODS
SUPPORT
EXPERIMENTATION &
ADAPTATION BY
REDUCING THE COST
OF CHANGE.
THIS IS DONE BY
EMPLOYING MANY
CONCURRENT, RAPID
FEEDBACK LOOPS TO
SURFACE AND
ADDRESS RISKS EARLY.
REDUCING THE COST OF CHANGE
Source: Examining the Cost of the Agile Change Curve by Scott
Ambler
15. 16
COMMON UNDERSTANDING
A document can’t generate the meaning in others that
conversations can.
There is a reason “Individuals and Interactions” is first
in the Agile Manifesto.
? ?
!
We don’t need an
accurate document, we
need a shared
understanding
- Jeff Patton / Agile 2012
16. 17
Deploy
Documen
t $
INCREMENTAL VALUE DELIVERY
Agile Concurrent
Development
• Fund incrementally – opt to
extend, redirect or cancel at a
very granular level
• Deliver & realize value steadily
• Validate designs with users &
customers
• Continuously adapt to risk and
change
• Integrate early & often
Waterfall Serial Development
Invest up front, only realize value at end, assuming value proposition
hasn’t changed
Test
Code
Design
Analyze
$$
$
Analyze
Design
Code
Test
Deploy
Document
Analyze
Design
Code
Test
Deploy
Document
Analyze
Design
Code
Test
Deploy
Document
$ $$
17. 18
COLLABORATION AND FEEDBACK LOOPS
Traditional methods only work for so long because…
• No or little feedback before delivery.
• Change not expected.
Why are agile methods being considered?
• Constant feedback loops.
• Change is expected.
18. 19
PROCESS BURDEN OR LACK OF
DISCIPLINE
• HISTORICALLY DEVELOPMENT TEAMS HAVE
FACED A FALSE CHOICE IN RESPECT TO
PROCESS
o OVERLY COMPLEX AND BURDENSOME
o OR, UNDISCIPLINED WITH NO CONTROLS
• AGILE PROVIDES A LIGHTWEIGHT, BUT
DISCIPLINED APPROACH FOR SPEEDING TIME
TO MARKET, IMPROVING QUALITY, AND
INCREASING PREDICTABILITY
AGILE IS DISCIPLINE W/O UNDUE BURDEN
19. 20
FOUR VOLUNTEERS, PLEASE!
TIME IS SET AT 2 MINUTES
ESTIMATE THROUGHPUT
ROUND 1 (MEASURE FIRST AND LAST DELIVERY TIME)
• FIRST PERSON FLIPS 50 COINS
• WHEN DONE WITH ENTIRE BATCH, PASS TO NEXT
PERSON
ROUND 2
• FIRST PERSON FLIPS ONE COIN OF HIGHEST VALUE AND PASSES TO NEXT PERSON
• KEEP FLIPPING AND PASSING UNTIL DONE
ROUND 3
• EACH TABLE CREATES THEIR OWN RULES TO MAXIMIZE COIN FLOW/THROUGHPUT IN LEAST AMOUNT
OF TIME
RETROSPECTIVE
EXERCISE – BATCH VS FLOW THROUGHPUT
20. 21
Key Agile Principles Traditional Waterfall
Focus on Highest Value First
Align project, product and team visions by prioritizing by business needs, and
using well architected code, to deliver better quality products faster and
cheaper.
All or nothing
Tight coupling & bias toward building out internals in a breadth first
fashion means that nothing can be delivered in isolation, even if it’s
valuable.
Responding to Change
Acknowledge uncertainty & adapt to both external (market) and internal
changes, by modifying plans & approach. Use engineering principles to make
code base easy to modify.
Baseline & Change Control
Constrain or even completely eliminate any significant change other
than dropping features. Work to initial plans, even when they are
proven to be invalid.
Iterative
Use short time boxes to provide a rhythm, continually flow of value to the
customer, and refine deliverables over time.
Phased
No rhythm as project is executed using long phases.
Feedback & Continuous Improvement
Use continual feedback to inform plans and modify approach.
Lessons Learned at the End
Feedback is rarely given in time for it to be applied towards improving
processes and project execution.
Small, Integrated Teams
A small team size, and overlap in skills sets, simplifies communications, allows
everyone to see the big picture, creates self discipline and provides flexibility.
Silo Teams with Handoffs
Staff works in functional oriented groups, throwing documentation
and code over the wall.
Technical Excellence / Bake Quality In
Use TDD , ATDD, refactoring, and other strong engineering principles to
ensure quality.
Inspection
Attempt to ensure quality by after the fact inspection.
AGILE PRINCIPLES COMPARED
21. 22
AGILE IS EMPIRICAL, NOT DEFINITIVE
Agile assumes that
baselines may change
significantly during
the project.
In such an
unpredictable
environment,
empirical methods
should be used to
monitor progress and
direct change, rather
than using definitive
methods to try and
predict progress and
stop change.
22. 23
ROLLING WAVE PLANNING, USED IN AGILE PROCESSES, EMBRACES
THE LEAN IDEAL OF MAKING DECISIONS AT THE LAST
RESPONSIBLE MOMENT, WHEN THE MOST POSSIBLE
INFORMATION IS AVAILABLE. THIS MAXIMIZES FLEXIBILITY AND
PLANNING ACCURACY.
AGILE USES ROLLING WAVE PLANNING
Level of Planning Planning Approach
Strategic product line goals Strategic Planning
Strategic product goals Product Planning
Specific problems to solve Lean / Six Sigma
Large functional goals Release Planning
Small, defined work items Iteration Planning
Tactical organization & execution Daily Standup
23. 24
LAYERS OF PRODUCT PLANNING
Product /
Project
What business objectives
will the product fulfill?
Product Goals
Product Charter
Elevator Pitch
Release
How can we release
value incrementally?
What subset of
business objectives will
each release achieve?
What user
constituencies will the
release serve?
What general
capabilities (big stories)
will the release offer?
Release Roadmap
Release Plan
Iteration /
Sprint
What specifically will we
build? (User Stories)
How will this iteration
move us toward release
objectives?
Iteration Plan
Development Tasks
Story (Backlog
Item)
What user or stakeholder
need will the story serve?
How will it specifically look
and behave?
How will I determine if it’s
completed?
Story Details
Acceptance Tests
24. 25
• TOP LEVEL GOAL(S) MUST BE
COMMUNICATED TO ALL
LEVELS OF THE
ORGANIZATION
• MEMBERS OF THE
ORGANIZATION OFFER
CANDID INFORMATION UP
THE MANAGEMENT LADDER.
• LEADERS/MANAGERS OFFER
GUIDANCE
(WHY AND WHAT ≠
HOW)
PRINCIPLE - SELF-ORGANIZED AND EMPOWERED
info
guide
info
guide
info
guideinfo
guide
25. 26
SOME BASIC TERMINOLOGY
Scrum
Extreme Programming
(XP)
Definition
Sprint Iteration
Fixed-length period of time
(timebox)
Release Small Release Release to production
Sprint/Release
Planning
Planning Game Agile planning meetings
Product Owner Customer
Business representative to
project
Retrospective Reflection “Lessons learned”-style meeting
ScrumMaster Coach Agile project manager
Development
Team
Team
Empowered Cross-Functional
team
Daily Scrum Daily Standup Brief daily status meeting
26. 27
SOME MORE AGILE TERMINOLOGY
Term Definition
Spike
Something cannot be estimated until a development team
runs a timeboxed investigation. The spike itself is a throw-
away.
Can include risk, architectural, or any unknown.
Tracer Bullet
An experimental solution that cuts through all the "layers" of
the architecture. It is not necessarily time-boxed. It is not
intended to be thrown away.
Kaizen
Continual improvement of all areas of a company not just
quality.
Value Stream
An end-to-end business process which delivers a product or
service
More
terms…
Go to the Community Guide of the PMI-ACP at
http://agile.vc.pmi.org/
27. 28
Session Purpose Timing/Durati
on
Attendees
Iteration 0 Orient Team to project’s business
value and analytical background,
the process, and one another.
Start of project
Approximately 1-
3 weeks of 2-4 hr
workshops
Team, PO, SM, Key
Stakeholders &
users
Release
Planning
Determine what a Release should
include and when it should be
delivered.
Start of Release
2-4 hours
PO, SM, Key
Stakeholders,
optionally Team
Daily
Standup
Facilitate rapid coordination
between Team members, and with
PO.
Daily
10-15 minutes
Team, SM, PO
Iteration
Planning
Elaborate, estimate and prioritize
highest-value Product Backlog
items for an Iteration.
Start of each
Iteration
2-4 hours
Team, SM, PO
Iteration
Retrospective
Reflect on project & process issues
and take action as appropriate.
End of each
Iteration
30-45 minutes
Team, SM, PO
Iteration
Review
Demonstrate completed
functionality to interested
stakeholders & users to show
progress and gain feedback.
End of each
Iteration
1-1½ hours
Team, PO, SM, Key
Stakeholders &
users
MEETINGS SUMMARIZED
28. 29
SMALL TEAMS WITH EVERYTHING NEEDED TO DELIVER
AN INCREMENT OF VALUE
BACKLOG PRIORITIZED BY VALUE BEING DELIVERED
INCREMENTALLY
AT SCALE, THE BACKLOG AND PRODUCTS FOR THESE
TEAMS NEED TO BE COORDINATED AND TECHNICAL
PRACTICES MUST ADDRESS THE CHALLENGES OF
INTEGRATION
HOW DOES AGILE WORK?
29. 30
Deploy
Documen
t $
INCREMENTAL VALUE DELIVERY
Agile Concurrent
Development
• Fund incrementally – opt to
extend, redirect or cancel at a
very granular level
• Deliver & realize value steadily
• Validate designs with users &
customers
• Continuously adapt to risk and
change
• Integrate early & often
Waterfall Serial Development
Invest up front, only realize value at end, assuming value proposition
hasn’t changed
Test
Code
Design
Analyze
$$
$
Analyze
Design
Code
Test
Deploy
Document
Analyze
Design
Code
Test
Deploy
Document
Analyze
Design
Code
Test
Deploy
Document
$ $$
30. 31
INCREMENTAL AND ITERATIVE DELIVERY
Incrementing is more about delivery.
1 2 3 4 5
1 2 3 4 5
Iterating allows you to move from vague
idea to realization. Going from rough to
polished
Image Credit: Jeff Patton
31. 32
• ITERATIONS ARE REGULARLY SCHEDULED, PRE-PLANNED, RECURRING
TIME BOXES. PROVIDE A CADENCE / RHYTHM THAT PROVIDES
PREDICTABILITY AND SYNCHRONIZATION POINTS FOR PLANNING. THE
MORE MATURE YOUR PROCESS, THE SHORTER THE ITERATIONS.
• THINGS WE TIME-BOX:
o SPRINTS (OR ITERATIONS) - LENGTH OF TIME IN WHICH WORK IS DONE
o RELEASES - PRODUCTION AND MAINTENANCE
o WORKING SESSIONS - RELEASE PLANNING, SPRINT PLANNING, SPRINT REVIEW,
RETROSPECTIVE
• ITERATIONS FACILITATE INCREMENTAL DEVELOPMENT (BUT
INCREMENTAL
DEVELOPMENT DOESN’T REQUIRE ITERATIONS).
ITERATIONS
33. 34
“A PRODUCTION PRACTICE
THAT CONSIDERS THE
EXPENDITURE OF
RESOURCES FOR ANY
GOAL OTHER THAN THE
CREATION OF VALUE FOR
THE END CUSTOMER TO
BE WASTEFUL, AND THUS
A TARGET FOR
ELIMINATION.“
WHAT IS LEAN?
Source: Wikipedia
34. 35
KANBAN (看板) LITERALLY
MEANING "SIGNBOARD" OR
"BILLBOARD", IS A
CONCEPT RELATED
TO LEAN AND JUST-IN-
TIME (JIT) PRODUCTION.
TAIICHI OHNO IS
CONSIDERED TO BE THE
FATHER OF THE TOYOTA
PRODUCTION SYSTEM
WHAT IS KANBAN?
Kanban is a scheduling system that tells
you what to produce, when to
produce it, and how much to produce.
35. 36
• A SOFTWARE DEVELOPMENT METHODOLOGY WHICH IS INTENDED
TO IMPROVE SOFTWARE QUALITY AND RESPONSIVENESS TO
CHANGING CUSTOMER REQUIREMENTS.
• IT ADVOCATES FREQUENT "RELEASES" IN SHORT DEVELOPMENT
CYCLES, WHICH IS INTENDED TO IMPROVE PRODUCTIVITY AND
INTRODUCE CHECKPOINTS WHERE NEW CUSTOMER REQUIREMENTS
CAN BE ADOPTED.
WHAT IS EXTREME PROGRAMMING?
36. 37
SCRUM IS AN ITERATIVE AND INCREMENTAL PROJECT DELIVERY
FRAMEWORK.
WHAT IS “SCRUM?”
Source: Wikipedia
37. 38
Iteration 0
Brief orientation to the
project’s business value
and analytical
background, the Agile
process, and the Team.
Project Orientation
• Business case overview
• Business process
analysis
• Project scope &
objectives
• Initial Product Backlog
Process Orientation
• Agile process training
• Sprint/Release cycles
• Definition of “Done”
Team Orientation
• Team room artifacts
• Team norms
• Technical environments,
design, architecture, etc
INITIATING AN AGILE
PROJECT
Release Planning Session
Initial project
planning, to
review initial
Product Backlog
and set
production
Release dates.
Release
Schedule
Product Backlog
List of desired
functionality prioritized by
business value by Product
Owner.
Allow a user to create a
free account. (Priority 1)
Allow subscribers to
purchase music. (Priority
3)
Allow user to personalize
store experience. (Priority
9)
38. 39
A USEFUL PROJECT CHARTER CONTAINS THREE KEY ELEMENTS:
1. VISION: THE VISION DEFINES THE “WHY” OF THE PROJECT. THIS IS THE HIGHER PURPOSE,
OR THE REASON FOR THE PROJECT’S EXISTENCE.
2. MISSION: THIS IS THE “WHAT” OF THE PROJECT AND IT STATES WHAT WILL BE DONE IN
THE PROJECT TO ACHIEVE ITS HIGHER PURPOSE.
3. SUCCESS CRITERIA: THE SUCCESS CRITERIA ARE MANAGEMENT TESTS THAT DESCRIBE
EFFECTS OUTSIDE OF THE SOLUTION ITSELF.
ADDITIONAL ELEMENTS:
WORKING PRACTICES – PLANNING, ESTIMATING, DEFINITION OF DONE, TRACKING PROGRESS,
TDD METHODS
CONTINUOUS INTEGRATION – INTEGRATION TIME LIMITS, BREAKING THE BUILD, CODE CHECK-
IN
CODE – PAIRED PROGRAMMING, OWNING THE CODE, DOCUMENTATION
ITERATIVE AND INCREMENTAL DEVELOPMENT – ITERATION CYCLE AND DEPLOYMENT CYCLE
AGILE PROJECT CHARTER
40. 41
LEAN PORTFOLIO MANAGEMENT
• Corporate strategy operates over years with direct line of sight to
priorities
• Optimize the whole
• Manage internal and external dependencies
• Focus on quickly delivering minimal marketable features
• Clear feedback mechanism between business and development
• Creates alignment beyond single teams
Year(s): Set corporate goals and strategies
Quarter(s): Discover and create innovative product strategies from
corporate goals
Month(s): Update Release Plans, Product Backlogs and
Roadmaps
Week(s): Decompose features from Product Backlog
into tasks and deliver working code
41. 42
THE 7 PRINCIPLES OF LEAN
1. ELIMINATE WASTE
2. CREATE KNOWLEDGE
3. BUILD QUALITY IN
4. DEFER COMMITMENT
5. OPTIMIZE THE WHOLE
6. DELIVER FAST
7. RESPECT PEOPLE
7 PRINCIPLES OF LEAN
Source: Mary and Tom Poppendieck
42. 53
PROCESS CYCLE EFFICIENCY IS THE KEY MEASURE OF LEANNESS
PROCESS MAP ENTIRE VALUE-STREAM AT A HIGH LEVEL, DRILLING DOWN INTO MORE DETAIL ONLY AS POTENTIAL
AREAS OF INTEREST ARE IDENTIFIED
• VALUE-ADDED: THIS STEP IN THE PROCESS ADDS FORM, FUNCTION, AND VALUE TO THE END PRODUCT AND FOR
THE CUSTOMER.
• NON-VALUE-ADDED: THIS STEP DOES NOT ADD FORM, FUNCTION, OR ASSIST IN THE FINISHED GOODS
MANUFACTURING OF THE PRODUCT.
• NON-VALUE-ADDED-BUT-NECESSARY: THIS STEP DOES NOT ADD
VALUE, BUT IS A NECESSARY STEP IN THE FINAL VALUE-ADDED PRODUCT.
LEAN PROCESS CYCLE EFFICIENCY
PCE = (sum of time for Value Added process
steps)
(sum of time for All process steps)
43. 56
THE “KAIZEN” MINDSET:
1. EVERYTHING, NOT JUST SOFTWARE
DEVELOPMENT, CAN AND SHOULD BE
IMPROVED
2. IMPROVEMENTS SHOULD BE MADE
DAY TO DAY
3. THE BEST IMPROVEMENTS COME
FROM TAKING THE CUSTOMER’S
POINT OF VIEW
4. MOVE FROM CRITICISM TO
SUGGESTION
5. KEEP IMPROVING, EVEN IF THINGS
ARE WORKING
CONTINUOUS IMPROVEMENT
改善
45. 60
1. VISUALIZE YOUR WORKFLOW
2. LIMIT YOUR WORK IN PROCESS
EXAMPLE: MATURE REQUIREMENTS SEPARATELY
• INSTEAD OF FIGURING EVERYTHING OUT FOR A USER STORY JUST IN TIME
AT SPRINT PLANNING, WE CAN READY THEM IN ADVANCE
• THE SPECIFIC PROCESS VARIES, BUT THERE IS A SET OF STEPS TO GET A
REQUIREMENT READY
KANBAN – HIGH LEVEL
New
Candidates PO
Approved
Decompose
d
Acceptance
Criteria
Testable
Example
Dev Review Ready for
Sprint
10 cards 6 cards 4 cards 4 cards 4 cards 8 cards 12 cards
46. AIRPLANE GAME
PAPER AIRPLANE GAME
• TEAM OF 5 MAKES 21
AIRPLANES
• 1ST RUN: FAST AS YOU CAN
• 2ND RUN: FLOW, BATCH SIZE
OF ONE
• CONSISTENTLY BETTER
RESULTS
• LEAD TIME: 3X
IMPROVEMENT
• THROUGHPUT: 10-20%
BETTER
47. 62
EVERYTHING AT ONCE
=
MANY STARTED
FEW FINISHED
COSTS OF OVER-UTILIZATION
Develop Test
In Process Ready In Process Ready
4 slots 3 slots 4 slots 3 slots
WIP Limits = Fast
“A system of local optimums is not an
optimum system at all” - Eli Goldratt
49. 64
AGILE ENGINEERING PRACTICES ALLOW
TEAMS TO MOVE FAST, BE FLEXIBLE AND
DELIVER HIGH QUALITY SOFTWARE:
• AUTOMATED BUILDS & CONTINUOUS
INTEGRATION REDUCE TIME AND
EFFORT ASSOCIATED WITH MANUAL
BUILDS, AND RISK FROM BIG-BANG
INTEGRATIONS
• SIMPLE DESIGN & REFACTORING KEEP
INCREMENTAL DEVELOPMENT FROM
LEADING TO POOR ARCHITECTURES
• MULTI-LEVEL/AUTOMATED TESTING &
TEST-DRIVEN DEVELOPMENT REDUCE
TESTING TIME AND EFFORT AND ALLOW
DEVELOPERS TO MAKE CHANGES WITH
CONFIDENCE
• PAIR PROGRAMMING INCREASES
SOFTWARE QUALITY WITHOUT
IMPACTING TIME TO DELIVER.
AGILE ENGINEERING PRACTICES
Source: Bill Wake, http://www.xp123.com
50. 65
XP COACH
• THE XP COACH ROLE HELPS A TEAM STAY ON PROCESS AND HELPS THE TEAM TO LEARN. A COACH BRINGS AN
OUTSIDE PERSPECTIVE TO HELP A TEAM SEE THEMSELVES MORE CLEARLY. THE COACH WILL HELP BALANCE THE
NEEDS OF DELIVERING THE PROJECT WHILE IMPROVING THE USE OF THE PRACTICES. A COACH OR TEAM OF COACHES
SUPPORTS THE CUSTOMER TEAM, THE DEVELOPER TEAM, AND THE ORGANIZATION.
• THE DECISIONS THAT COACHES MAKE SHOULD ALWAYS STEM FROM THE XP VALUES (COMMUNICATION, SIMPLICITY,
FEEDBACK, AND COURAGE) AND USUALLY MOVE TOWARD THE XP PRACTICES. AS SUCH, FAMILIARITY WITH THE
VALUES AND PRACTICES IS A PREREQUISITE. THE COACH MUST COMMAND THE RESPECT REQUIRED TO LEAD THE
RESPECTIVE TEAMS. THE COACH MUST POSSESS PEOPLE SKILLS AND BE EFFECTIVE IN INFLUENCING THE ACTIONS OF
THE TEAMS.
• THE XP COACH USES MANY DIFFERENT TECHNIQUES. THE COACH IS A MENTOR, WORKING SIDE BY SIDE WITH TEAM
MEMBERS ON THEIR TASKS. THE COACH IS A FACILITATOR, HELPING ACHIEVE MORE EFFECTIVE TEAM PERFORMANCE.
THE COACH IS A CONDUIT, REINFORCING COMMUNICATION WITHIN THE TEAM AND ACROSS TEAMS.
XP ROLES - COACH
51. 66
XP CUSTOMER
• THE XP CUSTOMER ROLE HAS THE RESPONSIBILITY OF DEFINING WHAT IS THE
RIGHT PRODUCT TO BUILD, DETERMINING THE ORDER IN WHICH FEATURES WILL
BE BUILT AND MAKING SURE THE PRODUCT ACTUALLY WORKS.
• THE XP CUSTOMER WRITES SYSTEM FEATURES IN THE FORM OF USER STORIES
THAT HAVE BUSINESS VALUE. USING THE PLANNING GAME, HE CHOOSES THE
ORDER IN WHICH THE STORIES WILL BE DONE BY THE DEVELOPMENT TEAM.
DEFINES ACCEPTANCE TESTS THAT WILL BE RUN AGAINST THE SYSTEM TO
PROVE THAT THE SYSTEM IS RELIABLE AND DOES WHAT IS REQUIRED.
XP ROLES - CUSTOMER
52. 67
XP PROGRAMMER
• THE XP PROGRAMMER IS RESPONSIBLE FOR IMPLEMENTING THE CODE TO
SUPPORT THE USER STORIES.
XP ROLES - PROGRAMMER
53. 68
XP TESTER
• THE PRIMARY RESPONSIBILITY OF THE XP TESTER IS TO HELP THE
CUSTOMER DEFINE AND IMPLEMENT ACCEPTANCE TESTS FOR USER
STORIES. THE XP TESTER IS ALSO RESPONSIBLE FOR RUNNING THE TESTS
FREQUENTLY AND POSTING THE RESULTS FOR THE WHOLE TEAM TO SEE.
AS THE NUMBER OF TESTS GROW, THE XP TESTER WILL LIKELY NEED TO
CREATE AND MAINTAIN SOME
KIND OF TOOL TO MAKE IT EASIER TO DEFINE
THEM, RUN THEM, AND GATHER THE RESULTS
QUICKLY.
XP ROLES - TESTER
54. 1. ______ IS RESPONSIBLE FOR IMPLEMENTING
THE CODE TO SUPPORT THE USER STORIES.
2. ______ HELP THE CUSTOMER DEFINE AND
IMPLEMENT ACCEPTANCE TESTS FOR USER
STORIES
3. ______ HELPS A TEAM STAY ON PROCESS
AND HELPS THE TEAM TO LEARN. IS A
MENTOR, WORKING SIDE BY SIDE WITH
TEAM MEMBERS ON THEIR TASKS
4. ______ WRITES SYSTEM FEATURES IN THE
FORM OF USER STORIES THAT HAVE
BUSINESS VALUE AND DEFINES ACCEPTANCE
TESTS.
XP ROLES – QUICK QUIZ
a) XP COACH
b) XP CUSTOMER
c) XP PROGRAMMER
d) XP TESTER
1(c)2(d)3(a)4(b)
55. 72
SIMPLE DESIGN:
• CODE IS ALWAYS TESTABLE, BROWSABLE, UNDERSTANDABLE, AND EXPLAINABLE
• DO THE SIMPLEST THING THAT COULD POSSIBLY WORK NEXT. COMPLEX DESIGN IS
REPLACED WITH SIMPLER DESIGN
• THE BEST ARCHITECTURES, REQUIREMENTS, AND DESIGNS EMERGE FROM SELF-
ORGANIZING TEAMS
REFACTORING:
• REMOVE REDUNDANCY, ELIMINATE UNUSED FUNCTIONALITY, AND REJUVENATE
OBSOLETE DESIGNS
• REFACTORING THROUGHOUT THE ENTIRE PROJECT LIFE CYCLE SAVES TIME AND
INCREASES QUALITY
• CODE IS KEPT CLEAN AND CONCISE SO IT IS EASIER TO UNDERSTAND,
MODIFY, AND EXTEND
SIMPLE DESIGN AND REFACTORING
57. 80
CREATE A RISK CENSUS DURING THE FIRST SPRINT PLANNING MEETING AND THEN UPDATE IT
QUICKLY DURING SUBSEQUENT PLANNING MEETINGS AS NEW RISKS ARE IDENTIFIED OR AS THE
PROBABILITIES OR SIZES OF KNOWN RISKS CHANGE.
RISK BURNDOWN
As with a regular release burndown
chart, we should see a linear drop in
risk over the course of the project.
Plot your project risk exposure
and display it with other big
visible charts in your team
area.
Source: Managing Risk on Agile Projects | Mike Cohn - Mountain Goat
Software
58. 81
RISK MANAGEMENT
Traditional Risk Management Agile Risk Management
Prepare formal risk management
plan
Educate the team. Invite them to
determine best approach to
manage
Formal risk identification
meetings and then create Risk
Register
Team identifies risks in all
meetings and add to information
radiators
Conduct qualitative and
quantitative analysis. Determine
how to respond
Facilitate the team in a qualitative
analysis, determine how to
respond, post results
Periodically review Risk Register
and make updates as needed
Constantly review risk and
responses as part of all meetings,
reviews and retrospectives
Source: Sliger & Broderick (2008),The Software Project Manager's Bridge to Agility, Addison-
Wesley
59. 82
IMPLICITLY MANAGING RISK:
• USER STORIES ARE PRIORITIZED BY THE PRODUCT OWNER
o HIGHEST VALUE ITEMS ARE ATTACKED FIRST
o HIGHEST RISK ITEMS ARE ALSO ATTACKED EARLY
• ITERATIVE DELIVERY ENSURES THAT INTEGRATION AND ROLLOUT RISKS ARE
ATTACKED VERY EARLY IN THE PROJECT LIFECYCLE
• TECHNICAL DISCIPLINE HELPS KEEP A TIGHT REIN ON DEVELOPMENT RISK
o AUTOMATED BUILDS AND CONTINUOUS INTEGRATION KEEP CODE INTEGRATION AND
CODE QUALITY RISK TO A MINIMUM
IMPLICIT RISK MANAGEMENT
60. 83
EXPLICITLY MANAGING RISK:
• REVIEW THE PRODUCT BACKLOG
• IDENTIFY AND LIST RISKS BY
IMPACT (HIGH/MEDIUM/LOW) AND
PROBABILITY (HIGH/MEDIUM/LOW)
• PROVIDE A MITIGATION PLAN WITH
CLEAR RESPONSIBILITY
• CREATE TASK CARDS FOR RISK
MITIGATION ITEMS
• INSERT INTO PRODUCT BACKLOG
AND/OR SPRINT BACKLOGS; OR
TRACK ON RISK BOARD
EXPLICIT RISK MANAGEMENT
Agile Risks, Agile Rewards, Smith and Pichler, Dr. Dobb’s 2005
62. 85
User Interface Layer
Business Logic Layer
Persistence Layer
WORK IN AGILE PROJECTS IS ORGANIZED BY UNITS OF VALUE, RATHER
THAN BY ARCHITECTURAL LAYER.
WORK ORGANIZED BY VALUE
Feature / User Story
2
Feature / User Story
1
Feature / User Story
3
63. 86
KEY CHARACTERISTICS
• HIGH-LEVEL DESCRIPTIONS OF
DESIRED FUNCTIONALITY AND
GOALS
• IMPLEMENT “VERTICAL SLICES”
OF THE SYSTEM’S
FUNCTIONALITY
• “CONTRACTS FOR
CONVERSATION,” NOT ALL-
INCLUSIVE REQUIREMENTS
• USER STORIES WAIT IN THE
PRODUCT BACKLOG UNTIL
PULLED INTO THE SPRINT
BACKLOG
• CONTAIN ACCEPTANCE CRITERIA
TO DEFINE “DONE”
USER STORIES AT A GLANCE
As a user I can create an
account.
Estimate 21 Points
Priority 1 (High)
As a user I can enter a
user name.
Estimate 4 points
Priority 1 (High)
As a user I can enter
password.
Estimate 8 points
Priority 1 (High)
Product Backlog User
Story
Sprint Backlog
User Stories
64. 87
FROM USER STORIES TO
TASKS
Tasks
As a user I can enter a
password.
Estimate 8 points
Priority 1 (High)
Acceptance Criteria
User Story
On
back…
• Design user interface
• Develop CSS/HTML
• Create database fields
• Develop validation
criteria
• Write test cases
• Code test fixtures
• Unit testing
• Acceptance testing
• Usability testing
• Write online help text
• Password match
validated
• Contains special
characters
• Minimum 10 digits
• Cannot be text only
65. 88
AS A <TYPE OF USER>,
I CAN <IMMEDIATE
GOAL>
SO THAT <BUSINESS
OUTCOME>.
USER STORY TEMPLATE
User Role
(Who?)
Desired Function
(What?)
End Result
(Why?)
Who, What, Why…
what’s not here?
66. 89
ACCEPTANCE CRITERIA HELP TO SET SCOPE AND DEFINE WHAT
DONE MEANS FOR A GIVEN USER STORY.
USER STORY ACCEPTANCE CRITERIA
•Verify that a premium member can cancel
the same day without a fee.
•Verify that a non-premium member is
charged 10% for a same-day cancellation.
•Verify that an email confirmation is sent.
•Verify that the hotel is notified of any
cancellation.
As a user, I can cancel a
reservation.
67. 90
CIRCLE WHICH ATTRIBUTES
MAKE A GOOD STORY AND
THEN DISCUSS AS THE GROUP
WHAT MAKES A GOOD STORY?
Independent
Valuable
Testable
CreativeEstimatabl
e
Small
Negotiable
Source: Bill Wake
68. 91
PRE RELEASE LIFE OF A USER STORY
• Phone # in US format,
contains no alpha characters,
minimum 10 digits
• First name, Last name and
email address required
• Email specified in standard
format
• Etc.
Acceptance Criteria Created
Prior to Release Planning
As a user
I want to create an account
User Stories Created Prior to
Release Planning
Sprint Tasks Created
at Sprint Planning
• Design UI Mock Up
• Write online help text
• Develop CSS/HTML
• Develop validation criteria
• Create database tables
• Code test fixtures
• Code
• Perform testing
Name Phone Email Valid
John
Smith
215-555-
1212
jsmith@ls.co
m TRUE
Smith
215-555-
1212
jsmith@ls.co
m FALSE
John
215-555-
1212
jsmith@ls.co
m FALSE
215-555-
1212
jsmith@ls.co
m FALSE
John
Smith
jsmith@ls.co
m FALSE
Smith
jsmith@ls.co
m FALSE
John
jsmith@ls.co
m FALSE
Testable Examples (ATDD) Created Prior
to Sprint Planning
Estimate 5-Points
Priority 1 -High
(Created at Release Planning)
69. 92
USER STORIES AREN’T THE ONLY WAY TO DEVELOP, EXPRESS AND ELABORATE
REQUIREMENTS IN AGILE. SOME COMPLEMENTARY TOOLS & METHODS INCLUDE:
• ESSENTIAL USE CASES
• LOW-FIDELITY PROTOTYPING
• HIGH-FIDELITY PROTOTYPING
THE BEST APPROACH WILL BE DETERMINED BY YOUR TEAM AND THE PROBLEMS AT HAND.
BEYOND USER STORIES
70. 93
LOW-FIDELITY
PROTOTYPING IS A FAST,
CHEAP, EASILY ITERATED,
COLLABORATIVE WAY TO
TEST VARIOUS CONCEPTS
& APPROACHES.
LOW-FIDELITY PROTOTYPING IN AGILE
Tools
• Paper sketches and collages
• Whiteboard drawings
Applications
• Concept design: to explore different metaphors and design
strategies
• Interaction design: to organize screen structure & flow
• Screen design: for initial screen layout & design
• Screen testing: to refine screen layoutSource Adaptive Path for Sketchboard example
71. 94
HIGH-FIDELITY PROTOTYPES ARE
DETAILED, INTERACTIVE AND REUSABLE
MEANS OF SIMULATION.
TOOLS:
• PHOTOSHOP, VISIO, POWERPOINT
• FLASH, IRISE STUDIO, SERENA
PROCESSVIEW
• WPF, XAML, XUL…
APPLICATIONS:
• WHEN STABLE REQUIREMENTS SUPPORT
REUSE
• TO TEST COMPLEX INTERACTION
SCENARIOS
• TO FINALIZE DETAILED DESIGNS
• AS INPUTS TO A SPRINT
HIGH-FIDELITY PROTOTYPING IN AGILE
Source: iRise Studio, www.irise.com
72. 1. IN GENERAL, WE CAN VIEW THE
MATURATION OF A NEED (EXPRESSED AS A
USER STORY) AS HAVING ENOUGH
INFORMATION TO PRIORITIZE,
__________ AND ___________.
2. THE USER STORY FORMAT HAS THREE
PARTS:
“AS A”, “I WANT TO” AND “_________.”
3. ACCEPTANCE CRITERIA IS WRITTEN FOR
TEAM MEMBERS AND, AS SUCH, ASSUMES
A LEVEL OF EXISTING ___________.
4. ACCEPTANCE CRITERIA IS INCREDIBLY
USEFUL BUT A ___________ WILL OFTEN
PROVIDE SIGNIFICANT ADDITIONAL
CLARITY.
AGILE REQUIREMENTS
a) BUILD
b) DOMAIN
KNOWLEDGE
c) ESTIMATE (TEST)
d) OUTSIDERS
e) SO THAT
f) TESTABLE
EXAMPLE
1(c)(a)2(e)3(b)4(f)
73. 5. A ___________ DEFINES HOW THE SOFTWARE WILL
BE IMPLEMENTED; IT CAN DEFINE THE EXTERNAL
BEHAVIOR, ___________ DESIGN, OR BOTH.
6. AS DEFINED IN THIS TRAINING, A SPECIFICATION
BUILDS ON A REQUIREMENT WITH ADDITIONAL
CONTEXT, CONVERSATIONS AND ___________.
7. A SPECIFICATION SHOULD BE ___________,
DEFINING JUST ENOUGH TO HELP THE TEAM BUILD
CONFIDENTLY WITHIN THE SPRINT.
8. THE APPROPRIATE LEVEL OF DETAIL REQUIRED IN A
SPECIFICATION WILL ___________, DEPENDING ON,
AMONG OTHER THINGS, THE ___________ OF THE
REQUIREMENT, THE DOMAIN KNOWLEDGE OF THE
TEAM, AND THE REQUIREMENTS’ SIMILARITY TO
WHAT HAS ALREADY BEEN BUILT.
AGILE REQUIREMENTS
g) COMPLEXITY
h) DESIGNS
i) INTERNAL
j) LIGHTWEIGHT
k) SPECIFICATION
l) VARY
5(k)(i)6(h)7(j)8(l)
(g)
75. 98
HIGH LEVEL – AFFINITY STORY LEVEL –
PLANNING POKER
STORY POINTS
o PURELY RELATIVE MEASURE OF COMPLEXITY (2 IS HALF AS
HARD AS 4)
o VARIABILITY AVERAGES OUT ACROSS MANY STORIES
o DON’T DECAY OVER TIME
SCALES WITH INCREASING GAPS BETWEEN ELEMENTS
ARE PREFERRED
o FIBONACCI: 1, 2, 3, 5, 8, 13
o DOUBLES: 1/2, 1, 2, 4, 8, 16
o “T-SHIRT SIZES:” S, M, L, XL, XXL
AGILE ESTIMATION LEVELS, UNITS AND SEQUENCES
Traditional project
estimation approaches
may be necessary for
initial scoping, but should
rapidly be replaced by
empirical observation of
Team output capacity
(velocity).
Avoid false precision to
avoid false expectations.
76. 99
1. USE MORE THAN ONE PERSON. BY ENGAGING THE TEAM IN THE ESTIMATION PROCESS, WE GAIN THE BENEFITS OF
ADDITIONAL INSIGHTS AND CONSENSUS BUILDING.
2. USE MORE THAN ONE APPROACH. USE MULTIPLE ESTIMATION APPROACHES (COMPARISON TO SIMILAR PROJECTS,
BOTTOM UP, USER STORY POINTS, ETC.) AND LOOK FOR CONVERGENCE BETWEEN MULTIPLE APPROACHES TO
REINFORCE LIKELY ESTIMATE RANGES.
3. AGREE ON WHAT “IT” AND “DONE” MEANS. MAKE SURE EVERYONE IS ESTIMATING IN THE SAME UNITS, HAVE THE
SAME ASSUMPTIONS AND ARE BASED ON STANDARD DEVELOPER ABILITY/EFFORT.
4. KNOW WHEN TO STOP. BALANCE ESTIMATION EFFORT AGAINST THE DIMINISHING RETURNS AND FALSE
ACCURACIES OF OVER ANALYSIS.
5. PRESENT ESTIMATES AS A RANGE. ESTIMATES ARE OFTEN POOR PREDICTIONS, AND SHOULD BE NOTED AS SUCH.
6. DEFEND/EXPLAIN ESTIMATE RANGE PROBABILITIES. EDUCATE STAKEHOLDERS ABOUT THE RELATIVE LIKELIHOOD
OF HITTING OPTIMISTIC/PESSIMISTIC ESTIMATES.
7. DON’T RESERVE ESTIMATING FOR WHEN YOU KNOW LEAST ABOUT THE PROJECT. ESTIMATION SHOULD NOT BE
RESERVED FOR ONLY THE BEGINNING OF PROJECTS.
8. BE AWARE OF COMMON ESTIMATION OMISSIONS. DON’T OVERLOOK COMMONLY MISSED TASKS, AND USE
RETROSPECTIVES TO INSPECT PROJECT-SPECIFIC ISSUES.
9. EMBRACE REALITY EARLY. DON’T UNDER-ESTIMATE THE LOAD OF MAINTAINING AND REFACTORING A GROWING
CODEBASE.
10.REVIEW, REVISIT, REMOVE HEAD FROM SAND, REPEAT. ADJUST PROJECT FORECAST BASED ON EMPIRICAL
AGILE ESTIMATION
ESSENTIALS
77. 100
PARTICIPANTS: WHOLE TEAM
MULTI-TEAM ENVIRONMENT: WORK TOGETHER!
PROCESS: CARDS ARE PLACED IN A STACK ON THE TABLE
• PRODUCT OWNER EXPLAINS THE TOP CARD
• FIRST TEAM MEMBER PLACES THIS CARD ON
TABLE BY SIZE (LEFT SMALLER, RIGHT LARGER)
• NEXT TEAM MEMBER EITHER REPEATS PROCESS WITH NEXT CARD, OR MOVES AN
EXISTING CARD TO A NEW POSITION, WITH AN ASSOCIATED EXPLANATION
• PROCESS REPEATS UNTIL ALL CARDS ARE PLACED AND GROUPED, AND NO MORE
MOVEMENT IS DESIRED
• EACH GROUP IS LABELED WITH ITS ESTIMATE
AFFINITY ESTIMATING
Smaller
Larger
78. 101
• CLIFFORD THE BIG RED
DOG
• MARMADUKE
• ENGLISH BULLDOG
• CHIHUAHUA
• PUG
• SCOOBY-DOO
• GREAT DANE
EXERCISE – RELATIVE DOG SIZING
Rules Point Estimating:
Team decides scale
Discuss criteria for complexity
Find the reference point
Estimate size for remaining items
Based on Mike Cohn’s dog
points
79. 102
“PLANNING POKER” IS BASED ON “WIDEBAND DELPHI” CONVERGENT
ESTIMATION TECHNIQUES.
HOW TO DO IT:
1. EACH ESTIMATOR (SOMEONE WHO COULD POSSIBLY BE DOING THE
WORK IN QUESTION) IS GIVEN A DECK OF CARDS, EACH CARD HAS A
VALID ESTIMATE WRITTEN ON IT
2. A MODERATOR READS A STORY AND IT’S DISCUSSED BRIEFLY
3. EACH ESTIMATOR SELECTS A CARD TO REPRESENT HER ESTIMATE
4. CARDS ARE TURNED OVER SO ALL CAN SEE THEM
5. DISCUSS DIFFERENCES (ESPECIALLY OUTLIERS)
6. RE-ESTIMATE UNTIL ESTIMATES CONVERGE (OR DON’T!)
AGILE ESTIMATION – PLANNING POKER
83. 106
THERE ARE ONLY THREE ROLES DEFINED IN SCRUM:
SCRUM ROLES & RESPONSIBILITIES
Product Owner
•Owns Product vision
•Defines features, decides
on release date and
content
•Responsible for market
success
•Prioritizes features
according to market value
•Can change features and
priorities every Sprint
ScrumMaster
•Responsible for
facilitating process
•Focuses Team and
protects them from
external interruption
•Looks for ways to
enhance productivity
•Assists Product Owner in
leveraging Scrum
The Team
•Small group containing
all necessary project
skills
•Focuses on steady
delivery of high quality
features
•Generates options for
delivery
•Manages own work within
Sprints
84. 107
• PRODUCT BACKLOG
PRIORITIZED LIST OF VALUABLE
ITEMS TO DELIVER DURING THE
PROJECT.
• SPRINT BACKLOG
LIST OF COMMITTED ITEMS TO BE
ADDRESSED WITHIN A SPRINT.
• BURNDOWN/BURN-UP CHART
VISUAL AID FOR TRACKING
TEAM PROGRESS AND
FORECASTING EXPECTED
COMPLETION DATES.
• VELOCITY CHART
TRACKS RATE OF FEATURE
COMPLETION.
ARTIFACTS OF SCRUM
85. 108
SCRUM MILESTONES
Product
Backlog
• ____________
• ____________
• ____________
• ____________
• ____________
F3 F6
Release
1
F1, F2,
F3
Release
2
F1, F2,
F3
F4, F5,
F6
Initial
Planning
Release
Planning
Release
Planning
F1
F2
F2 F1 F4
F5F3
U
S
1
U
S
2
U
S
3
U
S
4
U
S
5
U
S
6
U
S
7
U
S
8
U
S
1
U
S
2
U
S
3
U
S
4
U
S
5
U
S
6
U
S
7
U
S
8
Release
Planning
Sprint
Backlo
g
• ______
• ______
Sprint
Backlo
g
• ______
• ______
Sprint
Backlo
g
• ______
• ______
Sprint
Backlo
g
• ______
• ______
Sprint
Backlo
g
• ______
• ______
Sprint
Backlo
g
• ______
• ______
Sprint
Planning
Sprint
Planning
Sprint
Planning
Sprint
Planning
Sprint
Planning
Sprint
Planning
86. AGILE PRINCIPLES (1/2)
1. Value oriented: Our highest priority is to satisfy the customer through early and
continuous delivery of valuable software.
2. Flexibility: Welcome changing requirements, even late in development. Agile
processes harness change for the customer's competitive advantage.
3. Iterative: Deliver working software frequently, from a couple of weeks to a couple of
months, with a preference to the shorter timescale.
4. Team: Business people and developers must work together daily throughout the
project.
5. Team: Build projects around motivated individuals. Give them the environment and
support they need, and trust them to get the job done.
6. Team/Communication: The most efficient and effective method of conveying
information to and within a development team is face-to-face conversation.
87. AGILE PRINCIPLES (2/2)
7. Communication: Working software is the primary measure of progress.
8. Communication: Agile processes promote sustainable
development. The sponsors, developers, and users should be able to
maintain a constant pace indefinitely.
9. Quality: Continuous attention to technical excellence and good design
enhances agility.
10.Quality: Simplicity-the art of maximizing the amount of work not done-is
essential.
11.Team: The best architectures, requirements, and designs emerge from
self-organizing teams.
12.Retrospective: At regular intervals, the team reflects on how to become
more effective, then tunes and adjusts its behaviour accordingly.
89. AGILE METHODOLOGY - SUMMARY
Strengths Weaknesses
Scrum
Complements existing practices.
Priorities based on business value.
Self organizing teams and feedback.
Customer participation and steering.
Only approach that has a certification
process.
Only provides project management support, other
disciplines are out of scope.
Does not specify technical practices.
Can take some time to get the business to provide unique
priorities for each requirement.
Strong technical practices.
Customer ownership of feature priority,
developer ownership of estimates.
Frequent feedback opportunities.
Most widely known and adopted
approach in the US
Requires onsite customer.
Documentation primarily through verbal communication
and code. For some teams these are the only artifacts
created, others create minimal design and user
documentation.
Difficult for new adopters to determine how to
accommodate architectural and design concerns.
FDD
Supports multiple teams working in
parallel.
All aspects of a project tracked by
feature.
Scales to large teams or projects well.
Design by feature and build by feature
aspects are easy to understand and
adopt.
Promotes individual code ownership as opposed to
shared/team ownership.
Iterations are not as well defined by the process as other
Agile methodologies.
The model-centric aspects can have huge impacts when
working on existing systems that have no models.
看板
Kanban
Changes can be made any time
Remove activities that don’t add value
Scalable
No prescribed roles
No time boxing notion
Limit WIP
Based on what you do today
Cross-functional teams.
Complements existing practices.
Does not specify technical practices.
Requires constant gathering of metrics which may be
90. AGILE METHODOLOGY - SUMMARY
Strengths Weaknesses
AUP
Robust methodology with many artifacts and disciplines
to choose from.
Scales up very well.
Documentation helps communicate in distributed
environments.
Priorities set based on highest risk. Risk can be a
business or technical risk.
Higher levels of ceremony may be a hindrance in
smaller projects.
Documentation is much more formal than most
approaches mentioned here.
Minimal attention to team dynamics.
Crysta
l
Family of methodologies designed to scale by project
size and criticality.
Only methodology that specifically accounts for life
critical projects.
As project size grows, cross-functional teams are
utilized to ensure consistency.
An emphasis on testing is so strong that at least one
tester is expected to be on each project team.
The "human" component has been considered for every
aspect of the project support structure.
Expects all team members to be co-located. May
not work well for distributed teams.
Adjustments are required from one project
size/structure to another in order to follow the
prescribed flavor of Crystal for that project
size/criticality.
Moving from one flavor of Crystal to another in mid
project doesn't work, as Crystal was not designed to
be upward or downward compatible.
DSDM
An emphasis on testing is so strong that at least one
tester is expected to be on each project team.
Designed from the ground up by business people, so
business value is identified and expected to be the
highest priority deliverable.
Specific approach to determining how important each
requirement is to an iteration.
Set stakeholder expectations from the start of the
project that not all requirements will make it into the
final deliverable.
Probably the most heavyweight project
Defines several artifacts and work products for each
phase of the project; heavier documentation.
Expects continuous user involvement.
Access to material is controlled by a Consortium,
and fees may be charged just to access the
reference material.
91. METHODOLOGIES MOTTO
Methodology Summarizing Phrase
Scrum Prioritized Business Value
XP Simplicity
FDD Business Model
AUP Manage Risk
Crystal Size and Criticality
DSDM Current Business Value
Lean
Return on Investment (ROI) – Eliminating
waste
Kanban Work In Process (WIP)
92. ROLES
3 MAIN ROLES
• TEAM LEAD (SCRUM MASTER)
• PRODUCT LEAD
• THE TEAM
OTHER PERIPHERAL ROLES
• SPONSOR
• EXPERTS
Team Lead
Product
Lead
The team
Scrum Scrum Master Product Owner Different roles
XP Big boss Customer Programmer, Tracker, Tester
AUP Project Manager architect
Crysta
l
Project Manager
Business
expert
lead enginneer, designer,
programmer, tester, writer
DSDM Project Manager ambassador User
Advisor User, Technical coordinator,
Team leader, tester, scribe, facilitator,
FDD Project Manager
Chief programmer, programers,
testers, Class Owner, Domain expert,
chief architect