The Centripetal Forces for Successful Global Software

1. The Centripetal Forces for Successful Global Software Development methodology and Task Allocation

2. Development Methodology • The map that guide the team through the software development cycle • Common language bridging developers at different sites. • “ we do that during the alpha stage” • Terms and milestones are understood • At a given, all developers know where their place is in the bigger picture • It gives everyone a consistent set of expectations

3. Development Methodology • It groups similar activities together • It reduces redundant activates and excessive work • It organizes activities into steps and phases • It enhances quality by assuring that the activities are comprehensive and complete • It reduces irrational activities • And serve as effective documentation for management

4. Definitions • Methodology • Is a systematic approach to conducting at least one complete phase (e.g., design) of software production, consisting of a set of guidelines, activities, techniques, and tools, based on a particular philosophy of systems development and the target system. • Process Model • Is a representation of the sequence of stages (e.g., design, build, test) through which a software evolves. The term “methodology” is often used synonymously with “process model”

5. Development Methodology • Why Process model are not used in many software companies • Small development team • Co-located • Heroics • Relying on end-of-cycle all-night work weeks • Relying on few exceptional people, with exceptional abilities. • Supper programmers • The informal team mechanism for getting job done fall apart for GDSD

6. Development Methodology • Two Fundamental Development Approaches • Waterfall or linear or sequential model • Prototyping or iterative model

7. Development Methodology • Waterfall model • Moves through a number of stages in sequence • Each stage must be fully completed before moving to the next one. • Stages: • Problem definition • Analysis • Design • Code (implementation) • Testing (black box, white box, integration then acceptance) • Easier to manage • Less hand offs and each hand off tends is more clearly defined

8. Development Methodology • Prototyping • Harder to manage but more effective • Build successive iterations (or loops)

9. Example of process Model • IBM JavaBeans Project • Iterative • Problem Statement Creation. A simple 1-2 line definition that can be initiated by any of the sites. • Problem definition development. This stage was considered more difficult – working from a loose idea to high level implementation, requiring iterations. • Implementation (code). Usually a small unit of three to five people are involved. • Acceptance. Addresses the following questions: Does it function correctly? Is it packaged correctly? Is the documentation correct and complete?

10. Development Methodology • Methodology is a cook book • Can not be overly rigid • Need to be flexible • Changes with time (improvement) • Off the shelf models from many sources

11. Development Methodology • Methodological Clash • When two software companies (teams) conduct a cross-border joint venture, whose development methodology should be used? • Allowed methodological differences to continue • Imposed the headquarters standard • Choose the methodology of one of the partners

12. Summary: Development Methodology • Impose a development framework before development begins • Educate all team members on the chosen methodologies • Grow the methodology • Continue to raise the methodological capacity level of the development team

13. Summary: Development Methodology • When cross-border sites are consolidated into a team, consider one of the three methodological strategies • Forcing standardization • Blending methodological components from the various sites into one new methodology • Imposing high-level guidelines only • Define and agree to terminology every day • Define terms early and continue to define them as development progresses • Continue to standardized terms (e.g. freeze, fixed, etc)

14. Architecture & Task Allocation

15. Architecture & Task Allocation • Product architecture determines whether dispersed sites can work harmoniously with each other without stepping on each other’s toes. • Proper product architecture is based on the principle of modularity • Modularity: designing software components that are self-contained and have few interdependencies with other modules. • Modularity design reduces complexity and allows for easier parallel development • Components are designed in small granules, keeping each component’s interfaces to a manageable number.

16. Architecture & Task Allocation • Allocation of tasks • The key success factor for most dispersed global teams is the clean allocation of tasks: ensuring that each site has a significant task that relies as little as possible on other sites. • Coordination overhead is reduced by minimizing the interdependency between sites • The concept of modularity – allowing a software program to be manageable intellectually – is fundamental to computer science.

17. Architecture & Task Allocation • How should software be decomposed? • Information hiding • Is a design concept that calls for properly structuring the software’s modules such that the design logic is hidden from its user – the programmer. • Independence of modules can be measured • By degree of Coupling • Degree of interaction between modules • Minimize coupling • By degree of Cohesion • Degree to which a module comprises a well-defined functional whole. • Maximize cohesion

18. Architecture & Task Allocation High Low Good Cohesion Coupling Bad High Low Optimal modularization

19. Architecture & Task Allocation • Task Allocation Strategies • Modular-based • Phase-based • Integrated (follow-the-sun)

20. Architecture & Task Allocation • Modular-based • In modular-based allocation, site A and site B are each assigned one of two modules to develop from the beginning of the system development cycle to the end. Site A Site B Modular-based t=0 delivery

21. Architecture & Task Allocation • Phased-based • This strategy is based on the standard stages, or phases, in the systems development cycle: design, build, test. • That is, site A performs the first phase (design), while site B performs the next phase (build) and so on. Site A Site B Phase-based

22. Architecture & Task Allocation • Integrated • The integrated strategy works when (dispersed) sites work closely together, both across modules and across development cycle. • Known as follow-the-sum in global software teams Site A Site B Integrated (follow-the-sun)

23. Architecture & Task Allocation • Weakness of the strategies • The point of weakness of each of these task allocation schemes are in their coupling, that is, the transition, or hand-over, from site to site. • Module-based allocation’s point of weakness occurs at the end of the cycle when the modules need to be integrated together. • This happens during the first first “build” or during integration testing • The phase-module point of weakness is in the hand-over from phase to phase. • The integrated-module has hundreds of point of transactions and each one of them is a point of weakness.

24. Architecture & Task Allocation Site A Site B Modular-based t=0 delivery Site A Site B Phase-based Site A Site B Integrated (follow-the-sun)

25. Architecture & Task Allocation • Success Factor for each task allocation • Module-based: • Good architecture early on • Minimize inter-dependencies between the modules. • Phased-based: • Devote attention to transitioning (i.e., hand off). • Establish relatively stable requirements or specifications. • The specifications have to be well defined, comprehensive and accurate. • Integrated: • Set up small granules of work and pair up individuals from distant sites to work with each other. • Individual coordination of transition is simpler than passing work from group to group.

26. Architecture & Task Allocation • Inter-site task allocation criteria • Knowledge • Center of competence – used to describe a concentration of technical or more often, application expertise • Most centers of excellence built through experience • Some companies build center of excellence from the ground up. • Predetermined by acquisitions and are modular in nature • Cost • Emerging nations • In most cases the allocation strategy is phase-based: coding and testing and are allocated to distant sites • Structure and Abstract

27. Architecture & Task Allocation • Intra-site Task Allocation • Task assignment to individual developers at each site are best made by local team leads based on local norms • Individualistic culture approach • Who is doing what • Collective culture approach • Work together to meet the group goal

28. Architecture & Task Allocation • Changes in allocation over time: Stage Model of global software teams • Allocation is not static from project to project Stage Model for global Software Teams Stage 1 One Location HQ Stage 2 Central Coordination HQ Stage 3 Globally Integrated HQ

29. Architecture & Task Allocation • Changes in allocation over time • Stage Model of global software teams Unstructured tasks Ownership Functional specs High level design Low level design New Programming Redesign/maintenance Structured tasks Time Enhanced responsibility of remote site over time

31. Stages Performing / Strategic Focus (Not just focusing on cost) 5 4 3 2 1 Norming / Proactive Cost Focus (Beginning to form norms and actively focusing and proactively using outsourcing for cost saving including offshore. Outsourcing 20-40% of IT activities) Storming / Strategic decision point (Organization leaders share conflicting ideas about outsourcing and pursue different strategies to provide IT services) Forming / experimenting stage (outsourcing between 10-20% of IT activities) Insourcing / Bystander (outsourcing between 1-5% of IT. Mostly purchasing of IT functions). Low High

32. Offshore Outsourcing Readiness vs. Attractiveness Offshore Readiness Ready but not attractive Ready and attractive High Not attractive and not ready Attractive but not ready Low Offshore Attractiveness Low High

33. Architecture & Task Allocation • Best Practices • Architect or re-architect your product before dispersing its development • Success of GDSD depends on the architectural design in early stages of the development process • Architecture has to be managed • Set up architecture support in the form of an inter-site committee or assign someone to the task • Modularize • Build small, independent software components that are easily allocated across sites • Anticipate the points of weakness of your task allocation strategy • The hands off is the point of weakness • Do not tightly task individuals at each site. • Leave those responsibilities to local team leads.