integrating quality into project portfolio management

Integra(ng Quality into Project Por3olio Management

Friday, October 28, 2011

Chris SterlingCo-‐founder of Agile Advantage and VP of Engineering (www.AgileAdvantage.com)

Author of Book “Managing So;ware Debt: Building for Inevitable Change”

Consults on so;ware technology, Agile technical pracGces, Scrum, and effecGve management techniques

CerGfied Scrum Trainer

InnovaGon Games® Trained Facilitator

Open Source Developer

2

Email: [email protected] Web: h5p://www.agileadvantage.comBlog: h5p://www.ge<ngagile.comFollow me on Twi5er: @csterwa


http://www.AgileEVM.com

http://www.AgileEVM.com

mailto:[email protected]

mailto:[email protected]

http://chrissterling.gettingagile.com/




http://www.gettingagile.com




Agenda

Pa5erns for Scaling Agile delivery• Problems of Scaling SoDware Delivery

Balancing Signal to Noise at Scale• DefiniHon of Done• Source Control Management

• ConHnuous IntegraHon• Quality DashboardsPorNolio Management Decisions:• Commit, Transform, Kill

3


Pa6erns for Scaling Agile delivery


Component Teams

“Component Team” structure

Separate Product Backlog

Managing dependencies is oDen serialized

ProblemaHc integraHon issues are typically faced if mulHple components are required to release

Use an “IntegraHon Team” to pull components together

Causes more rework than “Feature Team” structure

5


Feature Teams

“Feature Team” structure

Uses common Product Backlog

IntegraHon is done in parallel

Requires high levels of communicaHon across teams to resolve integraHon issues

Forces Product Owners to be more coordinated

Sprints should be synchronized

Cross team ferHlizaHon is arequirement to successfully deliver in parallel

6


Story MapAreas of funcHonality/capabiliHes on top

Place associated user stories verHcally

7


Story Map -‐ Next ReleaseDraw line that represents viable release• Customer features above the line are “in”

• Do5ed line represents negoHability

!"#8


Forming the Meta-‐Scrum

9


Problems Scaling Agile methods

10

Dependencies across teams

IntegraHon points across architecture

Cross-‐team coordinaHon

Inconsistent quality standards

MulHple lists of work

Larger batches created for deployment

MulH-‐level planning

And probably much more...


Balancing Signal Indicators

Value

Quality Constraints(Schedule, Cost, Scope)Source: Jim Highsmith

11


Problems We’ll Focus On -‐ Quality

12

Dependencies across teams

Integra(on points across architecture

Cross-‐team coordina(on

Inconsistent quality standards

Mul(ple lists of work

Larger batches created for deployment

MulH-‐level planning

And probably much more...


DefiniUon of Done -‐ Assert QualityAcceptance defined criteria for each user story

Unit tests written and passed

Code compiles with no errors and no warnings

New code doesn’t break existing code

Test case review (Dev to review test case written)

Architectural impact assessed and artifacts updated if necessary

Comments in code

Error codes added

Code reviewed by peer

Code checked in with reference to US#/Task#

Tested on FE

Integration test written & passes

Test code reviewed

Environment requirements documented

Interface document updated/added and checked in to SVN

Acceptance criteria verified complete

All P1-P3 bugs for the story are closed

Test approves user story

Story demonstrated to product owner and accepted on Target Platform

13


Release DefiniUon of Done

Every release should have clear quality criteria

With a “Release DefiniHon of Done” you can understand targets be5er

Measure the gap between the teams’ DefiniHon of Done and a Release DefiniHon of Done.• This gap is a source of quality issues and represents significant risk to schedule


TradiUonal Source Control Management

15



15

Main Branch



15

Main Branch

Version 1Branch

Integrate forVersion 2

CodeComplete



15

Main BranchDebt

Death March

Version 1Branch


CodeComplete



15

Main BranchDebt

Death March {Debt accrues quickly within stabilizaBon periods

Version 1Branch


CodeComplete


Flexible Source Control Management

16



16

Main Branch



16

Main Branch

Version 1



16

Main Branch

Version 1 Version 2



16

Main Branch

Version 1 Version 2{Not Easy! Must have proper infrastructure to do this.


ConUnuous IntegraUon

17


18


Por3olio Management Decisions:

Commit, Transform, KillSource: Johanna Rothman

“Manage Your Project PorBolio”hDp://www.amazon.com/Manage-‐Your-‐Project-‐PorBolio-‐first/dp/B004SMU0OW


http://www.amazon.com/Manage-Your-Project-Portfolio-first/dp/B004SMU0OW

http://www.amazon.com/Manage-Your-Project-Portfolio-first/dp/B004SMU0OW

EsUmates are Unreliable but Useful

20

EsHmate using relaHve size

Affinity EsHmaHng technique*

Affinity EsHmaHng How-‐To: h5p://www.ge<ngagile.com/2008/07/04/affinity-‐esHmaHng-‐a-‐how-‐to/


http://www.gettingagile.com/2008/07/04/affinity-estimating-a-how-to/

http://www.gettingagile.com/2008/07/04/affinity-estimating-a-how-to/

PorYolio Level Project Commitment

21


PorYolio Project TransformaUon

22


Early Warning Signs

23

Early Warnings:•Broken Builds•Broken Automated Tests•Broken Custom Thresholds


24

Early Warnings:•Design Debt in DuplicaWon (DRY)•Technical Debt in Code Complexity•Quality Debt in Bug DB (Break/Fix)•Other Custom Thresholds


25

Project PorYolio Kill?

Early Warnings:•When transform and re-‐”commit” is not a valid opWon:•“Kill” should be an opWon on the table MORE


Thank you!

Ques(ons & Answers


Come see us at AgileAdvantage.com

27


integrating quality into project portfolio management

Technology