EE493.15 TeamOrganization References:HvV 5.2

1
EE493.15 Team Organization ReferencesHvV 5.2
Royal Military College of Canada Electrical and
Computer Engineering

• Professor Greg Phillips
• Greg.Phillips_at_rmc.ca
• 1-613-541-6000 ext. 6656

Major JW Paul Jeff.Paul_at_rmc.ca 1-613-541-6000
ext. 6091
2
The daily journal of a ..
3
A Dogs Diary

• 800  am Oh Boy! Dog food!   My favourite!930 
  am Oh Boy! A  car ride!   My favourite940 
  am Oh Boy! A  walk!   My favourite!1030  am Oh
  Boy! A  car ride!   My favourite!1130  am Oh
  Boy! Dog food!   My favourite!1200noon Oh Boy!
  Kids!   My favourite!100  pm Oh Boy! The
  garden!   My favourite!400  pm Oh Boy! Kids!  
  My favourite!500  pm Oh Boy! Dog food!   My
  favourite!530  pm Oh Boy! Mom!   My
  favourite600  pm Oh Boy! Playing ball!   My
  favourite!630  pm Oh Boy! Sleeping in mom's
  bed!   My favourite!

4
A Cats Diary Day 183 of My Captivity

• My captors continue to taunt me with bizarre
  little dangling objects. They dine lavishly on
  fresh meat, while I am forced to eat dry cereal.
  The only thing that keeps me going is the hope of
  escape, and the mild satisfaction I get from
  ruining the occasional piece of furniture.
  Tomorrow I may eat another houseplant.
• Today my attempt to kill my captors by weaving
  around their feet while they were walking almost
  succeededmust try this at the top of the
  stairs.I am convinced the other captives are
  flunkies and maybe snitches. The dog is
  routinely released and seems more than happy to
  return. He is obviously a half-wit.  The bird,
  on the other hand, has got to be an
  informant and speaks with them regularly.    I am
  certain he reports my every move.Due to his
  current placement in the metal room, his safety
  is assured.But I can wait it is only a matter
  of time...

5
Review

• The essential quality of software
• intellectual problem
• Currently cannot order a solution
• analysis design implementation
• Motivation

• Developers
• 1. Achievement
• 2. Possibility for growth
• 3. The work itself
• 4. Personal life (15)
• 5. Opportunity for technical supervision (13)

Managers 1. Responsibility (10) 2. Achievement 3.
The work itself 4. Recognition (8) 5. Possibility
for growth
6
Todays Class

• More on Individuals
• Line of Business Organizations
• Software Team Organizational Structures
• Selecting the Right Organizational Structure

7
Individuals
8
The Productivity Paradox

• an often used measure of productivity is
  SLOC/month
• this implies that to increase productivity you
  should produce as much code as possible
• however, recall that the primary cost driver is
  SLOC, implying that writing less code is cheaper
• this measure will therefore discourage good
  design practices and software reuse
• a better measure is therefore based upon
  functionality produced per unit time

9
The Quality Paradox

• software work products are frequently assessed
  for conformance or quality in group forums as
  part of verification and validation activities
• examples peer reviews (code and documents), code
  inspections, walkthroughs
• it is critical to all involved that what is being
  assessed is the product and not the individual
• if the individual is also being evaluated
  formally, or otherwise, the process breaks down -
  the quality benefits of the reviews are
  eventually lost
• therefore assessment of the individual must not
  be based upon the results of these processes

10
Morale Killers

• Hygiene factors not being met
• Management manipulation
• Management fads
• Excessive schedule pressure
• Lack of appreciation for developers efforts
• Inappropriate involvement of technically inept
  managers
• No involvment in decisions that affect them
• Productivity barriers
• Low quality
• Heavy-handed motivational campaigns

Ref Any Dilbert Cartoon...
11
Teamwork
12
The Importance of the Team

• numerous studies have shown that team capability
  has a disproportionate impact upon project
  productivity
• therefore getting the team composition and
  management right is critical
• factors such as morale, group norms and
  management style are more influential
  productivity drivers than say the use of higher
  level languages and product complexity

The human elements outweigh the technology
elements.
13
Types of Teams
14
Line-of-Business versus Project Organizations

• most studies of software engineering focus solely
  on the project organizational structures
• recognizing software functions within traditional
  line-of business hierarchies, emphasizes the
  important role that corporate policy and strategy
  has with respect to the success of software
  projects
• there is a requirement for staff / corporate
  bodies outside the selfish project office
• a project offices timeframe is too short

15
Line-of-Business Organizational Structure
(typical)
16
Hierarchical Organization

• distinct layers of workers versus managers
• suitable for production of software
• often designed according to the structure of the
  system
• often includes functional sub-teams responsible
  for project wide areas of responsibility
• examples CM, testing, QA
• coordination at the project level, generally
  based upon standardization of process or
  standardization of work products
• particular subsystems may dictate other styles

17
Hierarchical Disadvantages

• specific knowledge and real work is at the bottom
  of the pyramid while power and decision making is
  at the top
• translation of information from top to bottom is
  often a lossy communications channel
• separating project evaluation form personal
  evaluation is difficult / challenging
• the Peter Principal - a person is promoted to
  their level of incompetence
• different skills are required at each level
• promotion may not be a suitable reward

18
Matrix Organization

• employees act as corporate consultants, working
  on multiple teams at the same time
• a project team consists of a team core
  supplemented with matrix specialists
• matrix groups are usually formed based upon some
  common specialization
• examples GUI, databases, reliability, estimation
• coordination coordination of the matrix tasks is
  most closely aligned with the standardization of
  worker skills paradigm

19
Matrix Disadvantages

• requires a high degree of trust and cooperation
  between matrix managers and project managers
• project manager goals are selfish short term
  project goals
• matrix manager goals are longer term corporate
  positioning goals
• workers may feel like they have multiple bosses
  and are constantly being pulled in different
  directions
• loyalty isnt always obvious - who do they really
  work for?

20
Chief Programmer Team

• the equivalent of surgeon teams, but in software
• very small team sizes
• has a kernel of three people
• chief programmer - team leader, designer key
  programmer (competent technically and
  managerially)
• assistant - 2 I/C
• librarian - project administration and
  documentation, may be a junior programmer
  (trainee)
• coordination given the small team size and the
  predominance of the chief programmer, direct
  supervision is likely to be the means of
  coordinating tasks

21
Chief Programmer Disadvantages

• elitist
• may lead to friction between Chief Programmer run
  teams and other styles of projects within a
  company
• where are you going to find enough good chief
  programmers?
• it is frequently the case that the best
  programmers make poor managers
• what happens if other team members challenge the
  decisions / competence of the chief?

22
Skilled With Advanced Tools - SWAT Team

• usually only employed in an evolutionary or
  iterative development setting
• relatively small team (4-5 members- co-located)
• build increments of software systems
• employ whiteboarding / brainstorming techniques,
  component construction, high-level languages
  software generators
• supported often by GroupWare / workflow tools
• SWAT team leader more like a foreman
• team members generally multi-skilled
• coordination a mix of standardization of process
  (tied to tools) and mutual adjustment

23
SWAT Disadvantages

• relies heavily upon the motivation and
  cooperation of the team
• implies keeping everyone motivated
• implies everyone gets along well
• both are difficult to maintain over an extended
  period of time
• may not scale well
• how do you coordinate multiple SWAT teams towards
  a larger common goal
• requires consistency of tools

24
Open Structured Team

• combination of an open management style (to
  encourage innovation) with control structures (to
  ensure a timely execution)
• open management
• internal decisions are arrived by consensus
• technical team leader responsible for external
  controls and unresolved decisions
• all other team roles rotate among the team
• structure
• technical team leader ensures forward motion
• all proceedings recorded (products, process,
  decisions)
• coordination is by definition one of mutual
  adjustment

25
Open Structured Disadvantages

• decision making is by majority voting
• this can split the team into factions
• minority groups may reject ownership of decisions
• selection of technical leader is a sensitive
  issue
• the style is applied in situations where the
  requirement for innovation is high selection of
  a technical leader not supported by the group
  members will likely stifle innovation

26
Selecting the right Organizational Structure

• use fewer, better people
• small teams are more productive
• large groups require greater degrees of
  communication, leading to lower individual
  productivity and higher error rates
• strive for balance and harmony
• select a well rounded team
• do not attempt to assemble a team of stars
• look for good fits

27
Selecting the right Organizational Structure

• accommodate personal growth
• reverse Peter Principle - a person rises to a
  level where they are indispensable
• the Paul Principle - a person rises to a level
  where their skills quickly become obsolete
• remove those who dont fit
• if someone clearly does not work well within the
  group, quickly remove them before they sour the
  remaining team

28
Supplemental References

• Royce, Walker, Software Project Management - A
  Unified Framework, Addison-Wesley, 1998. ISBN
  0-201-30958-0

29
Next Class

• Monday - Discussion From Craft to Science
• MIDTERM (covers everything to end of discussion)
• your choice Friday 5 Mar
  or
  Monday 8 Mar
• Iteration 2 discussion - Tuesday 9 Mar

30
Next ClassConfiguration Management