AOSD: Agile Offshore

1
AOSD Agile Offshore

• Vincent Massol17/12/04

2
Agenda

• Agile Offshore Software Development (AOSD)
• Team organization
• Infrastructure
• Communication tools
• Delivery Management
• Active Quality
• Return of experience

3
Agenda

• Agile Offshore Software Development (AOSD)
• Team organization
• Infrastructure
• Communication tools
• Delivery Management
• Active Quality
• Return of experience

4
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 Customers 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
  

5
AOSD Agile Offshore Software Development

• Visibility at all levels
• Code, Quality, Productivity, Risk management
• Based on XP, RUP and Open Source practices
• Applied to the offshore context

AOSD
- Communication - Development - Planning
- Specifications - Developments - Delivery/Integ
ration
- Bug corrections/Change Requests
Collaborative Tools
Best Practices
Project Organization
6
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 versions
• AOSD Java, AOSD .Net, AOSD SAP, etc
• We will focus on AOSD Java in this presentation
• AOSD is a modular methodology
• Integrates well into an existing context
• Allow progressive and continuous adoption of its
  practices to improve communication/quality/product
  ivity.
  

7
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

8
Agenda

• Agile Offshore Software Development (AOSD)
• Team organization
• Infrastructure
• Communication tools
• Delivery Management
• Active Quality
• Return of experience

9
Team Organization (Logical model)
Depending on the size there can be one or several
coordinators
onsite
offshore
Offshore Project Manager
10
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
  directions
  
• Visa handling
• Infrastructure for offshore
• Infrastructure coordination improvements
  (monitor performances, tune tools) - with help
  from customers 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)
  

11
Team organization lessons No Micromanagement
Developer
Developer
Developer
Local Project Lead
Developer
Project Lead
Project Manager
Developer
Developer
onsite
offshore
onsite
offshore
12
Role diversity in offshore

• Same roles on both sides as much as possible
• To prevent feeling of superiority from one side
  / Help teams jell
  
• To spread overall knowledge which helps improve
  productivity
  
• Because 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

13
Agenda

• Agile Offshore Software Development (AOSD)
• Team organization
• Infrastructure
• Communication tools
• Delivery Management
• Active Quality
• Return of experience

14
Infrastructure
Intranet (Wiki, Build results, Issue tracker)
Source Repository
Continuous build
DMZ reachable from offshore
VPN over internet
firewall
firewall
firewall
Offshore
Onsite
15
Agenda

• Agile Offshore Software Development (AOSD)
• Team organization
• Infrastructure
• Communication tools
• Delivery Management
• Active Quality
• Return of experience

16
Communication tools
Value in team knowledge sharing
Travels
Word doc
Wiki
Mailing list/forum
Video Conf.
email
Phone
chat
Usage frequency

• 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

17
How to share functional knowledge?

• Travels in both directions
• Functional training for Project Leads
• Especially before new subjects
• Have Project Leads do the business conception
• As much as possible
• Have Project Leads do the detailed design
• Open chat channels with functional persons
• We 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 cases
• Have a separate team script and automate them

18
Agenda

• Agile Offshore Software Development (AOSD)
• Team organization
• Infrastructure
• Communication tools
• Delivery Management
• Active Quality
• Return of experience

19
Iteration planning (Time-boxed)
Meetings every week
Continuous build(2 hours)
Phase start
Phase end
time
Iteration(2 weeks)
Work Packet 1
Work Packet N(6-7 weeks)
Delivery
Production delivery
Functional delivery

• Fixed iteration delivery dates (Time-Boxing)
• Must not be changed, content can change
• Iterations must list all tasks taking ½ day or
  more
  
• To prevent misunderstanding
• To allow easy progress follow up
• To generate release notes automatically
• Done using Issue Driven Development

20
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 Board
• Made of representative of the different streams
  (business, architecture, developers, management,
  etc)

21
Agenda

• Agile Offshore Software Development (AOSD)
• Team organization
• Infrastructure
• Communication tools
• Delivery Management
• Active Quality
• Return of experience

22
Active Quality

• Goal share quality concepts through build
  automation
  
• Contrasts with Documentation-driven quality
• Automated
• Preventive 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 strategy
• Otherwise useless!
• Requires trained coachs and evangelization
• Need to develop culture of excellence
• Continuous integration requires a Build
  manager/engineer (full time job)
  

23
Continuous build platforms
24
Testing
Accessed from offshore
IST platform
Pre-UAT platform
UAT platform
Developer platform
Developer workstation
Assembly machine
- Unit tests (mocks) - Some integration tests (Db
Unit)
- 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
25
Agenda

• Agile Offshore Software Development (AOSD)
• Team organization
• Infrastructure
• Communication tools
• Delivery Management
• Active Quality
• Return of experience

26
Lessons learnt (1/2)

• Require good mediators/coordinators
• To solve communication issues due to language and
  cultural differences
  
• To suggest improvements continuously
• To act as harmonizers
• Ex prevent productivity measurements and
  associated disastrous communications
  
• To shield teams from the wearing effect of
  working from a distance
  
• Lots of travels/exchanges
• Hard to work with someone you havent seen
• Leads to misunderstandings
• Help share knowledge at all levels
• At all levels
• Managers, Project Leads, Lead Developers/Gurus,
  Developers
  
• Lots of discipline
• To follow development methodology
• JIRA issues and update
• The Build Must Pass! (requires developing a build
  culture)
  
• Weekly meetings

27
Lessons learnt (2/2)

• Share activities between onsite/offshore
• Not just development, but also
• Business Conception, Detailed Design, Testing,
  etc
  
• Improve team spirit/job satisfaction
• Allow offshore people to progress
• Share the global knowledge and thus improve
  efficiency
  
• Write functional test cases before development
  starts
  
• Helps transfer business knowledge
• Easy way to know requirements have been
  understood
  
• Can then be scripted/automated by testing team
• Dedicated offshore support persons in each team
• To minimize question round trips

28
The Right Attitude

• Always give the benefit of the doubt to the
  distant party
  
• Is it possible that it is me who has not
  understood?
  
• Cross-check what you have understood
• Look for reasons instead of only consequences
• Dig 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
  theres no point in dragging your feet. Either
  dont accept it or do it well!
  
• Interesting human experience
• International exposure and competencies (valuable
  on the market)

29
Benefits of distributed teams

• Today the main driver is cost
• Exchange of knowledge in both directions
• On how to develop software
• On 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)

30
QA
?