The Centripetal Forces for Successful Global Software Development

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

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

Development Methodology o It groups similar activities together n n n 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

Definitions o Methodology n o 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 n 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”

Development Methodology o Why Process model are not used in many software companies n n n Small development team Co-located Heroics o o o n 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

Development Methodology o Two Fundamental Development Approaches n Waterfall or linear or sequential model n Prototyping or iterative model

Development Methodology o Waterfall model n n n Moves through a number of stages in sequence Each stage must be fully completed before moving to the next one. Stages: o o o n n 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

Development Methodology o Prototyping n n Harder to manage but more effective Build successive iterations (or loops)

Example of process Model o IBM Java. Beans Project n 1. 2. 3. 4. 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?

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

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

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

Summary: Development Methodology o When cross-border sites are consolidated into a team, consider one of the three methodological strategies n n n o 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 n n Define terms early and continue to define them as development progresses Continue to standardized terms (e. g. freeze, fixed, etc)

o Architecture & Task Allocation

Architecture & Task Allocation o Product architecture determines whether dispersed sites can work harmoniously with each other without stepping on each other’s toes. n n Proper product architecture is based on the principle of modularity Modularity: designing software components that are selfcontained 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.

Architecture & Task Allocation of tasks n n n 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.

Architecture & Task Allocation o How should software be decomposed? n Information hiding o n 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 o o By degree of Coupling n Degree of interaction between modules n Minimize coupling By degree of Cohesion n Degree to which a module comprises a well-defined functional whole. n Maximize cohesion

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

Architecture & Task Allocation o Task Allocation Strategies n Modular-based n Phase-based n Integrated (follow-the-sun)

Architecture & Task Allocation o Modular-based n 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 Modular-based Site B t=0 delivery

Architecture & Task Allocation o Phased-based n n 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

Architecture & Task Allocation o Integrated n n 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)

Architecture & Task Allocation o Weakness of the strategies n n 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. o This happens during the 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.

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

Architecture & Task Allocation o Success Factor for each task allocation n Module-based: o o n Phased-based: o o o n Good architecture early on Minimize inter-dependencies between the modules. 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: o o 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.

Architecture & Task Allocation o Inter-site task allocation criteria n Knowledge o o n 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 o o o Emerging nations In most cases the allocation strategy is phase-based: coding and testing and are allocated to distant sites Structure and Abstract

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

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

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

Stages Performing / Strategic Focus (Not just focusing on cost) 5 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) 4 Storming / Strategic decision point (Organization leaders share conflicting ideas about outsourcing and pursue different strategies to provide IT services) 3 Forming / experimenting stage (outsourcing between 10 -20% of IT activities) 2 Insourcing / Bystander (outsourcing between 1 -5% of IT. Mostly purchasing of IT functions). 1 Low High

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

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