SlideShare una empresa de Scribd logo
1 de 94
Descargar para leer sin conexión
AGILE CERTIFIED
PRACTITIONER
(PMI-ACP)
Gobi Durairaj, PMI-PMP, ACP, PBA, SAFe Agilist.,
2
Based on Geoffrey Moore’s Technology Adoption Life Cycle Curve
PMI-ACP AND ADOPTION CURVE
The
chasm
PMPACP
We are
here!
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
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
Agile History
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
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
AGILE PRACTICES
Lean
Kanban
PMBOK
Agile is an umbrella term for a group of
iterative and incremental software development
methods.
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/
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
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
Understanding the
Basics
14
FLIPPING THE IRON TRIANGLE
Features Cost Date
Cost
Dat
e
Features
Source: DSDM
Plan-
Driven
Value-
Driven
$
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
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
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
$ $$
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.
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
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
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
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.
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
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
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
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
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/
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
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?
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
$ $$
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
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
Agile Methods
Lean
Kanban
Extreme Programming
Scrum
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
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.
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?
37
SCRUM IS AN ITERATIVE AND INCREMENTAL PROJECT DELIVERY
FRAMEWORK.
WHAT IS “SCRUM?”
Source: Wikipedia
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)
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
Lean
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
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
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)
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
改善
Kanban
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
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
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
Extreme Programming
(XP)
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
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
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
67
XP PROGRAMMER
• THE XP PROGRAMMER IS RESPONSIBLE FOR IMPLEMENTING THE CODE TO
SUPPORT THE USER STORIES.
XP ROLES - PROGRAMMER
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
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)
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
Risk
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
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
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
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
Agile Requirements
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
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
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
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?
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.
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
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)
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
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
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
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)
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)
Agile Estimation
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.
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
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
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
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
103
5
PLANNING POKER EXAMPLE
55Bill (Dev)
52Ann (BA)
58Vijay (QA)
33Susan (Dev)
Round 2Round 1Estimator
Scrum
105
SCRUM – 50,000 FOOT VIEW
Release
Planning
Sprint
Planning
Sprint
Review
Sprint
Retrospectiv
e
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
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
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
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.
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.
111
VARIOUS AGILE
METHODOLOGIES
看板
Lean
FDD
DSDM
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
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.
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)
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
AGILE PROCESS OVERVIEW
Envision
•Vision
•NPV
•ROI
Initiation
•Identify
Personas
•Create
backlog
•High
level
estimates
•Create
roadmap
Release
Planning
•Slicing
stories
•Stories
estimatio
ns
•Create
release
plan
Iteration 0
•Spikes
•Detailing
Next
iteration
stories
Iteration
•Iteration
planing
•Coding
•Testing
•Daily stand-
ups &
Updating
burn-ups
•Iteration
review
•Retrospective
•Preparing
stories for
Next iteration
Closing
•Project
close out
•Finishing
contracts
•Resource
release
IT Edge 116PMI-Pub 3 December 2014
117
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

Más contenido relacionado

La actualidad más candente

Generate a Shipley Associates Compliance Matrix
Generate a Shipley Associates Compliance MatrixGenerate a Shipley Associates Compliance Matrix
Generate a Shipley Associates Compliance MatrixAtebion, LLC
 
Sure Hit PMP @ First Attempt - Chapter Wise Summary Notes & Q & A’s Integrat...
Sure Hit PMP @ First Attempt - Chapter Wise  Summary Notes & Q & A’s Integrat...Sure Hit PMP @ First Attempt - Chapter Wise  Summary Notes & Q & A’s Integrat...
Sure Hit PMP @ First Attempt - Chapter Wise Summary Notes & Q & A’s Integrat...SN Panigrahi, PMP
 
Introduction agile scrum methodology
Introduction agile scrum methodologyIntroduction agile scrum methodology
Introduction agile scrum methodologyAmit Verma
 
PMI-ACP : PMI - Agile Certified Practitioner
PMI-ACP : PMI - Agile Certified PractitionerPMI-ACP : PMI - Agile Certified Practitioner
PMI-ACP : PMI - Agile Certified PractitionerSaket Bansal
 
What does a Scrum Master do, or should do, all day?
What does a Scrum Master do, or should do, all day? What does a Scrum Master do, or should do, all day?
What does a Scrum Master do, or should do, all day? Stefania Marinelli
 
PMP Training - 11 project risk management
PMP Training - 11 project risk managementPMP Training - 11 project risk management
PMP Training - 11 project risk managementejlp12
 
Green Belt Project Storyboard Template Example
Green Belt Project Storyboard Template Example Green Belt Project Storyboard Template Example
Green Belt Project Storyboard Template Example GoLeanSixSigma.com
 
Agile Software Development Methodologies
Agile Software Development MethodologiesAgile Software Development Methodologies
Agile Software Development Methodologieselvinefendi
 
User Acceptance Testing (Uat)
User Acceptance Testing (Uat)User Acceptance Testing (Uat)
User Acceptance Testing (Uat)Thomas Martin
 
PMI-ACP: Domain 3 - Stakeholder engagement-v2.2_lite_2_46_pages
PMI-ACP: Domain 3 - Stakeholder engagement-v2.2_lite_2_46_pagesPMI-ACP: Domain 3 - Stakeholder engagement-v2.2_lite_2_46_pages
PMI-ACP: Domain 3 - Stakeholder engagement-v2.2_lite_2_46_pagesPhuocNT (Fresher.VN)
 
PMI-ACP - Agile Framework
PMI-ACP - Agile FrameworkPMI-ACP - Agile Framework
PMI-ACP - Agile FrameworkWafi Mohtaseb
 
Failure Mode Effect Analysis (FMEA)
Failure Mode Effect Analysis (FMEA)Failure Mode Effect Analysis (FMEA)
Failure Mode Effect Analysis (FMEA)DEEPAK SAHOO
 
Agile Testing Process
Agile Testing ProcessAgile Testing Process
Agile Testing ProcessIntetics
 
Scrum process powerpoint ppt slides.
Scrum process powerpoint ppt slides.Scrum process powerpoint ppt slides.
Scrum process powerpoint ppt slides.SlideTeam.net
 
Agile Requirements Gathering Techniques
Agile Requirements Gathering TechniquesAgile Requirements Gathering Techniques
Agile Requirements Gathering TechniquesOnur Demir
 
Business Process Improvement
Business Process ImprovementBusiness Process Improvement
Business Process ImprovementAnand Subramaniam
 

La actualidad más candente (20)

Generate a Shipley Associates Compliance Matrix
Generate a Shipley Associates Compliance MatrixGenerate a Shipley Associates Compliance Matrix
Generate a Shipley Associates Compliance Matrix
 
Sure Hit PMP @ First Attempt - Chapter Wise Summary Notes & Q & A’s Integrat...
Sure Hit PMP @ First Attempt - Chapter Wise  Summary Notes & Q & A’s Integrat...Sure Hit PMP @ First Attempt - Chapter Wise  Summary Notes & Q & A’s Integrat...
Sure Hit PMP @ First Attempt - Chapter Wise Summary Notes & Q & A’s Integrat...
 
Introduction agile scrum methodology
Introduction agile scrum methodologyIntroduction agile scrum methodology
Introduction agile scrum methodology
 
PMI-ACP : PMI - Agile Certified Practitioner
PMI-ACP : PMI - Agile Certified PractitionerPMI-ACP : PMI - Agile Certified Practitioner
PMI-ACP : PMI - Agile Certified Practitioner
 
What does a Scrum Master do, or should do, all day?
What does a Scrum Master do, or should do, all day? What does a Scrum Master do, or should do, all day?
What does a Scrum Master do, or should do, all day?
 
Project Sign Off Tempalte
Project Sign Off TempalteProject Sign Off Tempalte
Project Sign Off Tempalte
 
Apqp ppt
Apqp pptApqp ppt
Apqp ppt
 
PMP Training - 11 project risk management
PMP Training - 11 project risk managementPMP Training - 11 project risk management
PMP Training - 11 project risk management
 
Green Belt Project Storyboard Template Example
Green Belt Project Storyboard Template Example Green Belt Project Storyboard Template Example
Green Belt Project Storyboard Template Example
 
Agile practice guide
Agile practice guideAgile practice guide
Agile practice guide
 
Agile Software Development Methodologies
Agile Software Development MethodologiesAgile Software Development Methodologies
Agile Software Development Methodologies
 
User Acceptance Testing (Uat)
User Acceptance Testing (Uat)User Acceptance Testing (Uat)
User Acceptance Testing (Uat)
 
PMI-ACP: Domain 3 - Stakeholder engagement-v2.2_lite_2_46_pages
PMI-ACP: Domain 3 - Stakeholder engagement-v2.2_lite_2_46_pagesPMI-ACP: Domain 3 - Stakeholder engagement-v2.2_lite_2_46_pages
PMI-ACP: Domain 3 - Stakeholder engagement-v2.2_lite_2_46_pages
 
PMI-ACP - Agile Framework
PMI-ACP - Agile FrameworkPMI-ACP - Agile Framework
PMI-ACP - Agile Framework
 
Failure Mode Effect Analysis (FMEA)
Failure Mode Effect Analysis (FMEA)Failure Mode Effect Analysis (FMEA)
Failure Mode Effect Analysis (FMEA)
 
Agile Testing Process
Agile Testing ProcessAgile Testing Process
Agile Testing Process
 
Scrum process powerpoint ppt slides.
Scrum process powerpoint ppt slides.Scrum process powerpoint ppt slides.
Scrum process powerpoint ppt slides.
 
Dar Training
Dar TrainingDar Training
Dar Training
 
Agile Requirements Gathering Techniques
Agile Requirements Gathering TechniquesAgile Requirements Gathering Techniques
Agile Requirements Gathering Techniques
 
Business Process Improvement
Business Process ImprovementBusiness Process Improvement
Business Process Improvement
 

Similar a Agile certified practitioner Exam Notes

PMI-ACP Training Deck
PMI-ACP Training DeckPMI-ACP Training Deck
PMI-ACP Training Deckwjperez0629
 
PMI-ACP Introduction by PMI-LA
PMI-ACP Introduction by PMI-LAPMI-ACP Introduction by PMI-LA
PMI-ACP Introduction by PMI-LAprojectation
 
Agile Development Overview
Agile Development OverviewAgile Development Overview
Agile Development Overviewguestb4c770
 
About Agile & PMI Agile Certified Practitioner (PMI-ACP) Overview
About Agile & PMI Agile Certified Practitioner (PMI-ACP) OverviewAbout Agile & PMI Agile Certified Practitioner (PMI-ACP) Overview
About Agile & PMI Agile Certified Practitioner (PMI-ACP) OverviewAleem Khan
 
Agile Development Overview
Agile Development OverviewAgile Development Overview
Agile Development OverviewMark Kovacevich
 
#Fundamental understanding of agile - By SN Panigrahi
#Fundamental understanding of agile - By SN Panigrahi#Fundamental understanding of agile - By SN Panigrahi
#Fundamental understanding of agile - By SN PanigrahiSN Panigrahi, PMP
 
Project Management to Enterprise Agile Product Delivery
Project Management to Enterprise Agile Product DeliveryProject Management to Enterprise Agile Product Delivery
Project Management to Enterprise Agile Product DeliveryLeadingAgile
 
Agile project management using scrum
Agile project management using scrumAgile project management using scrum
Agile project management using scrumPrudentialSolutions
 
Solit 2014, Agile ValueTeam, учимся понимать Scrum, Семенченко Антон
Solit 2014, Agile ValueTeam, учимся понимать Scrum, Семенченко АнтонSolit 2014, Agile ValueTeam, учимся понимать Scrum, Семенченко Антон
Solit 2014, Agile ValueTeam, учимся понимать Scrum, Семенченко Антонsolit
 
Manoj Kolhe - Testing in Agile Environment
Manoj Kolhe - Testing in Agile EnvironmentManoj Kolhe - Testing in Agile Environment
Manoj Kolhe - Testing in Agile EnvironmentManoj Kolhe
 
Agile Project Management - An introduction to Agile and the new PMI-ACP
Agile Project Management - An introduction to Agile and the new PMI-ACPAgile Project Management - An introduction to Agile and the new PMI-ACP
Agile Project Management - An introduction to Agile and the new PMI-ACPDimitri Ponomareff
 
Advancing Testing Program Maturity in your organization
Advancing Testing Program Maturity in your organizationAdvancing Testing Program Maturity in your organization
Advancing Testing Program Maturity in your organizationRamkumar Ravichandran
 
#Agile Methodology - Fundamental Principles & Basics - By SN Panigrahi
#Agile Methodology - Fundamental Principles & Basics - By SN Panigrahi#Agile Methodology - Fundamental Principles & Basics - By SN Panigrahi
#Agile Methodology - Fundamental Principles & Basics - By SN PanigrahiSN Panigrahi, PMP
 
Introduction to Agile Project Management
Introduction to Agile Project ManagementIntroduction to Agile Project Management
Introduction to Agile Project ManagementSemen Arslan
 
Agile, down the rabbit hole
Agile, down the rabbit holeAgile, down the rabbit hole
Agile, down the rabbit holeAmit Khanna
 
BSG tackling the fallacy of "Agile"
BSG tackling the fallacy of "Agile"BSG tackling the fallacy of "Agile"
BSG tackling the fallacy of "Agile"BSGAfrica
 
Scaling agile. Agile across the enterprise
Scaling agile. Agile across the enterpriseScaling agile. Agile across the enterprise
Scaling agile. Agile across the enterpriseDarren Wilmshurst
 

Similar a Agile certified practitioner Exam Notes (20)

PMI-ACP Training Deck
PMI-ACP Training DeckPMI-ACP Training Deck
PMI-ACP Training Deck
 
Michigan Agile Presentation
Michigan Agile PresentationMichigan Agile Presentation
Michigan Agile Presentation
 
PMI-ACP Introduction by PMI-LA
PMI-ACP Introduction by PMI-LAPMI-ACP Introduction by PMI-LA
PMI-ACP Introduction by PMI-LA
 
Agile Development Overview
Agile Development OverviewAgile Development Overview
Agile Development Overview
 
About Agile & PMI Agile Certified Practitioner (PMI-ACP) Overview
About Agile & PMI Agile Certified Practitioner (PMI-ACP) OverviewAbout Agile & PMI Agile Certified Practitioner (PMI-ACP) Overview
About Agile & PMI Agile Certified Practitioner (PMI-ACP) Overview
 
Agile Development Overview
Agile Development OverviewAgile Development Overview
Agile Development Overview
 
Agile Project Management
Agile Project ManagementAgile Project Management
Agile Project Management
 
#Fundamental understanding of agile - By SN Panigrahi
#Fundamental understanding of agile - By SN Panigrahi#Fundamental understanding of agile - By SN Panigrahi
#Fundamental understanding of agile - By SN Panigrahi
 
Project Management to Enterprise Agile Product Delivery
Project Management to Enterprise Agile Product DeliveryProject Management to Enterprise Agile Product Delivery
Project Management to Enterprise Agile Product Delivery
 
Agile project management using scrum
Agile project management using scrumAgile project management using scrum
Agile project management using scrum
 
Solit 2014, Agile ValueTeam, учимся понимать Scrum, Семенченко Антон
Solit 2014, Agile ValueTeam, учимся понимать Scrum, Семенченко АнтонSolit 2014, Agile ValueTeam, учимся понимать Scrum, Семенченко Антон
Solit 2014, Agile ValueTeam, учимся понимать Scrum, Семенченко Антон
 
Agile+Slides.pdf
Agile+Slides.pdfAgile+Slides.pdf
Agile+Slides.pdf
 
Manoj Kolhe - Testing in Agile Environment
Manoj Kolhe - Testing in Agile EnvironmentManoj Kolhe - Testing in Agile Environment
Manoj Kolhe - Testing in Agile Environment
 
Agile Project Management - An introduction to Agile and the new PMI-ACP
Agile Project Management - An introduction to Agile and the new PMI-ACPAgile Project Management - An introduction to Agile and the new PMI-ACP
Agile Project Management - An introduction to Agile and the new PMI-ACP
 
Advancing Testing Program Maturity in your organization
Advancing Testing Program Maturity in your organizationAdvancing Testing Program Maturity in your organization
Advancing Testing Program Maturity in your organization
 
#Agile Methodology - Fundamental Principles & Basics - By SN Panigrahi
#Agile Methodology - Fundamental Principles & Basics - By SN Panigrahi#Agile Methodology - Fundamental Principles & Basics - By SN Panigrahi
#Agile Methodology - Fundamental Principles & Basics - By SN Panigrahi
 
Introduction to Agile Project Management
Introduction to Agile Project ManagementIntroduction to Agile Project Management
Introduction to Agile Project Management
 
Agile, down the rabbit hole
Agile, down the rabbit holeAgile, down the rabbit hole
Agile, down the rabbit hole
 
BSG tackling the fallacy of "Agile"
BSG tackling the fallacy of "Agile"BSG tackling the fallacy of "Agile"
BSG tackling the fallacy of "Agile"
 
Scaling agile. Agile across the enterprise
Scaling agile. Agile across the enterpriseScaling agile. Agile across the enterprise
Scaling agile. Agile across the enterprise
 

Último

Agile Journey - Don’t DO agile, BE agile
Agile Journey - Don’t DO agile, BE agileAgile Journey - Don’t DO agile, BE agile
Agile Journey - Don’t DO agile, BE agileZuzana (Zuzi) Sochova
 
International Volunteer Programs presentation
International Volunteer Programs presentationInternational Volunteer Programs presentation
International Volunteer Programs presentationvwbinternational045
 
Mirko Corna - Google Certifications - Senior Project Manager
Mirko Corna - Google Certifications - Senior Project ManagerMirko Corna - Google Certifications - Senior Project Manager
Mirko Corna - Google Certifications - Senior Project ManagerMirko Corna
 
Creativity and Design Thinking - 2024.pdf
Creativity and Design Thinking  - 2024.pdfCreativity and Design Thinking  - 2024.pdf
Creativity and Design Thinking - 2024.pdfLuís Gustavo Martins
 
Choosing the Best Alternative Using the Pugh Matrix Method
Choosing the Best Alternative Using the Pugh Matrix MethodChoosing the Best Alternative Using the Pugh Matrix Method
Choosing the Best Alternative Using the Pugh Matrix MethodCIToolkit
 
Introduction to 5S: A Journey Towards Workplace Excellence
Introduction to 5S: A Journey Towards Workplace ExcellenceIntroduction to 5S: A Journey Towards Workplace Excellence
Introduction to 5S: A Journey Towards Workplace ExcellenceCIToolkit
 
Putting Prioritization Matrix into Practice for Effective Decision-Making
Putting Prioritization Matrix into Practice for Effective Decision-MakingPutting Prioritization Matrix into Practice for Effective Decision-Making
Putting Prioritization Matrix into Practice for Effective Decision-MakingCIToolkit
 
BPMN tutorial by Draw Libre Office
BPMN  tutorial by Draw Libre OfficeBPMN  tutorial by Draw Libre Office
BPMN tutorial by Draw Libre OfficeMassimo Talia
 
Mirko Corna - ITIL Courses - Senior Project Manager
Mirko Corna - ITIL Courses - Senior Project ManagerMirko Corna - ITIL Courses - Senior Project Manager
Mirko Corna - ITIL Courses - Senior Project ManagerMirko Corna
 
Using the RAID Log to Monitor Your Project
Using the RAID Log to Monitor Your ProjectUsing the RAID Log to Monitor Your Project
Using the RAID Log to Monitor Your ProjectCIToolkit
 
How Force Field Analysis Enhances Decision-Making and Team Engagement
How Force Field Analysis Enhances Decision-Making and Team EngagementHow Force Field Analysis Enhances Decision-Making and Team Engagement
How Force Field Analysis Enhances Decision-Making and Team EngagementCIToolkit
 

Último (11)

Agile Journey - Don’t DO agile, BE agile
Agile Journey - Don’t DO agile, BE agileAgile Journey - Don’t DO agile, BE agile
Agile Journey - Don’t DO agile, BE agile
 
International Volunteer Programs presentation
International Volunteer Programs presentationInternational Volunteer Programs presentation
International Volunteer Programs presentation
 
Mirko Corna - Google Certifications - Senior Project Manager
Mirko Corna - Google Certifications - Senior Project ManagerMirko Corna - Google Certifications - Senior Project Manager
Mirko Corna - Google Certifications - Senior Project Manager
 
Creativity and Design Thinking - 2024.pdf
Creativity and Design Thinking  - 2024.pdfCreativity and Design Thinking  - 2024.pdf
Creativity and Design Thinking - 2024.pdf
 
Choosing the Best Alternative Using the Pugh Matrix Method
Choosing the Best Alternative Using the Pugh Matrix MethodChoosing the Best Alternative Using the Pugh Matrix Method
Choosing the Best Alternative Using the Pugh Matrix Method
 
Introduction to 5S: A Journey Towards Workplace Excellence
Introduction to 5S: A Journey Towards Workplace ExcellenceIntroduction to 5S: A Journey Towards Workplace Excellence
Introduction to 5S: A Journey Towards Workplace Excellence
 
Putting Prioritization Matrix into Practice for Effective Decision-Making
Putting Prioritization Matrix into Practice for Effective Decision-MakingPutting Prioritization Matrix into Practice for Effective Decision-Making
Putting Prioritization Matrix into Practice for Effective Decision-Making
 
BPMN tutorial by Draw Libre Office
BPMN  tutorial by Draw Libre OfficeBPMN  tutorial by Draw Libre Office
BPMN tutorial by Draw Libre Office
 
Mirko Corna - ITIL Courses - Senior Project Manager
Mirko Corna - ITIL Courses - Senior Project ManagerMirko Corna - ITIL Courses - Senior Project Manager
Mirko Corna - ITIL Courses - Senior Project Manager
 
Using the RAID Log to Monitor Your Project
Using the RAID Log to Monitor Your ProjectUsing the RAID Log to Monitor Your Project
Using the RAID Log to Monitor Your Project
 
How Force Field Analysis Enhances Decision-Making and Team Engagement
How Force Field Analysis Enhances Decision-Making and Team EngagementHow Force Field Analysis Enhances Decision-Making and Team Engagement
How Force Field Analysis Enhances Decision-Making and Team Engagement
 

Agile certified practitioner Exam Notes

  • 1. AGILE CERTIFIED PRACTITIONER (PMI-ACP) Gobi Durairaj, PMI-PMP, ACP, PBA, SAFe Agilist.,
  • 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
  • 8. 9 AGILE PRACTICES Lean Kanban PMBOK Agile is an umbrella term for a group of iterative and incremental software development methods.
  • 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
  • 39. Lean
  • 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
  • 56. Risk
  • 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
  • 80. 103 5 PLANNING POKER EXAMPLE 55Bill (Dev) 52Ann (BA) 58Vijay (QA) 33Susan (Dev) Round 2Round 1Estimator
  • 81. Scrum
  • 82. 105 SCRUM – 50,000 FOOT VIEW Release Planning Sprint Planning Sprint Review Sprint Retrospectiv e
  • 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
  • 93. AGILE PROCESS OVERVIEW Envision •Vision •NPV •ROI Initiation •Identify Personas •Create backlog •High level estimates •Create roadmap Release Planning •Slicing stories •Stories estimatio ns •Create release plan Iteration 0 •Spikes •Detailing Next iteration stories Iteration •Iteration planing •Coding •Testing •Daily stand- ups & Updating burn-ups •Iteration review •Retrospective •Preparing stories for Next iteration Closing •Project close out •Finishing contracts •Resource release IT Edge 116PMI-Pub 3 December 2014
  • 94. 117 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