WiseCode

The Amdocs SD&I Journey to Agile Engineering

Practices

Implementing Agile in a large

organization with a large code base

and set ways of operation is a whole

new ballgame…

Workforce over 3,500

3 development centers in Israel, 2 in India and several others world-wide

Responsible for

◦ Customization

◦ Adaptation

◦ Integration

Short & Long lived Projects

Typical projects span 20-200 man years

Amdocs SD&I

The Commission

SD&I (then DCC) started Agile

implementation mentored by AgileSparks

Approached Trainologic in order to

analyze “Software Engineering Practices”

The questions:

◦ Are we following “Best Practices”

◦ Can we do more in this field:

Higher quality

Faster delivery

A Challenge

Amdocs is extremely successful

SD&I are known for their full

commitment and 100% delivery

At any given time there are multiple

efforts of improvement

Analysis

Talked with over 200 people in Amdocs

Delivery – Israel, India and UK

◦ 1x1 meetings, Round Tables, OTJ observation

Reviewed all aspects of SW engineering

◦ Architecture, Design, Coding, Debugging and

Reviewing

◦ Build & Integration

◦ Unit testing and Test Automation

◦ Configuration Control and Version Management

◦ Planning

Reviewed QE and Metrics

Analysis Findings

A well established set for “rules of

operation” at all levels

Challenges of large project management

Technical obstacles in order to fully

realize the improvements promised

by Agile

The 4 Pillars of Agile Implementation

Agile Managerial Practices

Agile Engineering Practices

Agile Development Environment

Engineering Professionalism

Agile Engineering Practices

Avoiding Waterfall

◦ Design in every stage

◦ Developer ownership

◦ Striving for release

Automated Testing

◦ TDD & Unit Testing

Agile Development Environment

Acceptable Hardware

Acceptable Software (VCS!)

Avoiding NIH and opening to the world

Continuous Integration

Legacy Build System

A typical build cycle using the legacy build

system took 7+ days and 1-2 dedicated

people

During time of build development was

constrained

Following build a torrent of “hot fixes”

would ensue

Engineering Professionalism

Setting a base line

◦ Clean Code

◦ SOLID

◦ TDD

OJT – mentoring teams

Creating internal leadership

◦ Coachers

Where do we Begin?

Local vs. Wide Spread

Serial vs. Parallel

Preach vs. Set foundations

Trying to do it all

During the first year:

◦ New Build System

◦ Unit Testing frameworks

◦ Development Courses

◦ OJ Mentoring

◦ Pep talk sessions

Uphill Battle

Shift in responsibilities

A new trust model

“Are we expected to do more?”

Changes in the schedule structure

Initial Wins

Light weight design processes

Shift from governance to mentoring

CI in the common project infrastructure -

BSS

Many Challenges Fright of change: “Yes, but…”

◦ Not Here

◦ Not Now

Misinterpretations

An Unexpected Win

Local leadership in the Negev:

◦ Long standing strategic customer

◦ 12 Year old project

◦ Large legacy code base

◦ Customer commissioned 2 substantial

improvement cycles

◦ First cycle followed the “old way”

◦ Second cycle “Jumped into the water”

And the results…

Within 3 cycles (2 month):

◦ Stable, always shippable

◦ Fully tested

A total shift in developer culture

A slow shift in management culture

Where we are today

3 Projects doing CI

3 Projects scheduled for CI by September

Developer responsibilities changed

Modern tooling becoming the norm

Unit testing slowly entering main stream

Looking Forward

It’s a complex implementation, but we

hope we are HereImplementation

Time

Some Closing Thoughts

The importance of local leadership

Continuous engagement

Prepare for a long battle

Never under-estimate the legacy build

Sequential or Parallel implementation?

Trumpeting success stories