key accenture learnings on scaled and distributed agile

Key Accenture Learnings

on Scaled and Distributed

Agile Delivery

Andrew Ball, Ajay Nair &

Mirco Hering

Focus for today

2Copyright © 2015 Accenture All rights reserved.

• Many companies struggle to implement Agile at scale when they have

distributed workforces.

• Accenture has a range of experience in implementing large-scale,

distributed Agile programs using the Scaled Agile Framework.

• The intention of today’s session is to give some insights into Accenture’s

solutions for implementing scaled and distributed Agile.

Copyright © 2015 Accenture All rights reserved. 3

Challenges for distributed and scaled

Agile

Challenges for distributed and scaled AgileAccenture has been able to leverage Scaled Agile Framework and a range of tools to address a number of these challenges


Process

• Solution misalignment between teams

• Timeline misalignment between scrum teams

• Integration of Agile with Waterfall

• Status tracking misalignment

Organization

• Different locations

• Different working hours

• Different holidays

• Different customs

• Cross-team activities

Tools

• Different DevOps Tools between teams

• Some tools don’t scale well

• Offshore system performance

• Poor collaboration technologies

Suggested solutions for these changes


Process – Aligning solutions between teamsEnhanced SAFe processes are key to attaining solution alignment between different scrum teams


Program

Feature

Backlog

Feature

Elaboration

Team A

Backlog

Team B

Backlog

KDD

I1, I2, I3…

I1, I2, I3…

PI

Objective

s

EVOLVE

Hard

en

Rele

ase

DISCOVER

Hig

h L

evel

Rele

ase P

lannin

g

Revis

ed

Rele

ase P

lannin

g

INITIATE

Pro

ject In

itiatio

n

Process – Ensuring timeline alignment between teamsSAFe is critical to the alignment of delivery timelines


Synchronize iterations

Group iterations into common Program Increments (PIs)

Aim for synchronized iterations and PIs across enterprise

Process – Integrating Agile and Waterfall


– Upfront identification of features/scope requiring Agile and Waterfall delivery

– Synchronize these activities for impacted features:

• Discovery (Agile) and Solution Definition (Waterfall)

• Release Planning

• Integration Test

• Release

– Manage any further changes in release via change control process for Waterfall team

– Consistent tooling and common DevOps team

Iteration 1

Design

Rele

ase

Ente

rpris

e-w

ide

Inte

gra

tion T

est

Revis

ed R

ele

ase

Pla

nnin

g

Waterfall Change Control Process

Build

Test

Iteration 2

Iteration 3

Iteration 4

Waterfall Team

Agile Team

Process – Status tracking alignment


Aligned tracking across scrum teams requires:

• Consistent definition of ‘Done’

• Consistent sizing method through the use of:

– Ideal hours

– Standardized story points – this requires:

1. Creating a catalogue of story types for each team

2. Agree on equivalent stories across teams

3. Using equivalent story types as guides, extrapolate sizes for other story types

2. Equivalent sized story

3. E

xtra

pola

te

Team A backlog Team B backlog

1. C

ata

logue

sto

ry ty

pes

Organization – Possible different structures


Release Train

Engineer

Local

Vendor

Product

Manager

Client

Testers

BAs

Testers

BAs

Scrum Master

Developers

Selection Criteria

• Business requirements are too critical or confidential

to be offshored

• Team has limited knowledge of business functionality

• Limited availability of Business Users/Product Owner

• Adequate budget

Product

Owner

Local

Te

am

Pro

gra

m

Release Train

Engineer

Remote

Vendor

Product

Manager

Client

Testers

BAs

Testers

BAs

Scrum Master

Developers

Selection Criteria

• Simple business requirements

• Remote team has good knowledge of business

functionality

• High availability of Business Users/Product Owner

Product

Owner

Local

Te

am

Pro

gra

m

Organization – Possible different structures


Release Train

Engineer

Local Remote

Vendor

Product

Manager

Release Train

Engineer

Client

Testers

BAs

Testers

BAs

Scrum Master

Developers

Selection Criteria

• Business requirements are complex or not very

well-defined

• Remote site team has limited knowledge of

business functionality

• Limited availability of Business Users/Product

Owner

Product

Owner

Local

Te

am

Pro

gra

m

Vendor

Release Train

Engineer

Local Remote

Vendor

Product

Manager

Release Train

Engineer

Client

Testers

BAs

TestersScrum Master

Developers

Selection Criteria

• Business requirements are complex and not well-defined

• Remote team has limited knowledge of business

functionality and availability of Business Users/Product

Owner

• Development of some application areas cannot be

shifted to remote locations

Product

Owner

Local

Te

am

Pro

gra

m

Vendor

Developers

Organization - Example Activity Split


Offshore Team Activities:• Release Planning input• Planning Poker and

estimation• Build and unit test

stories• Application test stories• Test planning,

preparation and execution – Integration Test, SVT and ORT

• Application deployment• Application support

Onshore Team Activities• Backlog definition• Release Planning• Architecture• Business value definition and

measurement• Planning Poker and estimation• Story verification• Integration (E2E) test planning

and execution support• Deployment support• Support readiness• Application support (client

liaison)• Agile coaching and training

RTE

Onshore Team

Scrum Stan-ups, Planning Poker, Conversations etc.

Program Stand-up, Release Planning etc.

Dev QA

Dev Lead

Dev QA

Dev Lead

RTE

Scrum A Scrum B

Offshore Team

IMBA

Prod. Owner

Scrum B

IMBA

Prod. Owner

Scrum A

Collaboration in time zone


Time Monday Tuesday Wednesday Thursday Friday

Start of Day Indian

Standard Time (IST)Offshore team connects with onshore UX Lead receive inputs from SMEs

Offshore Factory

Workday

Offshore team works on UX planning

and execute UX delivery and

delivery management activities.

Peer review of UX deliverables.Uses Vr controlled shared location

to park the deliverables.

End of Day IST

/

Start of Day US

Standing call

on project

update

Standing call on

project update

Offshore

Factory/US Team

Meeting

Standing call on

project update

Offshore Factory/

US Team Meeting

Standing call on

project update

US Workday

Work on UX delivery planning activities

Review user stories and query logs with SME

Review session with Business Partners and Stakeholders

Work on UX deliverables

End of Day US Provide next day instructions to offshore UX team

Ind

ian

Sta

nd

ard

Tim

e (

IST

)U

S C

en

tra

l S

tan

dard

Tim

e

(CS

T)

CST

23:30

00:30

01:30

02:30

03:30

04:30

05:30

06:30

07:30

09:00

10:00

11:00

12:00

13:00

14:00

15:00

16:00

17:00

18:00

Use virtual collaboration tools (tele-

conference, Lync screen sharing,

video conferencing) to facilitate

standup meetings between

distributed teams.

Onshore - Offshore model provides the ability for the team to work around the clock

Approach


Agile & DevOps

Development Operations

Why DevOps – example in an Agile delivery context


Adopting DevOps principles compliments Agile delivery to enable faster delivery and speed to market

Team B

Backlog

Rele

ase

Itera

tion

Pla

nn

ing

Itera

tion

Pla

nn

ing

Iteration 1

Iteration 3

Iteration 2

Team A

Backlog

Iteration 1

Iteration 3

Iteration 2

Working software

Working software

Working software

Working software

Working software

Working software

! Wait

! Wait

! Wait

! Wait

Wa

ll of c

on

fusio

n

Developers Ops

Month 1

Month 2

Month 3

Month 4

Month 5

Month 6

Release 1

Release 2

Want Change Want Stability

DevOps principles


DevOps uses automation techniques to optimize collaboration across

development and operations, enabling faster, more predictable and more frequent

deployments to market

IMPROVE

CONTINUOUSLY

AUTOMATE

EVERYTHING

COHESIVE

TEAMS

DELIVER

SMALL

INCREMENTS

EXPERIMENT

FREQUENTLY

Strong Source

Control

Experiment

frequently

Deliver small

increments Test early

and often

Improve

continuously

Automate

everything

Cohesive

teams

Key building blocks


Some of the key building blocks in moving to a DevOps model are below

IMPROVE

CONTINUOUSLYDELIVER

SMALL

INCREMENTS

EXPERIMENT

FREQUENTLY

VM Provisioning

Automation

Automate Firewall

Provisioning

Application

provisioning

Service

Virtualisation /

Stubbing

Test Automation

Deployment

Automation

Asset Repository

Management

Analytics &

Reporting

So

ftw

are

De

live

ry

Unit Test

Automation

Code Quality &

Coverage Review

Source Code

Configuration

Management

Infr

as

tru

ctu

re &

Pla

tfo

rm

De

live

ry

Platform Monitoring

& Alarming

Application

lifecycle

Management

Incident

Management

App Monitoring &

Alarming

Configuration

Management

Capacity

Management

Automate LB

Provisioning

Automate Storage

Provisioning

Platform validation

/ Test Automation

Continuous

Integration

Infrastructure

lifecycle

Management

Analytics &

Reporting

Security

Management

Feature Toggling

Arc

hite

ctu

re (E

nte

rpris

e &

Te

ch

nic

al)

Pro

ce

sse

s &

Me

tho

ds

Go

ve

rna

nce

& C

ha

nge

Ma

na

ge

me

nt

Environment

Management

Software Defined

Networking

Increase in maturity can be via further improvements within each capability or targeting additional capabilities

Example Reference Architecture


DELIVER

SMALL

INCREMENTS

EXPERIMENT

FREQUENTLY

• Tools to manage application lifecycle

getting rid of manual trackers, emails

• Use workflow tooling for deployment

requests, build requests, etc.

• Quality gates through the lifecycle

• Integration between tools to obtain

traceability through lifecycle

• Continuous integration for

applications

• Process and automation to ensure

builds are well documented

• Deployment automation for all

applications eliminating error prone

manual deployments

• Test automation to ensure faster feedback to

developers and reduced test efforts

• Stubs/harnesses as required

• Integrations between tools to automate defect

creation, traceability and tracking

• Automation and orchestration

for platform provisioning to

reduce lead times in setting up

environments

• Centralized configuration

management

• Metrics collection and

reporting across the

lifecycle – providing

visibility and identification of

continuous improvement

areas


Benefits

Early benefits


Quantitative Benefits

Activity Measured as % Improvement Comments

Merge and

retrofit

% of the build effort

across releases50% • Based on the actual effort tracked

Software

configuration

management

Effort to support SCM

activities63%

• Elimination of manual trackers [workflow lists, baselines, objects]

• Maintenance of two tools [CVS, CC], scorecards and run books not

required

• Unnecessary environment sync-up eliminated

Cost of poor

quality

% of defects

attributed to SCM,

deployment

59%

• Elimination of defects introduced because of previous

• Inefficient SCM processes

• Incorrect deployments

Build and

deployment

Process and effort to

raise deployment

requests

90%

• No. of deployment requests (DR) reduced - enterprise build [not

incremental or individual builds]

• Effort per DR reduced because DR not in spreadsheets [now raised

on tool – RTC] and elimination of extra step in the flow of DR

• Improved demand management and traceability from portfolio through to Agile delivery teams

• Granular configuration management and traceability

• Integration with agile lifecycle tooling to allow story based configuration management driven from meta

data

• Real-time traceability of status for build and deployment

• Automated build and deployments – “one-button deployment”

• Developer efficiencies as a consequence of improved tool interaction times, processes

Qualitative Benefits

key accenture learnings on scaled and distributed agile

Documents