© 2009-2010 Leffingwell, LLC. Scaling Software Agility: Best Practices for Large Enterprises By Dean Leffingwell September, 2010 (Rev 9 (9_10)

© 2009-2010 Leffingwell, LLC.

Scaling Software Agility:Best Practices for Large

Enterprises

By Dean Leffingwell

September, 2010

(Rev 9 (9_10)

© 2009-2010 Leffingwell, LLC. (Rev 6)

About Dean Leffingwell

2

AuthorExecutive

Founder/CEO Requisite, Inc.

Makers of RequisitePro

Senior VPRational Software

Responsible for Rational Unified Process (RUP) &

Support of UML

Founder and CEOProQuo, Inc., Internet identity

Agile Executive MentorBMC, John Deere and others

Agile Enterprise CoachContinuing…medium size,

large and very large software enterprises...

Coach

Cofounder/AdvisorPing Identity, Roving Planet,

Rally Software


More from Dean Leffingwell

Books

– Coming Soon: Agile Software Requirements: Lean Requirements Practices for Teams, Programs and the Enterprise

– Scaling Software Agility: Best Practices for Large Enterprises

Blog and Resources

– www.scalingsoftwareagility.wordpress.com

Reach me at [email protected]

3

© 2009-2010 Leffingwell, LLC. Copyright 2007 Dean Leffingwell

Approaching Agile at Scale

.We place the highest value on actual implementation and

taking action.

There are many things one doesn’t understand; therefore, we ask them, why don’t 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 you can redo it once again.

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

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

-- Fuijo Sho, Chairman, Toyota


If you accept the premise that market needs change faster than the software industry’s traditional ability to develop solutions, you’re 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


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‘ enables

process to succeed in spite of geographically dispersed teams– “Other companies experience higher defects and longer

schedules with split teams, BMC does not. I've never seen this before. The low bug rates also result in very low defect rates post-production”

… clearly ahead of more than 95 percent of all the software projects captured in the SLIM metrics database, they're among the best I've seen

Source: QSM Associates Press Release, Sep 10, 2007

6


What is Software Agility?

1. A disciplined project management process that encourages frequent inspection and adaptation and continuous strategic improvement

2. A leadership philosophy that encourages teamwork, self-organization and accountability

3. A set of software engineering best practices that promotes rapid delivery of high-quality software

4. A business approach that aligns IT with customer needs and company goals

7Source: wikipedia


Before: Predictive Process Approach

1970 1980 1990 2000

Predictive Processes

Waterfall

Predictive, plan-based Process

Plan – measure – re-plan - repeatPr

oces

s

Inpu

ts

Out

puts

8


Predictive vs. Empirical Process

If a process is too unpredictable or too complicated for the planned, (predictive) approach, then the empirical approach

(measure and adapt) is the method of choice. - Ken Schwaber

Empirical (Adaptive) Process

Proc

ess

Controls

Inpu

ts

Out

puts

Plan – measure – re-plan - repeat

9


Agile Process Movement

IterativeProcesses

Spiral RAD RUP…

Often confused with waterfall Continued to be artifact heavy

A stepping stone to agile…

1970 1980 1990 2000


Waterfall

10© 2007 Trail Ridge Consulting, LLC


Agile Process Movement

IterativeProcesses

Spiral RAD RUP…

Agile (Adaptive) Processes

Scrum, XP, Lean, Open UP, FDD, Crystal…

1970 1980 1990 2000


11Adapted from Trail Ridge Consulting, LLC

2010

Enterprise Agility

Yahoo, Google, BTI, BMC, Nokia, DTE Energy, Cisco, Citrix, HP, JP Morgan, AOL Boeing, Comcast, PayPal, EDS, Emerson, Fidelity…

http://users.evtek.fi/~jaanah/ApplicationD/waterfall.gif


Agile Methods

Adaptive Software Development (Highsmith)

Crystal Methods (Cockburn)

Dynamic System Development Method (Faulkner et al)

Feature Driven Development (Coad & DeLuca)

Lean Software Development (Poppendiecks)

SCRUM (Schwaber, Beebe, Sutherland)

Extreme Programming (XP) (Beck, Gamma)

Iterative/Agile – RUP and Open Unified Process (Jacobson, Kruchten, Royce, Kroll)

12


Agile Principles—The Agile Manifesto

“We 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”

13

http://www.agilemanifesto.org

http://agilemanifesto.org/principles.html


Agile Manifesto Principles

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software

Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage

Working software is the primary measure of progress

Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale

Business people and developers must work together daily throughout the project

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done

14




Principles (continued)

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

Continuous attention to technical excellence and good design enhances agility.

Simplicity--the art of maximizing the amount of work not done--is essential.

The best architectures, requirements, and designs emerge from self-organizing teams.

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

15


Agile Turns Tradition Upside-Down

PlanDriven

Requirements Cost ScheduleConstraints

Cost Schedule FeaturesEstimates

Value/VisionDriven

Predictive Process(Waterfall)

Adaptive Process(Agile)

The plan createscost/schedule estimates

The vision createsfeature estimates

16


Helps Avoid the Death March

Agile

Waterfall

Time

Pre

ssu

re

Deadline

17

Peak performance achieved and maintained indefinitely at a sustainable pace


Reduces Risk

Time

Deadline

Ris

k

Agile

Waterfall

18


Starts Delivering Immediately

Time

Deadline

Va

lue

De

live

ry

Agile Waterfall

19


Makes Money Faster

Time

Deadline

Va

lue

De

live

ry

20

Market value of a feature over

time

Cumulative gross margins


Project Multiplexing

Your team has three projects. Each will take the entire team one month and delivers value of one unit.

Plot value delivery curves over time of doing the projects in Scenario A Serially and Scenario B parallel (simultaneously)

(Assume 20% task switching overhead for each team member in Scenario B)

What is the efficiency of the team in Scenario A vs. B?

Project A Project B Project C

Scenario A – Serial Delivery

Scenario B – Parallel

Time

Project A

Project B

Project C

Time


Delivers Better Fit for Purpose

Time

What the customer would, in the end,

like to have

What the customer thought they

wantedwaterfall plan, result

agile(adaptive) plan, result

Measure ofwaterfall customerdissatisfaction

22


Achieving Team Agility

1. The Define/Build/Test Team

2. Mastering the Iteration

3. Two-levels of Planning and Tracking

4. Smaller, More Frequent Releases

5. Concurrent Testing

6. Continuous Integration

7. Regular Reflection and Adaptation

Seven Agile Team Practices that Scale

23


Seven Agile Team Practices That Scale

The Define/Build/Test Team

Mastering the Iteration

Two-level Planning and Tracking

Smaller, More frequent releases

Concurrent Testing

Continuous Integration

Regular Reflection and Adaptation

24


1. Define/Build/Test Team

Optimized for vertical communication

Friction across the silos

Location via function

Political boundaries between functions

Pro

du

ct M

gt

Arc

hit

ectu

re

Dev

elo

pm

ent

Test

an

d Q

A

Before Agile: Typical Functional Silos

Management Challenge: Connect the Silos

25


A self-organizing team that can Define, Build and Test a thing of interest

Optimized for communication about the thing Repeated at larger scales to produce larger

systems Teams can be based on

– Features

– Products

– Components

– Subsystems

– Interfaces

D/B/T Team – Agile Fractal

Team 1

Team 100

26


D/B/T Teams Have the Necessary Skills

8-10 Team members maximum

Developer Developer Developer Tester

TesterDeveloperProduct Owner

Tech

nic

al

Inte

rfac

eArchitect

Tech lead Scrum / Agile Master

Team

of

Team

In

terf

ace

QA/Release Mgt

27


The iteration is the heartbeat of agility. Master that, and most other things agile tend to

naturally fall into place.


28


Iteration Pattern

Story AStory BStory CStory DStory EStory F

Story …

Iteration backlog

Define

Develop

Accept

Iteration Objective

Pla

n

Review

Fix

ed

Res

ourc

es

Fixed Time (Iteration)

Story A Story B

Story C

29


3. Two-Level Planning and Tracking

Iteration Cycle

Release Cycle

Drives

Feedback - Adjust

Plan Releases at the System Level– Three to six months

horizon

– Prioritized feature sets define content

Plan iterations at the component/feature level– 2-4 iteration visibility

– Currency: user stories

ReleaseVision

Release PlanningRelease Scopeand Boundaries

30

Iteration Planning

Develop & TestReview &

Adapt


Release Pattern

Prioritized Release (feature)

Backlog

– Feature 1– Feature 2– Feature 3– Feature 4

Feature 1

Feature 2

Feature 3

PlanStories

Release timebox

Release theme and objectives

Review

31


4. Regular Cadence - Smaller, More Frequent Releases

Faster value delivery and faster feedback

– 60-120 days

Less Work in Process

Predictable delivery

– Date, theme, planned feature set, quality

Scope is the variable

– Release date and quality are fixed

BEFORE

Release Time Frame

Cycle Cycle Cycle

AFTER

Cycle Cycle Cycle Cycle Cycle Cycle

Release Time Frame

32

We have to figure out a way to deliver software so fast that our customers won’t have time to change their minds.

─Poppendiecks - Implementing Lean Software Development


Achieving Cadence: Fix Dates & Quality - Float the Features

Teams learn that dates MATTER Product owners learn that priorities MATTER Agile teams MEET their commitments Floating features provides the capacity reserve to meet deadlines

PSI 1 PSI 2 PSI 3

10/1/2010 11/1/2010 12/1/2010 1/1/2010 2/1/2010 3/1/2010

3/25/20109/24/2010

33

“



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 all write tests.

Test automation is the rule, not the exception.

Philosophy of Agile Testing

34


Concurrent

Unit Testing

– Developer written

Acceptance Testing

– Customer, product owner, tester written

Component Testing

– Integrated BVT (build verification tests) at component/module level

System, Performance and Reliability Testing

– Systems tester and developer Written

– QA Involvement

35


Agile Testing Quadrants

36

Business-Facing

Su

pp

ort

Dev

elo

pm

ent C

ritiqu

e Pro

du

ct

Technology-Facing

Functional TestsStory

acceptance tests

Exploratory TestingUsability TestingScenario Testing

User Acceptance Testing

Unit TestsComponent Tests

System QualitiesPerformance and LoadSecurity“ility” (NFR) Testing

ManualAutomated & Manual

Automated Tools

Q1

Q2 Q3

Q4

Adapted from Brian Marick, and Agile Testing by Crispen and Gregory 2009


On Test Automation

You have no choice Manual tests bottleneck velocity You can’t ship what you can’t test

Automate Now

37



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

38


Continuous Integration Success

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

39

Source: Martin Fowler


Memo from an XP Shop

40

“The XP environment provides us with many benefits, not the least of which is the incredible pace of progress we are so proud of. Lately we have had a rash of build failures, some related to infrastructure issues, but more related to carelessness. Broken builds destroy the “heartbeat” of an XP team. Each of you has a primary responsibility to ensure that this doesn’t happen . . . but here are a few tips to ensure that you aren’t the one who broke the build:

– Write your test cases before you write the code

– Build and test the code on your desktop BEFORE you check it in

– Make sure you run all of the cases that the build does

– Do not comment-out inconveniently failing unit tests. Find out why they are broken, and either fix the test or fix your code

– If you are changing code that may affect another team, ASK before you check it in

– Do not leave the building until you are SURE your last check-in built successfully and the unit tests all ran

The Build master is there to make sure that broken builds get addressed, not to address them. The responsibility for a broken build is yours. Breaking the build will have an affect on your standing within the team and, potentially, your review, so let’s be careful out there.”



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 isn’t, and what one thing to do differently next time

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

Agile Manifesto, Principle 12

The shorter the iterations and releases ‒ the faster the learning

41


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 customer feedback

A set of – organizational best practices– core values and beliefs

42


Achieving Enterprise Agility

1. Intentional Architecture

2. Lean Requirements at Scale

3. Systems of Systems and the Agile Release Train

4. Managing Highly Distributed Development

5. Impact on Customers and Operations

6. Changing the Organization

7. Measuring Business Performance

Seven Enterprise Practices

43



Continuous refactoring of large-scale, system-level architectures 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 necessary44


Principles of Agile Architecture

Principle #1 The teams that code the system design thesystem.

Principle #2 Build the simplest architecture that canpossibly work.

Principle #3 When in doubt, code (or model) it out.

Principle #4 They build it, they test it.

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

Principle #6 System architecture is a role collaboration.

Principle #7 There is no monopoly on innovation

Principle #8 Implement architectural flow

45


System Architecture is a Role Collaboration

Value Stories+ Arch. Spikes

Agile Team

Customers

System/ Portfolio Team

SystemArchitect

Design Spike Tech lead/

architect

ProductManager

ProductOwner

Scrum/Agile

Master

Project Stakeholders

ProductVision

Architectural- Inputs- Ideas

- Constraints

46

Architectural Evolution



Requirements still matter in agile. At scale, lean and more extensible

requirements practices can be applied.

47


Lean Requirements at Scale

A scalable requirements practice with three elements

Vision+ Roadmap Just-in-Time Elaboration

Story 1

Story 2

Story 3

|1 |3|2 |4

48


Vision - Management’s responsibility

Where are we headed as a business?

What problem does this product solve?

What features and benefits does it provide?

For whom does it provide it?

What performance does it deliver?

49


Common and Non-functional 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

Common Requirements

Documented and available to all affected teams.

50

Non-functional (Quality) Requirements


Roadmap – System Team’s Responsibility

May 15, 10 May 22, ’10 July ‘10

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 demo New features for both

games (see prioritized list)

Beemer game to E3 Tradeshow?

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

First two games available (Road Rage and Brickyard)

First distributed game (Road Rage)

Game 1 Demo - Proof of viability on new platform

IR1 IR2 IR3

51


FEATURE

Story 1Omnis decus

Plurubus unum

Story 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, elaboration is required – Refine the team’s understanding

– Support design, implementation and testing

– Define acceptance criteria

User Stories are the currency

Just-In-Time Elaboration – Agile Team’s Responsibility

52


Implemented byStoryEpic Feature

Realized by Realized by

0,1 1..* 0,1 1..*

Is one of

Backlog ItemNonfunctionalRequirement0.. 0..*

Constrained by

Investment Themes 0, 1 1..*

Realized byTask

1 1..*

Acceptance Test

Done when passes

1..*

1..*

0..*

System Qualities Test

Compliant when passes

User Story

Other Work Item

1..*

Is one of

1..*

A Lean, Enterprise-Scale Requirements Model

version

*



Align all teams to the enterprise mission Scaling agile requires managing interdependencies

amongst distributed agile teams Teams themselves must understand and manage their

dependencies Requires coordinated planning and synchronized

development activities This is facilitated by an “agile release train” delivery

model

Rolling-wave Enterprise Release Planning drives release train vision and execution

54


Principles of the Agile Release Train

Release dates for the solution are fixed

Intermediate, global integration milestones are established and enforced

Therefore, component functionality must flex

Teams evolve to a flexible model:

– Design spectrum for new functionality

– Backup plan to ship existing assets if necessary

55

Lease Imaginable

Minimum Credible

Moderate Best

“Time pressures will drive extreme use of simultaneous engineering”

-- The New, New Product Development GameHarvard Business Review, 1986


Everybody Must Be on the Train

Waterfall doesn’t work

delay

Planned release

MRD PRD SRS Dev Drop 1 to QA

Drop 2 to QA

Test drop 1

Release docs

System test and bug fix

Test drop 2

Ports, certs

Actual releaseAgile works better

PSI

Iterate Iterate Iterate

Release docs

Harden

Ports, certs

Iterate Iterate Iterate Harden

56

Waterscrumming doesn’t work

What do we integrate here?


But Cadence Alone is not Enough

57

Time when you discover you are not

Planned system release date

…....time spent thinking you are on track…….

Integrate and slip!

System

External Release

External Release

External Release

Internal Release

Internal Release

Iterate Iterate Iterate Harden Iterate Iterate Iterate Harden

Iterate Iterate Harden Iterate Iterate Harden

A

B

C

Modules

Internal Release


The slowest component drags the whole train

Release docs

Port and certs

Port and certs

Release docs

Release docs


Synchronize to Assure Delivery

58

First PSI Second PSI or Release

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




Team A

Team B

Team C

Modules

System Iterations

External Release

External Release

External Release

Release docs

Ports certs

Release Docs

Release Docs

Ports certs

Ports certs

Internal Release

Internal Release

Internal Release




S H

I P !

Regular, system wide integration provides higher fidelity tests and objective

assessment

Synch events facilitate cross functional tradeoffs

Assured Potentially Shippable Increment


Business Context

Product Vision

Team Breakouts

Draft Release Plan Review

Problem Solving / 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

|2

|2

|3

|3

|4

|4

architects

Product managers/ Product Owners

PMs

Executives

Rolling Wave Release Planning Drives the Train

59


Rolling Wave Release Planning Day 2

9-10

10-11

11-12

12-1

1-2

2-3

Objectives for release Prioritized feature set

All Issues/impediments assigned Release commitment vote

What did we learn? Update Product Roadmap

60

Revise Objectives?

Plan/Re-plan as necessary

Final Plan Review

Commitment

Dev teams

Eng mgrs

Eng mgrs/PMs

Product Managers

|1

|1

|2

|2

|3

|3

|4

|4


Release Commitment

61



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) Don’t 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 of

status

62



Transition as a Project “All in” or Incremental Rollout Eliminating Impediments Moving to Agile Portfolio Management

63


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

Transition as a Project

64

− Executive sponsors

− Cross functional


All-In or Incremental?

Advantages Disadvantages

Minimizes adoption risk More modest training resources Develop successful organizational

patterns Develop internal mentors

Failure is an option Dual software processes Continuously re-factoring process

guidance Delayed enterprise benefits

Advantages Disadvantages

Failure not an option All hands on deck Unified software practices Enterprise benefits achieved most

quickly

Enterprise disruption Risk of larger scale failure Risk of organizational buy-in Training and education resource

demands

All-in

Incremental

65


Eliminating Impediments

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 of increased delivery pace

Legacy thinking - Management expectations for fixed-price, fixed-time, fixed-function delivery

66


Moving to Agile Portfolio Management

67

Changing Legacy Mindsets

From:

To:

DTE Energy Case Study, Agile 2009



More frequent releases challenge:– Customers

– Suppliers

– Marketing and Sales

– Support

– Documentation, certification, localization

68


Solution: Separation of Concerns

Version 1.0Analyst toursCustomer shipComprehensive U

General Availability Version 2.0Analyst toursCustomer shipComprehensive U

Marketing Controlled Announcement Window

Release to Market Processes

Asynchronous Collaborative

Development release (internal release) train 8/20/2010

7/1/20104/1/20101/1/201010/1/20107/1/2010

6/10/2010

Customer upgrade Possible

New productIR 5IR 4IR 3IR 2IR1

Docs and certsCustomer preview Docs and certs

General Availability Firewall



70

The primary metric for agile is whether or not working software actually exists, and is

demonstrably 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)


Release theme established and communicated

Release planning meeting attended and effective

Release backlog defined

Release backlog ranked by priority

Release backlog estimated at plan level

The team has small and frequent releases

The team has a common language and metaphor to describe the release

Release progress tracked by feature acceptance

Team completes and product owner accepts the release by the release date

Release review meeting attended and effective

Team inspects and adapts (continuous improvement) the release plan

Team meets its commitments to release

Total Release Planning and Tracking Score

Process Self-Assessment Metrics

Software Agility Team Self-AssessmentScore(0-5)

Comments

Backlog prioritized and ranked by business value

Backlog estimated at gross level

Product owner defines acceptance criteria for stories

Product owner and stakeholders participate at iteration andrelease planning

Product owner and stakeholders participate at iteration and release review

Product owner collaboration with team is continuous

Stories sufficiently elaborated prior to planning meetings

Total Product Ownership Score

All testing is done within the iteration and does not lag behind

Iteration defects are fixed within that iteration

Unit tests are written before development

Acceptance tests are written before development

100% automated unit test coverage

Automated acceptance tests

Total “Testing” Practices Score

Iteration progress tracked by task to do (burn-down chart) and card acceptance (velocity)

Work is not added by the product owner during the iteration

Team completes and product owner accepts the iteration

Iterations are of a consistent fixed length

Iterations are no more than 4 weeks in length

Iteration review meeting attended and effective

Team inspects and adapts (continuous improvement) the iteration plan

Total Iteration Planning and Tracking Score

71


Team Agility Assessment Radar Chart

Product Ownership

Development Practices/Infrastructure

Release Planning and Tracking

Testing Practices Iteration Planning and Tracking

Team

150%

125%

100%

75%

50%

25%

0%

72


Watch for these Anti-patterns…

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

73


Summary

1. The Define/Build/Test Team


3. Two-level Planning and Tracking

4. Smaller, More Frequent Releases




Agile Teams








Agile Enterprise

74

Team

Portf

olio

Prog

ram

Re

lea

se

(o

r P

SI)

Developers & Testers

Tea

m B

ac

klo

g

Stories fit in iterations

(Implemented by) Tasks

Features fit in

releases

Epics span

releases

Iterations Iterations

Release theme and objectives

Architectureevolves

continuously

Spikes are research, design, refactor Stories

Systems, applications, products

The Big Picture

Agile Teams(3-10 typical per “pod”)

Architectural Runway

Epic 3

Epic 4

Portfolio Vision

H

HH

H

Stories

Features and components

Scrum/Agile

Master

Rel

ea

se P

lan

nin

g

Rel

ea

se P

lan

nin

g

Pla

n

Dem

o

Feature 3

Feature 4

System Team

Release Planning

Feature 2

Feature 1

Epic 1

Epic 2

Pla

n

Dem

o

Nonfunctional

requirements (

NFRs

Stories

Investment Themes

RoadmapVision

Arch 1

©2010 Leffingwell, LLC.

Re

lea

se

(o

r P

SI)

Po

rtfo

lio

Bac

klo

g

Pro

gra

m

Bac

klo

g

Product Owner

NFRsTea

m B

ac

klo

gTe

am

Ba

ckl

og

Source: Agile Software Requirements: Lean Requirements Practices for Teams, Programs and the Enterprise.

Copyright 2010, Leffingwell, LLC.See www.scalingsoftwareagility.wordpress.com


Suggested Readings

Scaling Software Agility: Best Practices for Large Enterprises. Leffingwell, Dean. Addison-Wesley. 2007.

Scaling Lean and Agile Development: Thinking and Organizational tools for Large-Scale Scrum. Larman, Craig and Bas Vodde. Addison-Wesley. 2009.

76

Documents

© 2009-2010 Leffingwell, LLC. Scaling Software Agility: Best Practices for Large Enterprises By Dean Leffingwell September, 2010 (Rev 9 (9_10)