scaling software agility - wordpress.com few, if any of ... document requirements fully elaborated...

Copyright 2008 Dean Leffingwell

Scaling Software Agility:Best Practices for Large

Enterprises

Agile 301 - Creating the Agile

Enterprise

1


Seven Enterprise

Practices

2


1. Intentional Architecture

Continuous refactoring of large scale system level

architectures becomes 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

– Some, common imposed architectural constructs can ease

usability, extensibility, performance and maintenance

3


Architecture in the Methods

no Big Up-Front Design

architecture emerges

continuous refactoring

architecture-centric

build arch. in early

iterations

lots of guidance

Domain model

as central

architectural

view

model as

necessary

guidance

provided

4


Principles of Agile Architecture

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 the runway.

Principle #6 System architecture is a role collaboration.

Principle #7 There is no monopoly on innovation.

5


#1 –The team that codes the system

designs the system

Architectural decisions are optimally made by those who are

closest to the implementation

Once chosen, they will likely work really hard to make their

decision work

6


“What’s the simplest thing that can possibly work?”

Ward Cunningham

“If simplicity is good, we’ll leave the system with the simplest design

that supports its current functionality.”

Kent Beck

“Only way to manage as large distributed system is to keep things as

simple as possible. Keep things simple by making sure there are no

hidden requirements and hidden dependencies in the design. Cut

technology to the minimum you need to solve the problem you have.

It doesn’t help the company to create artificial and unneeded layers

of complexity.”

Warner Vogels, CTO, Amazon

#2 –Build the simplest architecture that

can possibly work

7


#3 –When in doubt, code it out

"Use measurement and objective debate to separate the good from the

bad. …. this is the aspect of Amazon that strikes me as uniquely different

and interesting from other companies.

Their deep seated ethic is to expose real customers to a choice and see

which one works best and to make decisions based on those tests.

…. calls this getting rid of the influence of the HiPPO’s, the highest paid

people in the room.

This is done with techniques like A/B testing and Web Analytics. If you

have a question about what you should do, code it up, let people use it,

and see which alternative gives you the results you want.”

-- Greg Linden, http://highscalability.com/amazon-architecture

8


# 4 –They build it, they test it

Testing architecture comes down to “testing how the system works without the details”,

i.e. testing the system‟s ability to meet its functional (in the large), operational, performance and reliability requirements (all the “ilities”).

Who has the skills to test systems of the complexity we are building today?

Who can take the responsibility?

9

"Take away everything in the system that you

don’t need to describe how it works, and what

you have left is it’s architecture”

-- Philippe Kruchten


Taking Responsibility

10

ChristopherAVERY.com


#5 –The bigger the system, the longer the

runway

teams of teams, building

systems of systems

(100s of teams)more teams

(5-10 teams)

small team scale

(1-3 teams)

How much architecture you need

Depends on what you are building

11


Building Architecture in Early Iterations

Time

Agile Project Kickoff

12


Adding Feature and Component Teams

Agile Project Kickoff

Time

13


Builds Some Architectural Runway

Arc

hit

ec

tura

l R

un

way

Time

14


Using Architecture over Time

A strong focus on value delivery stories

+ Increased productivity

+ Higher innate quality

+ more rapid delivery

= Faster reduction of feature backlog

= Faster reduction of architectural runway

15


And Faster Reduction of Runway

Arc

hit

ec

tura

l R

un

way

Time

16


Unless You Extend the Runway

build

Design

Spike

build

design test

build

design test

build

design test

build

design test

build

design test

build

design test

build

design test

build

design test

build

design test

build

Design

Spike

build

design test

build

design test

build

design test

build

Design

Spike

17


Agile Architecture Skills

Design spikes to test architectural

concepts

Refactoring – refactoring - refactoring

Enabled by

– Mature design practices, OO techniques, tooling

– Test automation

– Multi-iteration implementation

18


Multi-iteration Architecture Example

Example: three –iteration architectural pattern

2build

Design

Spike

build

design test

build

design test

3build

Design

Spike

build

design test

build

design test

1build

Design

Spike

build

design test

build

design test

19


System Architecture is a Role

Collaboration

Architectural

- Inputs

- Ideas

- Constraints

20

Architectural Evolution


Role of the System Architect

Market, technology and system-wide perspective

– How will this system need to be extended over time?

– What infrastructure technologies should be used?

Architectural governance

– Common platforms, constraints, system requirements

– Defining and negotiating component

interfaces

– Driving system-level integration

mechanisms

Release planning

– System-level impact analysis for new features

– Negotiating design spikes with the team

– Factoring system features and themes into component level stories

(requirements decomposition)

– Triaging technical scope at release planning time

21


2. Lean Requirements at Scale

Requirements still matter in agile.

At scale, lean yet more extensive

requirements practices can be

effectively applied.

22


What's so Different about Requirements in

Agile?

Prescriptive: emphasis on

getting all the requirements

right and early.

Documents: Vision, PRD,

SRS, SDS, etc.

Discovery-based: continuous,

iterative

– Acknowledge it‟s

impossible know all

requirements up-front

– Acknowledge time and

relevance dimension

Documents: few, if any of the

above

23


Lean Requirements at Scale

24

A scalable requirements practice with three

elements


Vision + Management‟s Responsibility

Where are we headed?

What problem does it solve?

What features and benefits does it provide?

For whom does it provide it

What performance does it deliver?

What platforms, standards,

applications, etc will it support?

25


Vision – Data Sheet Approach

Envision the product “flyer” or product “box” that describes the product to perspective users

– What problem does your product solve?

– What features and benefits does it provide?

– How do you communicate that to the prospect?

– What performance does it deliver?

– What platforms, standards, applications, etc does it support?

26


Vision + Records Common Requirements

Some requirements must be

known by all teams

– Performance, reliability and security requirements

– Industry/Regulatory/Customer standards and imposed

specifications

– Internationalization, accessibility

– Corporate standards: copyright, logo, graphics, legal

27


Roadmap – System Team‟s

Responsibility

28

May 15, „08 May 22, ‟08 July „08

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

Multiuser Road Rage

first release

Brickyard Ported

multiuser demo

New features for both

games (see prioritized

list)

Beemer game to E3

Tradeshow?

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


Roadmap is a “Plan of Record”

Driven by release planning function

All Features prioritized within each release

– High confidence in near term Release features

– Lower confidence in later Release features

Underestimation, stuff happens

Often replaced by new, emergent, higher priority features

Avoid fixed schedule/fixed resource/fixed requirements

claims

If everything is fixed, it isn‟t agile

29


Just-In-Time Elaboration –

Component Team‟s Responsibility

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

30


Why “Stories”, not “Requirements?”

Requirements, by definition, are something that

the system must do

(hmmmm . can’t negotiate, have to do it, have to do it just like it says”)

User Stories communicate intent, along the “CCC” model

– The card part describes the label or brief description of the story

– The conversation part reminds us that the story is not a

requirement but is a promise to discuss the intent of the story with

the product owner

– The confirmation part refers to that aspect of the story that

indicates how the story will be accepted

Jeffries [2001]

31


When is it Time to “INVEST”?

. Whenever possible, stories should be written to be independent of other

stories.

. Stories differ from our traditional notion of requirements in that user stories

are negotiable. Negotiation between the development team and the product

owners on the requirements continuum is integral to agile efficiency.

. Most stories will directly affect the user or purchaser, and the value to the

user is obvious in well-written stories.

. Good user stories are estimable, and they can be analyzed and estimated

by the team with a reasonable accuracy.

. Each user story should be sized to fit within an iteration and will typically

require no more than a few person-days to implement and test. Larger,

compound, complex stories should be divided into multiple stories that are

required to realize the feature.

. Stories should be written so that the team can understand when the story is

complete and can be accepted within the iteration.

Wake [2003]

Just before the iteration boundary, stories are written:

32


Driving Requirements

Product Manager

Product Owner

33


Product Owner in Scrum

34

Product Owner Assure team is pursuing a common vision

Establish priorities to track business value

Act as „the customer‟ for developer questions

Work with product management to plan releases

Accept user stories and iteration

Scrum Master Run team meetings, enforce scrum

Remove impediments

Attend integration scrum meetings

Protect the team from outside influence

Team Create user stories from product backlog

Commit to iteration plan

Define/Build/Test/Deliver stories (fully accepted)


PM VS PO What's Different with Agile?

Understand customer need Up front and discontinuous Constant interaction

Document requirements Fully elaborated in MRD/PRD Coarsely documented in Vision

Scheduling Plan one time delivery way later Continuous near term roadmap

Prioritize requirements Not at all or one time only in PRDReprioritize every release and

iteration

Validate requirements NA – QA responsibility?

Accept every iteration and

release.

Smaller, more frequent releases

Manage changeProhibit change – weekly CCB

meetings

Adapt and adjust at every

release and iteration boundary

Assess status Milestone document reviewSee working code every iteration

and every release

Assess likelihood of release

date

Defect trends or crystal ball,

developers words?

Release dates are fixed. Manage

scope expectations

35


So What‟s the Problem?

For the enterprise PM, this looks like a lot more work

for the PM.

And, realistically, it is

Solution – get help - in the form of a “Product

Owner”

36


Roles: Product Manager and Product

Owner

Strategic and outbound Technical and tactical - inbound

Lives with other PMs, marketing, sales

and customerLives with the development team

Messaging and positioning Define iteration objectives

Product, System and portfolio planningComponent and subsystem

responsibility

Identify market needs Write stories and acceptance criteria

Own the Vision Own the implementation

Own the Release Own the iteration

37


3. Systems of Systems and the Agile

Release Train

Scaling agile requires managing

interdependencies amongst distributed teams

of component developers

This requires more coordinated planning and

somewhat longer release cycles

Scaling agile requires a component-based,

“agile release train” delivery model

38


Principles of the Agile Release Train

Release dates for the solution are fixed

Intermediate, global integration milestones are

established and enforced

Constraining these means that component functionality

must flex

Shared infrastructure components must track ahead

Teams evolve to a flexible model:

– Design spectrum for new

functionality

– Backup plan to ship the

old version if necessary

39

Lease

Imaginable

Minimum

CredibleModerate Best


Agile Synchronizes and Better Assures

Component Delivery

40


But Component Agile is not System Agile

41

Time when you discover you are not

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

The slowest component drags the train


Synchronized Release Train

42

S H

I P !


Planning Agile at Scale

Organizing for Scale

Release Planning and Tracking in the Large

43


Organizing for Scale

44


Integration Scrum

A daily interactive venue for progress tracking and

raising issues that are cross-team dependant. Forces

every team to talk together every day

– What my team did yesterday

– What my team is going to do today

– Any blocks, interdependencies or requirements for coordination

that are necessary to keep that team moving forward that day

45


Release Mgt Team/ Steering Committee

VP/Director-level managers –Development and executive level

development mangers who have responsibility for multiple teams or

larger subsystems or systems.

Enterprise architect –one or more architects may share responsibility

for system architecture and requirements governance

System-level QA – one or more senior QA persons who are responsible

for system level quality, platform, and performance testing

Product Managers and Business Owners – senior product managers

and business people who are responsible for the strategic direction of the

product line

The steering committee meets weekly and addressed the following questions:

What is the status of the current release?

What coordination do we need to provide to facilitate progress?

Are we likely to meet the release schedule, and if not, how do we adjust

scope to assure that we can meet the release dates?

46


Release Planning is a “Big Event”

A full day (or two for larger teams) for every release

Most everyone attends in person if at all possible

Adequate logistics and facilitation

– Big room with lots of whiteboard space

– Break-out rooms for multiple teams.

Product Manager owns the feature priorities

Development team owns story planning and high-level

estimates

Architects work as intermediaries for governance,

interfaces and dependencies

47


Release Review

From the perspective of the code, this may or

may not be a major event

– Often, it is only a slightly more extended review of the last iteration

in the release cycle.

– Often, the more agile the teams become, the less of a “Big Event”

this is

Most all the code has been running, integrated, tested and accepted for many

iterations

Almost all functionality has been demo‟d before

However, it does represent a major accomplishment (the

purpose of the enterprise!) and some ceremony/

celebration is appropriate

48


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

Release Planning Day 1

49


Draft Plan Review

50


Release Planning Day 2

51

Objectives for release

Prioritized feature set

All Issues/impediments assigned

Release commitment vote

What did we learn?

Multi-release planning

Dev teams

Eng mgrs

Eng mgrs/PMs

Product Managers

|1|1

|1|1

|2|2

|2|2

|3|3

|3|3

|4|4

|4|4


Results: A Plan for Next Release

Hi fidelity plan for

iteration 1

Mechanisms for

tracking feature

based progress

52


Results: the “Commitment”

53


Result: Release Roadmap

54

May 15, May 15, „„0808

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

May 22, ‟08 May 22, ‟08

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

July July „„0808

Multiuser Road Rage

first release

Brickyard Ported

multiuser demo

New features for both

games (see prioritized

list)

Beemer game to E3

Tradeshow?

An updated, themed, and prioritized “plan of record”


4. Managing Highly Distributed

Development

At scale, all development is

distributed development.

▬ Chapter 19, Scaling Software Agility

55


Recommendations

Organization

– Apply high cohesion and low coupling to sites (organize and

reorganize around the architecture)

People and F2F

– Co-locate team often – at least at Release Planning

Daily Communication

– Establish core hours, with overlap required

– No team/person goes “dark” - apply integration scrums

Tooling

– Establish a single global instance of project assets

– Invest in tools that support distributed, but shared project status

56


Example: Distributed Team – Outsourced

Implementation

57


Example: Agile Swarm

Allows remote, exceptional talent to work on the D/B/T

team

Combination of working at home and f2f

– One f2f syncs per iteration (little swarm)

– Large on-site presence during hardening tails (big swarm)

General work situations will vary:

– Those largely working from home

– Those choosing to always work on-site

– Those required to work on-site for short periods

– Those always required to work on-site

58

Highly Distributed Team within a Daily Working

Cadence

Copyright 2008 Dean Leffingwell 59

Swarm Work and Travel Patterns


Swarm Daily “Standup”

60

Daily standup time is

mandatory

Offsite team members

flex as necessary

Meetings indexed to on-

site team

Core hours expectations

support scheduling of

on-line meeting


Asynchronous Collaboration

Shared, program-wide visibility into priorities, status,

dependencies & blocks for tight coordination across

time zones

Communication, communication

– Skype, wikis, IM, email, Web conferencing,

VOIP, international mobiles

– Shuttle diplomacy

+A backup for all

communication channels

61


Backlog Management Across Teams

Centrally capture, organize and

decompose by program or project/component

– Feature lists, user stories, and non-functional requirements

– Priorities, estimates, status and owners

Program Backlog By

Project

62


Real-Time Project Reporting

Quick, daily updates

to task estimates,

status &

remaining effort

Roll-up by project

and by program

Automated burn

down charts

63


Real Time Status – the big picture

64


5. Changing the Organization

Agile Transformation is a process of continuous

improvement, not a one-time event

Where change is the norm, not the exception,

This creates an environment of continuous

insecurity in our organizations

Which Requires Agile and Adaptive

Leadership

65

-Trailridge Consulting


Transition Required

Acknowledge losses

Recognize opportunities and frustrations

Have the patience to succeed

Experiment, re-conceive, innovate

66


“Scrumming” the Transition

1. Establish an Agile Enterprise Transition Team

– Executive leadership

– Cross-functional, cross-level

– Establishes objectives

– Facilitates implementation

2. Create a transition backlog

3. Implement in iterations

– Commit to iteration goals

– Demo progress, plan next iteration

– Report to other stakeholders

– Experience agile project management

67


Eliminating Impediments

Management assumes fixed price/time/scope?

Existing rules demand adherence to document-driven,

waterfall processes?

Software/system test not integrated with teams?

Inadequate build and integration infrastructure?

Organization rewards individual over team behavior?

Teams not co-located to maximum extent feasible?

Teams cannot make small decisions needed?

Other functions - sales, marketing, customer not

supportive of increased delivery pace?

68


Scope - All-In or Incremental?

69

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

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


Practices – Minimum Subset or?

70

Continuous integration

Assured unit testing

Test automation

TDD

Peer review

Shared code

ownership/cross training

Pair programming

Code quality & standards

D/B/T Teams

Iterations & Releases

Empowering team

leadership – agile master

Agile Product Owner

Daily Standup

Demo and retrospective

Lean requirements

Intentional Architecture

Agile Release Train

Collaborative, Multi-level

Release Planning

Agile Metrics


Incremental Rollout Pattern

Establish 3-5 pilot teams

Provide training and mentoring for those teams

Run for 3-4 months

Gather metrics and lessons learned

Expand by 5-10 more teams

Run for 3-4 months

Gather metrics and lessons learned

Rollout across the organization

71


All-in Rollout Model

Agile enterprise transition team is critical

– Manages resources and training budgets

– Implements communication plan

– Tracks progress

Leveraged agile training

– Delivers training to large audience

Experienced + internal agile mentoring and guidance

– Train internal mentors and coaches for teams

– Fills in the gaps

– Adjusts to enterprise context

72


Ideal Training Profile

Agile Team Training (2 days)

Agile Master Training (CSM+)

Agile Product Owner (1)

Agile Release and

Project Management (1)

Agile Product Manager (1)

Scaling Software Agility (1)

73


Leveraged Rollout Model

Project/Release Project/Release

Manager

(20-30)

Product Owner Product Owner

Training

(30-40)

Agile Master

training

(30-50)

Agile Team Training

(30-50 teams)

74


Watch for these Observed Anti- patterns…

1. Insufficient refactoring of testing organizations and

inadequate test automation

– Iterations do not have requisite quality, excess technical debt

2. Lack of team proficiency in agile technical practices

– iterations and sprints treated as demo milestones, rather than

potentially shippable increments

3. Insufficient depth/competency in the critical product

owner role

4. Inadequate coordination of vision and delivery strategies

– Lack of coordinated, multi-level release planning

75


6. Impact on Customers and Operations

More frequent releases challenge:

– Our customers

– Our sales and marketing teams

– Our customer care and support teams

76


Development develops

faster, in smaller

increments

External processes follows

old model, ignoring

incremental releases

Guidance & feedback into

releases compromised

Ultimate outcome:

– Slow delivery

– Extremely limited feedback

– Inventory of undelivered

value

– Increased product

trajectory risk

Agile Market Release Planning

Pitfall 1 – The “Ignore Agile” Approach

GA

Internal

Release

Internal

Release

Internal

Release

Internal

Release

Time

77


Agile Market Release Planning

Development ships more

function, faster, in smaller

increments

Interfaces & organizations

follow synchronized

model

– try to keep up - quickly

overloaded

– System can break down

completely

Ultimate outcome

– Increased execution risk

– Market confusion- Too

much noise, messaging

and feedback are

compromised

GA

GA

GA

Time

78

Pitfall 2 – Hyper-waterfall – “Chasing Agile”


Solution: Separation of Concerns

79


Benefits

Internal releases on fast agile cadence

– No limit – the faster the better

– Constant feedback

– Continuous integration

Internal releases available for preview, trial deployments

GA releases timed to external market events – no fixed

release schedule required

Minimized GA release coordination challenges

80


7. Measuring Business Performance

“The primary metric for agile software

development is whether or not working software

actually exists, and is demonstrably suitable for

its intended purpose.

In Agile, this key indicator is determined

empirically, by demonstration, at the end of

every single iteration.”

All other measures are secondary

81


Types of Agile Metrics

Project Metrics

Process Metrics Self-Assessment

Enterprise Balanced Scorecard

82


Agile Project Metrics

# stories (loaded at beginning of iteration)

# accepted (defined/built/tested and accepted)

% accepted

# not accepted (not achieved within iteration)

# pushed to next (rescheduled in next iteration)

# not accepted: deferred to later date

# not accepted: deleted from backlog

# added (during iteration, should typically be 0)

% SC with test available/test automated

Defect count at start iteration

Defect count at end of iteration

# new test cases

# new test cases automated

# new manual test cases

Total automated tests

Total manual tests

% tests automated

Unit test coverage percentage

83


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

84

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 and

release 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


Process Metrics Radar Chart

85

Product Ownership

Development

Practices/InfrastructureRelease Planning and Tracking

Testing Practices Iteration Planning and Tracking

Team

150%

125%

100%

75%

50%

25%

0%


Balanced Scorecard Approach

Product ROI

Employee turnover

R&D cost as % revenue

# releases in last 12 months

# features in last 12 months

# story cards in last 12 months

%sc achieve in last 12

Release date % achieve last 12

# arch re-factors in the last 12

Normalized defects

Normalized support calls

Support satisfaction

Product satisfaction

Escalation rate %

Product management

Release planning and tracking

Iteration planning and tracking

Agile process

Teamwork

Development practices

86


Summary

87

1. The Define/Build/Test

Component Team

2. Mastering the Iteration

3. Two-level Planning and

Tracking

4. Smaller, More Frequent

Releases

5. Concurrent Testing

6. Continuous Integration

7. Regular Reflection and

Adaptation

1. Intentional Architecture

2. Lean Requirements at Scale

3. Multi-level Release Planning

4. Managing Highly Distributed

Development

5. Changing the Organization

6. Impact on Customers and

Distribution

7. Measuring Business

Performance

Copyright 2008 Dean LeffingwellInspired by collaboration

Leffingwell, LLC & Symbian Software Ltd.

H

HH

H

Rele

ase

Pla

nn

ing

Rele

ase

Pla

nn

ing

Rele

ase

Pla

nn

ing

Pla

n

De

mo

Pla

n

Dem

o

Level 3

Le

vel 2

Level 1

8


More from Dean Leffingwell

89

http://www.scalingsoftwareagility.wordpress.com/

http://www.leffingwell.org/

mailto:[email protected]


END AGILE 301

90