Business Change: Agile Trade Off

Gaetano Lombardi

Program Manager Ericsson

Agenda

Manifesto for Agile Software Development

We are uncovering better ways of developingsoftware by doing it and helping others do it.Through this work we have come to value:

Individuals and interactions over processes and toolsWorking software over comprehensive documentation

Customer collaboration over contract negotiationResponding to change over following a plan

That is, while there is value in the items onthe right, we value the items on the left more.

Principles behind the Agile Manifesto

We follow these 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. 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. The most efficient and effective method of conveying information to and within a

development team is face-to-face conversation. Working software is the primary measure of progress. 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. http://agilemanifesto.org/

AGILE

Misconception

Agile is undisciplined process of simply writing code with no planning and control

Truth

Implementing agile process requires just as much or more discipline as traditional approaches

The Stacey Matrix

Source: Stacey RD. Strategic management and organisational dynamics: the challenge of complexity. 3rd ed. Harlow: Prentice Hall, 2002

CHAOS Report Findings by Year 1994 to 2009

Successful: The project is completed on time and on budget, offering all features and functions as initially specified. Challenged: The project is completed and operational but over budget and over the time estimate, and offers fewer features and

functions than originally specified. Failed: The project is cancelled at some point during the development cycle

Figure from http://leadinganswers.typepad.com/leading_answers/2011/04/lies-damn-lies-and-statistics.html , basedOn Eveleens & Verhoef “The Rise and Fall of the Chaos Report Figures,” IEEE Software, January/February 2010

Successful Project ?

6 months later 66% over budget, at that time the

most expensive movie 200 million $ Best forecast gross 190 million $

Highest grossing movie all time: $1,835,300,000 (100 million in 12 days, 250 million in 25 days)

Titanic was nominated for 14 Academy Awards and won 11 of them

Source: Titanic Anatomy of a Blockbuster, Kevin S. Sandler

Defining Success

Time/Schedule 20% prefer to deliver on time according to the schedule 26% prefer to deliver when the system is ready to be shipped 51% say both are equally important

Return on Investment (ROI) 15% prefer to deliver within budget 60% prefer to provide good ROI 25% say both are equally important

Value 4% prefer to build the system to specification 80% prefer to meet the actual needs of stakeholders 16% say both are equally important

Quality 4% prefer to deliver on time and on budget 57% prefer to deliver high-quality, easy-to-maintain systems 40% say both are equally important

Only 12% of respondents indicated that their definition of success on their most recent project included all three of delivering according to schedule, within budget, and to the specification.

Copyright 2011 Scott W. Ambler www.ambysoft.com/surveys/

The Agile Triangle

Source: Jim Highsmiths, Agile Project Management, Creating Innovative Products

AGILE & Planning

AGILE Project Management Principles

Rolling Wave Planning Upfront planning to minimum effort

Breakup functionalities into iterations and prioritize requirements

Customer Collaboration

Collective Ownership Team as whole is expected to take collective ownership of delivering the

solution

Emphasis on Validation over Verification Is the Right Product? Or Is the Product Right?

Fail Early, Fail Often and Continous Improvement

Levels of Agile Planning

Vision, For ..Who ..The ..That ..Unlike .. Product Provides

Roadmap, break down vision down into releases to describe how the obverallfunctionality required by the vision will be delivered

Release, how each release is break down into iterations to describe how functionality will be incrementally developed

Iteration, define tasks to be performed to develop User Stories required for Iteration

Daily, review progress against planned effort for the iteration

AGILE Mechanics Flow

Pro

duct

Bac

klog

Ana

tom

y

SP

RIN

Ts

Del

iver

y

Tes

t &

Qua

lity

Pro

duct

to b

e re

leas

ed

Stage Gate Model

Agile Planning

Initiating

Planning

Executing

Closing

0

10

20

30

40

50

60

70

80

Sec Ha

rden

ing

1588

WP1

Sec Lo

cal A

cces

s Ar

ea

SOAM

Nerd

Sec SN

MP V3

Extend

ed SNM

Pv3 Te

st

Reba

se TN5

.0

MMU3

A RL

WP1

MMU3

A ET

HSS

H

Capa

bility Ha

ndler

1588

WP2

MMU3

B WP4

TM LCH

IRM U

ser S

pace

SOAM

WP2

Centralised

Use

r

HW Sca

n Re

factoring

Linu

x Br

ing Up

& In

tern

al Com

mun

ication

TACA

CS +

Reba

se TN5

.0 sec

ond

MMU3

A RL

WP2

MMU3

B WP5

(WP6

?)

NANS

refactoring

Kernel Spa

ce

1588

WP2

B

SOAM

WP4

Reba

se TN5

.0 th

ird

Port Protectrio

n

NERD

& EPS

MMU3

B (A

NS) W

P6

MMU3

B WP6

RL on CN

Part 2

Radius

CN Start U

p

SOAM

WP3

RPS 9

RPS 10

Lice

nsing Sp

rint 1

Deminers 1:

NFS

QinQ

Extend

ed Bac

kward Co

mpa

tibility

1588

WP2

C

Misc

ellane

ous Se

curit

y

MMU3

A RL

3 and

HLS

Gene

ric SFP

Secu

rity De

fault S

ettin

gs II

Reba

se TN5

.0 fo

urth

E1/T

1 Traffic

Port Protection Sp

rint 3

AT&

T Fu

ll

NPU3

D WP 1A

Secu

rity Co

nsolidation

ETH

Traffic

CN R

L Pa

rt 3

RPS 11

RPS1

2

MMU3

B WP7

(Beta)

Role Selec

tion &

Config

SW U

pgrade

Port Protection Sp

rint 3

SWP

TN Reb

ase an

d TR

s

Committ to planned delivery

Commit to actual delivery

Delay Moving Average

Agile Planning Improved

Initiating

Planning

Executing

Closing

Release

Initiating

Planning

Executing

Closing

Agile Planning vs Predicibility

Sprint

Release

Next Release

Why AGILE? High Success Rate

0% 20% 40% 60% 80% 100%

Traditional

Ad-Hoc

Lean

Agile

Iterative

Successful Challenged Failed

Copyright 2011 Scott W. Ambler www.ambysoft.com/surveys/

Case Study

Program in Telecommunication Industry 20 million euros development per year 18 Team + 3 Platform (HW) project Teams distributed among Italy, Sweden (2 sites), Hungary,

China Program Benefits

Develop a common SW to be used by three different product platform while continuing introducing new system functionalities

Apply common Agile practices among the three platform developments to develop common SW

Positioning

Dealing with complexity

Pro

duct

Bac

klog

Ana

tom

y

SP

RIN

Ts

Del

iver

y

Tes

t & Q

uali

ty

Pro

duct

to

be r

elea

sed

SP

RIN

Ts

SP

RIN

Ts

Working Procedure in pills

Product Backlog System Team prepares/updates Anatomy made by anatoms that could have dimension of

one iteration to be developed by a team composed by 7/8 people in 4/5 weeks Ceremonies

Go Meeting by System to present User Stories: User Stories prioritized according to MOSCOW

Commit Meeting by the team to present iterations scope according to Time Box approach, Time Breakdown Chart, Cost, Risks, expected delivery

Delivery Meeting by the Team SAT by Acceptance Test Team to evaluate if the quality is good enough to merge

delivery into main Latest System Version (LSV) Retrospective

Node & Network Test continuously evaluates quality on main LSV by executing specific Test Campaigns last 2 weeks

Risk Based Assessment, Every two Test Campaigns the quality of LSV and overall releases forecast

Master & Commander