Global Software Development

1. Global Software Development Niels Hallenberg IT University of Copenhagen BAAAP – Spring 2009

2. Outline • Global Software Development at Siemens: Experience from Nine Projects Splitting the • Organization and Integrating the Code: Conway’s Law Revisited • Agile Practices reduce Distance in Global Software

3. Nine Projects at Siemens • Methodology: • 18 interviews, three Siemens sites • Project management, technical leadership, middle management positions and executive or senior management roles • Locations: Europe, India, US, Japan • Interview topics • Role and responsibilities • Development divided among sites • How work was managed • Cross-site relationships • Processes and tools • Problems, issues and best practices

4. Nine Projects at Siemens • Management and Control • Incentives may differ among the sites • There may be “hidden” tensions: job cuts, competition, same functionalities goes in different products. • Decision-making having a negative impact on product, eg., when decisions are made of personal or political reasons and not for rational or technical reasons - this also happens on single sited projects. • Project planning and tracking is a discipline and differences will cause problems. • Informal communication is very difficult

5. Nine Projects at Siemens • Formal communication is slow and time consuming and not always precise • Examples of formal contra informal communication? • Skills – are we satisfied with the other sites programmers? • Project insight at the other site – no information often means that they are behind schedule. • Projects involving integration relied heavily on tracking information • Late deliverables or deliverables of poor quality at one site leave the other site with no work.

6. Nine Projects at Siemens • Process compatibility: • Translating formal documents • Confusion about roles – what is exactly the role of a project manager – does he make decisions or is she basically an information gathering function. • Engineering style: do you use lot of time on design or do you make design and implementation simultaneously. • Process maturity: Poor process quality infer late deliverables of poor quality. If you cant provide a status for your project, then you are probably performing poorly.

7. Nine Projects at Siemens • Decision making: are staff at the lowest technical level allowed to make decisions not affecting functionality and schedule negatively? This is highly cultural dependent. • Development environment: • Build capabilities at all sites – maybe even a central build capability. • Connection Speed! • Collaboration technology – “is there really a person over there”: • Photo gallery • Photo-annotated organization chart

8. Nine Projects at Siemens • Communication • You really needs to know who you ara talking to – getting to know each other. • Are you communicating through a project manager (centralized) or directly between the involved persons (decentralized) • Do you understand the format that is communicated – eg. UML or a home made class diagram notation. • The domain knowledge is very important – an external contractor may have more need for education than a newly hired employee at your local site.

9. Nine Projects at Siemens • Workshops are very effective – and all important decisions should be made the last day. • We want to meet people and spend time – also on non professional matters • Drink a few beers together – it makes a big difference when problems occur. • The way agreement and disagreement is expressed differs among cultures! • Some cultures are good at asking questions and very precisely express their agreement and disagreement. But other cultures may give the impressions of agreement but actually it is just to be polite.

10. Nine Projects at Siemens • Time zones make it harder to have over lapping working hours. • YOU MUST DEVELOP TRUST • ALWAYS SPEND YOUR TRAVELING BUDGET AT THE START OF THE PROJECT

11. Integrating the Code • Case study of integrating a geographically distributed project. • Project dimensions: • Project structure: what is to be developed • Development process: how is the project developed • Milestones: when is the milestones achieved • Ressources: who is working on the project. • Brooks law: if a project is late then adding more people will slow the project even more. • Capability Maturity Model (CMM – 5 levels) • http://en.wikipedia.org/wiki/Capability_Maturity_Model

12. Integrating the Code • It is impossible to avoid the unpredictable and “outside-the-plan” actions. • Informal communication is very important – you do not know what you don’t know – and informal communication often leads to make the unkown known. • The functionality of an Interface Specification is hard to make precise: • Two sites building simulators for the other sites deliverables. Different assumptions got into the simulators and the programmers didn’t realize before integration started.

13. Integrating the Code • Change Control Board (CCB) • They must cover the entire project and still be able to make decisions. • Informal Communication: • Who to contact. • It is difficult to get an informal contact right away – time zone etc. • Language barriers • Lack of trust for an openly communication • Unplanned contacts are very important! • You must communicate even though there is no reason for it – why? Many problems are unknown.

14. Integrating the Code • Efficient communication: • Do communicate cross site even though its expensive and troublesome. • Publish your calendar openly – else people will ware time trying to get in contact with you • Agree on communication slots if you are working long distances. • Reduces responsiveness is hard to avoid when working across sites. • Consequences are high if you don’t communicate • Communication is hard when you can’t see what the other site is talking about, eg. a detail on a GUI. • Use communication different communication technologies: email, chat, wiki, skype, etc. • YOU MUST PUSH THE COMMUNICATION

15. Lessons Learned • Reduce the need for cross-site communication: • Modular and independent modules • Products must have well understood boundaries • Overcome barriers to informal communication: • Travel at the beginning of the project. • Build relationships • Use appropriate tools

16. Agile Practices • Agile Development Methodologies in Global Software Development (GSD) • XP • Scrum • Agile methods are characterized by short, iterative cycles of development driven by product features, periods of reflection, collaborative decision making, incorporation of rapid feedback and continuously integration of code. • Agile in GSD is difficult because communication is difficult.

17. Agile Practices • Distributed eXreme Programming – practices that are independent of location: • Small releases, simple design, testing, refactoring and coding standards • Practices that is highly dependent on location: • Planning game, pair programming, continuous integration and on-site customers • This study asks: can agile methods be used to reduce the negative influence of distance on communication, coordination, and control in a GSD context?

18. Agile Practices • Locations: US, Ireland, India, Poland, China and Malaysia • Challenges with Temporal Distance: • Time zones • You get behind a discussion – happended while you were at sleep. • Slow responsiveness • Challenges with Geographical Distance: • Hard to build trust – we are two separate teams • Also people at the technical level should meet physically • Plan when people should meet face-to-face, fx while integration

19. Agile Practices • Challenges with Sociocultural Distance, that is company culture, national culture and language. • Language limitations – it is harder to socialize in a foreign language than talking technicalities. • In some cultures it is impolite to say no – can you deliver on Monday – yes – and still three month later there had been no delivery. • Different interpretation

20. Agile Practices • Conclusions – GSD benefits: • XP and Scrum improve communication, coordination and control • XP pair programming -> collective ownership, higher and coherent code quality • XP simple design -> design documents evolve while coorporating • XP refactoring -> bugs are eliminated • Scrum planning game -> project activities are shared openly

21. Agile Practices • Conclusions – GSD benefits: • XP Pair programming -> increase time overlap and reduce temporal distance • Scrum planning game -> increase “teamness” and reduce geographical distance • XP pair programming and Scrum pre-game phase -> increase mutual understanding and reduce sociocultural distance.