HKSM

A facilitated, time-boxed meeting where the team reflects on recent work to learn and agree concrete improvements. It strengthens performance by turning insights into a small set of owned, trackable actions.

Key Points

• Short, focused session for the whole team to inspect ways of working and decide improvements.
• Psychological safety is essential; focus on process and systems, not blame.
• Time-boxed and recurring (e.g., end of an iteration or milestone) to drive continuous improvement.
• Outputs are specific actions with owners and due dates, limited to a manageable number.
• Facilitated by the project manager, Scrum Master, or neutral facilitator to keep it structured and inclusive.
• Improvements feed back into team working agreements, plans, and organizational knowledge bases.
• Track actions visibly and review progress in subsequent team meetings.

Purpose of Analysis

The session examines recent collaboration, workflow, tools, and results to identify friction and opportunities. It prioritizes changes that improve flow, quality, predictability, and morale. It also aligns the team on norms and commitments that sustain performance.

Method Steps

• Prepare: Pick a format (e.g., Start–Stop–Continue, 4Ls, Sailboat), gather data, and set a clear timebox (30–90 minutes depending on cycle length).
• Set the stage: Reaffirm the goal and working agreements, establish safety, and define the scope of the period being reviewed.
• Gather data: Capture facts and signals such as cycle time, defects, handoff delays, blockers, wins, and sentiments.
• Generate insights: Cluster themes, use 5 Whys or Fishbone to find root causes, and distinguish symptoms from causes.
• Decide actions: Vote to select 1–3 high-impact, feasible improvements; make them SMART with owners and target dates.
• Close: Confirm commitments, plan how progress will be tracked, and appreciate contributions.
• Follow up: Add items to the improvement backlog, review status regularly, and adjust if actions stall.

Inputs Needed

• Recent goals and outcomes (e.g., iteration plan, release objectives, deliverables completed).
• Performance data: throughput, cycle/lead time, defects, escaped bugs, rework, incidents, and WIP levels.
• Team feedback: survey results, kudos, pain points, stakeholder comments, and customer support trends.
• Working agreements, Definition of Done/Ready, and process checklists.
• Impediment/risk/issue logs and change requests touching the period under review.

Outputs Produced

• Improvement action items with owners, due dates, and expected impact.
• Updated team working agreements and process policies.
• Entries for the lessons learned register and organizational process assets.
• Backlog updates for improvement work, including capacity allocation if needed.
• Updates to risk and issue logs where process changes mitigate or introduce risks.

Interpretation Tips

• Target causes within the team’s influence; escalate only what truly needs outside help.
• Balance quick wins with one systemic improvement to avoid superficial fixes.
• Use data to validate perceptions but avoid weaponizing metrics.
• Limit WIP in improvements; too many actions dilute focus and accountability.
• Make outcomes observable (e.g., “reduce average code review wait time by 20% in 2 sprints”).

Example

After a two-week iteration, a software team runs a 60-minute Start–Stop–Continue retrospective. Data shows long code review queues and three production rollbacks. The team commits to: (1) implement a two-reviewer cap per person and rotate reviewers, owner: Dev Lead, due: next iteration; (2) add automated smoke tests to the deploy pipeline, owner: QA, due: two iterations; and (3) update the working agreement to review within 24 hours. These are tracked on the team board and reviewed in the next standups.

Pitfalls

• Blame or defensiveness that shuts down honest discussion.
• Vague actions without owners or dates.
• Overloading the team with too many improvements at once.
• Skipping follow-up, so the same issues recur.
• Unclear scope that mixes months of issues into one session.
• Facilitator dominates; quieter voices are not heard.
• Inviting external stakeholders who inhibit openness without a clear reason.

PMP Example Question

During executing, the team has recurring handoff delays. To run an effective retrospective, what should the project manager do first?

1. Invite senior stakeholders to observe so the team feels accountable.
2. Facilitate a time-boxed session that establishes safety, reviews data, and selects 1–3 SMART actions with owners.
3. Assign action items to individuals based on the manager’s assessment of the root cause.
4. Skip the session and send a directive to reduce handoffs immediately.

Correct Answer: B — Facilitate a time-boxed, structured retrospective that yields a few owned, specific actions.

Explanation: Retrospectives work when they are safe, data-informed, and action-focused. The facilitator guides the team to agree on targeted improvements instead of top-down directives or public scrutiny.