Global Software
Development
Riku Granat
Vice President, Applications Software
In this episode …







Where do I come from?
What is GSD?
Why GSD?
Why not GSD?
Challenges and what to
do with them?
Summary
Q&A
What is GSD?
What is GSD?
What is Global Software Development?


Software development
Geographically distributed to multiple countries




Across national, cultural and other boundaries
Controlled – driven by



Common goals
Common policies
Coordinated – orchestrated – managed




Global development (own + 3rd party)
Global markets
Teams
Tasks
Deliverables
Communication between the distributed teams

Information sharing
Why GSD?
Why GSD?
– the most common answers

Cost savings

“Up to -80%”
Lack of local software
developers
 Focus on core competencies
…
 I.e. the usual management
story

Why GSD? – “the right answer”





Access to the world wide talent pool
Cost structure and savings
Risk management
Focus on where you get the best ROI
Market presence


understanding local needs
being close to the customer
Mergers and acquisitions
 Improved quality
 Follow-the-sun / -seasons development
Gaining competitive advantage

The bottom line is …
Regardless of what your reasons are you need to
understand them, you need to understand “why” …
… build your GSD strategy to support it
... because there are a lot of issues as well
i.e. there is a price to pay!
Why not GSD? – some issues









Strategic choices – timing, partners, …
Management / comms overhead –
complexity
Cultural issues
Communication issues
Technical issues – does your software
architecture support distributed development
model?
…
Your own management and leadership
skills!
…
You name it!
Challenges











Site strategy
Cost level
Communication
Culture
Work split
Software architecture
Processes
Methods
Open source
Internet
Leadership
Challenges – What to do about
them?
Everyone needs to and almost
everyone can change!
Site strategy

Challenge



Understand why you do it
Understand what you want to achieve
It is all about strategic choices



When, where, with whom, …
The bottom line: how to maintain and gain competitive
advantage?
What to do about it?





Create a strategy
Create an implementation plan
Execute it
Make frequent but not too frequent updates
Continuously review whether your “whys” and your strategy /
plans match
Costs

Challenge



Savings and how to measure them?
How can you control costs in a dynamic environment without losing
productivity?
What to do about it?


Develop unambiguous metrics / “accounting system” and follow-up
Flexibility from tactical, typically black box, subcontracting


For long term business more sustainable solutions are needed





Build on the site strategy – have a portfolio of sites – distribute risks
Have real options, based on own staff and partners
Have critical mass per site
Do not move responsibilities “every day”
Can cost saving ever be your only goal?


Typically suitable only for simple well-specified short term projects
Costs will always go up, if there is success
“Went for cost, stayed for quality, building future on innovation”
Communication
# of “tribes”
Communication

Challenge




Frequency of comms decreases with distance, more
comms with local than remote staff
Formal comms: how to keep the mill running (normal
reporting, specifications, reviews, meetings, …)
Informal comms: changes, legacy knowledge,
background, informal requirements
What to do about it?

Keep your comms tools in extremely good shape


Make sure that also development tools work fluently


phone, video conf, net meeting, e-mail, chat,
discussion forums, wiki pages, …
Distributed SCM, sharing documents (wiki,
databases), …
Encourage people to share and collaborate

Explain reasons, motivate, use common goals, …
Culture

Challenge




What to do about it?






Meaning of the org chart, not taking risks,
collectivism, long term vs short term, …
Attitude to time, work itself, quality, …
Race, religion, …
Be very sensitive to the cultural differences
Pay attention to the work split
Pay attention to the management structure
Bridge cultures
 site visits, local people on- site, common
processes, expatriates, …
Trainings
See also work split
Work split 1/2

Challenge


How to split the work in an optimal way?
What to do about it?


Understand what you are trying to do! What is driving your business?
Define clearly your work split approach based on your business drivers





Distributing software assets (for special competences)
Distributing development phases e.g. testing (for cost savings)
Distributing product or product families e.g. customization for certain regions
Distributing localization e.g. Chinese variants to China
Examples of candidates for remote development



Driven by cost – maintenance or further development of old versions or
specific components
Driven by local requirements – localization / tailoring specific components /
products
Driven by scale and access to global talent pool – whatever your
architecture supports
Work split 2/2
What to do about it?




“One size does not fit all” – different goals require different set-ups
Distribute only big enough and isolated enough projects
 Otherwise the management overhead will eat your gains quickly
Ultimately aim at self contained local teams
 Remote extensions are ok as starting points but are not sustainable solutions
Remember that is the evening it is still team work


and things must come together
Software architecture

Challenge


What to do about it?





How can you split the work between separate development sites
and still get the components integrated and maintain software
integrity?
Ideally do only things that your software architecture supports!
Respect the interfaces in the architecture (existing specs, change
control, …)
Develop the architecture to support independent development
and ultimately also independent deployment
Distribute only architecturally isolated development efforts
What if your architecture is not ready for all this?


Build on strict SCM code line policy
Inner source model – Use controlled parallel development
practices – have one “master” and as many “slaves” as you need
Software architecture special topics


Vertical
integration
User
experiences
Processes

Challenge




Global business and strategy driven optimization vs local optimization
Even in a distributed development environment people need to communicate,
software has to be integrated, project status has to be made visible, …
Doing all that with totally different processes will result into misunderstandings,
invisibility, delays, additional cost, frustration, …, and ultimately to failure
What to do about it?


Always start from the business imperatives and globally optimize for those
Have a common project model


Sufficient level of common processes (key milestones, key phase results, key
deliverables, …)
But leave some room for local fine-tuning




keeping people motivated
getting the best out of the team
accommodating some local differences
acknowledging that “one size does not fit all”
Methods

Challenge



Some methods are more local by their nature than
some others
e.g. some agile methods have some implicit and even
explicit needs for proximity of people
What to do about it?




Apply the theory / processes, you rarely find an out-ofthe-box solution from the school books
Use common methods across the sites
Look at the development methods from work split
perspectives and the other way round
Understand the constraints of your software
architecture e.g. in terms of where can you use Scrum
teams
Open source

Challenge





You are not in charge anymore!
You need to learn to collaborate with/in the communities
Potential mismatch between OSS drivers and your business drivers
Mismatch between your processes and tools and those of open source
What to do about it?


Again, start from your business drivers
Understand where you can use OSS and still meet your business goals





Licenses e.g. GPL vs protecting your IPR
Development drivers – differentiation vs commoditization, …
Adapt to the community (externally)!
Communicate with the community!
Give, not only take – be a good citizen in the OSS communities
Internet

Challenge





You are not in control anymore, neither is your company, nor your
government
Things happen where the experts are / where they want to go
Things can be more easily move from place A to B
Blogs, information leaks, …
What to do about it?



Just accept it and adapt, take it as an opportunity
Be a good citizen in the Internet
Communicate, communicate and communicate
Leadership

Challenge


Need for fuzzy management
 More unknowns
 More dependencies
 Can’t control everything
What to do about it?


Train your leaders and staff to cope with it
 Global project management and working in a global project is a
totally different ball game than local small projects
Recruit “modern leaders” with strong collaboration skills
Summary
Summary
Summary
GSD is a must in any big software business
 It comes with a lot of challenges and issues …
… most of which have solutions or workarounds
… if you know what you want to achieve
… and if you manage those challenges properly!


Remember to drive GSD from your business and strategy
perspectives, don’t let it become an engineering exercise
Every GSD case is unique in terms of culture, work split, drivers etc
… you need to treat them uniquely and learn as you go!
 Mr Brooks is still right – there is no silver bullet!

Thanks!
Any questions?