tactics for global software development when to do what
play

Tactics for Global Software Development: When to Do What? James - PowerPoint PPT Presentation

Tactics for Global Software Development: When to Do What? James Herbsleb Carnegie Mellon University 1 Multi-site Delay Modification Request (MR) interval Work Last Modification - First Modification Days All changes over 2 year period 30


  1. Tactics for Global Software Development: When to Do What? James Herbsleb Carnegie Mellon University 1

  2. Multi-site Delay Modification Request (MR) interval Work Last Modification - First Modification Days All changes over 2 year period 30 multi site single site 18.1 20 12.7 10 6.9 4.9 0 Network Element A Network Element B 2

  3. Working Across Boundaries . . .  Issue resolution paralysis − even small issues can take days  Very difficult to stay “in the loop” − constantly surprised, “swimming upstream”  Misalignment − undiscovered, conflicting assumptions  Nonexistent or impaired social networks − loss of critical problem-solving mechanism  Ineffective collaborative sessions − “What was decided?”  Don’t know what you don’t know 3

  4. Coordination is the Key  Managing dependencies between tasks* *Malone, T.W. and Crowston, K., The interdisciplinary theory of coordination . ACM Computing Surveys, 26, 1 (1994), p. 87-119. 4

  5. Conway’s Law  “Any organization that designs a system will inevitably produce a design whose structure is a copy of the organization's communication structure .” − M.E. Conway, “How Do Committees Invent?” Datamation, Vol. 14, No. 4, Apr. 1968, pp. 28–31 .  Implication: Modularity works as a coordination strategy  Problem: Modularity has major limitations 5

  6. Conway’s Law Components Teams Isomorphism Software Organization 6

  7. Conway’s Law Components Teams Homomorphism Software Organization 7

  8. What about the Connectors? Components Teams Software Organization 8

  9. Complexity and Uncertainty Components Teams Complexity Uncertainty ? What kind of coordination is required? Software Organization 9

  10. Coordination Requirements: Complexity  Examples − How “big” is an API? − How complicated are API usage policies? − Features with implementations spanning components − Challenging non-functional requirements • Performance • Security • Availability • Etc. 10

  11. Coordination Requirements: Uncertainty  Examples − Allocation of functionality to components − Modification and refinement of component interfaces − Volatile requirements − Dependencies on other systems that are changing • Hardware • Firmware • Middleware • Etc. 11

  12. Congruence Components Teams ? Software Organization 12

  13. Congruence Components Teams ? Coordination Coordination Requirements Capbility What determines coordination capability? Software Organization 13

  14. Coordination Mechanisms  Preparation, e.g., − Plans − Specifications − Defined processes  Shared representation, e.g., − Metrics dashboard − Posting test results − “Living” documents  Communication, e.g., − Meetings − “Informal” communication 14

  15. Distance Breaks Down Communication Communication Within site Lack of unplanned contact Knowing who to contact about what Difficulty of initiating contact Gap Ability to communicate effectively Lack of trust, or willingness to communicate openly Across sites 15

  16. Distance Breaks Down Preparation and Shared Representations Meeting of Minds Within site Variation in practices Variation in understanding Interpretation depends on context Gap Lack of shared notations Little ability to anticipate actions Across sites 16

  17. Many Factors Affect Coordination Capability  Organizational factors, e.g., − Geographic distribution − Divergent processes − Different management practices − Communication infrastructure  People factors, e.g., − Experience working together − Domain and technology expertise − Language skills 17

  18. Achieving Congruence  Matching coordination requirements and coordination capability 18

  19. Thinking About Tactics Uncertainty Low High Co-locate if Planning High Complexity possible! Shared Representation Communication (Cautious) Low Shared Representation Modularity 19

  20. Changing the Game Uncertainty Low High High Complexity Reduce Complexity Low 20

  21. Changing the Game Uncertainty Low High Reduce High Uncertainty Complexity Low 21

  22. Beware of Architectural Change  Lessons from the history of photolithographic alignment equipment* *Henderson, R.M. & Clark, K.B. (1990). Architectural Innovation: The Reconfiguration of Existing Product Technologies and the Failure of Established Firms. Administrative Science Quarterly , 35 (1), pp. 9-30. 22

  23. Future Work  “Coordination view” of an architecture  Measuring congruence of architecture and organization  Architectural tactics for improving congruence 23

  24. Conclusion  Architectural decisions create the “coordination landscape”  Architectural structure and organizational structure are strongly related  Congruence is necessary for project success  Complexity and uncertainty present different problems  Need research on measuring congruence, devising tactics for improving it 24

Recommend


More recommend