Collaborative Software Design & Development Teams

1

Collaborative Software Design & Development

© 2005, Dewayne E Perry

Lecture 4

EE 382V – Spring 2008

Collaborative Software Design & Development

*Teams*

Dewayne E PerryENS 623A

Office Hours: T/Th

10:00-11:00perry @ ece.utexas.edu

www.ece.utexas.edu/~perry/education/382V-s08/

2

Collaborative Software Design & Development Lecture 4

© 2005, Dewayne E Perry EE 382V – Spring 2008

Teamwork According to Dilbert

3



Study ContextSwindon in the UK, Nuernberg in GermanyEnglish in Swindon, German in NuernbergFirst product in Nuernberg, this second driven managerially from SwindonExisting Team in Nuernberg, new team in SwindonDomain experience in both places

Swindon team hired away from Motorola etcTelecom domainAt the end of project, success and failure

Testing team – considered to be very successfulIntegration team – considered to be a failureWhy?

4



Forming TeamsSuccess Factors

Do effective planningSelf-managingGet the work done

Factors in forming teamsI

Inception and acceptance of project goalsII

Agreement on solution of technical issues, attaining goalsIII

Resolving conflicts and political issuesIV

attaining goals, execution of requirements –

ie, doing itCritical factors

Need time to build trustFace to face is necessary to build working relationshipsNeed clear agreement on team goalsMatch communication bandwidth to intensive interfaces

5



Test Team SuccessMirrored team formation theoryContributing factors

Managerial strategiesContext for self managementShared vision among team leadersWork critical issues ahead of time, not when criticalOptimize critical issues by divide and conquer

ProactiveIsolate critical issuesImprove processes, for example

Initially, hand coded testsAutomated regression testingAutomate test generation and testing

6



Conway’s Law and the Integration TeamConway’s Lay:

The structure of your system mirrors the structure of your organization

Why?Organizational structure governed by management structure not project structureModules are divisions of laborSystems components are assigned as responsibilities to people and they reside in organizationsDifferent stages of the product are often produced by different parts of the organization, eg

Requirements and architecture in one organizationDesign and code in anotherSystem build and integration in yet anotherTesting and quality control in still another

7



Conway and Geographical DistributionProblem exacerbated in geographically separated organizationProblems in geographically separated development

Informal communication – eg75 minutes per day, informal, short, unplanned interactionsFace to face interactions

Formal communicationsNeed bandwidth appropriate to needs of communication

Inherently unpredictable aspectsNeed spontaneous communication

Unanticipated breakdowns in communication lead to delay, inefficiency and frustration

8



Why Projects FailGutless estimation

Lack of ability to predict (well)Monitoring progress is difficultProject plans seldom are changed except at the last minuteBrooks Law:

Adding more people to a late project only make it laterTime to acclimatize new people to projectMore communication overhead

9



IntegrationIntegration team constrained by

The integration planComponent interface specificationsSoftware processesDocumentation

Integration PlanDependence on overall development plan

In this case overly optimisticComponents have to be ready at the right time

Changing requirements, schedulesInadequate substrate for the product/project

Both software and hardwareLack of alignment

10



IntegrationInterface Specifications

Used ORBIX (based on CORBA) to support interface specificationInterfaces + simulators for others use

Hides problems of real implementationCode based understanding of actual interfaceInterface management based on substrate

Different assumptions etc

11



IntegrationSoftware Processes

Weaknesses in process uncovered in integrationSite isolation – due to architecture component assignment

Initially a good decision, paid for it laterProcess consolidation at one site

Problem: timely feedbackDifferent environments in different sites

Change Control BoardInitially at one site – knew little about code at other siteLack of knowledge of the legacy system built onAdded architect from the other cite to CCB

12



IntegrationDocumentation of processes and design decisions

Technologies that were supposed to help did not meet expectationsDue to time pressures, proceeded with coding

Not an unusual state of affairsBUT, code diverged from designThis impacts integration significantly

Shift in role of documentationInitially, focus on designLater, oriented towards change management process

Documentation omissionsIn substrate docs – significant problemsIn project - also

13



Success BarriersLack of informal unplanned interactionNot knowing who to contact about what

Lack of necessary informationThe cost of initiating contact – high when distributed

Who is availableTime differencesLack of responsiveness

Ability to communicate effectivelyDifferent languages and culturesCommunication mediums – face to face vs phones, eg

Lack of trust/willingness to communicate openly

14



Towards Successful TeamsArchitecture centric –

Keep interfaces clean and distinctAs modular as possible

Need stable processesFront load travel

face to face to build trustTo create liaisons

Tools toFind organizational informationCheck availabilityEffective cross site meeting, planned and unplanned

15



A Common Syndrome in Business/Academia

Punish the competentReward the incompetentPromote the uninvolved (cartoon off just a bit here)

Documents

Collaborative Software Design & Development *Teams*

Collaborative Software Design & Development Teams