dollars and dates are killing agile

Dollars and Dates Are Killing Agile

Wednesday, November 2, 2011

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

Author of Book “Managing SoBware Debt: Building for Inevitable Change”

Consults on soBware technology, Agile technical pracKces, Scrum, and effecKve management techniques

CerKfied Scrum Trainer

InnovaKon Games® Trained Facilitator

Open Source Developer

2

Email: [email protected] Web: hWp://www.agileadvantage.comBlog: hWp://www.geYngagile.comFollow me on TwiWer: @csterwa


http://www.AgileEVM.com

http://www.AgileEVM.com

mailto:[email protected]

mailto:[email protected]

http://chrissterling.gettingagile.com/




http://www.gettingagile.com




Agenda

Business Value and Agility• How AdapKve Planning Stresses Strategic Planning

Balancing Signal to Noise at Scale

The Agile Business Roadmap• Year 1: Reduce Carryover• Year 2: OpKmize Por_olio

• Year 3: Incremental Funding

•What we can do to help all along the way

Ques:ons & Answers

3


Value


What is Value?

5


AgileWednesday, November 2, 2011

Value


Value

Agile

What’sIn-‐Between?


DemandValue


Demand

Rhythm of the Business

Value


Demand

CFOCost Constraints

Human ResourcesPeople Constraints


Value


Demand

CFOCost Constraints

Human ResourcesPeople Constraints


PorEolio/Budget

Value


ValueDemand

PorEolio/Budget


ValueDemand

PorEolio/Budget

Agile

Perfec&on Goes Here


10


?10


10

Conclusion:AdapKve Planning Stresses Strategic Planning(Fine Print: ** Except in cases of PerfecKon **)


Business can’t take advantage of Adap:ve Planning methods

It is decided that Agile can’t scale

Subop:mal results

Restarted several :mes

11

Typical Outcomes


Balancing Signal to Noise at Scale


Balancing Signal Indicators

Value

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

13


The Agile Business Roadmap


Iden:fy issues sooner

Make decisions earlier

Demonstrate progress frequently

Focus on quality

15

Agile Business Roadmap

Year 1: Reduce carryover


PaMerns for Scaling Agile delivery


Component Teams

“Component Team” structure

Separate Product Backlog

Managing dependencies is oBen serialized

ProblemaKc integraKon issues are typically faced if mulKple components are required to release

Use an “IntegraKon Team” to pull components together

Causes more rework than “Feature Team” structure

17


Feature Teams

“Feature Team” structure

Uses common Product Backlog

IntegraKon is done in parallel

Requires high levels of communicaKon across teams to resolve integraKon issues

Forces Product Owners to be more coordinated

Sprints should be synchronized

Cross team ferKlizaKon is arequirement to successfully deliver in parallel

18


Story MapAreas of func:onality/capabili:es on top

Place associated user stories ver:cally

19


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

• DoMed line represents nego:ability

!"#20


Forming the Meta-‐Scrum

21


DefiniKon 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

22


Release DefiniKon of Done

Every release should have clear quality criteria

With a “Release Defini:on of Done” you can understand targets beMer

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


Iden:fy emergent value

Compare performance across porRolio

Increase overall value/cost ra:o

Lower cost of compliance

Deliver smaller batches

Reduce stabiliza:on periods

Coordinate across groups

24

Agile Business RoadmapYear 2: Optimize Project Portfolio


Process AutomaOon & OpOmizaOon with AddiOon of Appropriate “Slack”


TradiKonal Source Control Management

26



26

Main Branch



26

Main Branch

Version 1Branch

Integrate forVersion 2

CodeComplete



26

Main BranchDebt

Death March

Version 1Branch


CodeComplete



26

Main BranchDebt

Death March {Debt accrues quickly within stabilizaCon periods

Version 1Branch


CodeComplete


Flexible Source Control Management

27



27

Main Branch



27

Main Branch

Version 1



27

Main Branch

Version 1 Version 2



27

Main Branch

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


ConKnuous IntegraKon

28


29


Safe-‐fail environment

Use experimenta:on as a compe::ve advantage

Combat compe::ve threats

Integrate technical & customer feedback promptly

Aggressively use commit/transform/kill for porRolio op:miza:on

Pull ini:a:ves through teams rather than pushing resources to projects

30

Agile Business RoadmapYear 3: Incremental Funding


PorEolio Management Decisions:

Commit, Transform, KillSource: Johanna Rothman

“Manage Your Project PorLolio”hNp://www.amazon.com/Manage-‐Your-‐Project-‐PorLolio-‐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

EsKmates are Unreliable but Useful

32

Es:mate using rela:ve size

Affinity Es:ma:ng technique*

Affinity EsKmaKng How-‐To: hWp://www.geYngagile.com/2008/07/04/affinity-‐esKmaKng-‐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/

Por_olio Level Project Commitment

33


Por_olio Project TransformaKon

34


Early Warning Signs

35

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


36

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


37

Project Por_olio Kill?

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


Thank you!

QuesOons & Answers


Come see us at AgileAdvantage.com

39


dollars and dates are killing agile

Technology

teams deni

release draw line

integrakon team

value demandrhythm

source of quality issues

agile business roadmapyear

agenda business value

value whatsin