software project manager's bridge to quality - quality and risk management
DESCRIPTION
Software Project Manager's Bridge to Quality - Quality and Risk ManagementTRANSCRIPT
www.agileevolution.com1
The Software Project Manager’s Bridge to AgilityStacia Broderick, PMP, CST
Part 4 of 5: Quality and Risk Management
Presented to: Hewlett Packard CompanyOctober 14, 2008
www.agileevolution.com2
Stacia Broderick• 14+ years of project
management experience in manufacturing and software
• Certifed ScrumTrainer (CST)
• PMP
• Co-author along with Michele Sliger of The Software Project Manager’s Bridge to Agility
• First Agile implementation at Primavera Systems in 2003; dozens of others since
www.agileevolution.com
Purpose
3
Build a bridge from traditional to agile
practices
Learn how agile methods directly
impact the responsibilities of the “agile project
manager”
www.agileevolution.com
Logistics
4
• 2 hours presentation
• 30 minutes for Q&A at end; some questions will be addressed during presentation
• 10 minute break after one hour
• Any questions not answered in the seminar will be answered afterwards and posted to Grow@HP
www.agileevolution.com
Topics• Agile Intro Recap
• Quality Management
• Risk Management
Oct 15, 2008: HR Management & Responsibilities of the APM
5
www.agileevolution.com
The Agile ManifestoWe are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
www.agilemanifesto.org
6
www.agileevolution.com
Knowledge/Decision Curves
7
time
Knowledge
Decisions
An empirical process is best when the project outcome is not predictable and the process is not repeatable.
www.agileevolution.com
Place Your MethodWaterfallSequential
Late integration and testing
RelaxedLittle documentation
Light process
Low ceremony
High CeremonyWell-documented
Traceability
CCB
Iterative and incrementalRisk driven
Continuous integration and testing
Repeatable, Predictable
Creative, Innovative
Exercise by Maria Thelin8
Empirical Process!
www.agileevolution.com
A Case for Change
9
From InfoQ interview with Jim Johnson of the Standish Group
www.agileevolution.com
Feature Bloat
Three Biggest Wastes in Software Developmentwww.poppendieck.com
10
Standish Group Study Reported at XP2002 by Jim Johnson, Chairman
Always
7%
Often
13%
Sometimes16%
Rarely19%
Never45%
Rarely or never used: 64%
Often or always used: 20%
©2004 Poppendieck.LLC
Working on the wrong priorities hurts product delivery—
www.agileevolution.com 20
Traditional vs. Agile Project Management
Traditional:
• Plan what you expect to happen
• Enforce that what happens is the same as what is planned
– Directive management– Control, control, control
• Use change control to manage change
– Change Control Board– Defect Management
Agile:• Plan what you expect to happen
with detail appropriate to the horizon
• “Control” is through inspection and adaptation– Reviews and Retrospectives– Self-Organizing Teams
• Use Agile practices to manage change:– Continuous feedback loops– Iterative and incremental
development– Prioritized backlogs
www.agileevolution.com
Survey Question: If you answered yes, is it because:• We run out of time
• My team does not include testing representatives
• Testing is remote
• We can’t get the proper tools
• Developers don’t work closely with testers
• All of the Above
• None of the Above15
www.agileevolution.com
Survey Question: If you answered yes, please explain why:
• Free text response
16
www.agileevolution.com
Quality Management
17
“The processes include all of the activities of the performing organization that determine quality policies, objectives and responsibilities so that the project will satisfy the needs for which it was undertaken.”
- PMBOK® Guide
www.agileevolution.com
Quality Management
18
Traditional
Quality Planning
Project Plan Execution
Direct, Manage, Monitor, Control
Agile
Iteration Work
Facilitate, Inspect & Adapt
Perform Quality Assurance
Perform Quality Control
“Quality is planned, designed and built in - not inspected in.” - PMBOK® Guide
Quality Planning
QA Part of Team
Definition of Done
www.agileevolution.com
Principles of Lean Software Development
• Eliminate Waste
• Build Quality In
• Create Knowledge
• Defer Commitment
• Deliver Fast
• Respect People
• Optimize the whole
“A predictable organization does not guess about the future
and call it a plan; it develops the capacity to
rapidly respond to the future as it unfolds.”
- Mary Poppendieck
19
www.agileevolution.com
Fremont - NUMMI Team Leader
20
Robert B. Austenfeld, Jr. NUMMI - The Great Experiment
www.agileevolution.com
Survey Question:
• I am so proud of the quality of the products that I have helped build that I would gladly put my name and home phone number on the package so that customers can call me anytime they wish. Additionally, a bicep tattoo “I love my product” would be cool.
• agreed
• no way!
21
www.agileevolution.com
Quality References in Agile
• “Build Quality In” - Lean
• “Potentially Shippable Product Increment” - Scrum
• “Running Tested Features” - XP
• “Working Software” - AgileManifest
22
www.agileevolution.com
Agile Planning 101
fix
estimate
RequirementsCost Date
Cost DateFeatures
Value-Driven
$
Source: DSDM
Plan-Driven
23
Sprint Backlog
Sprint Backlog
Sprint Backlog
StoryTaskTaskTask
StoryTaskTaskTask
StoryTaskTaskTask
Force Ranked
Deliberate SWAGs
Strategic Planning“The What and Why”
Can drive roadmaps
EpicEpic
Q1 Q2 Q3EpicEpic
EpicEpic
Can Drive Release Plans
Sprint 1
StoryStoryStory
\
Sprint 2 Sprint 3
Tactical Planning“The How and How Fast”
Working Document: Product BacklogLowest level: Epic/User StoryUOM: Story points or other SWAG
Working Document: Sprint BacklogLowest level: Work TasksUOM: Hours/Days
Deliberate DetailStoryStoryStory
StoryStoryStory
Product Backlog
1. Story 22. Story 33. Story 54. Story 85. Story 136. Story 37. Story 208. Story 409. Story 100.....
Vision
www.agileevolution.com
Quality Planning - PMBOK® Guide
“Identifying which quality standards are relevant to the project and determining how to satisfy them.”
- PMBOK® Guide
25
www.agileevolution.com
Quality Planning
26
• Prioritized, Estimated Product Backlog / Vision
• Team• Product Owner
• Definition of Done
• Testing Tools
• Define Metrics
www.agileevolution.com
Core ProjectTeam
BA
BA
TesterProductOwner
Developer
Designer
Developer PM
ReleaseManager
CapacityPlanner
Prod.
Architect
TechOps
BusinessSponsor
RiskAssessor
Security
ProductOwner BA Designer Developer TesterTraditional
Silos
Integrated Scrum TeamThe Core Project Team ideally consists of 5-9 members (7 +/- 2).
PM
ExtendedProject Team
28
Traditional vs. Scrum Team
Source: Lithespeed, LLC
www.agileevolution.com
Fit for Use: Acceptance Criteria• User stories are how we plan our work
in agile
• It is critical that the team understand how the story will be accepted by the product owner
• This requires involvement by the product owner in planning to identify acceptance criteria for each planned story
30
www.agileevolution.com
The Three C’s in Action1. Card: As a shopper I want to be able to pay with a credit
card because it is convenient.2. Conversation:
DEV: What credit cards are valid?PROD: Diners, MasterCard, VISA, and American Express, but
not Discover.DEV: What should I do if the card check comes back invalid
(card reported lost or stolen, expired, does not exist, etc.)?PROD: Give them a nice message explaining why it isn’t valid,
and let them try to enter a card again.3. Confirmation:– Test that Discover is not accepted– Test that expired cards are not accepted– Confirm that rejected cards are not accepted
31
www.agileevolution.com
Updated User Story
32
Rank 3 Size 5
As a shopper I want to pay with a credit card because it is convenient.
Acceptance Criteria:– Test that Discover is not accepted– Test that expired cards are not accepted– Confirm that rejected cards are not accepted– .....
www.agileevolution.com
Agile Metrics
34
Team Performance-meets goals-velocity
Customer Satisfaction-# support calls-# escalations - survey results
ROI-project costs-project value delivered-time to market
Quality-automation-test cases pass/fail-# defects w/severity level-decisions
www.agileevolution.com
Release Test Activities
36
Scott Ambler, Agile Testing Strategies, Dr. Dobbs Online Dec 12, 2006
www.agileevolution.com
More about testing...• A bug is anything that could ‘bug’ the
user. Testers don’t make the final call.
• Testing does not assure quality (the whole team does - or doesn’t)
• Testing is not a game of ‘gotcha’
~ Brad Pettichord
37
www.agileevolution.com
Test-First Programming
• Developers write unit tests before coding.
• Many open-source test tools have been developed to support this (e.g. xUnit)
38
www.agileevolution.com
Refactoring
39
“Changing a software system in such a way that it does not alter the external behavior of the
code yet improves its internal structure”
• Make the simplest design that will work. • Add complexity only when needed. • Refactor as necessary. • Refactoring requires unit tests to ensure that
design changes (refactorings) don’t break existing code.
~ Brad Pettichord
www.agileevolution.com
Unfinished Product Increments Erode Velocity
0
250
500
750
1000
1250
1500
Start End Sprint 1 End Sprint 2 End Sprint 3 End Sprint 4 End Sprint 5 End Sprint 6
Chart 6
Perfect World Burndown Bug Backlog New Burndown
41
www.agileevolution.com
Testing Resources
44
http://softwaredevelopmentisfun.blogspot.com/2008/04/ten-tips-for-agile-testing.html
Crispin, Lisa. Testing Extreme Programming, Addison-Wesley, 2002.
Bain, Scott L. Emergent Design: The Evolutionary Nature of Professional Software Development. Pearson, 2008.
www.agileevolution.com
Risk Management
46
“Includes the processes concerned with conducting risk management planning, identification, analysis, responses, and monitoring and control on a project. Most of these processes are updated throughout the project.”
- PMBOK® Guide
www.agileevolution.com
Objectives
• Increase the probability and impact of positive events,
• Decrease the probability and impact of adverse events.
47
“Risk management is an iterative process because new tasks may become known as the project progresses through its life cycle.”
- PMBOK® Guide
www.agileevolution.com 51
The Agile Framework Addresses Core Risks
• Intrinsic schedule flaw (estimates that are wrong and undoable from day one, often based on wishful thinking)
Δ Detailed estimation is done at the beginning of each iteration
• Specification breakdown (failure to achieve stakeholder consensus on what to build)
Δ Assignment of a product owner who owns the backlog of work
• Scope creep (additional requirements that inflate the initially accepted set)
Δ Change is expected and welcome, before the iteration has been planned
• Personnel loss
Δ Self-organizing teams experience greater job satisfaction
• Productivity variation (difference between assumed and actual performance)
Δ Demos of working code every iteration
Core risks from Tom DeMarco and Tim Lister: “Risk Management During Requirements” IEEE Software
www.agileevolution.com 52
Identifying Risk• Can occur overtly as an agenda item, or happen organically as a
result of discussing constraints, assumptions, and concerns
• You may choose to create a Risk Board and refer to it in all planning meetings and retrospectives
– Avoid – don’t do the project or part of the project that entails the risk
– Mitigate – take steps before the risk materializes to reduce the eventual containment costs
– Plan Contingency or Contain – set aside time and money to pay for the risk should it materialize
– Accept or Evade – when you do none of the above and yet manage to get lucky
– Transfer – literal. Ex: insurance, contracts
www.agileevolution.com 55
Risk Analysis and Response Planning
Photo © Rally Software Development Corp., All rights reserved
www.agileevolution.com
Journal 1. Group too big. Lots of storming in weeks one & two. Group finally started
performing by end of week three.
2. Very difficult to get team to update the sprint backlog. Once they saw the trend line, participation was better....
3. Definitive line in the sand between dev and testing. This was troubling at times when overhearing conversation. Definitely an ownership perception....
4. Implementation of the initiation engine took longer than planned. A 16 hour estimate blew up to 45 hours real time.
5. Received quite an extensive list of new features for the product backlog. Will need to visit this in the Look Ahead Meeting...
6. Are attendees at the Sprint Review chickens? We are getting off track!
58
www.agileevolution.com
PDUs• You are eligible for 2 PDUs under category 4 - Other
Provider
• Knowledge areas for this seminar include:
• Quality Management
• Risk Management
• Process areas:
• 01 Initiating, 02 Planning, 03 Executing, 04 Controlling, 05 Closing
• www.pmi.org
63
www.agileevolution.com
ReferencesFor more information, visit our sites:
www.theagilebridge.com
www.agileevolution.com
www.sligerconsulting.com
Check out our book: The Software Project Manager’s Bridge to Agility (Addison-Wesley)
65
www.agileevolution.com
HP Agile SIG
66
For more information regarding the use of Agile methods at HP, visit:
http://agile.corp.hp.com/
The HP Agile SIG value proposition is:
"For Software development teams, advocates (managers, business leaders, PMOs) and inquiring minds who are looking for another approach or want help getting started, the Agile Special Interest
Group provides best practices, guidelines, metrics, coaching, experience reports, influence and advisory services."
You may contact the HP Agile SIG at: [email protected]