scaling agile(good!)

8/8/2019 Scaling Agile(Good!)

1/70

Scaling Software Agility:Best Practices for Large

Enterprises

Dean Leffingwell

Agile 2009

Chicago, IL

August 26, 2009

1


2/70

About Dean Leffingwell

2

Executive MentorBMC Agile Transformation

Agile Enterprise CoachNokia S60, Symantec, Safeco

Insurance, Symbian

Software.

Cofounder/AdvisorPing Identity, Roving Planet,

Rally Software

Founder/CEORequisite, Inc.

Makers of RequisitePro

Senior VPRational Software

Responsible for Rational Unified

Process (RUP) & Support of

UML

Founder and CEOProQuo, Inc., Internet identity


3/70

More from Dean Leffingwell

Scaling Software Agility: Best Practices for Large

Enterprises, Addison-Wesley 2007Blog and Resources

www.scalingsoftwareagility.wordpress.com

Website

www.leffingwell.org

Reach me at [email protected]

3
http://www.scalingsoftwareagility.wordpress.com/http://www.leffingwell.org/mailto:[email protected]:[email protected]://www.leffingwell.org/http://www.scalingsoftwareagility.wordpress.com/


4/704

If you accept the premise that market needs change fasterthan the software industrys traditional ability to developsoluions, youre left with the question what can we do about

it? For me, the answer is Agile.

Israel Gat, Vice President,

Infrastructure Management, BMC Software, Inc.


5/70

BMC Results

QSM Associates press release remarkable levels of time-to-market and quality

produce large scale enterprise software in 4-5 months,

compared to typical one year exceptional time-to-market without sacrificing quality

especially noteworthy - BMC 'Secret Sauce enablesprocess to succeed in spite of geographically dispersedteams

Other companies experience higher defects and longerschedules with split teams, BMC does not. I've never seenthis before. The low bug rates also result in very low defect

rates post-production

clearly ahead of more than 95 percent of all the softwareprojects captured in the SLIM metrics database, they're

among the best I've seenSource: QSM Associates Press Release, Sep 10, 2007

5


6/70

Approaching Challenge at Scale

6

We place the highest value on actual implementation and taking action.There are many things one doesnt understand; therefore, we ask them,why dont you just go ahead and take action?

You realize how little you know, and you face your own failures and redo

it again, and at the second trial you realize another mistake . . . So youcan redo it once again.

So by constant improvement one can rise to the higher level of practiceand knowledge.

This guidance reminds us that there is no problem too large to be solvedif we are only willing to take the first step.

FuijoSho, President, Toyota


7/70

What Is Software Agility?

7


8/70

Team Agility

A disciplined set of

enhanced software engineering practices

empirical software project management practices

modified social behaviors

That empowers teams to: more rapidly deliver quality software

explicitly driven by intimate and immediate customer feedback

8


9/70

1.

The Define/Build/Test Team

2.

Mastering the Iteration

3. Two-levels of Planning and Tracking4.

Smaller, More Frequent Releases

5.

Concurrent Testing

6.

Continuous Integration

7.

Regular Reflection and Adaptation

1.


2.


3. Two-levels of Planning and Tracking4.

Smaller, More Frequent Releases

5.

Concurrent Testing

6.


7.


Achieving Team Agility

9


10/70

Enterprise Agility

That harness large numbers of agile teams to build

and release quality enterprise-class software more

rapidly than ever before

Explicitly driven by intimate and immediate customerfeedback

That harness large numbers of agile teams to build

and release quality enterprise-class software more

rapidly than ever before

Explicitly driven by intimate and immediate customer

feedback

A set of organizational best practices

core values and beliefs

A set of organizational best practices

core values and beliefs

10


11/70

Achieving Enterprise Agility

11

1.

Intentional Architecture

2.

Lean Requirements at Scale

3. Systems of Systems and the Agile Release Train4.

Managing Highly Distributed Development

5.

Impact on Customers and Operations

6.

Changing the Organization

7.

Measuring Business Performance

1.

Intentional Architecture

2.


3. Systems of Systems and the Agile Release Train4.

Managing Highly Distributed Development

5.

Impact on Customers and Operations

6.

Changing the Organization

7.

Measuring Business Performance


12/70

Agile Turns Tradition Upside-Down

Predictive Process

(Waterfall)

Adaptive Process

(Agile)

The plan createscost/schedule estimates

The vision createsfeature estimates

12


13/70

Helps Avoid the Death March

Time

Pressure

Deadline

13

Peak performanceachieved andmaintained indefinitely

at a sustainable pace


14/70

Reduces Risk

Time

Deadline

Risk

14


15/70

Starts Delivering Immediately

15

Time

ValueDe

livery

Deadline


16/70

Makes Money Faster

16

Time

ValueDe

livery

Deadline


17/70

Delivers Better Fit for Purpose

Time

waterfall plan, result

agile

(adaptive) plan, result

Measure of

waterfall customer

dissatisfaction

17


18/70

Agile Delivers Higher

18


19/70

Our implementation of agile practices . . . helps us find bugsearlier, helps us achieve higher quality, and helps us work wellwith SW QA

Jon Spence, Medtronic

Our implementation of agile practices . . . helps us find bugsearlier, helps us achieve higher quality, and helps us work wellwith SW QA


I measure quality by the life of a defect, time measured frominjection to finding and fixing. Agile gives us solid results with

most defects living no longer than one to two iterations. Agiledelivers higher quality than anything Ive found with the waterfallmodel

Bill Wood, VP, Ping Identity Corp.

I measure quality by the life of a defect, time measured frominjection to finding and fixing. Agile gives us solid results with

most defects living no longer than one to two iterations. Agiledelivers higher quality than anything Ive found with the waterfallmodel

Bill Wood, VP, Ping Identity Corp.

19


20/70

Last year, we had 22 releases across 3 major product lines, andnot a one of them was late. We support hundreds of Fortune1000 enterprises with a single person dedicated to support --the software is that solid

Andre Durand, CEO, Ping Identity Corp.

Last year, we had 22 releases across 3 major product lines, andnot a one of them was late. We support hundreds of Fortune1000 enterprises with a single person dedicated to support --the software is that solid

Andre Durand, CEO, Ping Identity Corp.

We increased individual developer and team productivity by an

estimated 20 percent to 50 percentBMC Software

We increased individual developer and team productivity by an

estimated 20 percent to 50 percentBMC Software

20


21/70

Development teams are more engaged, empowered and highlysupportive of the new development process

BMC Software

Development teams are more engaged, empowered and highlysupportive of the new development process

BMC Software

Our implementation of agile practices . . . (1) makes the workmore enjoyable, (2) helps us work together, and (3) isempowering


Our implementation of agile practices . . . (1) makes the workmore enjoyable, (2) helps us work together, and (3) isempowering


21


22/70

Seven Agile TeamPractices That Scale



Two-level Planning and Tracking

Smaller, More frequent releases

Concurrent Testing



22

1 D fi /B ild/T t T


23/70

1. Define/Build/Test Team

Before Agile: Typical Functional Silos

Management Challenge:

Connect the Silos

23

D/B/T Team Agile Fractal


24/70

A self-organizing team that can Define, Buildand Testa thing of interest

Optimized for communication about the thing

Repeated at larger scales to produce largersystems

Teams can be based on

Components

Subsystems

Features

Interfaces

Products

D/B/T Team Agile Fractal

Team1

Team100

24

D/B/T Teams Have the Necessary Skills


25/70

D/B/T Teams Have the Necessary Skills

Developer Developer Developer Tester

TesterDeveloperProduct Owner

Architect

Tech lead Scrum / Agile Master

QA/Release

Mgt

25

2 Mastering the Iteration


26/70

The iteration is the heartbeat of agility. Master that,

and most other things agile tend to naturally fallinto place.

2. Mastering the Iteration

26

Iteration Pattern


27/70

Iteration Pattern

Story AStory B

Story C

Story D

Story E

Story FStory

Story AStory B

Story C

Story D

Story E

Story FStory

DefineDefine

P

lan

Plan

FixedR

esources

Fixed Time (Iteration)

27

3 Two Level Planning and Tracking


28/70

3. Two-Level Planning and Tracking

Iteration CycleIteration Cycle

Release CycleRelease Cycle

Drives

Feedback- Adjust

Plan Releases at the

SystemLevel

Three to six monthshorizon

Prioritized feature

sets define content

Plan iterations at the

component/feature level 2-4 iteration visibility

Currency: user stories

ReleaseVision

Release Planning

Release Scope

and Boundaries

28

IterationPlanning

Develop &TestReview

&Adapt

Release Pattern


29/70

Release Pattern

PrioritizedRelease (feature)

Backlog

Stories

Release timebox

29

4 Smaller More Frequent Releases


30/70

4. Smaller, More Frequent Releases

Shorter release dates

60-120 days

Releases defined by

Date, theme, planned

feature set, quality

Scope is the variable

Release date and

quality are fixed

CycleCycleCycle CycleCycleCycle CycleCycleCycle

30

CycleCycleCycle CycleCycleCycle CycleCycleCycle CycleCycleCycle CycleCycleCycle CycleCycleCycle

Fix the Dates - Float the Features


31/70

Fix the Dates Float the Features

Teams learn that dates MATTER

Product and business owners learn that priorities

MATTER

Agile teams MEET their commitments

Releasable

Increment

10/1/2009 11/1/2009 12/1/2009 1/1/2009 2/1/2009 3/1/2009

31

Releasable

Increment

5 Concurrent Testing


32/70

5. Concurrent Testing

All code is tested code. Teams get no credit for

delivering functionality that is coded, but not tested. Tests are written before, or concurrently with, the

code itself.

Testing is a team effort. Testers and developers allwrite tests.

Test automation is the rule, not the exception.

Philosophy of Agile Testing

32

Concurrent


33/70

Concurrent

Unit Testing Developer written

Acceptance Testing

Customer, product owner, tester written

Component Testing

Integrated BVT (build verification tests) at component/modulelevel

System, Performance and Reliability Testing

Systems tester and developer Written QA Involvement

33

Agile Testing Quadrants


34/70

Agile Testing Quadrants

34

Business-Facing

Su

pportDevelopment

Critiqu

eProduct

Technology-Facing

ManualAutomated &Manual

Automated Tools

Q1

Q2 Q3

Q4

Adapted from Brian Marick, Crispen and Gregory

On Test Automation


35/70

On Test Automation

You have no choice

Manual tests bottleneck velocity You cant ship what you cant test

35

6. Continuous Integration


36/70

g

Continuous integration is neither new nor invented by agile

It has been applied as a best practice for at least a decade

However, continuous integration is mandatory with agile

the teams ability to build continuously is

a critical bottleneck to delivered

velocity

the teams ability to build continuously is

a critical bottleneck to delivered

velocity

36


37/70

Continuous Integration Success


38/70

g

Team can build at least once a day

Effort is inversely proportional to time between builds!

A broken build stops

production and is addressed

immediately

Successful builds

Checks in all the latest source code

Recompile every file from scratch

Successfully execute all unit tests

Link and deploy for execution

Successfully execute automated Build Verification Test

38

Source: Martin Fowler

7. Regular Reflection and Adaptation


39/70

g p

Periodically, the entire team including owners/end users

reflects on the results of the process

learn from that examination

adapt the process -

and organization -

to produce better results

The team decides what is working well, what isnt, and

what one thing to do differentlynext time

At regular intervals, the team reflects on how to become moreeffective, then tunes and adjusts its behavior accordingly.

Agile Manifesto, Principle 12

The shorter the iterations and releases

the

faster the learning The shorter the iterations and releases

the

faster the learning

39

A hi i E i


40/70

Achieving Enterprise

Agility

40

1. Intentional Architecture


41/70

Continuous refactoring of large-scale, system-levelarchitectures is problematic:

Substantive rework for large numbers of teams

Some of whom would otherwise NOT have to refactor their component or

module

Potential Impact on deployed systems/ users

Best possible BVT (Build Verification Tests) are imperfect

Common architectural constructs ease usability, extensibility,

performance and maintenance

For systems of scale, some intentional architecture

is necessary

For systems of scale, some intentional architecture

is necessary41

Principles of Agile Architecture


42/70

Principle #1 The teams that code the system design the

system.Principle #2 Build the simplest architecture that can

possibly work.Principle #3 When in doubt, code it out.

Principle #4 They build it, they test it.

Principle #5 The bigger the system, the longer therunway.

Principle #6 System architecture is a role collaboration.

Principle #7 There is no monopoly on innovation42


43/70

2. Lean Requirements at Scale


44/70

Requirements still matter in agile. Atscale, lean and more extensible

requirements practices can be applied.

44



45/70

A scalable requirements practice with three elements

Vision+Vision+ RoadmapRoadmap Just-in-TimeElaboration

Just-in-TimeElaboration

45

Vision - Managements responsibility


46/70

Where are we headed as a

business?

What problem does this product

solve?

What features and benefits does itprovide?

For whom does it provide it?

What performance does it deliver?

46

Common and Non-functionalR i t


47/70

Requirements

Some requirements must be

known by all teams Common components, common

behaviors

Internationalization, accessibility Performance, reliability and security

requirements

Industry/Regulatory/Customer standards/specifications

Corporate standards: copyright, logo, graphics, legal

Documented and available to all affected teams.Documented and available to all affected teams.47

Roadmap System TeamsR ibilit


48/70

Responsibility

May 15, 08 May 22, 08 July 08

Features

Road Rage Ported

(part I)

Brickyard port started

(stretch goal to complete)Distributed platform demo

ALL GUIs for both games

demonstrable

New features (see

prioritized list)

Demo of Beemer game

Features

Road Rage Ported

(part I)

Brickyard port started

(stretch goal to complete)Distributed platform demo

ALL GUIs for both games

demonstrable

New features (see

prioritized list)

Demo of Beemer game

48

Features

Road Rage Completed

(single user)

Brickyard Ported (single

user)Road Rage multiuser

demonstrable

First multiuser game

feature for Road Rage

New features (see

prioritized list)Beemer game in Alpha

Features

Road Rage Completed

(single user)

Brickyard Ported (single

user)Road Rage multiuser

demonstrable

First multiuser game

feature for Road Rage

New features (see

prioritized list)Beemer game in Alpha

Features

Multiuser Road Rage first

release

Brickyard Ported

multiuser demoNew features for both

games (see prioritized list)

Beemer game to E3

Tradeshow?

Features

Multiuser Road Rage first

release

Brickyard Ported

multiuser demoNew features for both

games (see prioritized list)

Beemer game to E3

Tradeshow?

Just-In-Time Elaboration Agile Teams Responsibility


49/70

Story 1

Omnis decus

Plurubusunum

Story 1

Omnis decus

Plurubusunum

Story 2Story 2

Agile investment in documenting

requirements is minimal prior to

implementation

Features are high level, abstract

Communicate only concept

Little work in process

At iteration boundaries, elaborationis required

Refine the teams understanding

Support design, implementation andtesting

Define acceptance criteria

User Stories are the currency

Agile Teams Responsibility

49

3. Systems of Systems and the AgileRelease Train


50/70

Release Train

Scaling agile requires managing interdependencies

amongst teams of developers

Only the teams themselves can plan and manage this

complexity

Only the teams can commit to the schedule Systematic enterprise delivery requires an agile release

train delivery model

Rolling-wave Enterprise Release Planning drives release

train vision and execution

50

Component Agile is not System Agile


51/70

51

Time when you

discover you arenot Planned system

release date

....time spent thinking you are on track.IntegrateIntegrateand slip!and slip!SystemSystem

External Release

External Release

External Release

Internal Release

Internal Release

IterateIterate IterateIterate IterateIterate

IterateIterate IterateIterate IterateIterate IterateIterate

AA

BB

CC

Agile teams

Internal Release

IterateIterate IterateIterate IterateIterate IterateIterate IterateIterate IterateIterate

The slowest team drags thetrain

Release docsRelease docs

Port and certsPort and certs

Port and certsPort and certs



Rules of the Agile Release Train


52/70

Periodic release dates for the solution are fixed

Intermediate, global integration milestones areestablished and enforced

Constraining these means that component/feature

functionality must flex Shared infrastructure must track ahead

Teams evolve to a flexible model:

Design spectrum for newfunctionality

Backup plan to ship

less capable version

if necessary

Lease

Imaginable

Minimum

CredibleModerate Best

52

Agile release train design continuum

Synchronized Agile Release Train


53/70

53

Release IncrementRelease Increment

(Potentially shippable(Potentially shippableincrement)increment)

Sys 1Sys 1 Sys 2Sys 2 Sys 3Sys 3 Sys 4Sys 4 Sys 5Sys 5 Sys 6Sys 6 Sys 7Sys 7 Sys 8Sys 8




TeamTeam

AA

Team BTeam B

TeamTeam

CC

SystemSystem

IterationsIterations


Ports certsPorts certs

ReleaseDocs

ReleaseDocs

ReleaseDocs

ReleaseDocs

Ports certsPorts certs

ContinuousIntegration



Component/Component/

Feature/Feature/

SubsystemSubsystem

IterationsIterations

For discussion, see www.scalingsoftwareagility.wordpress.com
http://www.scalingsoftwareagility.wordpress.com/http://www.scalingsoftwareagility.wordpress.com/


54/70

H

HH

H

2009 Leffingwell, LLC.

Rolling Wave Release Planning Drivesthe Train


55/70

BusinessContext

BusinessContext

Product VisionProduct Vision

TeamBreakouts

TeamBreakouts

Draft Release

Plan Review

Draft Release

Plan Review

ProblemSolving / Scope

Management

ProblemSolving / Scope

Management

9-10

10-11

11-12

12-1

1-2

2-3

3-4

4-6

Eng mgrs

State of the business

Objectives for upcoming periods

Objectives for release

Prioritized feature set

Each team presents plans to group

Issues/impediments noted

Issues/impediments assigned

Release commitment vote?

Teams plan stories for iterations

Work out dependencies

Architects and PMs, POs circulate

|1|1

|1|1

|2|2

|2|2

|3|3

|3|3

|4|4

|4|4

architects

Product managers/Product Owners

PMs

Executives

the Train

55


56/70

Release Commitment


57/70

57

4. Managing Highly DistributedDevelopment


58/70

Development

Co-locate team often at least at Release Planning

Establish core hours, with overlap required

Apply high cohesion and low coupling to sites (organize

and reorganize around features/components)

Dont let anyone go dark - apply daily Integration Scrums

Establish a single global instance of project assets

Invest in tools that support distributed, but shared view ofstatus

58

5. Changing the Organization


59/70

Transition as a Project

All in or Incremental Rollout

Eliminating Impediments

Moving to Agile Portfolio Management

59

Transition as a Project


60/70

Establish an Agile Enterprise Transition Team

Drives the enterprise vision and facilitates

implementation Cross-functional involvement

Cross-level involvement

Executive leadership

Create a transition backlog

Run project in iterations

Commit to weekly iteration goals

Meet at least weekly

Report to other executive stakeholders

Experience agile project management

60

Executive sponsors

Cross functional

All-In or Incremental?


61/70

All-in

Incremental

61

Eliminating Impediments


62/70

Existing rules demand adherence to document-driven, waterfall

processes and artifacts

Software test/ system test not integrated, responsive

Inadequate build and support infrastructure

Organization rewards individual over team behavior

Teams not co-located to maximum extent feasible

Teams not truly empowered

Other functions - sales, marketing, customer not supportive ofincreased delivery pace

Legacy thinking - Management expectations for fixed-price,

fixed-time, fixed-function delivery

62

Moving to Agile Portfolio Management

Changing Legacy Mindsets


63/70

63

g g g y

Investment

Funding Investment

Funding

Change

Management Change

Management

Governance

and Oversight Governance

and Oversight

From:

To:

DTE Energy Case Study, Agile 2009

6. Impact on Customers and Operations


64/70

More frequent releases challenge:

Customers

Suppliers

Marketing and Sales

Support

Documentation, certification, localization

64


65/70

7. Measuring Business Performance


66/70

66

The primary metric for agile is whether or not

working software actually exists, and isdemonstrably suitable for its intended purpose.

This is determined empirically, by demonstration,at the end of every single iteration.

All other measures are secondary.. (but not useless)

All other measures are secondary.. (but not useless)

Process Self-Assessment Metrics


67/70

67

Team Agility Assessment Radar Chart


68/70

Product Ownership

DevelopmentPractices/Infrastructure

Release Planning and Tracking

Testing Practices Iteration Planning and Tracking

Team

150%

125%

100%

75%

50%

25%

0%

68

Watch for these Anti-patterns


69/70

Insufficient refactoring of testing organizations and

inadequate test automation

Lack of team proficiency in agile technical practices

iterations and sprints treated as demo milestones, rather than

potentially shippable increments

Insufficient depth/competency in the critical product

owner role

Inadequate coordination of vision and delivery strategies

due to lack of coordinated, multi-level release planning

69


70/70

scaling agile(good!)

Documents