Lecture 6 1

Lecture 7

COM822J1: Project Management & Software

Quality Control

Lecture 6 2

Lecture 7 Motivation (Chapter 11)

Teamwork (Chapter 12)

Team structure (Chapter 13)

Steve McConnell, Rapid Development: Taming Wilde Software Projects, Microsoft Press, ISBN 1-55615-900-5, 1996

Chapter 11 3

Chapter 11

Motivation

Motivation 4

Motivation

Of the four dimensions of rapid development (people, process, product, technology) – people has the greatest potential to shorten software schedules across a variety of projects

“Motivation is undoubtedly the single greatest influence on how well people perform. Most productivity studies have found that motivation has a stronger influence on productivity than any other factor” (Boehm, 1981)

Motivation 5

… Motivation

Is a soft factor

Is difficult to quantify and measure

Is known to be an important factor But companies often don’t do anything about it

Knowledge about it is available

Typical Developer Motivation 6

Typical Developer Motivation

Typical Developer Motivation 7

… Programmers – public

More motivated by Possibility for growth Personal life Opportunity for technical

supervision Interpersonal relations with

their peers

Much less motivated by Status Interpersonal relationship to

subordinates Responsibility Recognition

Programmers – managers More motivated by

Possibility for growth Personal life Opportunity for technical

supervision

Much less motivated by responsibility

Recognition Interpersonal relationship

with subordinates

Top Five Motivation Factors For Developers

8

Top Five Motivation Factors For Developers

Achievement

Possibility for growth

Work itself

Personal life

Technical-supervision opportunity

Top Five Motivation Factors For Developers

9

… (Achievement) Ownership (buy-in)

People will work harder to achieve their own goals Let developers set their own schedules

Goal setting Avoid setting too many goals/objectives/priorities

Team performance ranked against objectives that teams were told to optimise (Source: Rapid Development - Taming Wilde Software Projects, McConnell, 1996).

Top Five Motivation Factors For Developers

10

… (Possibility For Growth) Software development

Is an exciting, constantly changing field You have to (can) learn every day

It is in an organisations best interest to help people determine how they wish to grow professionally

Short-term and long-term impacts and benefits

Possibilities for an organisation Providing tuition reimbursements for professional development classes Giving time off to attend classes or to study Providing reimbursements for purchase of professional books Assigning developers to projects that enhance their skills Assigning a mentor to each new developer Avoid excessive schedule pressure

Top Five Motivation Factors For Developers

11

… (Work Itself) Internal motivation comes from three sources

People need to experience meaning in their work Experience responsibility for the outcome of their work They must know the actual results of their work activities

Five dimensions of the work itself that can contribute to these three sources of motivation

Meaningfulness to people Skill variety (avoid boredom and fatigue) Task identity (requires you to complete a whole, identifiable piece of work) Task significance (how does your work affect others, social welfare)

Responsibility for outcome Autonomy (degree of control over means and methods you use to do your job)

Know about the result of work activities Job feedback (direct feedback how effective you are)

Opportunity to focus on the work itself (distractions such as administration)

Top Five Motivation Factors For Developers

12

… (Personal Life) Personal life is 4th most important factor for developers - but only 15th

for managers

Likely to be the hardest motivational factor for the manager to understand

Managers sometimes reward their best workers by assigning them to the highest-profile, highest-pressure projects

To a manager the extra responsibility would be a treat (reward) - personal life doesn’t matter that much for him

To the developer the diminished personal life is a loss (punishment)

Manager doesn’t have to understand the details why personal life is so important for the developer

All a company can do is Schedule projects realistically Respect vacation and holidays Be sensitive to requests for time off during the workday

Top Five Motivation Factors For Developers

13

… (Technical-Supervision Opportunity) For a developer a technical-supervision opportunity represents

an achievement There exists a level of expertise sufficient to direct others For a manager this might represent a step backwards

A manager is already supervising others and is probably happy to not getting involved into technical supervision

Tips Assign each person on a project to be the technical lead for a

particular product area (user-interface design, database connectivity, etc.)

Assign each person to be the technical lead for a particular process area (technical reviews, data conversion, installation, etc.)

Assign all but the most junior developers to be mentors

Other Motivation Factors 14

Other Motivation Factors Rewards and incentives

Developers grow tired of working for unappreciative companies

Rewards are therefore important for long-term motivation

It is important to present any reward as a gesture of appreciation rather than an incentive

A reward should be unexpected The work should be the motivator

and not the (expected) reward

Possible awards Recognition diners Conference sponsorship Cash bonuses Vacation-time bonuses

Pilot projects The Hawthorne Effect Run every project as an

experiment (pilot project) Try out some new methodology

in each project Inform the team that the

project is a pilot project

Performance reviews Is the single most important

form of task-relevant feedback supervisors can provide

Motivation Killers 15

Motivation Killers Hygiene factors

Management manipulation

Excessive schedule pressure

Lack of appreciation for development’s efforts

Inappropriate involvement of technically inept management

Not involving developers in decisions that affect them

Productivity barriers

Low quality

Heavy-handed motivation campaigns

Chapter 12 16

Chapter 12

Teamwork

Software Uses Of Teamwork 17

Software Uses Of Teamwork Team - a small group of people with complementary skills

who are committed to a common purpose, performance goals, and approach for which they hold themselves mutually responsible

Teaming up in software Developing and reviewing project’s requirements Designing difficult parts of the project Reviewing individuals developers designs and code Developing coding standards Coordinating work on related pieces of a project Testing of requirements and design Auditing of projects progress …

Teamwork’s Importance In Rapid Development

18

Teamwork’s Importance In Rapid Development Small projects versus large projects

Large projects are group efforts

Variations in team productivity 10/1 differences on individual productivity levels Team productivity

5/1 differences, different backgrounds and experience 2.5/1 differences, similar backgrounds and experience

Cohesiveness and performance Work hard, are focused on project goals, enjoy work Cohesiveness contributes more to productivity than individual

capabilities and experience do Contribution of a person’s to the cohesiveness of the team before their

individual capabilities

Creating A High-Performance Team

19

Creating A High-Performance Team A shared, elevating vision or

goal

A sense of team identity

A result driven structure

Competent team members

A commitment to the team

Mutual respect

Interdependence among team members

Effective communications

A sense of autonomy

A sense of empowerment

Small team size

A high level of enjoyment

Why Teams Fail 20

Why Teams Fail Lack of common vision

Lack of identity

Lack of recognition

Productivity roadblocks

Problem personnel

Ineffective communication

Lack of trust

Long-term Team Building 21

Long-term Team Building Higher productivity

Lower start-up costs

Lower risk of personnel problems

Less turnover

The idleness question

Teamwork Guidelines 22

Teamwork Guidelines

Source: Rapid Development -Taming Wilde Software Projects, McConnell, 1996.

Chapter 12 23

Chapter 13

Team Structure

Comments 24

Comments Even when you have skilled, motivated, hard-working people,

the wrong team structure can undercut their efforts instead of catapulting them to success

A poor team structure can increase development time, reduce quality, damage moral, increase turnover, and ultimately lead to project cancellation

Currently about on-third of all team projects are organised in ineffective ways

(Johns 1994)

Team Objectives And Team Structures

25

Team Objectives And Team Structures The first consideration is to determine the team’s broad

objectives

Problem resolution Focuses on solving a complex poorly defined problem

Creativity Aim of the team is to explore possibilities and alternatives

Tactical execution Team focuses on carrying out a well-defined plan

Team Objectives And Team Structures

26

…

Source: Rapid Development - Taming Wilde Software Projects, McConnell, 1996.

Additional Team Design Features

27

Additional Team Design Features There are four more team-structure features that seem to

characterise all kinds of efficiently functioning teams

Clear roles and accountabilities Every person in the team counts, knows what to do, and is accountable

for his/her work

Monitoring of individual performance and providing feedback Need for mechanisms for letting the team know whether their

performance is acceptable and in what way it needs improvement

Effective communication Information must be easily accessible, originate from reliable

resources, room for informal discussions/communication

Fact-based decision making E.g., avoid arbitrary, subjective, decision making

Team Models 28

Team Models Business team (all kinds of projects: problem resolution, creative,

tactical execution) Peer group headed by a technical lead Aside from technical lead all team members have equal status Technical lead is an active contributor, and is chosen on the basis of

technical experience rather than management skills

Chief programmer team (projects: creative, tactical execution) Some developers are (much) better than others The chief programmer drafts the entire specification, completes all the

design, writes the vast majority of the production code, and is virtually responsible for all of the decisions on a project

Backup programmers, research assistants

Skunkworks team (projects: creative) Group of talented, creative product developers Work in a facility free from bureaucratic restrictions Develop and innovate (creative, but poor visibility)

Team Models 29

… Feature team (projects: problem-resolution, creative)

Team organised according to features (printing, graphing, documentation) Responsibility for parts of the product’s functionality Hierarchical, reporting structure

Search and rescue team (projects: problem resolution) Focuses on solving a specific problem Requires specialised knowledge, skills

SWAT team (projects: tactical execution) Special weapons and tactics - skilled with advanced tools

Professional athletic team (projects: tactical execution) The manager operates more in the background The developers are the stars of the team Team members have highly specialised roles and so are critical for the success

of a project Highly specialised projects relevant to the individual strength of the team

members

Team Models 30

… Theatre team (projects: modern multimedia projects)

Central role is occupied by the director Individual team members are restricted in their creativity (interpret their

roles) You sign up for a (one) particular role Strong direction and a lot of negotiation about project roles Integrates strong individual contributions within a central vision on creative

projects

Large teams Special problems of communication and coordination Create small groups (teams) Appoint representatives to interact with each other

In reality we find a mixture, or the use of different team structures at different times or in parallel

Effectiveness Profile Of Team Lifecycle

31

Effectiveness Profile Of Team Lifecycle

Source: Project Management, H. Maylor, 1996

Lecture 6 Summary 32

Lecture Summary

This lecture was about Motivation Teamwork Team structure