Interpersonal, Team, and Agile Communication

Introduction

Software development is a social and communicative activity as much as a technical one. A developer may write excellent code, yet a product can still fail when requirements are misunderstood, risks are concealed, feedback is ignored, or team members cannot coordinate their work. In modern full-stack development, communication occurs across disciplines, cultures, time zones, technologies, and organizational levels. Effective communication is therefore not an optional soft skill; it is a professional competence that affects quality, delivery speed, security, inclusion, and user satisfaction.

Agile development makes communication particularly visible. Agile teams inspect progress frequently, adapt plans, share responsibility, and deliver work incrementally. Practices such as stand-ups, planning meetings, retrospectives, pair programming, code reviews, and remote collaboration create structured opportunities for communication. However, meetings and tools alone do not guarantee collaboration. Their value depends on listening, clarity, psychological safety, evidence-based reasoning, respectful disagreement, and a shared commitment to outcomes.

This chapter explains how interpersonal communication operates within software teams and how it can be deliberately improved. It connects communication theory with practical engineering situations, including requirements clarification, technical disagreement, code review, distributed work, negotiation, and conflict resolution.

Learning Objectives

By the end of this chapter, you should be able to:

1. Explain the role of interpersonal communication in software engineering.
2. Apply active listening, questioning, and feedback techniques.
3. Participate effectively in stand-ups, planning meetings, and retrospectives.
4. Use communication practices that support pair programming and code review.
5. Adapt communication for remote, multicultural, and multidisciplinary teams.
6. Analyze conflict and select constructive resolution strategies.
7. Negotiate scope, priorities, risks, and technical trade-offs.
8. Evaluate communication practices ethically and improve them using evidence.

1. Communication as a Socio-Technical Competence

Communication is the process through which people create, interpret, and coordinate meaning. In software work, meaning includes business goals, user needs, technical constraints, responsibilities, decisions, and risks. Communication is not merely the transmission of information from a sender to a receiver. It is a process of interpretation in which context, assumptions, language, status, emotion, and prior experience influence what is understood.

A useful communication model contains five elements:

• Source: the person or group initiating a message.
• Message: the information, request, concern, or decision being conveyed.
• Channel: the medium, such as conversation, email, issue tracker, video call, or pull request.
• Receiver: the person or group interpreting the message.
• Feedback: evidence that the message has been understood or requires clarification.

Noise can affect every stage. Noise includes poor audio, ambiguous requirements, unfamiliar terminology, competing priorities, emotional tension, cultural assumptions, and information overload. In software teams, documentation and shared artifacts reduce some forms of noise, while active listening and clarification reduce others.

Communication competence has four dimensions:

Technical teams often overvalue accuracy and undervalue relational effectiveness. Both are necessary. A technically correct message that humiliates a colleague may reduce future reporting of defects and risks. Conversely, a pleasant but vague message may create expensive rework.

Shared mental models

A shared mental model is a sufficiently aligned understanding among team members about a system, goal, process, or situation. It does not mean that everyone thinks identically. Rather, people know the important facts, assumptions, dependencies, and decision boundaries well enough to coordinate.

Shared mental models are developed through diagrams, examples, demonstrations, decision records, acceptance criteria, and repeated opportunities for questions. They deteriorate when information is kept in private conversations, when decisions are undocumented, or when teams use terms inconsistently.

Psychological safety

Psychological safety is the shared belief that people can ask questions, admit uncertainty, report mistakes, and offer dissenting views without humiliation or retaliation. It is not the absence of standards or accountability. A psychologically safe team can maintain demanding quality expectations while treating mistakes as opportunities for learning and process improvement.

In software development, psychological safety is directly connected to reliability. Engineers who fear blame may hide defects, avoid raising security concerns, or agree publicly with a decision they privately believe is dangerous. Leaders and peers build safety by responding appreciatively to early warnings, separating people from problems, and examining system conditions rather than searching immediately for a scapegoat.

2. Interpersonal Skills for Software Professionals

Active listening

Active listening involves attending to a speaker, interpreting the message, checking understanding, and responding appropriately. It is more demanding than remaining silent while preparing a reply.

A practical active-listening sequence is:

1. Attend: remove distractions and focus on the speaker.
2. Clarify: ask questions about ambiguous terms, constraints, or priorities.
3. Reflect: restate the essential point in your own words.
4. Confirm: check whether your interpretation is correct.
5. Respond: propose an action, decision, or next question.

For example, instead of replying immediately to “The search feature must be faster,” a developer might ask: “When you say faster, which user journey is most important, and what response time would be acceptable under the expected load?” This converts an impression into a testable requirement.

Questioning techniques

Questions should reveal information rather than demonstrate superiority. Open questions encourage explanation: “What problem are we trying to solve?” Closed questions efficiently confirm facts: “Has the migration been tested in staging?” Probing questions explore consequences: “What happens if the payment provider is unavailable?” Socratic questions expose assumptions: “What evidence supports that estimate?”

Questions should be proportionate. Excessive questioning can feel obstructive, while insufficient questioning produces false agreement. A useful practice is to distinguish facts, assumptions, preferences, and decisions explicitly.

Assertive communication

Assertiveness means expressing a position clearly and respectfully while recognizing the rights and perspectives of others. It differs from passivity, aggression, and passive aggression.

An assertive technical statement often has four parts:

• observation: “The endpoint currently returns personal data in the response”;
• impact: “This increases the risk of unintended exposure”;
• recommendation: “I recommend removing the field and adding a contract test”;
• invitation: “Can we examine that option before merging?”

This structure focuses on evidence and consequences rather than character or motives.

Nonverbal and paralinguistic communication

Tone, pace, pauses, facial expression, posture, and turn-taking influence how a message is interpreted. In text-based communication, punctuation and response timing can carry unintended meanings. A short message such as “Fine.” may be interpreted as agreement, annoyance, or dismissal depending on context. Important or sensitive matters should not be forced into channels that cannot support adequate nuance.

3. Communication in Agile Events

Agile events are coordination mechanisms. Their purpose is not to produce the appearance of activity but to support inspection, adaptation, and delivery of value. Teams should periodically ask whether an event is improving decisions and flow.

Daily stand-up

A stand-up is a short coordination meeting in which team members synchronize around progress, current work, impediments, and near-term priorities. The traditional three-question format—what was done, what will be done, and what is blocking progress—can be useful for inexperienced teams, but it may encourage reporting to a manager rather than collaboration among peers.

A more effective format is task-oriented:

1. What is the current goal or most important outcome?
2. Which work is moving toward that goal?
3. Where is help, a decision, or an escalation needed?
4. What has changed since the last synchronization?

A stand-up should not become a detailed problem-solving meeting. Complex discussions should be recorded and continued afterward with the relevant people. Participants should mention risks early, avoid irrelevant detail, and listen for opportunities to help.

Sprint or iteration planning

Planning connects product intent with a feasible technical commitment. Effective planning requires more than selecting a list of tickets. The team needs a shared understanding of:

• the objective and expected user value;
• acceptance criteria and unresolved assumptions;
• dependencies and technical risks;
• capacity, availability, and relevant skills;
• the definition of done;
• how progress and completion will be observed.

Developers should ask questions without treating uncertainty as incompetence. Product representatives should explain value and priority without prescribing unnecessary implementation details. If a story cannot be understood well enough to discuss its risks and completion conditions, it may need refinement before commitment.

Review or demonstration

A review examines the increment with stakeholders and gathers evidence about whether it meets expectations. The team should demonstrate working behavior, not merely describe completed tasks. Stakeholder feedback should be distinguished from a change request, a defect report, and a new product idea. These may have different priorities and handling processes.

Retrospective

A retrospective is a structured conversation about how the team worked and how it can improve. A productive retrospective is evidence-based, inclusive, and action-oriented. One possible sequence is:

1. establish the purpose and a respectful working agreement;
2. collect observations and relevant data;
3. identify patterns and contributing conditions;
4. select one or two improvements;
5. assign ownership and define a follow-up signal.

The team should avoid turning the retrospective into a complaint session or a performance trial. “The deployment failed because Alex was careless” is less useful than “The deployment lacked an automated rollback check, and the review step was ambiguous.” The second statement supports a process improvement while preserving accountability for learning and corrective action.

4. Pair Programming and Collaborative Technical Work

Pair programming involves two developers working together at one workstation or through a shared development environment. The driver controls the immediate implementation, while the navigator considers direction, edge cases, design implications, and verification. Roles should rotate regularly.

Pair programming is not simply two people watching one person type. Its benefits arise from continuous explanation, rapid feedback, shared context, and early detection of misunderstandings. It can be especially valuable for unfamiliar code, risky changes, onboarding, security-sensitive logic, and complex debugging.

Effective pairing requires:

• agreement on the goal and working interval;
• explicit role rotation;
• thinking aloud without monopolizing the discussion;
• allowing the driver to experiment;
• distinguishing design disagreement from personal criticism;
• taking breaks when cognitive fatigue reduces quality.

A common failure is “expert and assistant” pairing, in which one person controls every decision. This reduces learning and creates dependence. Another failure is excessive debate before a small experiment could provide evidence. Teams should use discussion, prototypes, tests, and documentation as complementary forms of reasoning.

5. Code Review as Communication

A code review is both a quality-control activity and a knowledge-sharing conversation. The reviewer evaluates whether a change is correct, understandable, maintainable, secure, appropriately tested, and consistent with project standards. The author remains responsible for explaining the change and responding to feedback; the reviewer remains responsible for examining it carefully.

A review workflow

1. The author provides a focused change with a useful description.
2. Automated checks run before human review where practical.
3. The reviewer examines behavior, tests, design, risks, and maintainability.
4. Comments are classified by importance, such as blocking defect, significant concern, suggestion, or optional style preference.
5. The author responds, revises, or explains a reasoned alternative.
6. The final decision and any unresolved trade-off are documented.

Review comments should be specific and actionable. “This is bad code” is neither respectful nor useful. “Could this validation occur before the database call? It would avoid unnecessary work and make the failure path explicit” identifies a concern and invites analysis.

Use language that separates the code from the person: “This function is difficult to test because it combines input parsing and persistence” rather than “You wrote an untestable function.” When a comment reflects a mandatory standard, identify the standard. When it reflects a preference, label it as a suggestion.

Review limitations

Code review cannot replace automated tests, security analysis, architecture governance, or production monitoring. Review quality also decreases when pull requests are too large, reviewers lack context, or organizational pressure rewards rapid approval over careful examination. Small, coherent changes and clear review expectations improve both speed and depth.

6. Remote, Cross-Cultural, and Inclusive Collaboration

Distributed teams require deliberate communication design. Informal office interactions are reduced, time zones create delays, and written messages become more important. Teams should establish explicit norms for channels, response expectations, meeting participation, documentation, and escalation.

A useful channel policy might distinguish:

Asynchronous communication should include context, the requested action, deadline or urgency, relevant links, and a clear decision question. This reduces repeated clarification and supports colleagues in different time zones.

Cross-cultural communication requires humility. Differences may exist in directness, turn-taking, attitudes toward hierarchy, use of silence, and willingness to disagree publicly. These patterns should not be treated as fixed characteristics of individuals. The practical response is to establish explicit norms: invite written input, rotate facilitation, avoid interrupting, explain acronyms, and confirm decisions in writing.

Inclusion also involves accessibility. Captions, readable documents, adequate contrast, descriptive headings, and alternatives to voice-only participation help people contribute. Meetings should not reward only the fastest speaker. Facilitators can provide agendas in advance and create a pause for written questions.

7. Feedback and Performance Conversations

Feedback is information intended to improve future behavior or outcomes. It is most useful when it is timely, specific, observable, and connected to consequences or goals.

A practical feedback pattern is:

• Situation: identify when and where the event occurred.
• Behavior: describe what was observable.
• Impact: explain the effect on people, work, or outcomes.
• Next step: agree on a constructive action.

Example: “In yesterday’s planning meeting, the security concern was raised after the estimate was finalized. Because the risk affected the design, the team had to revisit the plan. In future, please raise similar concerns during refinement or record them as soon as they emerge.”

Feedback should be a dialogue. The recipient may provide context, identify a system constraint, or disagree with the interpretation. Managers and senior engineers should request feedback about their own communication as well as giving it.

Praise should also be specific. “Good job” is pleasant but limited. “Your reproduction steps made the defect easy to verify, and the accompanying test prevents regression” reinforces a behavior the team values.

8. Negotiation and Technical Trade-offs

Negotiation is the process of reaching an acceptable agreement when parties have partly shared and partly different interests. In software projects, negotiation concerns scope, schedule, quality, cost, architecture, risk, and ownership.

A useful distinction is between positions and interests. A position is what someone requests; an interest is why it matters. “We must release all five features this week” is a position. The underlying interest may be a regulatory deadline, a customer demonstration, or revenue recognition. Understanding the interest can reveal alternatives, such as releasing a smaller compliant subset or using a controlled pilot.

Principled negotiation commonly involves:

1. separating people from the problem;
2. focusing on interests rather than stated positions;
3. generating multiple options;
4. using objective criteria where possible;
5. clarifying what each party can commit to.

Technical trade-offs should be expressed explicitly. For example, a team might compare a fast implementation, a more scalable design, and a safer migration path. The decision should record assumptions, risks, reversibility, and review conditions. This prevents later disagreement about what was actually agreed.

Negotiation becomes unethical when information is deliberately concealed, stakeholders are manipulated, vulnerable colleagues are pressured, or technical language is used to obscure a business consequence. Professional communication requires honest representation of uncertainty and limitations.

9. Constructive Conflict Resolution

Conflict is not always harmful. Task conflict can expose assumptions and improve decisions; relationship conflict involving hostility or personal attack usually damages collaboration. Avoiding every disagreement can produce conformity and hidden risk, while unmanaged disagreement can produce delay and distrust.

A conflict-resolution process can be organized into six steps:

1. Describe the issue: state the observable disagreement without assigning motives.
2. Listen to perspectives: allow each person to explain evidence, concerns, and constraints.
3. Identify interests: determine what each party is trying to protect or achieve.
4. Generate options: create alternatives before judging them.
5. Apply criteria: compare options against agreed goals, evidence, risk, and standards.
6. Agree and follow up: record the decision, owner, and conditions for revisiting it.

The Thomas–Kilmann framework describes five conflict modes: competing, collaborating, compromising, avoiding, and accommodating. None is universally correct. Competing may be appropriate during an immediate safety incident; collaborating is valuable for complex design decisions; avoiding may be sensible when emotions are too high for a productive conversation; accommodating may preserve a relationship when the issue has low importance to one party. The framework is best used as a diagnostic vocabulary rather than a rigid prescription.

If conflict includes harassment, discrimination, threats, retaliation, or persistent abuse of authority, it is not merely a communication-style issue. Organizational policies, human resources processes, safeguarding procedures, or formal reporting channels may be necessary.

10. A Detailed Applied Case

Illustrative case: The delayed checkout release

Background. An e-commerce team is preparing a new checkout service. The team includes front-end and back-end developers, a product manager, a quality engineer, and a security specialist working across three time zones.

Problem. During planning, the product manager requests release within two weeks. The back-end developer believes the proposed payment integration requires more testing. A reviewer later identifies that error messages could expose provider details. In a remote meeting, the disagreement becomes personal: the developer says the product manager “does not understand engineering,” while the product manager says the developer is “blocking delivery.” Other team members stop contributing.

Analysis. The conflict combines several issues: an unexamined schedule assumption, a security risk, unclear acceptance criteria, and deteriorating psychological safety. The personal statements are symptoms, not the complete problem. The team lacks a shared definition of release readiness and has not separated must-have compliance requirements from desirable enhancements.

Approach. The team facilitator pauses the argument and restates the shared goal: a safe, usable checkout release. Each participant explains interests and evidence without interruption. The team identifies three categories of work:

• essential payment and security behavior;
• usability improvements that can follow;
• technical debt requiring a documented follow-up plan.

The team agrees to create a thin vertical slice, test it with a sandbox provider, and conduct a focused security review. The product manager accepts a limited pilot rather than a full release. The developer agrees to provide an evidence-based estimate with explicit assumptions. The reviewer records the error-message issue as a release-blocking security concern. Decisions, owners, and review dates are placed in the project tracker.

Outcome. The pilot is released later than the original informal target but with reduced exposure risk and clearer scope. Subsequent planning includes security acceptance criteria and a risk review. Team members report that disagreement feels safer because decisions are now based on shared criteria rather than status or volume of speech.

Learning points. First, respectful communication does not mean avoiding difficult facts. Second, negotiation improves when interests and constraints are made visible. Third, a technical concern should be escalated early and documented. Fourth, a facilitator can convert interpersonal conflict into a structured problem-solving process. Finally, delivery speed must be evaluated together with quality, security, and reversibility rather than treated as an isolated goal.

11. Technology, AI, and Communication Governance

Collaboration platforms, issue trackers, automated review tools, transcription systems, and generative AI can support team communication. AI may summarize meetings, suggest clearer wording, classify issue reports, or identify repeated themes in retrospectives. These uses require human verification.

Teams should consider confidentiality, intellectual property, privacy, bias, data retention, and accountability before entering organizational or personal information into an AI service. An AI-generated summary may omit dissent, misattribute a statement, or present an uncertain inference as a decision. Participants should approve important summaries, and authoritative decisions should remain in controlled organizational records.

Automation should reduce routine effort, not remove human responsibility. A bot can detect a missing test or stale ticket; it cannot determine alone whether a product decision is ethical, whether a colleague feels unsafe, or whether a risk is acceptable. Governance should specify approved tools, access controls, retention periods, review responsibilities, and escalation procedures.

12. Measuring and Improving Team Communication

Communication improvement should be based on observable evidence rather than a desire for more meetings. Possible indicators include:

• number of reopened or misunderstood work items;
• time required to resolve blocked work;
• proportion of decisions with documented rationale;
• review cycle time and size of changes;
• defects caused by unclear requirements;
• participation patterns in meetings;
• completion and effectiveness of retrospective actions;
• anonymous perceptions of psychological safety.

No single metric proves communication quality. For example, fewer reported risks may indicate improvement—or fear of reporting. Measures should be interpreted in context and combined with qualitative evidence. Teams should avoid using communication metrics to rank individuals mechanically, because such systems can encourage gaming and silence.

A practical improvement cycle is to identify one communication problem, collect examples, test a small intervention, review its effect, and adjust. Examples include introducing decision records, reducing pull-request size, rotating meeting facilitation, or adding a written pre-read for planning.

Best Practices

• State the purpose of a conversation before discussing details.
• Distinguish facts, assumptions, preferences, risks, and decisions.
• Make requests specific about action, owner, and timing.
• Prefer small, coherent work items and reviewable changes.
• Raise risks early, even when evidence is incomplete.
• Critique artifacts and proposals rather than personal character.
• Document decisions and unresolved trade-offs.
• Invite quieter and remote participants deliberately.
• Use synchronous conversation for complexity, emotion, or rapid coordination; summarize outcomes asynchronously.
• Treat feedback as a two-way learning process.
• Escalate harassment, discrimination, retaliation, and safety concerns through appropriate formal channels.

Chapter Summary

Effective software development depends on communication that creates shared understanding, supports coordination, and preserves professional trust. Communication competence includes clarity, accuracy, adaptability, and relational effectiveness. Active listening, purposeful questioning, assertiveness, and psychological safety help teams identify requirements and risks before they become expensive failures.

Agile events are valuable when they support inspection and adaptation rather than performative reporting. Stand-ups coordinate immediate work, planning aligns value with feasibility, reviews gather evidence from stakeholders, and retrospectives produce focused improvements. Pair programming and code review extend communication into technical practice by encouraging explanation, feedback, shared ownership, and knowledge transfer.

Remote and multicultural teams need explicit channel norms, accessible participation, documentation, and sensitivity to different communication patterns. Feedback is most effective when it describes observable behavior, impact, and a constructive next step. Negotiation should focus on interests, options, objective criteria, and transparent trade-offs. Conflict can improve decisions when it is structured around evidence and shared goals, but harmful conduct requires formal intervention.

Technology and AI can support communication, yet they introduce privacy, accuracy, bias, and accountability concerns. Teams should measure communication through multiple forms of evidence and improve it through small, deliberate experiments. The central professional principle is that respectful communication is not separate from engineering quality: it is one of the means by which quality is produced.

Key Terms

Active listening: Deliberately attending, interpreting, clarifying, and responding to another person’s message.

Agile event: A structured activity used to inspect progress, coordinate work, or adapt plans.

Assertiveness: Clear and respectful expression of one’s views, needs, or concerns.

Channel: The medium through which a message is communicated.

Code review: A systematic examination of a proposed code change by one or more colleagues.

Conflict of interests: A situation in which parties seek outcomes that are partly different.

Feedback: Information intended to influence future behavior or performance.

Interpersonal communication: Meaning-making and coordination between people.

Negotiation: A process for reaching agreement among parties with shared and differing interests.

Noise: Anything that interferes with accurate communication or interpretation.

Pair programming: Collaborative programming in which two developers work together on the same task.

Psychological safety: A shared belief that people can speak up, ask questions, and admit errors without humiliation or retaliation.

Retrospective: An Agile discussion focused on learning and improving team processes.

Shared mental model: A sufficiently aligned understanding of a goal, system, process, or situation.

Stand-up: A short team synchronization meeting focused on progress, priorities, and impediments.

Technical trade-off: A decision in which improving one quality or constraint affects another.

Asynchronous communication: Communication that does not require participants to respond at the same time.

Constructive conflict: Disagreement managed in a way that improves understanding or decisions.

Review Questions

Short Answer Questions

1. What are the four dimensions of communication competence described in this chapter?
2. Why should complex problem-solving usually continue outside a daily stand-up?
3. What is the difference between a position and an interest in negotiation?
4. State two characteristics of useful code-review feedback.
5. What does psychological safety enable in a software team?

Long Answer Questions

1. Explain how active listening and questioning can improve requirements clarification. Use a software example.
2. Compare the purposes of planning meetings, reviews, and retrospectives in an Agile team.
3. Discuss how remote and cross-cultural teams can design inclusive communication norms.
4. Explain the role of feedback in professional development and describe a suitable feedback structure.
5. Analyze the benefits and limitations of pair programming and code review as communication practices.

Analytical / Application Questions

1. A developer repeatedly receives vague pull-request comments such as “clean this up.” Analyze the communication problem and propose a specific improvement process.
2. During planning, a product manager demands a fixed deadline while engineers identify an unresolved security risk. Apply negotiation and conflict-resolution principles to recommend a course of action.
3. A distributed team has many meetings but continues to misunderstand decisions. Diagnose possible causes and design a small evidence-based intervention.

Multiple Choice Questions with Answers

Question 1

Which practice best demonstrates active listening during requirements clarification?

A. Immediately proposing an implementation

B. Restating the requirement and checking whether the interpretation is correct

C. Avoiding questions to save meeting time

D. Sending the requirement to another team without discussion

Correct Answer: B. Restating the requirement and checking whether the interpretation is correct

Question 2

What is the primary purpose of a daily stand-up?

A. To conduct detailed architecture design

B. To evaluate individual employee performance

C. To synchronize work and identify impediments

D. To replace all project documentation

Correct Answer: C. To synchronize work and identify impediments

Question 3

Which statement is most appropriate in a constructive code review?

A. You clearly do not understand programming

B. This is bad code and should be rewritten

C. Could validation occur before the database call to avoid unnecessary work?

D. Everyone knows this approach is wrong

Correct Answer: C. Could validation occur before the database call to avoid unnecessary work?

Question 4

Psychological safety primarily enables team members to:

A. Avoid accountability for mistakes

B. Raise concerns and admit uncertainty without fear of humiliation

C. Prevent all disagreement

D. Work without quality standards

Correct Answer: B. Raise concerns and admit uncertainty without fear of humiliation

Question 5

In negotiation, an interest is best described as:

A. The stated demand made by a party

B. The underlying need or reason behind a request

C. The final document recording a decision

D. A technical defect in the product

Correct Answer: B. The underlying need or reason behind a request

Question 6

Which communication channel is generally most appropriate for recording a decision affecting future development?

A. An undocumented hallway conversation

B. A decision record or issue tracker

C. A private instant message visible only to one person

D. An informal verbal reminder

Correct Answer: B. A decision record or issue tracker

Question 7

During pair programming, the navigator primarily:

A. Controls all keyboard input

B. Observes direction, edge cases, and design implications

C. Approves the final release alone

D. Prevents the driver from explaining decisions

Correct Answer: B. Observes direction, edge cases, and design implications

Question 8

Which statement best describes a constructive retrospective?

A. It assigns blame for every failure

B. It focuses on evidence, patterns, and actionable improvements

C. It is used only to report status to management

D. It avoids discussing process problems

Correct Answer: B. It focuses on evidence, patterns, and actionable improvements

Question 9

Which feedback statement is most specific and useful?

A. Good work

B. You need to communicate better

C. In yesterday’s planning meeting, the late security concern caused rework; please raise similar risks during refinement

D. Your attitude is the problem

Correct Answer: C. In yesterday’s planning meeting, the late security concern caused rework; please raise similar risks during refinement

Question 10

When conflict involves harassment or retaliation, the issue should be treated as:

A. A normal technical disagreement only

B. A matter to ignore until the next retrospective

C. A potential formal conduct or safeguarding issue

D. A reason to remove all code reviews

Correct Answer: C. A potential formal conduct or safeguarding issue