Lecture 4 Teams

1. Lecture 4Teams CSCI – 3250 Software Engineering I Spring 2014 Bill Pine

2. Lecture Overview • Introduction • Divisibility and Brooks’ Law • Characteristics of a Good Team Member • Effective Groups • Consensus Taking • Group Organizations CSCI 3250

3. Introduction • Assigned Reading: Braude and Bernstein, Chapters 7 • Large products are the norm • Just adding developers is no solution • What is needed • Structure for management and control • The result? • Technical staff structure + management structure CSCI 3250

4. An Example • Suppose that you have a project • Estimated effort = 1 man-year • Estimated schedule = 2 people for 6 months • Customer says must be completed within 3 months • The answer is obvious • Bring 4 developers on the project CSCI 3250

5. An Example (cont) • Or is it obvious? • Without management, planning, control • Will likely take longer than 6 months rather than the desired 3 months • Will likely be of lower quality CSCI 3250

6. Divisibility of Effort • Consider two extremes of divisibility • If 1 man can pick a patch of strawberries in 5 days, 5 men can pick the same field in 1 day • If it takes a woman 9 months to produce a baby, 9 women cannot produce a baby in 1 month • Divisibility of effort in software development • Unlike baby production • It is possible to divide the effort • Unlike strawberry picking • Team members must interact in complex and meaningful ways, limiting the gains from divisibility CSCI 3250

7. Brooks’ Law • Suppose we have a project that is running a little behind schedule, what to do? • Add some more developers? • An opposing view Adding additional programming personnel to a team when the product is late has the effect of making the product even later – Frederick Brooks CSCI 3250

8. Software Divisibility • Suppose we need to code two classes, classB and classG, and have programmers: Burf and Ginger • What can go wrong? • Burf and Ginger code the same class • Burf codes classB and Ginger codes classG • classB uses classG, Burf invokes a method of classG • Wrong number of parameter • Wrong order to parameters • Wrong type of parameters CSCI 3250

9. Divisibility (cont) • The issue isn’t that Burf is an incompetent dweeb (although he may be) • The issues are planning, design, design specification, management, and communications • The successful software development organization • Provides effective support these issues CSCI 3250

10. Communications • A large number of project failures can be traced to poor communications • Anyone remember the three modes of project failure? • Cost of communications can be high • Communication is required in all project workflows CSCI 3250

11. Communication Paths • Consider a 6-member team • Total of 15 communications paths CSCI 3250

12. Communications Paths (cont) • The number of communications paths between n team members is n*(n-1) / 2 • Evaluate for a few values of n CSCI 3250

13. Communications Paths (cont) • For even a moderate group size of 50 people • With unconstrained communications • Chaos rules the project • The solution? • Provide a structured setting within which communications occurs • The structure will be chosen appropriate to the project and type of communication CSCI 3250

14. Why Do We Need Structure? • Groups will be a mixture of personality types, work styles and goals • The interaction within the mixture can lead to • Interpersonal strife • Wasted or duplicated effort • Loss of productivity • Group collapse • Guidelines are needed to address the issue of group dynamics CSCI 3250

15. A Few Observations on Effective Teams • Team work is important to produce a effective and efficient effort • Because of group dynamics, • The most effective team is not necessarily the most talented team • Effective teams are cohesive teams • Effective teams communicate efficiently • In particular, • Have focused, effective team meetings CSCI 3250

16. Team Exercise • What is the purpose of team meetings? • Why do you need an agenda? • Why are meeting notes essential? CSCI 3250

17. Characteristics of a Good Team Member • Accepts his share of responsibility • Does quality work in a timely fashion • Regularly attends team meetings • Listens to and respects opinions of other team members • Committed to team success • The bottom line • Is someone you would like to have on a future team CSCI 3250

18. Evaluation • Evaluate yourself and your teammates one a scale of 1 – 5 for each of the previous characteristics CSCI 3250

19. Ground Rules for Effective Groups • Point out assumptions, inferences, and question the rationale • Agree on common definition of important terms • Share all relevant information • Be specific, provide examples not just generalities • Focus on issues, not a pre-conceived position • If you disagree, disagree openly CSCI 3250

20. Ground Rules (cont) • Invite questions • Keep discussion focused • No “ad hominem” attacks • Participate actively • Perform self and group assessments, periodically • Take decisions by consensus • When appropriate CSCI 3250

21. Consensus Decisions • Consensus • A general agreement that is perceived as workable • Reflect common thinking of the group • All group members can accept and support • Universal support • Accepted without opposition or reservation • Produce mutual satisfaction CSCI 3250

22. Consensus Decisions Are Not • Majority rule • The opinion held by the strongest personality in the group • Morally or ethically objectionable to any member of the group CSCI 3250

23. When to Take a Consensus Decision • To determine operating ground rules • Resolve group conflicts • Identifying a problem • Analyzing the source of a problem • If the decision will have a major impact • To develop at a new goal or direction • To obtain group commitment to a new goal or direction CSCI 3250

24. How To Reach Consensus • Actively seek opinion of all before taking the decision • Identify all underlying assumptions • Consider all opinions before pushing your own • Don’t change your mind just to avoid conflict • Avoid “cop-out” decisions produced by • Vote • Coin toss • Averaging • Bargaining • Do not assume win/lose is the inevitable outcome CSCI 3250

25. Group Organization • Structures ranging from • A strict hierarchy, called the cathedral model • To • A dynamic collection of people, called the bazaar model • When viewed in terms of centralized “command and control” CSCI 3250

26. Group Organization (cont) • Bazaar Model • Decentralized control • Pure Democratic Team • Cathedral Model • Centralized control • Classic Chief Programmer Team CSCI 3250

27. Pure Democratic Model • The foundation for the pure democratic team is “egoless programming” • Egoless programming a term first coined by Gerald Weinberg in 1971 • Ego – Impedes the detection and removal of faults • Many programmers are attached to their code • See the code as an extension of themselves • With such an attachment • Programmers have a disincentive to try to find errors in their code CSCI 3250

28. Pure Democratic Model (cont) • Weinberg’s solution: Restructure the programming culture • Faults are recognized as an inevitable side effect of the process • The code belongs to the group and not the individual • To increase the quality of the code, each programmer encourages other programmers to find faults in his code • The other programmers welcome the opportunity to improve the code, not denigrate the original programmer • The focus is team identity and reputation CSCI 3250

29. Pure Democratic Model (cont) • Pure democratic team has • No single leader • Maximum size of approximately 10 people • Mutual respect, with all members working toward a common goal • Advantages • A great attitude toward fault removal • Are generally very productive • Works best when the project is very difficult CSCI 3250

30. Pure Democratic Model (cont) • Disadvantages • Upper organizational management has a hard time dealing with a pure democratic team • Requires that the team members be of roughly equal experience • Experienced programmers generally resent their code being inspected by “newbies” • Issue of communications paths CSCI 3250

31. Classic Chief Programmer Team • For the same team size • Only 5 comm. paths • At what expense? • The Chief Programmer is the focus, (read bottleneck) • Key aspects • Specialization • Hierarchy CSCI 3250

32. Chief Programmer • Successful manager and highly-skilled programmer • Performs the architectural design • Allocates coding among the team members • Writes the critical (or complex) sections of code • Handles all the interfacing issues • Reviews the work of the other team members • Is personally responsible for every line of code CSCI 3250

33. Backup Programmer • Necessary only because the chief programmer is human • The back-up programmer must be as competent as the chief programmer, in every way • Must know as much about the project as the chief programmer • Responsible for test case planning and other tasks, independent of the design process CSCI 3250

34. Programming Secretary • A highly skilled, well paid, central member of the chief programmer team • Responsible for maintaining the program production library (documentation of project), including: • Source code listings • JCL • Test data • Programmers hand their source code to the secretary who is responsible for: • Conversion to machine-readable form, • Compilation, linking, loading, execution, and running test cases • This is 1971, remember! CSCI 3250

35. Programmers • Do nothing but program • Write code only, no code or data entry • All other aspects are handled by the programming secretary CSCI 3250

36. The New York Times Project • Chief programmer—F. Terry Baker • Why is this relevant? • Project in Brief • To automate the clippings data bank (“morgue“) of TheNew York Times • 1971 • IBM • Showcase project of PL/I CSCI 3250

37. Times Project (cont) • 83,000 source lines of code (SLOC) • 22 calendar months • 11 man-years • At end of year one, only the file maintenance system had been written (12,000 SLOC – 14%) • Most of the code was written in the last 6 months • 21 faults • Detected in the first 5 weeks of acceptance testing • 25 additional faults • Detected in the first year of operation CSCI 3250

38. Times Project (cont) • The file maintenance system • Delivered 1 week after coding was completed • Operated 20 months before a single failure occurred • Almost half the subprograms • Were correct at first compilation • 200 to 400 lines of PL/I • Principal programmers averaged • One detected fault • 10,000 LOC per man-year CSCI 3250

39. Times Project (cont) • But, after this fantastic success • No comparable claims for chief programmer team concept have been made CSCI 3250

40. Why So Successful? • First and foremost - F. Terry Baker • Super programmer • Superb manager and leader • His skills, enthusiasm, and personality “carried” the project CSCI 3250

41. Why So Successful? (continued) • Second - a prestige project for IBM • First real trial for PL/I (developed by IBM) • IBM used its best people • Third - IBM provided strong technical backup • PL/I compiler writers were available to help the programmers • JCL experts assisted with the job control language • Fourth • See First CSCI 3250

42. Disadvantages of Chief Programmer Team • Chief programmer must be a highly skilled programmer and a successful manager • Highly skilled programmers are rare • Successful managers are rare • The skill sets of highly skilled programmers and highly skilled managers are so different that finding an individual with both sets is highly improbable • Back-up programmer must be as good as the chief programmer • But he must take a back seat (and a lower salary) waiting for something to happen to the chief programmer • Top programmers, top managers will not do that • Programming secretary does paperwork all day • Software professionals as a general rule, hate paperwork CSCI 3250

43. What To Do? • Pure Democratic or Hierarchical Structure • Neither organizational extreme is well suited for today’s large projects • Chaos will surely result if you try to implement a Pure Democratic Team for 100 members • Anyone think of an exception? • A single Chief Programmer is not capable of managing a team of 100 members • Not even F. Terry Baker CSCI 3250

44. What To Do? (cont) • Modern team organizations fall between the two extremes, attempting to meld the best features of both • One person cannot be personally responsible for each line of code • Use code reviews and code walkthroughs to move toward egoless programming • The Chief Programmer is responsible for the code • Must be present at the reviews and walkthroughs • Butthe Chief Programmer is also a manager, and • Must not be present at the reviews and walkthroughs CSCI 3250

45. What To Do? (cont) • Solution • Reduce the management responsibilities of the Chief Programmer and create a new management position responsible for non-technical management • Non-technical Management Responsibilities • Budgetary issues, • Legal issues, and • Performance appraisal • Good idea, since it is very difficult to find a single individual who is both an excellent manager and programmer CSCI 3250

46. What To Do? (cont) • What about larger projects? • Create a hierarchy of authority • A technical project manager over the project as a whole, with several team leaders CSCI 3250

47. What To Do? (cont) • Decentralize the decision-making process where appropriate • Useful where the democratic team is effective CSCI 3250

48. Corporate Structures • Three models for corporate organization • Functional Organization • Project-based organization • Matrix organization CSCI 3250

49. Functional Organization • Individuals are grouped by specialty into departments • Department of analysis • Department of designers • Programming department • … • Departments correspond to the core workflows of the process model the organization is using • The project is “passed from department to department” • Few individuals are involved throughout the project • Appropriate only for well defined projects where the number of changes is expected to be small CSCI 3250

50. Project-based Organization • Individuals are assigned to a project for the life of the project • Can be difficult to hold good people • Better able to handle change • Why? CSCI 3250