Chakra M. VenkataramanaDirector

SPAN Infotech

The De Agile Model(Tailored for Offshore)

Distributed Agile

• Context is Testing and Development teams being distributed geographically

• Multiple Test requirements including – Regression– System– Compatibility– Automation– Technical Testing – Perf, Security and Compliances

• Can be applied to distributed Dev teams too – with minor tweaks

2

Against De-Agile

Time zone differencesConflicting work hours, Personal Sacrifices in terms of time managementAvailability – F2F Meetings, Information sharing, planning, daily-standups, retrospectivesParallel work – Peer coding/testing, immediate requirementsWork allocation and Scheduling, Effort deviations

Staffing and Shared Understanding

Self motivating and Self Organizing resourcesMisunderstanding requirementsDelay or reluctance for clarifications / time consuming

Trust and Communication

Capabilities – Technical, Domain, Standards, PersonalCultural and Language barriersUnseen speakerTwo way communication

3

Need for Distributed Teams

Programming

Paired ResourcesStreamlined processes – Comm & Collaboration, Source Control, Automation, CIFollow the Sun Model for faster deployment

CapabilitiesAll rounder resources are rareDomain, Tech, Design, Dev, Test, Tech-TestVendor Org support to offshored resources – draw up on support structuresInnovation and Value Adds

Cost

Globally distributed teams reduce cost, Contract Employees as needed – required competency at a short noticeOffshore resources at lower costImplicit additional hours - reasonable

4

When would De-Agile Work?

Cost Advantages

Pros outweigh Cons

CapabilitySpecific Technology Requirements (expensive or not available)Available at short noticeStaff on demand / reduce when neededWilling to accept that there are challenges

Us vs ThemWorking FOR and not AGAINST ThemAcceptance

5

Tools and Techniques that enable De-Agile

• Dedicated Meetings rooms / Conf bridges• Collaboration Tools – TFS (requirements repositories,

SCM, management, Automatic build and deployment setup, Continuous

Testing, Automated defect tracking, and project management tools) • Communication - IM, Skype, IP Phones, Video

Conference and Web Cams• Daily Standups on Skype boards• Frequent (not too frequent) travel and work

from other locations• Classification of tasks Simple to complex - grow with time

• Overlap and Hand-shake

6

Diagrammatic Model

• Project Initiation / Initiation of resource into the project

7

Travel – Either Direction (4-6 weeks), every six months, Intro to stakeholders including POs, most affected people

Training – Domain, Standards, Technology, Architecture and Design Overview, SCM, Process inclusion

Task Allocation – Onsite execution under supervision, Graded tasks (complexity), Constant reviews initially, offsite tasks – graded tasks

Offsite Delivery – Testing Specific

8

SPRIN

T M

EETI

NG

Gro

omin

g Se

ssio

ns

SPO

C

Dis

cuss

ions

Test

ing

Wor

k in

Pr

ogre

ss

Test

ing

Act

ual

Test

ing

Aut

omat

ion

Script

ing

Test

ing

Inte

grat

ion

Reu

sabl

e Cod

eCon

tinu

ous

Test

ing

Vid

eo C

on

fere

nce

WE

BE

X/G

oto

Mtg

IM,

Sky

pe,

Ph

on

e

PO Scrum Master SPOC

SC Manager

Reviewer - Temporary

Stakeholder

Roles (Additional?)

Measure - Metrics

Statistical Trends

Productivity and Quality

Feedback Continuous Improvement

Documentation

Activities (Additional?)

TFS

Collaboratio

n tools

TFS Client

SME Review

Tool based Review

Planned Additional Activities• Sprint and Retrospective (Video or In

Person)• Sprint Grooming• SPOC Discussions• Work in Progress testing• Automate for CI & CT• Metrics – Online Dashboards, Burndown and

Burndown charts, Velocity, Defect Trend, Requirement Stability, Productivity, Quality

• Frequent planned Demos• Reviews 9

Will all this work?

• We have multiple projects which have inherited processes from this model to succeed

• There needs to be strong incentive for this to work

• It is time and effort consuming but will stabilize in time (3 months)

• May not be very cost effective as it will not be a pyramid model of delivery

10

Implications of De-Agile

• Willingness to make it work is important • Additional effort from the Agile team to

manage distributed deliveries – atleast initially

• Slow onboarding – takes time to deliver• Additional processes and metrics• Additional documentation – adequacy can

be set

• Dependence on Collaboration tools• Additional Travel costs

11

Q&A

12