AOSD: Agile Offshore

© Vincent Massol 2004

AOSD: Agile Offshore

Vincent Massol17/12/04

© Pivolis 2004

Agenda

Agile Offshore Software Development (AOSD)

Team organization

Infrastructure

Communication tools

Delivery Management

Active Quality

Return of experience

© Pivolis 2004

Types of offshore projects

There are 2 main types of offshore projects

Fixed-price projects− Black box for the customer− Well-defined specifications− Not at heart of Customer’s Information System

- Or highly risky if they are!

Collaborative/Agile projects− Moving specifications− IT teams on both sides

- Possibly developers on both sides- Possibly Architects/Framework on one side and development team on the

other side

− Minimal project duration required- For processes/tools/communications to settle- For people interactions to reach a satisfactory level

− Can tackle complex projects (and with higher satisfaction levels)

This presentation is about Collaborative/Agile projects

© Pivolis 2004

AOSD is flexible

Best practices from XP, RUP and Open Source:XP

− Continuous Integration− Strong Quality− Short iterations

RUP− UML notation to formalize specifications

Open Source− Collaborative tools and associated practices

Different versionsAOSD Java, AOSD .Net, AOSD SAP, etc

− We will focus on AOSD Java in this presentation

AOSD is a modular methodologyIntegrates well into an existing contextAllow progressive and continuous adoption of its practices to improve communication/quality/productivity.

© Pivolis 2004

AOSD core values

Continuous improvements

Establish a team spirit with virtual teams

Automation as much as possible

Continuously improved during project lifecycle

Continuous communications

Shared expectations

© Pivolis 2004

Agenda


Team organization

Infrastructure

Communication tools

Delivery Management

Active Quality


© Pivolis 2004

Team Organization (Logical model)

Development Manager

OnsiteProject Lead

Functional teamOffshore

Delivery Manager

Onsite developers Offshore coordinator Offshore coordinator Offshore coordinator

OffshoreProject Lead



Offshore developers Offshore developers Offshore developers

Depending on the size

there can be one or

several coordinators

Offshore

Project Manager

offshore

onsite

© Pivolis 2004

Coordinator role

Neutral stance as much as possible

Administrative tasks: Arrival/Departure administration (e.g. Secure id card, Star Team account, Test Director account, Wiki account, JIRA account, mailing lists accounts, etc) Organization of visits (identification of requirement, dates, agendas, people) in both directionsVisa handling

Infrastructure for offshore: Infrastructure coordination + improvements (monitor performances, tune tools) - with help from customer’s infrastructure team

Organisational: Weekly technical and management conf calls with all the teams (dev team + integration team + tech team) + follow up from these calls Management meetings Communication facilitators + related communication improvements Offshore team selection (senior members mostly) Offshore training programme improvements Crisis escalation investigation + handling Accompany Onsite members during offshore visits, ensuring success of agenda/visit.

[Good to have] Methodology/Expertise: Definition of Project Development Process with “offshore in mind” and continuous improvements (e.g. short iterations introduction, usage of JIRA for detailed plannings, acceptance criteria for code delivery, wiki setup, etc). Work inside the teams to implement the collaborative development process. Quality suggestions + improvements (testing strategy / build improvements for quality + measurements) Expertise on build (e.g. Maven) + continuous build + testing + collaborative development processes Architecture + implementation of regression platform

© Pivolis 2004

Team organization lessons: No Micromanagement

LocalProject Lead

DeveloperProjectLead

Developer

Developer

onsite offshore

ProjectManager

Developer

Developer

Developer

onsite offshore

© Pivolis 2004

Role diversity in offshore

Same roles on both sides as much as possible

To prevent feeling of “superiority” from one side / Help teams jellTo spread overall knowledge which helps improve productivityBecause of distribution cost

− A technical Guru only on one side will have difficulties helping across distance

Examples of possible offshore roles− Integration team – Tests− Business conception− Detailed design− Architecture relay / Build guru

© Pivolis 2004

Agenda


Team organization

Infrastructure

Communication tools

Delivery Management

Active Quality


© Pivolis 2004

Infrastructure

VPN over

internet

Offshore

firewallfirewall

Onsite

Source

Repository

Continuous

build

Intranet (Wiki,

Build results,

Issue tracker)

DMZ reachable from offshore

firewall

© Pivolis 2004

Agenda


Team organization

Infrastructure

Communication tools

Delivery Management

Active Quality


© Pivolis 2004

Communication tools

Value in team knowledge

sharing

Usage frequency

“Word”doc

Travels

Video Conf.

Wiki

Phone

Mailinglist/forum

email

chat

Travels: Every 1.5 months (3p per trip)

“Word” docs: 1 every month

Phone: 3 calls per week (for 10p)

Wiki: 1 topic modified per day (for 10p)

Email: several times per day

Through builds: every 2 hours

Chat: continuously

© Pivolis 2004

How to share functional knowledge?

Travels in both directionsFunctional training for Project LeadsEspecially before new subjects

Have Project Leads do the business conceptionAs much as possible

Have Project Leads do the detailed design

Open chat channels with functional personsWe have dedicated functional persons. 1 per team => 1 person per 10 developers roughly. Can decrease with time.

Helpful to have onsite coordinators in teams

Send functional tests along with use casesHave a separate team script and automate them

© Pivolis 2004

Agenda


Team organization

Infrastructure

Communication tools

Delivery Management

Active Quality


© Pivolis 2004

Iteration planning (Time-boxed)

time

Phase start Phase end

Production delivery

Work Packet 1 Work Packet N(6-7 weeks)

Iteration(2 weeks)

Continuous build(2 hours)

Functional delivery

Delivery

Fixed iteration delivery dates (Time-Boxing)Must not be changed, content can change

Iterations must list *all* tasks taking ½ day or moreTo prevent misunderstandingTo allow easy progress follow upTo generate release notes automaticallyDone using Issue Driven Development

Meetings every week

© Pivolis 2004

Issue Driven Development

Every task is visible as an issue in the issue tracker

If a task is not there, add it before checking in and add task id in check-in comment

It is critical that the iteration issues are up to date continuously

Otherwise, leads to expectation gaps which itself leads to frustrations on both sides

If a task cannot be performed in time for the iteration or if it is changed or a new task added, trigger a CCB conf call

CCB = Change Control BoardMade of representative of the different streams (business, architecture, developers, management, etc)

© Pivolis 2004

Agenda


Team organization

Infrastructure

Communication tools

Delivery Management

Active Quality


© Pivolis 2004

Active Quality

Goal: share quality concepts through build automation

Contrasts with Documentation-driven qualityAutomatedPreventive instead of curative

Automation through builds/continuous builds and make the build fail as much as possible

Tests− Unit tests, Integration tests, Functional tests− Clover/Emma/JCoverage

Code quality− Checkstyle/PMD/Findbugs, Pattern Testing

Others− Metrics (NCSS, JDepend, etc)

Each tool requires an associated strategyOtherwise useless!

Requires trained coachs and evangelizationNeed to develop culture of excellence

Continuous integration requires a Build manager/engineer (full time job)

© Pivolis 2004

Testing

Developerworkstation

Assemblymachine

ISTplatform

Pre-UATplatform

UATplatform

Developer platform

Accessed from offshore

- Unit tests (mocks)

- Some integration tests

(DbUnit)

- Integration testing

(manual)

- Functional tests by

developers (manual)

- Technical / Functional tests

(manual)

- Performance testing

(manual)

- Functional tests by IT

users (manual)

- Functional tests by

end users (manual)

Automated f.e. with Abbot for Swing apps

© Pivolis 2004

Lessons learnt (1/2)

Require good mediators/coordinatorsTo solve communication issues due to language and cultural differencesTo suggest improvements continuouslyTo act as “harmonizers”

− Ex: prevent productivity measurements and associated disastrous communications

To shield teams from the wearing effect of working from a distanceLots of travels/exchanges

Hard to work with someone you haven’t seen− Leads to misunderstandings

Help share knowledge at all levelsAt all levels

− Managers, Project Leads, Lead Developers/Gurus, Developers

Lots of disciplineTo follow development methodology

− JIRA issues and update− The Build Must Pass! (requires developing a build culture)− Weekly meetings

© Pivolis 2004

Lessons learnt (2/2)

Share activities between onsite/offshore

Not just development, but also− Business Conception, Detailed Design, Testing, etc

Improve team spirit/job satisfactionAllow offshore people to progressShare the global knowledge and thus improve efficiency

Write functional test cases before development starts

Helps transfer business knowledgeEasy way to know requirements have been understoodCan then be scripted/automated by testing team

Dedicated offshore support persons in each team

To minimize question round trips

© Pivolis 2004

The Right Attitude

Always give the benefit of the doubt to the distant partyIs it possible that it is me who has not understood?Cross-check what you have understoodLook for reasons instead of only consequencesDig into the reasons to find root causes

Think of the distant party as « we » instead of « them » and « us »

Always try to improve processes/tools so that the global solution works better

Why do this?Because if you have accepted the situation there’s no point in dragging your feet. Either don’t accept it or do it well!Interesting human experience…International exposure and competencies (valuable on the market)

© Pivolis 2004

Benefits of distributed teams

Today the main driver is cost…

Exchange of knowledge in both directions

On how to develop softwareOn cultures / languages

Broadening of vision for all participants

Key skill for participants: working in an international team

Organization are more and more distributed

Will require practices for working from a distance− Ex: Mars/Earth

Ability to find talents/skills

Ex: Open Source (pushed to the extreme)

AOSD: Agile Offshore

Technology

Transcript of AOSD: Agile Offshore