• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Integrating Quality into Project Portfolio Management
 

Integrating Quality into Project Portfolio Management

on

  • 5,576 views

Traditionally, projects are managed based on cost, schedule, and scope. This continues to be insufficient and leads to poor outcomes, unsustainable development efforts, quality issues, and software ...

Traditionally, projects are managed based on cost, schedule, and scope. This continues to be insufficient and leads to poor outcomes, unsustainable development efforts, quality issues, and software that may meet requirements but not the expectations of users. This talk will go into how organizations can integrate quality and value considerations into their portfolio management strategies leading to less surprises and more valuable outcomes. The talk will go into detail about how Agile, Lean thinking, and Managing Software Debt can give a more holistic view of the project portfolio.

Statistics

Views

Total Views
5,576
Views on SlideShare
1,854
Embed Views
3,722

Actions

Likes
1
Downloads
21
Comments
0

6 Embeds 3,722

http://www.gettingagile.com 3697
http://abtasty.com 16
http://cloud.feedly.com 5
http://prlog.ru 2
http://thecloud 1
http://jsonviewer.stack.hu 1

Accessibility

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Integrating Quality into Project Portfolio Management Integrating Quality into Project Portfolio Management Presentation Transcript

    • Integra(ng  Quality  into  Project   Por3olio  ManagementFriday, October 28, 2011
    • Chris  Sterling Co-­‐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   Email:  chris@sterlingbarton.com   Web:  h5p://www.agileadvantage.com Facilitator Blog:  h5p://www.ge<ngagile.com Follow  me  on  Twi5er:  @csterwa Open  Source  Developer 2Friday, October 28, 2011
    • 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  Dashboards PorNolio  Management  Decisions: • Commit,  Transform,  Kill 3Friday, October 28, 2011
    • Pa6erns  for  Scaling  Agile  deliveryFriday, October 28, 2011
    • 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 5Friday, October 28, 2011
    • 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  a requirement  to  successfully   deliver  in  parallel 6Friday, October 28, 2011
    • Story  Map Areas  of  funcHonality/capabiliHes  on  top Place  associated  user  stories  verHcally 7Friday, October 28, 2011
    • Story  Map  -­‐  Next  Release Draw  line  that  represents  viable  release • Customer  features  above  the  line  are  “in” • Do5ed  line  represents  negoHability !" 8Friday, October 28, 2011
    • Forming  the  Meta-­‐Scrum 9Friday, October 28, 2011
    • Problems  Scaling  Agile  methods 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... 10Friday, October 28, 2011
    • Balancing  Signal  Indicators   Value Quality Constraints Source:  Jim  Highsmith (Schedule,  Cost,  Scope) 11Friday, October 28, 2011
    • Problems  We’ll  Focus  On  -­‐  Quality 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... 12Friday, October 28, 2011
    • DefiniUon  of  Done  -­‐  Assert  Quality Acceptance defined criteria for each Code checked in with reference to user story US#/Task# Unit tests written and passed Tested on FE Code compiles with no errors and no Integration test written & passes warnings Test code reviewed New code doesn’t break existing code Environment requirements documented Test case review (Dev to review test Interface document updated/added case written) and checked in to SVN Architectural impact assessed and Acceptance criteria verified complete artifacts updated if necessary All P1-P3 bugs for the story are Comments in code closed Error codes added Test approves user story Code reviewed by peer Story demonstrated to product owner and accepted on Target Platform 13Friday, October 28, 2011
    • 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  scheduleFriday, October 28, 2011
    • 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  scheduleFriday, October 28, 2011
    • TradiUonal  Source  Control  Management 15Friday, October 28, 2011
    • TradiUonal  Source  Control  Management Main  Branch 15Friday, October 28, 2011
    • TradiUonal  Source  Control  Management Code Complete Version  1 Integrate  for Branch Version  2 Main  Branch 15Friday, October 28, 2011
    • TradiUonal  Source  Control  Management Code Complete Version  1 Integrate  for Branch Version  2 Debt Main  Branch Death  March 15Friday, October 28, 2011
    • TradiUonal  Source  Control  Management Code Complete Version  1 Integrate  for Branch Version  2 Debt Main  Branch Death  March { Debt  accrues  quickly  within  stabilizaBon  periods 15Friday, October 28, 2011
    • Flexible  Source  Control  Management 16Friday, October 28, 2011
    • Flexible  Source  Control  Management Main Branch 16Friday, October 28, 2011
    • Flexible  Source  Control  Management Version 1 Main Branch 16Friday, October 28, 2011
    • Flexible  Source  Control  Management Version 1 Version 2 Main Branch 16Friday, October 28, 2011
    • Flexible  Source  Control  Management Version 1 Version 2 Main Branch { Not Easy! Must have proper infrastructure to do this. 16Friday, October 28, 2011
    • ConUnuous  IntegraUon 17Friday, October 28, 2011
    • 18Friday, October 28, 2011
    • Por3olio  Management  Decisions: Commit,  Transform,  Kill Source:  Johanna  Rothman “Manage  Your  Project  PorBolio” hDp://www.amazon.com/Manage-­‐Your-­‐Project-­‐PorBolio-­‐first/dp/B004SMU0OWFriday, October 28, 2011
    • EsUmates  are  Unreliable  but  Useful EsHmate  using  relaHve  size Affinity  EsHmaHng  technique* Affinity  EsHmaHng  How-­‐To:  h5p://www.ge<ngagile.com/2008/07/04/affinity-­‐esHmaHng-­‐a-­‐how-­‐to/ 20Friday, October 28, 2011
    • PorYolio  Level  Project  Commitment 21Friday, October 28, 2011
    • PorYolio  Project  TransformaUon 22Friday, October 28, 2011
    • Early  Warning  Signs Early  Warnings: •Broken  Builds •Broken  Automated  Tests •Broken  Custom  Thresholds 23Friday, October 28, 2011
    • Early  Warnings: •Design  Debt  in  DuplicaWon  (DRY) •Technical  Debt  in  Code  Complexity •Quality  Debt  in  Bug  DB  (Break/Fix) •Other  Custom  Thresholds 24Friday, October 28, 2011
    • Project  PorYolio  Kill? Early  Warnings: •When  transform  and  re-­‐”commit”  is  not  a  valid  opWon: •“Kill”  should  be  an  opWon  on  the  table  MORE 25Friday, October 28, 2011
    • Thank  you! Ques(ons  &  AnswersFriday, October 28, 2011
    • Come  see  us  at  AgileAdvantage.com 27Friday, October 28, 2011