Global Software Development

1. Global Software Development Riku Granat Vice President, Applications Software

2. 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

3. What is GSD? What is GSD?

4. What is Global Software Development? • Software development • Geographically distributed to multiple countries • Global development (own + 3rd party) • Global markets • Across national, cultural and other boundaries • Controlled – driven by • Common goals • Common policies • Coordinated – orchestrated – managed • Teams • Tasks • Deliverables • Communication between the distributed teams • Information sharing

5. Why GSD?

6. 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

7. 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

8. 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!

9. 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!

10. Challenges • Site strategy • Cost level • Communication • Culture • Work split • Software architecture • Processes • Methods • Open source • Internet • Leadership

11. Challenges – What to do about them? Everyone needs to and almost everyone can change!

12. 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

13. 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 • Typically suitable only for simple well-specified short term projects • 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? • Costs will always go up, if there is success • “Went for cost, stayed for quality, building future on innovation”

14. Communication # of “tribes”

15. 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 • phone, video conf, net meeting, e-mail, chat, discussion forums, wiki pages, … • Make sure that also development tools work fluently • Distributed SCM, sharing documents (wiki, databases), … • Encourage people to share and collaborate • Explain reasons, motivate, use common goals, …

16. Culture • Challenge • Meaning of the org chart, not taking risks, collectivism, long term vs short term, … • Attitude to time, work itself, quality, … • Race, religion, … • What to do about it? • 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

17. 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

18. 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

19. Software architecture • Challenge • How can you split the work between separate development sites and still get the components integrated and maintain software integrity? • What to do about it? • 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

20. Software architecture special topics • Vertical integration • User experiences

21. 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”

22. 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-of-the-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

23. 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

24. 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

25. 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

26. Summary Summary

27. 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!

28. Thanks! Any questions?