Team

• Team Development
• Building Trust
• Managing Conflict
• Embracing Accountability
• Team Models
• Managing People

“Software projects fail for one of two general reasons: the project team lacks the knowledge to conduct a software project successfully, or the project team lacks the resolve^① (determination, commitment, mental toughness) to conduct a project effectively.”

• Steve C McConnell, Author of “code complete”

• Trust is the foundation of teamwork (Without trust, teams struggle to collaborate, share ideas, or resolve conflict)^①
• Trust is all about vulnerability, which is difficult for most people: Vulnerability-based trust means: Admitting mistakes, Asking for help, Saying “I don’t know”^②
• Takes time (Trust isn’t built overnight. It requires: Consistent behavior, Follow-through on commitments, Shared experiences—especially under pressure)
• Needs to be maintained over time.
• Techniques – Behavioral profiling (like Myers-Briggs). Helps to admit strengths & weaknesses: (Ex: Recognize their introverted tendencies, Adjust task assignments to match their strengths, Create a psychologically safe space for participation)^③

• A solid basis for trust is earned, not granted
  • Most human beings in most situations are inherently wary of others^①
• Maintain open communication within the project team– communication barriers create project risks
• Be fallible. Take responsibility for making mistakes, correct them, and make it clear how you plan to avoid these mistakes in the future
• Lead by example rather than by mandate. Show the team what you expect from yourself and from them
• Complete all your commitments on time. If you cannot do so, give adequate notice and an explanation, not an excuse
• Don’t confuse friendship with leadership^②

• Good (healthy) conflict among team members requires trust, which is all about engaging in unfiltered, passionate debate around issues.^①
• Even among the best teams, conflict will at times be uncomfortable.
• Conflict norms will vary in each team, and must be discussed and made clear:
  • Norms = rules of engagement: These define what’s acceptable in debate—tone, language, timing, emotional expression.
• The fear of occasional personal conflict should not deter a team from having regular, productive debate:
  • Avoidance is costly: Teams that fear conflict often fall into groupthink (psychological phenomenon where a cohesive group prioritizes harmony and consensus over critical thinking and realistic decision-making), suppress dissent (actively prevent or silence disagreement, criticism, or opposition), or make poor decisions.^②

• Conflict Resolution Techniques
  • Confronting (Problem Solving): Resolve the root cause through open, honest dialogue
  • Compromising: Reach a middle ground by mutual concessions
  • Withdrawal (Avoidance): Delay or sidestep the conflict
  • Smoothing (Accommodating): Preserve harmony by downplaying differences
  • Collaborating: Integrate multiple perspectives to find a creative solution
  • Forcing: Impose a solution through authority or pressure^①
• Problem Solving

1. Define the real/root problem
2. Analyze the problem
3. Identify Solutions
4. Pick a Solution
5. Implement a solution
6. Review the solution, and confirm that it solved the problem^②

• Every team encounters conflict: successful teams resolve conflicts, while unsuccessful teams force conflict to the background
• Disagreement is not the same as conflict: conflict involves a hardening of position and associated intractability (insolvability)^①
• Virtually all conflicts can be traced to a clash between two parties
• To preserve a team’s effectiveness, those outside the conflict must assume a neutral stance, even if they themselves agree with one of the parties to the conflict
• One of those outside the conflict must take on the role of conciliator^②; he or she must mediate between the two parties to defuse the situation
• The goal is to reduce the conflict to a disagreement which can then be addressed through consensus
• Strive for reconciliation between the conflicting parties, if possible

• Commitment requires clarity & buy-in:
  • Clarity ensures everyone knows exactly what was decided, why it matters, and what’s expected next.^①
  • Buy-in means team members support the decision—even if they didn’t fully agree—because they trust the process and feel heard.
• Clarity requires that teams avoid assumptions and ambiguity, and end discussions with a clear understanding about what they’ve decided upon.
• Buy-in does not require consensus. Members of great teams learn to disagree with one another and still commit to a decision.^②

• Accountability on a strong team occurs directly among peers: In high-performing teams, members don’t just rely on the manager to enforce standards—they hold each other accountable.^①
• For a culture of accountability to thrive, a leader must demonstrate a willingness to confront accountability: A project manager should model transparency, follow through on commitments, and address underperformance respectfully but firmly.
• Best opportunity occurs during meetings and regular review of accomplishments. Example: During a sprint review, the PM might say, “ We committed to five stories but completed three. Let’s explore what happened and how we can improve next sprint.^② ”

• A resource planning tool
• Who does What
• Can be for both planning and tracking
• Identify authority, accountability, responsibility
• Who: can be individual, team or department
• Can have totals/summary at end of row or column (ex: total Contributors on a task)^①

• The true measure of a great team is that it accomplishes the results it sets out to achieve.
• To avoid distractions, team members must prioritize the results of the team over their individual or organizational (dept) needs.
• To stay focused, team must publicly clarify their desired results and keep them visible.^①

• Two early philosophies
  • Decentralized/democratic
  • Centralized/autocratic
• Variation
  • Controlled Decentralized^①

• Business Team : commonly used in software projects and general business environments.
  • Most common model^①
  • Technical lead + team (rest of team at equal status)
  • Hierarchical with one principal contact
  • Can be strong (The lead has clear authority and control) or loose hierarchy (The lead facilitates rather than commands—more collaborative)
  • Adaptable and general
  • Variation: Democratic Team
    • All decisions made by whole team
    • The Business Team is often the default starting point—especially in structured environments. But as teams mature, gain trust, and develop shared norms, they may evolve toward a Democratic Team model.^②

• The group acts as a whole and comes to a consensus on decisions affecting the system
• The group leader serves as the external interface of the group but does not allocate specific work items^①
• Rather, work is discussed by the group as a whole and tasks are allocated according to ability and experience
• This approach is successful for groups where all members are experienced and competent
• Sometimes known as self-organizing teams.^②

• Agile programming groups are variants of democratic organization
• In Agile programming groups, some ‘management’ decisions are delegated to group members
• In XP, Programmers work in pairs and take a collective responsibility for code that is developed^①

Chief-Programmer Team a.k.a. ‘surgical team’, from IBM in the 70’s: puts a superstar at the top. Just as a surgeon performs the critical operation while being supported by anesthetists, nurses, and technicians, the chief programmer writes the core code while being supported by a carefully selected team of specialists.^①

• Backup Programmer/co-pilot (Equally skilled—ready to step in if needed, often reviews or shadows the chief.)
• Program Clerk (Manages documentation, version control, and technical records.)
• Administrator (Handles administrative tasks, freeing technical staff to focus on development.)
• Tool-smith (Builds and maintains development tools and environments.)
• “Language lawyer” (Deep expert in the programming language(s) used—consulted for tricky syntax or semantics.)

• Issues: Difficult to achieve, Ego issues: superstar and/or team^②
• Can be appropriate for creative projects or tactical execution

• Consist of a kernel of specialists helped by others added to the project as required
• The motivation behind their development is the wide difference in ability in different programmers
• Chief programmer teams provide a supporting environment for very able programmers to be responsible for most of the system development^①

• This chief programmer approach, in different forms, has undoubtedly been successful
• However, it suffers from a number of problems
  • Talented designers and programmers are hard to find. Without exceptional people in these roles, the approach will fail
  • Other group members may resent the chief programmer taking the credit for success so may deliberately undermine his/her role.
  • High project risk as the project will fail if both the chief and deputy programmer are unavailable
  • Organizational structures and grades may be unable to accommodate this type of group^①

• Skunk works Team
  • Put a bunch of talented, creative developers away from the mother ship
    • Off-site literally or figuratively
  • Pro: Creates high ownership & buy-in
  • Con: Little visibility into team progress
  • Applicable: exploratory projects needing creativity
    • Not on well-defined or narrow problem^①
• SWAT Team
  • Highly skilled team
  • Skills tightly match goal
  • Members often work together
  • Ex: security swat team, Oracle performance team^②

• Large teams
  • Communication increases multiplicatively
    • Square of the number of people
    • 50 programmers = 1200 possible paths^①
    • Communication must be formalized
  • Always use a hierarchy
  • Reduce units to optimal team sizes
    • Always less than 10 (seven plus or minus one)
• What is the optimal team size?
  • 4-6 developers^②
    • Tech lead + developers
  • Small projects inspire stronger identification
  • Increases cohesiveness
  • QA, ops, and design on top of this

• People are an organization’s most important assets
• The tasks of a manager are essentially people oriented. Unless there is some understanding of people, management will be unsuccessful^①

• Problem solving (using available people)
• Motivating (people who work on a project)
• Planning (what people are going to do)
• Estimating (how fast people will work)
• Controlling (people’s activities)
• Organizing (the way in which people work)^①

• People’s Motivations depend on satisfying needs
• It can be assumed that physiological and safety needs are satisfied
• Social, esteem and self-realization (self-actualization) needs are most significant from a managerial viewpoint^①
• If a lower set of needs is continually unmet for an extended period of time, the individual will temporarily shift focus downwards those needs – dropping down to that level until those lower needs are reasonably satisfied again.^②

• Social
  • Provide communal facilities (shared spaces, break rooms, collaborative zones, etc.)
  • Allow informal communications (support casual conversations, team chats, non-work-related exchanges such as during lunch, etc.)
• Esteem
  • Recognition of achievements
  • Appropriate rewards (bonuses, promotions, certificates, symbolic gestures, etc.)
• Self-realization
  • Training – people want to learn more
  • Responsibility (empower team members to make decisions)^①

• The needs hierarchy is almost certainly an over-simplification
• Motivation should also take into account different personality types:
  • Task-oriented
    • The motivation for doing the work is the work itself
  • Self-oriented
    • The work is a means to an end which is the achievement of individual goals – e.g. to get rich, to buy a house, to travel etc.
  • Interaction-oriented
    • The principal motivation is the presence and actions of co-workers.
    • People go to work because they like to go to work^①

• Individual motivations are made up of elements of each class (from previous slide).
• Balance can change depending on personal circumstances and external events
• However, people are not just motivated by personal factors but also by being part of a group and culture.
• People go to work also because they are motivated by the people that they work with^①

• Most software engineering is a group activity
  • The development schedule for most non-trivial software projects is such that they cannot be completed by one person working alone
• Group interaction is a key determinant of group performance
• Flexibility in group composition is limited
  • Managers must do the best they can with available people^①

• Group composed of members who share the same motivation can be problematic:
  • Task-oriented – everyone wants to do their own thing
  • Self-oriented – everyone wants to be the boss
  • Interaction-oriented – too much chatting, not enough work
• An effective group has a balance of all types
• Can be difficult to achieve because most engineers are task-oriented^①

• Leadership depends on respect not titular status (titular = holding a title)^①
• There may be both a technical and an administrative leader
• Democratic leadership is more effective than autocratic leadership
• A career path based on technical competence should be supported

• In a cohesive group, members consider the group to be more important than any individual in it
• Advantages of a cohesive group are:
  • Group quality standards can be developed
  • Group members work closely together so inhibitions caused by ignorance are reduced
  • Team members learn from each other and get to know each other’s work
  • Egoless programming where members strive to improve each other’s programs can be practiced^①

• Cohesiveness is influenced by factors such as the organizational culture and the personalities in the group
• Cohesiveness can be encouraged through
  • Social events, such as team outings
  • Developing a group identity and territory
  • Explicit team-building activities
• Openness with information is a simple way of ensuring all group members feel part of the group^①

• Group members tend to be loyal to cohesive groups
• 'Groupthink’ is preservation of group irrespective of technical or organizational considerations
• Management should act positively to avoid groupthink by forcing external involvement with each group^①

• Good communications are essential for effective group working
• Information must be exchanged on the status of work, design decisions and changes to previous decisions
• Good communications also strengthens group cohesion as it promotes understanding

Notes:

• Status of group members
  • Higher status members tend to dominate conversations
• Personalities in groups
  • Too many people of the same personality type can be a problem
• Communication channels
  • Communications channelled though a central coordinator tend to be ineffective^①

• Software engineering group sizes should be relatively small (< 10 members) optimal is less than seven (see previous slides)
• Break big projects down into multiple smaller projects
• Small teams may be organized in an informal, democratic way
• Chief programmer teams try to make the most effective use of skills and experience^①

• Choosing people to work on a project is a major managerial responsibility
• Appointment decisions are usually based on
  • information provided by the candidate (their resume or CV)
  • information gained at an interview
  • Interviews with potential co-workers
  • recommendations from other people who know the candidate
• Some companies use psychological or aptitude tests
  • There is no agreement on whether or not these tests are actually useful^①

• Physical workplace provision has an important effect on individual productivity and satisfaction
  • Comfort
  • Privacy [see next slide]
  • Facilities
• Health and safety considerations must be taken into account
  • Lighting
  • Heating
  • Furniture^①

• Privacy – each engineer requires an area for uninterrupted work (see next slide)
• Outside awareness – people prefer to work in natural light
• Personalization – individuals adopt different working practices and like to organize their environment in different ways^①

• Workspaces should provide private spaces where people can work without interruption
  • Providing individual offices for staff has been shown to increase productivity^①
• However, teams working together also require spaces where formal and informal meetings can be held

• The phrase ‘human resources’ has its origins as an economic and corporate asset term
• These origins lead to two semantic problems:
  • People are (to some extent) considered in the same light as inanimate resources: “maximizing the ROI in human capital is the goal of HR management”
  • People are considered (to some extent) as being uniform, interchangeable, and expendable^①
• To improve the chances of project success, the project manager should ensure that he views and acts with his team members as “collaborators”, “stakeholders”, “teammates” by recognizing and nurturing their individual talent and fostering psychological safety and team cohesion.^②

• The project manager must develop people skills in a number of related areas:
  • Interpersonal skills
  • Shaping project culture
  • Managing people
  • Making people better
  • Leadership^①

• The project manager needs a well-developed set of interpersonal skills in order to effectively manage a project
• Effective communication .
  • Follows a defined protocol: structured channels and formats (e.g., status reports, stand-ups, escalation paths). This ensures clarity and consistency.
  • Reaches all recipients in a timely manner
  • Provides all the information necessary, no more or no less^①
• Influencing the organization . The ability to get a project completed depends on the abilities of and respect for the PM and PM team (influence, negotiate, and build credibility)
• Leadership: is one of the most misunderstood concepts in project management–leadership has little to do with authority: it’s about inspiring, guiding, and aligning people toward a shared goal^②

• Motivation . Providing people with incentives to act in the interest of the project and overcome inevitable challenges
  • Motivation comes in a number of forms; studies show financial incentives are among the least effective motivators^①
• Negotiation and conflict management . Working with others to come to agreement and overcome differences, real or perceived
  • Reaching consensus and defusing conflict are two elements of these skills
• Problem solving . Being able to recognize and define problems; formulate, evaluate, and make decisions regarding possible solutions
  • Problem solving is a skill that can be learned but requires practice: progressive elaboration helps manage the complexity of most project problems

• The project manager must shape the project culture within the broader context of the framework of the organizational culture
• Understand organizational culture
  • Understanding the attitude of the organization toward the project and toward project management processes is essential (Every organization has its own values, norms, and attitudes toward projects—some embrace structured methodologies, others prefer informal or ad hoc approaches)
  • Organization attitudes toward real– as opposed to fanciful–project management practices varies widely (practices that exist in theory but not in reality )
• Understand each team member’s engineering and personal background
  • Education, experience, generation, and personality all determine what roles the person may take and how they will fit in with the rest of the team
• Assess each team member’s cultural role or roles and match this to their project role^①

• Match cultural and project roles to people
• Representative cultural roles include:
  • Leader (Takes initiative, inspires others)
  • Listener/talker (Facilitates communication, bridges gaps)
  • Complainer/naysayer (who habitually expresses negative or skeptical views: Raises concerns, challenges assumptions)
  • Expert (Offers deep knowledge and credibility)
  • Charger/plodder (Pushes forward with energy)^①
• Significant project roles include:
  • Project manager . Guides the team planning and tracks progress against the plan
  • Team leader . Builds and maintains an effective team
  • Development leader . Produces a superior product
• Remain non-judgmental: every cultural role has potential value for the team^②

• Cultural and social factors
  • Projects are planned and implemented in a social and cultural context
  • Some factors that will influence a project might be: economic, educational, ethical, ethnic, and religious
  • These factors can affect the authority of the project manager^①
• International and political
  • As globalization expands, familiarity with local laws and customs is essential for effective project management
  • Shifting international, national, and local political factors can have dramatic influences on a project
  • Some mundane factors that will influence a project might be: time zone differences, holidays, travel requirements, teleconferencing capabilities^②

• Monitor and manage team culture as you would manage technical issues
  • Make each person’s project role clear
  • Understand each person’s personality and make known your understanding of each person’s social role in a positive way
  • State and maintain your view of the team
    • Example: “we are all equals in this team, but if a critical situation arises, I will make the decision.”^①
• Recognize potential cultural role problems before they have a negative impact on the team (A dominant voice silencing others, A skeptic undermining morale)
• Solve project role problems before they have a negative impact on the project

• Monitor team members’ satisfaction with their role.
  • You will need to monitor team role satisfaction throughout the project.
  • It is especially important during project launch when roles can be changed easily.
• Monitor the engineering task-to-people fit to make sure each person can perform the engineering task.
  • Role mismatches lead to project problems and schedule slip.^①
  • If you don’t review task-to-people fit, you will be unaware of each person’s ability, or lack thereof, to perform tasks.
• Monitor the cultural climate of the team as a whole.
  • Monitor project culture by watching and listening to each team member.
  • Guide the cultural views of the project by your own example.
  • You need to be able to monitor the team culture throughout the project in order to build confident people and a confident team.

• The main problems of our work are not so much technological as sociological in nature^①
• (optional reading) One of the most enlightened sources for information about managing people is: Peopleware: Productive Projects and Teams , Third Edition,
• Most technical managers come from technical backgrounds and manage that way as if they are solving an engineering problem
• Most managers do not consider individual idiosyncrasies (personal strange habit), yet these can make or break a project

Guidelines for Managing People:

• Gain visibility without micromanagement.
• Review process and products, not people.^①
  • Say: “This testing regime allows too many bugs to slip through to the customer; what can we do to correct this?”
  • Not: “You all don’t seem to know how to write unit tests properly.”
• Coordinate, don’t manipulate.
• Use your knowledge, not your position of power.
• Channel people, don’t put dams in front of them.
  • Redirect misplaced energy or effort, don’t cut it off
• Focus on project and people needs, not your authority as manager.
  • This will maintain your leadership role without explicit effort^②

• The application of production line efficiency principles to thought workers can be a sign of disaster for a project
• Common errors include:
  • Squeeze out error – make the ‘machine’ run as smoothly as possible
  • Take a hard line about people goofing off on the job (Assuming that any non-visible output equals laziness: creative people need time to reflect)
  • Treat workers as interchangeable pieces of the machine
  • Optimize the steady state – don’t worry about start up and shut down
  • Standardize procedure – run by the book (rigid processes)
  • Eliminate experimentation (Discouraging trial-and-error or creative risk-taking)^①
• Consider how each of these errors might impact your own work

• Make professional development a project goal
• Recognize long- and short-term development goals
  • Short-term goals focus on skills needed for the project
  • Long-term goals prepare team members for future projects
• Let each team member specify personal improvement goals
  • Starting point: Competency framework goals such as: Technical, leadership, domain, general/personal, communication, and management
• For a fixed interval, have team members track their individual time expenditure in detail
  • This concept goes well beyond the weekly timesheet concept
  • This is an awareness-building activity, not a monitoring activity
  • The Personal Software Process (PSP) is a formal application of this idea^①

• Have team members track their individual time
  • Goes beyond the weekly timesheet concept
• One formal approach to this is the Personal Software Process (PSP) which shows developers how to:
  • Manage the quality of their projects
  • Make commitments they can meet
  • Improve estimating and planning
  • Reduce defects in their products^①
• One element of PSP is to track daily time spent on all project-related tasks: reading, writing, meetings, training, requirements, design, coding, testing, deployment, e-mail, phone.

• Leadership is the capacity to mobilize a group to solve the most challenging problems ( wrong to think that leadership is about authority )^①
• Two types of leadership:
  • Technical leadership (a.k.a. authority ) motivates people when the problem can be solved by known means: the leader directs, instructs and applies best practices.
  • Adaptive leadership motivates people to solve problems that cannot be solved by known means ( needed when the problem is complex or novel )
    • Requires learning on the part of the leader as well as the group (facilitate learning and research)
    • Often involves leading with good questions (provoke thinking, guide inquiry)
    • Requires a deep clarity of purpose (to keep the team anchored toward its goals) : Example: during brainstorming meetings, the leader is the one that needs to stop the conversation from diverging to unimportant arguments, problems and bring the discussion back to the essential questions.^②

• Need to be aware of which kind of leadership is needed and choose between technical leadership and adaptive leadership for a project based on whether the problem can be solved by known means or not.^①
• Most IT projects have a mix of known and unknown problems.
• An adaptive leader can address known problems by delegation –allow one who can lead the team in solving the problem by known means do so when appropriate^②

• Consensus simply means ‘general agreement’. But in the context of project teams, consensus doesn’t mean everyone agrees—it means everyone feels heard, and the group can move forward with a shared commitment.^①
• If possible, reach consensus on all decisions affecting the team
• Simple majority rule can be detrimental on a small team in which everyone’s commitment is essential
• To reach that point, leaders must curate the quality of discourse^②: Valid argument need to be highlighted, invalid arguments need to constructively disqualified to protect decision quality:
  • Example: In a product design debate, a team member cites user data to support a feature. The leader highlights this as a valuable contribution, reinforcing data-driven thinking.

• Steps to reaching consensus:
  • Pose the problem to be solved or decision to be made
  • Solicit input on options for the problem or decision
  • Discuss and weigh pros and cons of each option
  • Work toward the options that have the most benefit for the project
  • When it is clear which option is most suitable, work with its opponents to help them buy in to it–persuade, don’t dictate
  • Consensus takes more time than mandate, but has huge pay-offs^①
• Beware passive/aggressive agreement–this is simply subsumed conflict^②

This is a reprise of our view of establishing a basis of trust

• Be confident in yourself and the team
• Maintain open communication within the project team– communication barriers create project risks
• Be fallible. Take responsibility for making mistakes, correct them, and make it clear how you plan to avoid these mistakes in the future
• Lead by example rather than by mandate. Show the team what you expect from yourself and from them
• Utilize all the talents of your team. You can’t make the project succeed all by yourself
• Complete all your commitments on time. If you cannot do so, give adequate notice and an explanation, not an excuse
• Don’t confuse friendship with leadership: Warmth and connection are vital—but leadership requires clarity, boundaries, and accountability^①

• Managers must have some understanding of human factors to avoid making unrealistic demands on people
• Staff selection factors include education, domain experience, adaptability and personality
• Software development groups should be small and cohesive
• Group communications are affected by status, group size and the group composition and organization
• The working environment has a significant effect on productivity
• Develop methods to monitor the project culture and technical status early so you can continually monitor these issues as the project progresses.^①