amdocs case study: massive kanban implementation (lkna14)

© 2014 – Copyright Amdocs. All rights reserved 1

CUSTOMERS

30+ GLOBAL TELCOS

KANBAN BOARDS

130+

USAGE

1600+ BOARD

USERS

2500+ DEVELOPERS

DIR

EC

T

20 - 300

TEAM SIZE

PER BOARD 15000+ CARDS

1000+

BA

CK

LO

G

6000+

ON

BO

AR

D

7500+

AR

CH

IVE

D

TIME TO SCALE < 2 YEARS

GLOBAL DISTRIBUTED TEAMS

MAN MONTH HANDLED > 10000

Amdocs Delivery

Kanban

Implementation

Story

#1 in North America

Telecom Operations

Management Systems

(TOMS)

Amdocs wins

2013 Outsourcing

Excellence Award

Public Company of

the Year Award

About Amdocs

Overview

● Leader in Customer Experience Systems and Services

● $3.3 billion revenue in 2013

● More than 20,000 professionals

● Serving customers in more than 70 countries

● Listed on NASDAQ (DOX)



“Amdocs has a proven

track record with

demonstrated

transformation

capabilities in various

service provider

accounts around the

world.”

Amdocs Delivery

4000 PROFESSIONALS

Global foot print with development centers around the world (inc. Israel, India, Brazil)

100+ PROJECTS running in parallel

Proven track record of 95% successful project delivered on budget, on time, with quality and at large scale Industry standard 60% -

“Amdocs has

shown it has the

size, scale and

stability to reliably

supply telecom

software

professional

services to CSPs.”


Starting the journey

Our strategy for the implementation was “Pull”.

We told the first VP who wanted this that the first

stage is visualization.


• Slowly yet surely

• Identify board substitutions

• Notice questions in daily meetings

• Adapt policies

• Adapt board

5

400 people

4 development centres

1 Release every 4 months

16 Products

Two weeks later our first board was up in the air.

It took them 1 week to abandon the traditional

project plan and a month to start telling high

management about it.


Management were very happy about it.

So they asked us to prepare an implementation

plan.

So we did.

And then life started to manage the

implementation.


Status – January 2013

7

● Our third project started implementation

● A small group from Cyprus decided to dare and are

starting these days

● We see a lot of interest in Kanban/agile

● A lot of groups are asking for sessions to introduce the

concept

●In most cases managers would rather wait

8 © 2014 – Copyright Amdocs. All rights reserved

The popcorn syndrome

There was the first account.

After a month another.

Then a lot of “sounds interesting”.

And then another.

And then many more.


Implementation Growth

Pro

jec

ts

© 2014 – Copyright Amdocs. All rights reserved 10 https://c2.staticflickr.com/8/7134/7722572538_5cbe0dc746_z.jpg

We were elated.

Management were very happy.

Management wanted to mandate the change.


http://farm1.staticflickr.com/29/55862858_3e90b4da68_o.jpg

Our implementation was based on doing it only

with people who wanted to do it.

People who want the change see challenges

while those who are pushed into it see problems

.


V1

V2

V3

The transition from

waterfall to flow most

projects went through.


Each project, on average:

• 1 Delivery manager

• 2 program managers

• 7 development directors

• 13 project managers

• 20 team leaders

• 100 Developers/Testers

• 8 products

Coaching managers, helping them to:

- Visualize the end to end flow

- Manage the flow

- Break scope to small chunks

- Start to test early

- Move from component teams to feature teams


With Kanban, people started to feel

emancipated: they got the freedom to define

their own processes.

Some existing processes were being

abandoned.

Some people in management were worried:

“where is the methodology?”

We were focused on guidelines.


http://farm6.staticflickr.com/5474/12105522476_edd50e5eae

_o.jpg

500-1000 Dev MM

New customer

New team

New system

Few months to deliver

Many interfaces

Then Transformation projects started the

implementation.

These are very challenging.

Many challenges started to surface.


One of the main issues was “how am I doing?”

Kanban is basing on actual pace.

And at the beginning of a project pace is slow.


We realized we can’t expect high pressure

projects to “evolve”. These should get much

more detailed guidelines then ongoing

projects.

Implementation strategy for each project

should take into account its specific context.


AC

CO

UN

T ROADMAP & VISION SUSTAINABLE PACE

Agile Maturity Indicators

REL

EASE

Kanban for Backlog Management Frequent SWP

Release Scoping

RELEASE SCOPING & IMPLEMENTATION

Release Planning

Construct (Develop and Test) Accept and Deploy

METRICS &

REPORTS

TEA

M

Daily Team Meeting

METRICS &

REPORTS iTeam

LM CSU

Developers & Testers

Topic iLead

Code Ownership Ongoing Planning

Kanban For Task Management

Kickoff

Ready For

Topic Test

BP iLead (IM)

Agile Depth Improvement Focus Map

Ongoing Planning

Daily Execution Meetings Release retrospectives Customer Demos

Unit Automation Team Retrospectives Team Demos

Op

erat

e

Topic

} Prioritized Stories

}

On

site

Tes

tin

g

Dep

loy

Cer

tifi

cati

on

Topics in Development

Certified Topics

Production

Design Develop

2 – 4 weeks

Story Test

iTeams

Pri

ori

tize

d

Top

ics

Agr

eed

Sco

pe

Bre

ak S

cop

e to

To

pic

s

New Features

Defects & Improvements

Operability Pla

nn

ed S

cop

e

Kanban for Release Management

So we came up with

more detailed

implementation

guidelines.


And then at one cold winter day we had a

meeting with management at which we

realized they don’t see it like we do.

Suddenly many challenges became

problems.


“What is the impact of agile?”

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

Work life balance

Issue Resolution

Quality

Ownership

Visibility

Flexibility

Working together

Early feedback

200 respondents

So we ran a survey

After doing some investigations we

realized that many problems that were

hidden or were revealed in later

stages are being revealed early and

people were not used to it.


We ran a root cause analysis to

understand why Work Life Balance

was deteriorating.


Delivery Sustainable Pace Manifesto

Pulling work & going home happy

with today’s amount & quality of

work

Delivering working scope

Having a profitable bottom line for

the whole project

Finding the time to fine-tune

the way we work

Pushing for meeting

due dates

Delivering 100% of scope

Meeting construct budget

Focusing on

day to day activities

Over

We Value:

Meaning:

While there is value in the items on the right,

we value the items on the left more.

And came up, together

with management, with

this.


…

But… What if?...

“What if...

● “… I am pressured to complete large scope by an unrealistic due date?...”

● “… I am pushed to start something new when I’m already overloaded? ”

● “… I see no option but to push untested code to the CC? ”

● “… I don’t believe the plan is achievable?...”

“Don’t agree to compromise your professional integrity!

Engage your peers, managers & CDU

to find a reasonable alternative.

If all measures were exhausted,

and you still feel the issue is not settled – Escalate!

Escalate to us if needed!

We in SD&I Management want to hear about it!

I personally invite you to call me or email me anytime,

I will back you up! ”

XXXX, +xxx-xx-xxx-xxx

A message sent from high

management to the people


Construct Scoping UAT

The first implementing account

is now preparing for the next

leap toward wider and deeper

agility


Where we are today

● Most projects moved to kanban

● Many projects are either stabilizing or recharging

● The next phase of the implementation is starting: Projects

are starting to work on the next leap


CUSTOMERS

30+ GLOBAL TELCOS

KANBAN BOARDS

130+

USAGE

1600+ BOARD

USERS

2500+ DEVELOPERS

DIR

EC

T

20 - 300

TEAM SIZE

PER BOARD 15000+ CARDS

1000+

BA

CK

LO

G

6000+

ON

BO

AR

D

7500+

AR

CH

IVE

D

TIME TO SCALE < 2 YEARS

GLOBAL DISTRIBUTED TEAMS

MAN MONTH HANDLED > 10000 Some statistics about the scale of the

implementation

amdocs case study: massive kanban implementation (lkna14)

Software