COMP 325 Lecture 4: Teams and People
major resources: Introduction to Object Oriented Analysis, David Brown 2002, Object-Oriented and Classical Software Engineering 6ed, Schach 2005, Object-Oriented Software Engineering, Schach 2008.

[ previous | schedule | next ]

sensitivity and people issues

Many of you will have taken or are taking COMM 280 by now, tell me about it

What kind of issues are involved in communicating with clients and users?

• technophobia
• shy in group setting, even though knowledgeable
• uncooperative: may be in danger of losing job to your system
• maybe openly hostile
• maybe planning sabotage
• cultural differences
  e.g. some studies show that Latin Americans make more eye contact, face each other more, and touch more when they speak, compared to North Americans. other considerations are "personal space", exchange of pleasantries at the start of a meeting, etc. Here is a good introduction with exercises

• may not be familiar with same technologies
• may be much more, or less, experienced than you
• may be much more, or less, productive than you
• you may not trust him/her
• he/she may not trust you
• problems scheduling a time to meet

• fear, if things are not going well
• dislike or disrespect
• evidence or suspicion of favoritism

Team Building

• small in size
• possessing complementary skills
• commitment to common purpose
• specific goals
• members feel accountable to each other

• Study by IEEE shows optimum size for computer science student teams is 3 to 5.
• With 3 people, there are 3 possible pairwise communication lines; with 4 there are 6; with 5, 10.
  what is general formula for N people?
• team organization determines number of communication lines: democratic, hierarchical, chief programmer, XP

• Myers and Briggs four dimensions of personality with two values for each
• Introvert vs Extrovert
• iNtuitive vs Sensing
• Feeling vs Thinking
• Perceiving vs Judging
• yields 16 combinations, from INFP to ESTJ
• The second (N/S) and fourth (P/J)dimensions appear to be more important, as their four combinations match four personality types theorized by many philosophers and psychologists over the years
• SJ is highly organized and rule-oriented
• SP is impulsive and live-for-the-moment
• NF is feeling and rule-bending
• NT is thoughtful and scientific
• mixture on a team is good but all have to recognize the others' strengths and take advantage of them
• the complete Myers-Briggs test is long and not free, but there are scaled down versions available on the web
• As a lab exercise, we will do the following:
• Each of you will take the 72 question Jung Typology Test online at http://www.humanmetrics.com/#Jtype
• We will share and discuss the results, then form teams based on the results.
• All teams will complete the NASA "Lost on the Moon" team exercise online at http://nasa.perbang.dk/

• it is obvious that the mix of technical skills need to be appropriate for the task at hand

• see section above on communication issues
• listening skills ("2 ears and 1 mouth")
• reflective listening (also goes by other names)
• client makes statement or ask question
• you rephrase it using your own, different, words
• if client agrees that you understand, then you may proceed to answer or respond
• otherwise, repeat first two steps using different terms and phrases
• remember that client's head is normally in "problem domain" while yours may be in "solution domain"
• each person hears through their own frame of reference.
• the "seven habits of highly effective people" (see franklincovey.com )
• these skills are also good for conflict resolution
• tips for interviewing clients:
• upon introduction, greet person by making eye contact and repeating his/her name as given
• ask open-ended questions (as opposed to yes/no or short answer questions)
• ask one question at a time
• to learn how things are done, ask about specific instances in the past, not just hypothetical "what would you do if..."

• team must agree to common purpose, to achieve commitment
• team must then identify specific performance goals toward that purpose
• goal must require something to be done
• goal (and progress toward it) must be measurable
• goal must have a date
• such goals promote good communication, commitment, and sense of achievement

Team Dynamics

teams typically follow predictable sequence of experiences over time

• Forming - very emotional: excitement, fear, confusion, anticipation
• Storming - also very emotional: argue over task, competition, turmoil, threatened mutiny
• Norming - start to agree on task at head, hierarchy settled, growing cohesion
• Performing - making progress, everyone knows role, getting to know and be comfortable with colleagues, able to resolve conflicts

Team Structures

team structure affects number and complexity of communication channels

there are many models for software development teams, here are a few

Democratic

• no defined leaders or hierarchy
• very loose organization, many communication channels
• based on egoless programming
• programmer attitude crucial: willingness to have others review "your" code
• reviewer attitude crucial; must not consider code faults to be programmer weakness
• leads to team ownership of code
• all working toward common goals
• does not scale up well

• Strict organizational structure, highly formalized
• Clear leadership through Chief Programmer; all others report to Chief
• Specialization through functional separation
• Roles are:
• Chief Programmer: manages project, designs software architecture, implements critical parts of the software, makes all major technical decisions and delegates work to other team members.
• Assistant Chief: Consults chief programmer on technical matters and serves as backup to the chief programmer.
• Librarian: Maintains program listings and other documentation. a.k.a. Secretary
• 2-5 Programmers: Implement design, document code and carry out testing.
• major downside is finding CP and AC with both technical and nontechnical management skills

• Compromise between the democratic and chief-programmer structures.
• Separates technical management and nontechnical management
• Team Manager: manages nontechnical aspects such as budgets, personnel issues, performance appraisals
• Team Leader: manages technical aspects such as schedules, reviews, major technical decisions
• programmers report to team manager
• many tech companies provide "dual ladder" promotion track based on this structure
• This can scale up to larger by adding additional management layer above both. Example for technical management:
• Project Leader: Responsible for major decisions, assigns tasks, participates in evaluations and performs technical duties as a member of a technical group
• Team Leaders: In charge of one or more separate aspects of system development. Reports directly to project leader and communicates with other team leaders.

The major organization in Agile is pair programming

• two programmers working together at the same keyboard
• one is driver the other is navigator; they switch roles periodically
• unit of work is the task, which could be a method or class
• XP is test-driven, one of the pair can prepare test cases then the other composes code based on those cases
• programming pair is a resiliant organization; if one leaves suddenly there is minimal project knowledge loss, e.g. the other can quickly bring replacement up to speed
• working in pairs is a good way to learn

Synchronize and Stabilize Teams (Microsoft)

• builds produced by teams working in parallel
• each team has manager, 3-8 developers, 3-8 testers
• each team is given free reign within constraints of specification and nightly synchronize
• Code for nightly synchronize has to work correctly (as determined by tests) even if partially completed