Agile team coaching and mentoring interview questions

Agile coaching centers on asking powerful questions and guiding the team to discover its own solutions rather than telling it what to do. The goal is building the team's self-sufficiency so it can keep improving continuously without depending on the coach for answers.

False. A coach primarily asks powerful questions and helps the team discover its own solutions, rather than telling members exactly what to do or assigning their daily tasks. Directing work is a manager-style approach; coaching builds the team's own problem-solving and growth.

An Agile coach guides the team toward self-organization and continuous improvement, asks powerful questions rather than giving directives, helps the team inspect and adapt their process, and acts as a servant leader who removes impediments. Unlike a traditional project manager, who typically assigns work and controls decisions, the coach builds the team's own capability so the team does not come to depend on the coach.

Coaching draws out the team member's own answers through questioning and facilitation, while mentoring draws on the mentor's personal experience and expertise to offer advice and guidance. A coach assumes the coachee has (or can develop) the answers; a mentor shares their own knowledge directly.

An Agile coach is expected to facilitate team ceremonies such as retrospectives, and to coach team members in Agile practices and mindset. They also help remove impediments the team cannot resolve on its own and guide the team toward greater self-organization and continuous improvement. They are not expected to assign tasks to individuals — that is the team's responsibility in a self-organizing model.

A coaching stance means guiding the team through questions and facilitated reflection so they surface problems and solutions themselves, rather than telling the team what to do. The leader's job is to grow the team's own capability to inspect, adapt, and self-organize, not to supply answers.

False. Agile coaching is grounded in a non-directive stance, where the coach asks questions and facilitates the team's own problem-solving rather than telling the team exactly what to do and how. Directing the team by command undercuts the self-organization that coaching aims to build.

Goal, Reality, Options, Will (or Way Forward).

On a previous engagement I joined a product team that had been told to 'do Scrum' but was skipping retrospectives and treating the daily standup as a status report to me. Rather than mandate retrospectives, I asked team members one-on-one what they felt was getting in the way of improvement, then facilitated a short 'start-stop-continue' retro. I coached the Scrum Master to facilitate rather than report out at standup, and I cleared a couple of external blockers the team raised. Over the next three sprints the team ran their own retrospectives, fixed two recurring deployment issues, and sprint goal attainment rose from roughly 40% to over 80%. In hindsight, I waited too long to address the standup format directly. I should have named the pattern sooner rather than letting it drift for a couple of weeks.

Tuckman's team-development model runs in this order: Forming, Storming, Norming, then Performing. A new team first forms around its goals and roles, then storms as conflicts surface, norms as working agreements settle, and finally performs once it works effectively together.

A servant leader puts the team's needs first, removing impediments and enabling the team to self-organize and deliver, rather than commanding and controlling. Two concrete actions are clearing blockers that slow the team and coaching individuals to grow their skills.

Asking open questions that surface the team's own reasoning, supporting small safe-to-fail experiments, and reflecting on outcomes together is the coaching stance. A coach who prescribes the process or makes decisions for the team builds dependency rather than the self-sufficiency the coach is aiming for.

Powerful questioning: the coach uses open-ended, non-leading questions to help the team reflect and discover its own solutions rather than prescribing advice.

A coaching stance is non-directive: the Scrum Master uses open-ended inquiry to help the developer reason through the problem and build their own problem-solving capacity, for example by asking, 'What do you think is the smallest valuable slice we could deliver here?' In contrast, a teaching stance would demonstrate or explain the right technique directly, and a consulting stance would privately prescribe the solution or the 'correct' questions to ask. Coaching develops the developer's own capability rather than transferring knowledge or answers from the Scrum Master.

The GROW coaching model runs Goal, Reality, Options, Will. A coach first helps the coachee define the desired outcome, then examines the current situation, then explores possible approaches, and finally secures commitment to specific actions. Each stage builds on the clarity established by the one before it.

Coaching is non-directive and inquiry-based: the coach asks questions so the coachee discovers their own solutions. Mentoring is directive: the mentor shares experience and gives advice drawn from their own expertise. The distinction matters because coaching builds self-sufficient problem-solving capacity, while mentoring transfers specific knowledge quickly. A team lead should consciously choose the mode based on whether the goal is capability development (coach) or knowledge transfer (mentor), and should avoid defaulting to one mode for every interaction.

First, I would conduct a baseline assessment: sprint retrospectives, individual 1:1s with each team member, and observation of two sprint cycles to understand each team's current maturity, pain points, and existing Agile knowledge—roughly the first two weeks. Phase 1 (weeks 1-4): Foundations. Here I lean heavily on mentoring—direct instruction on Scrum ceremonies, role expectations, and definitions of done—because teams transitioning from waterfall lack foundational Agile knowledge and need knowledge transfer, not self-discovery. I run interactive workshops rather than lectures. Phase 2 (weeks 5-8): Practice deepening. As teams gain comfort, I shift toward coaching: asking questions during retrospectives rather than providing answers, encouraging teams to identify their own improvement experiments, and using the GROW model in individual conversations with Scrum Masters. Phase 3 (weeks 9-12): Self-organization. I step back from active facilitation, observe whether teams self-correct issues, and coach team leads on sustaining the culture. The mentoring-to-coaching shift is deliberate: mentoring when knowledge is genuinely missing, coaching when the capability exists but needs unlocking. Success metrics I track: (1) Do teams facilitate their own retrospectives without the coach? (2) Are sprint goals met at a stable rate? (3) Do team members volunteer improvement actions without prompting? (4) Cross-functional collaboration—do stories get picked up by people outside the original specialist silo? These are observable and measurable, not subjective 'feels Agile' indicators. I also set expectations with leadership early: 'fully self-organizing' in 12 weeks is aspirational—I commit to demonstrable progress and a trajectory, not a binary milestone.

Coaching is a non-directive approach: the coach asks open questions and facilitates self-discovery so the individual develops their own solutions and builds lasting problem-solving capability. Mentoring is directive: the mentor draws on their own experience to give specific advice, guidance, and answers. In an Agile team, coaching grows autonomy and self-organization, while mentoring transfers knowledge and skills that a more experienced practitioner already has. A strong Agile coach uses both, but recognizes that over-mentoring can create dependency while effective coaching builds lasting independence.

I joined a team that had been running two-week sprints for three months but consistently carried over 40% of their committed stories each sprint. The developers felt demoralized and the product owner was losing confidence in the team's commitments. Instead of imposing a new estimation framework, I held short one-on-ones with each developer and asked what they believed was causing the carryover. Several cited unclear acceptance criteria and mid-sprint scope changes from the PO. I then facilitated a focused retrospective where the team mapped their top three impediments and voted on one to tackle first. I coached the PO and tech lead through writing acceptance criteria using a lightweight template, and the team agreed on a 'stop the line' rule: if scope shifted mid-sprint, the story was pulled and re-planned rather than quietly expanded. Over the next three sprints, carryover dropped from 40% to under 10% and sprint goal achievement rose from roughly 60% to above 90%. Looking back, I spent too long on the individual sessions, and a single team workshop would likely have surfaced the same issues faster. I also initially pushed the acceptance-criteria template too hard on the PO; when she pushed back, I pivoted to letting the developers request it, which got better buy-in.

Non-directive (inquiry-based) coaching is the approach a coach should use when a self-managing team repeatedly identifies an impediment but never acts on it. Powerful questions help the team uncover what blocks action and commit to its own next step, which builds the ownership needed for lasting behavioral change.

A coaching stance means the team lead holds a private one-to-one and uses open questions, such as what the senior developer notices about team dynamics, what they want ceremonies to achieve, and how their responses affect juniors' willingness to contribute. The goal is for the senior developer to discover the impact and commit to change, rather than being told what to do or given the lead's own past experience.

A coaching stance is non-directive: the coach asks powerful questions that help the coachee discover their own solutions and build self-sufficiency. A mentoring stance is directive: the mentor draws on their own experience to share knowledge, give advice, and model desired behaviors. Coaching is more appropriate when the coachee has the capability to solve the problem but needs to reflect and gain clarity, for example a senior team struggling to improve their retrospective outcomes. Mentoring is more appropriate when there is a genuine knowledge or skill gap, for example a junior developer who has never written acceptance criteria and needs to learn how from someone with experience.

The GROW coaching model runs in the order Goal, Reality, Options, Will. A coach first clarifies the desired goal, then establishes the current reality, explores the options for action, and finally secures the person's commitment to a specific next step. Each stage builds on the clarity of the one before it.

Month 1 (assess and establish safety): I hold a 1:1 with every team member in week one to listen rather than solve, and run an anonymous psychological safety survey (Edmondson's 7-item team scale) to set a baseline. I redesign retrospectives around a structured format (for example keep/drop/try or sailboat) with a prime directive, redirect blame language toward learning language, and use 5 Whys to focus root-cause analysis on systems rather than individuals. Month 2 (intervene on commitments and capability): I move sprint planning to capacity-based planning with a velocity range instead of a single point total, separate forecast from commitment with the product owner, and add a definition of ready to reduce mid-sprint surprises. I rotate retrospective facilitation among team members, starting with a willing senior engineer, and track action items on a visible board reviewed at the start of each retro. Differentiation: for the four junior engineers I pair and mentor on technical practices, estimation, and speaking up, and introduce a weekly mob-programming session for cross-skilling; for the three senior engineers I coach them as behavior setters who model vulnerability, delegate, and deliberately yield the floor to juniors in design discussions. Month 3 (measure, adjust, hand off): I re-run the safety survey against the baseline, track sprint forecast accuracy (target at least 80% of forecasted stories completed), retro action item completion (target at least 75%), and the safety survey average (target at least a 1-point gain on the 7-point scale). I step back from facilitating retrospectives so the team owns the process, and facilitate a working-agreement workshop to codify norms. If safety scores stay flat, I check for a specific interpersonal dynamic that needs mediation rather than assuming a team-wide culture problem.

I was brought in as an agile coach for a 9-person platform team that had been running two-week sprints for a year but consistently carried 40-60% of stories into the next sprint and had stopped speaking up in retrospectives; the same three people talked every time. I diagnosed this not as a skills gap but as a combination of learned helplessness and low psychological safety, rooted in a previous tech lead who had publicly criticized missed estimates. My first action was a one-on-one listening tour with every team member, using open questions like 'What would make this team better for you?', which surfaced a common theme: people felt estimates were punishments rather than planning tools. I then facilitated a retro using the Sailboat exercise, introduced psychological safety explicitly, and coached the tech lead, rather than mandating changes, to shift from 'Why didn't you finish?' to 'What got in your way, and how can we unblock it together?' Over four sprints I introduced silent retrospectives (sticky notes first, then group discussion) to give quieter voices a structured entry point, and worked with the product owner to tighten the Definition of Ready. By sprint 12 the carryover rate dropped from about 50% to under 15%, retro participation went from 3 people to 8 of 9, and the team's self-reported confidence on a 1-5 pulse rose from 2.1 to 4.0. My key lesson was that I initially over-indexed on process mechanics and under-invested in human dynamics; the process improvements only stuck once safety improved, so I now start every engagement with individual conversations and explicitly measure safety.