Prepared and presented by Keren Yahalom and Yaki Koren at LKNA14 The goals set before us a year and half ago were to stop saying “no” to customers for late or changed scope, while helping them achieve time to value. We have gone through a successful revolutionary change of the way we manage our projects a few years earlier (CCPM), and we felt that the organization cannot handle another revolution. Still, Our customers’ (Telecommunication Service Providers) business required better responsiveness and flexibility, reduce risks and a much faster time to market. Our hundreds to thousands person months complex mission critical projects span up to 70 groups of experts handling products that are tightly integrated over a timeline of a few months, and we had to maintain, if not improve, our quality, while reaching a sustainable development process. The challenge was huge. In this session we will describe how we pulled it off again, in a completely different implementation approach – evolutionary, pull based. We implemented in different types of projects (huge business transformations, on going releases with existing customers), different scales (from 10 to 150 Person Years projects), different personas (the leaders, the laggers) and in a different manner (adapting the implementation to the specifics of our internal customers). We will describe what it takes to make it work, and what obstacles we faced. we will share actual boards and reports helping the audience experience the scale, the challenge, the journey. We will also share the story of the implementation in our first project – a mega project servicing a giant North American telecommunication service provider

1. © 2014 – Copyright Amdocs. All rights reserved1
CUSTOMERS
30+
GLOBAL TELCOS
KANBAN BOARDS
130+
USAGE
1600+
BOARD
USERS
2500+
DEVELOPERS
DIRECT
20 - 300
TEAM SIZE
PER BOARD15000+ CARDS
1000+
BACKLOG
6000+
ONBOARD
7500+
ARCHIVED
TIME TO SCALE < 2 YEARS
GLOBAL DISTRIBUTED TEAMS
MAN MONTH HANDLED > 10000
Amdocs Delivery
Kanban
Implementation
Story

2. #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)
© 2014 – Copyright Amdocs. All rights reserved2

3. © 2014 – Copyright Amdocs. All rights reserved3
“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.”

4. © 2014 – Copyright Amdocs. All rights reserved4
Starting the journey
Our strategy for the implementation was “Pull”.
We told the first VP who wanted this that the first
stage is visualization.

5. © 2014 – Copyright Amdocs. All rights reserved5
• 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.

6. © 2014 – Copyright Amdocs. All rights reserved6
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.

7. © 2014 – Copyright Amdocs. All rights reserved7
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. 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.

9. © 2014 – Copyright Amdocs. All rights reserved9
Implementation Growth
Projects

10. © 2014 – Copyright Amdocs. All rights reserved10https://c2.staticflickr.com/8/7134/7722572538_5cbe0dc746_z.jpg
We were elated.
Management were very happy.
Management wanted to mandate the change.

11. 11 © 2014 – Copyright Amdocs. All rights reserved
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
.

12. 12 © 2014 – Copyright Amdocs. All rights reserved
V1
V2
V3
The transition from
waterfall to flow most
projects went through.

13. 13 © 2014 – Copyright Amdocs. All rights reserved
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

14. 14 © 2014 – Copyright Amdocs. All rights reserved
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.

15. 15 © 2014 – Copyright Amdocs. All rights reserved
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.

16. © 2014 – Copyright Amdocs. All rights reserved16
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.

17. © 2014 – Copyright Amdocs. All rights reserved17
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.

18. © 2014 – Copyright Amdocs. All rights reserved18
ACCOUNT
ROADMAP & VISION SUSTAINABLE PACE
Agile Maturity Indicators
RELEASE
Kanban for Backlog Management
Frequent SWP
Release Scoping
RELEASE SCOPING & IMPLEMENTATION
Release
Planning
Construct (Develop and Test) Accept
and Deploy
METRICS
&
REPORTS
TEAM
Daily Team Meeting
METRICS
&
REPORTSiTeam
LMCSU
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
Operate
Topic
}
Prioritized Stories
}
OnsiteTesting
Deploy
Certification
Topics in Development
Certified Topics
Production
Design Develop
2 – 4 weeks
Story
Test
iTeams
Prioritized
Topics
AgreedScope
BreakScopeto
Topics
New Features
Defects & Improvements
Operability
PlannedScope
Kanban for Release Management
So we came up with
more detailed
implementation
guidelines.

19. 19 © 2014 – Copyright Amdocs. All rights reserved
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.

20. © 2014 – Copyright Amdocs. All rights reserved20
“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.

21. © 2014 – Copyright Amdocs. All rights reserved21
We ran a root cause analysis to
understand why Work Life Balance
was deteriorating.

22. © 2014 – Copyright Amdocs. All rights reserved22
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.

23. © 2014 – Copyright Amdocs. All rights reserved23
…
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-xxxA message sent from high
management to the people

24. 24 © 2014 – Copyright Amdocs. All rights reserved
ConstructScoping UAT
The first implementing account
is now preparing for the next
leap toward wider and deeper
agility

25. © 2014 – Copyright Amdocs. All rights reserved25
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

26. © 2014 – Copyright Amdocs. All rights reserved26
CUSTOMERS
30+
GLOBAL TELCOS
KANBAN BOARDS
130+
USAGE
1600+
BOARD
USERS
2500+
DEVELOPERS
DIRECT
20 - 300
TEAM SIZE
PER BOARD15000+ CARDS
1000+
BACKLOG
6000+
ONBOARD
7500+
ARCHIVED
TIME TO SCALE < 2 YEARS
GLOBAL DISTRIBUTED TEAMS
MAN MONTH HANDLED > 10000
Some statistics about the scale of the
implementation