Lecture 7

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 Lecture 6

3. Chapter 11 Motivation Chapter 11

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 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 … Typical Developer Motivation

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. 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 … (Achievement) 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 Top Five Motivation Factors For Developers

14. 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 Other Motivation Factors Other Motivation Factors

15. 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 Motivation Killers Motivation Killers

16. Chapter 12 Teamwork Chapter 12

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 • … Software Uses Of Teamwork

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 Teamwork’s Importance In Rapid Development

19. 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 Creating A High-Performance Team Creating A High-Performance Team

20. Why Teams Fail • Lack of common vision • Lack of identity • Lack of recognition • Productivity roadblocks • Problem personnel • Ineffective communication • Lack of trust Why Teams Fail

21. Long-term Team Building • Higher productivity • Lower start-up costs • Lower risk of personnel problems • Less turnover • The idleness question Long-term Team Building

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

23. Chapter 13 Team Structure Chapter 12

24. Comments • Even when you have skilled, motivated, hard-working people, the wrong team structure can undercut their efforts instead of catapulting them to successA poor team structure can increase development time, reduce quality, damage moral, increase turnover, and ultimately lead to project cancellationCurrently about on-third of all team projects are organised in ineffective ways (Johns 1994) Comments

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. Team Objectives And Team Structures

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 Additional Team Design Features

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 Team Models

31. Effectiveness Profile Of Team Lifecycle Source: Project Management, H. Maylor, 1996 Effectiveness Profile Of Team Lifecycle

32. Lecture Summary • This lecture was about • Motivation • Teamwork • Team structure Lecture 6 Summary