Software Project Manager's Bridge to Quality - Quality and Risk Management

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


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”


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


Topics• Agile Intro Recap

• Quality Management

• Risk Management

Oct 15, 2008: HR Management & Responsibilities of the APM

5


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


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.


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!


A Case for Change

9

From InfoQ interview with Jim Johnson of the Standish Group


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—


The Agile Fractal

11

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


Quality Management13


Survey Question: Is Quality an issue in your projects?

• Yes

• No

14


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


Survey Question: If you answered yes, please explain why:

• Free text response

16


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


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


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


Fremont - NUMMI Team Leader

20

Robert B. Austenfeld, Jr. NUMMI - The Great Experiment


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


Quality References in Agile

• “Build Quality In” - Lean

• “Potentially Shippable Product Increment” - Scrum

• “Running Tested Features” - XP

• “Working Software” - AgileManifest

22


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


Quality Planning - PMBOK® Guide

“Identifying which quality standards are relevant to the project and determining how to satisfy them.”

- PMBOK® Guide

25


Quality Planning

26

• Prioritized, Estimated Product Backlog / Vision

• Team• Product Owner

• Definition of Done

• Testing Tools

• Define Metrics


Quality Planning

27


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


Definition of Done

29


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


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


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– .....


Tactical Quality Planning

33

Sprint Backlog

StoryTaskTaskTask


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


Strategic QualityPlanning


Release Test Activities

36

Scott Ambler, Agile Testing Strategies, Dr. Dobbs Online Dec 12, 2006


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


Test-First Programming

• Developers write unit tests before coding.

• Many open-source test tools have been developed to support this (e.g. xUnit)

38


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


Quality Assurance

40


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


Quality Control

42


APM’s Change List

43


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.

Risk Management45


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


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


Risk Identification

48


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


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


Risk IdentificationIn Planning Meetings - In Daily Stand-ups -


Risk Analysis

52


Sample Risk Board


Risk Response Planning

54


Risk Analysis and Response Planning

Photo © Rally Software Development Corp., All rights reserved


Risk Monitoring and Controlling

56


Response Planning, Monitoring, Controlling


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


APM’s Change List

59


What Worked Well?


What Didn’t Work So Well?


What Recommendations Do We Have?


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


Q&A

64


ReferencesFor more information, visit our sites:

www.theagilebridge.com


www.sligerconsulting.com

Check out our book: The Software Project Manager’s Bridge to Agility (Addison-Wesley)

65


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]


Thank You!

67

Documents

Software Project Manager's Bridge to Quality - Quality and Risk Management