Running a Salesforce Programme Retrospective That Actually Changes Things

The Failure of Performative Post-Mortems

In many enterprise Salesforce programmes, retrospectives have devolved into a sterile corporate ritual. Teams gather at the end of a sprint or a major release, fill a virtual whiteboard with colourful sticky notes under standard headings ("What went well", "What didn't go well", "Shout-outs"), exchange polite pleasantries, and then return to their desks. The resulting action items are either banally vague ("improve communication between developers and BAs", "ensure requirements are locked down earlier") or are promptly buried in a neglected corner of the project wiki, never to be reviewed again.

This performative approach is a waste of valuable delivery capacity, but in the context of Salesforce, it is particularly dangerous. Salesforce delivery is uniquely multidisciplinary. It requires the seamless coordination of business process owners, functional consultants, declarative builders, programmatic developers, integration specialists, environment managers, and QA engineers. The platform's low-code, high-code hybrid nature means that a single process decision can have instant, far-reaching consequences across multiple environments, security models, and system integrations.

When a Salesforce retrospective fails to go deep, the same delivery bottlenecks reappear release after release. Sandbox drift goes unaddressed, leading to silent metadata overwrites. Flawed branching strategies continue to trigger catastrophic merge conflicts during release weeks. Vague user stories pass through grooming, resulting in functional solutions that fail UAT because they do not reflect actual business operations. A performative post-mortem does not just fail to solve these problems; it actively sanitises them, creating an illusion of continuous improvement while the technical debt and delivery friction steadily accumulate.

To escape this cycle, delivery leaders must shift the retrospective's focus from comforting team therapy to rigorous, data-driven systems engineering. The goal is not to assign blame, nor is it merely to "vent" about the difficulties of the release. The objective is to analyse the delivery system, identify the structural points of friction, and implement automated or procedural guardrails that prevent those failures from recurring. This requires a culture of high psychological safety, where team members can speak honestly about system failures without fear of reprisal, combined with high analytical accountability, where failures are systematically dissected to their root causes.

The Five Dimensions of a Salesforce Retrospective

A standard Scrum retrospective typically focuses on team dynamics, collaboration, and sprint velocity. While these are important, they are insufficient for the specific complexities of a Salesforce programme. A senior practitioner needs a broader, multi-dimensional framework that dissects the engineering, operational, and governance realities of the platform. A successful Salesforce retrospective must categorise and evaluate delivery failures across five distinct dimensions.

1. Release and Environment Integrity

This dimension covers the technical pipelines, branching strategies, deployment automation, and environment management. In a multi-stream Salesforce project, environment issues are often the single greatest source of delivery friction. The retrospective must ask:

• Did we experience deployment failures due to missing metadata dependencies in our package XML or repository?
• How much time did developers spend resolving complex merge conflicts that could have been avoided with smaller, more frequent pull requests?
• Was there significant "sandbox drift" (differences in metadata and configuration between developer sandboxes, integration environments, and production) that led to unexpected bugs during late-stage testing?
• Did our deployment automation (CI/CD) catch issues early, or did we rely on manual post-deployment configuration steps that introduced human error?

2. Governance and Decision Velocity

This refers to the speed and clarity with which architectural, process, and business decisions are made. Salesforce programmes are highly sensitive to decision delays because low-code builders can configure functionality much faster than traditional software pipelines, meaning blocking decisions can halt entire streams of work in hours rather than days. The retrospective must examine:

• Did we have clear owners for cross-cutting architectural decisions (such as sharing model modifications, choosing between Flow and Apex, or defining integration contracts)?
• Were blocking issues escalated quickly to the Design Authority or Steering Committee, or did they sit in the queue while teams debated?
• Did business stakeholders change their minds late in the cycle, necessitating costly rework of completed configurations?

3. Technical Debt and Code Quality

Salesforce makes it incredibly easy to build technical debt quickly. Declarative tools like Flow can be created in minutes but, if unmanaged, can clash with Apex triggers, bypass validation rules, and degrade org performance. Retrospectives must assess:

• Did we bypass established architectural standards (such as the "one trigger per object" rule, or standard custom metadata-driven bypass frameworks) in order to meet immediate sprint commitments?
• What was the quality of our unit tests and automated test coverage? Did they genuinely assert business logic, or were they written merely to pass the 75% deployment threshold?
• Did we introduce redundant custom fields, hardcoded IDs, or duplicate automation that will complicate future changes?

4. Business-IT Alignment and Requirement Fidelity

This dimension addresses the interface between business analysis, product ownership, and technical execution. Salesforce's rapid prototyping capability means BAs and developers must maintain tight alignment. The retrospective should ask:

• Were user stories genuinely "Ready for Development" according to the Definition of Ready, or did developers have to make assumptions about critical business rules during build?
• Did the functional solution demonstrated in sprint reviews match the business sponsor's actual expectations, or did UAT surface major gaps in understanding?
• Was the product owner sufficiently empowered and available to clarify requirements in real time during the sprint?

5. Estimation Accuracy and Velocity

Finally, delivery leaders must analyse the planning mechanics. Because Salesforce projects combine configuration with code, estimating can be deceptive. A simple "create a custom field" task can explode in complexity when page layouts, sharing rules, lightning pages, and reporting must be configured across multiple profiles. The retrospective should evaluate:

• Were our sizing assumptions accurate? Did "small" configuration tasks turn out to require extensive Apex customisation or integration updates?
• Did we encounter scope creep within the active sprint, where additional fields or process steps were silently added to stories?
• How did our actual velocity compare to our planned capacity, and what were the primary distractors (such as support requests, production hotfixes, or environment maintenance)?

To illustrate the shift in focus, consider the following comparison between standard agile retrospectives and Salesforce-specific program retrospectives:

Designing the Retrospective Framework

To move beyond performative sticky-note exercises, a senior Salesforce Delivery Manager must implement a structured, data-driven retrospective framework. This framework relies on a core thesis: you cannot run an effective retrospective based entirely on how people feel; you must ground the discussion in quantitative delivery telemetry.

Phase 1: Pre-Workshop Data Gathering

Before the retrospective workshop begins, the facilitator (ideally a Delivery Manager or an objective Agile Coach) must gather delivery telemetry from the sprint or release cycle. This objective data serves as a mirror, preventing emotional bias and grounding the team in realities they might otherwise forget or minimise.

The metrics to collect include:

• Deployment Telemetry: How many deployments to the Integration or QA environment failed? What were the primary failure reasons (such as missing custom fields, test class failures, profile metadata mismatches)?
• Git Repository Analytics: How many pull requests (PRs) were opened? What was the average time to merge? Which branches experienced the most merge conflicts?
• Jira / ADO Analytics: How many user stories were pushed back from QA or UAT? Which stories had their estimates revised mid-sprint? How many bugs were logged during UAT, and what was their severity?
• Support and Hypercare Logs: If this is a post-go-live retrospective, what was the volume and category of support tickets raised by end users in the first two weeks?

Phase 2: The Structured Workshop Agenda

A high-impact retrospective requires structured facilitation. For a major milestone or release retrospective, allocate a dedicated 2-to-3 hour session. The agenda should follow a structured progression:

1. Set the Stage (10 minutes): Establish the psychological baseline. Read the Retrospective Prime Directive: "Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand." Establish that this is an engineering review of our delivery system, not a performance evaluation of individuals.
2. Review the Telemetry (20 minutes): Present the gathered data. Highlight the hard facts: "We had 14 deployment failures in the Integration sandbox this sprint, and 45% of our QA bugs related to sharing rules and field-level security." This shifts the focus from subjective complaints to undeniable systemic issues.
3. Timeline Reconstruction (30 minutes): If reviewing a major release, co-create a visual timeline of the cycle. Mark key milestones: build start, integration environment refreshes, UAT kick-off, deployment dry runs, and go-live. Ask the team to plot emotional highs and lows along this timeline. This helps correlate specific technical events (such as a broken sandbox refresh) with team distress and delivery delays.
4. Dimensional Grouping and Brainstorming (40 minutes): Have the team brainstorm what went well and what went poorly, but force them to categorise their feedback into the Five Dimensions of a Salesforce Retrospective. This prevents the sticky-note board from becoming a chaotic list of disconnected complaints.
5. Deep-Dive and Actioning (50 minutes): Rather than voting on every card, select the top 2 or 3 systemic issues that had the most severe impact on delivery velocity or quality. Apply the "Five Whys" root-cause analysis method to these issues (see Section 4). Draft high-fidelity, systemic action items for each.
6. Wrap-up (10 minutes): Review the agreed action items, ensure each has a single named owner and a realistic target date, and quickly gather feedback on the retrospective format itself to optimise the next session.

Translating Insights into Systemic Actions

The ultimate metric of a retrospective's success is not the quality of the conversation; it is the concrete change in the delivery system's behaviour in the subsequent sprints. The greatest failure of retrospectives is the creation of "human-centric" action items.

A human-centric action item relies on human beings remembering to behave differently. These action items are virtually useless. Under the pressure of tight deadlines, human beings will always default to their established habits and the path of least resistance. If your delivery system relies on developers remembering to manually check for metadata dependencies before they push a branch, you have a broken delivery system.

Instead, a senior Salesforce practitioner must translate retrospective insights into Systemic Actions. A systemic action modifies the process, the tooling, the automation, or the physical environment to make the correct behaviour the default path, or to make the incorrect behaviour technically impossible.

To build systemic actions, the team must first perform a rigorous root-cause analysis using the Five Whys technique. Let us examine how a common Salesforce delivery failure is analysed to find a systemic, rather than human-centric, solution.

Case Study: The Broken Integration Sandbox

• The Symptom: Deployments to the QA sandbox failed repeatedly in the final week of the sprint, causing UAT to start three days late.
• Why? (First Why) -> Because the QA sandbox was missing several custom fields and custom metadata records that developers had configured in their individual environments.
• Why? (Second Why) -> Because the deployment package (package.xml or git delta) was created manually by the developers, and they forgot to include these dependencies.
• Why? (Third Why) -> Because there is no automated mechanism to identify metadata dependencies, and developers are under severe pressure to meet sprint velocity goals, leading them to rush manual manifest creation.
• Why? (Fourth Why) -> Because we have not configured automated metadata dependency checking in our CI/CD pipeline, nor do we run automated dry-run deployments on pull requests.
• Why? (Fifth Why) -> Because we did not allocate architectural or DevOps engineering capacity during our discovery phase to build a robust CI/CD pipeline with automated validation, choosing instead to focus all capacity on building functional features.

By going five levels deep, we move from a shallow, finger-pointing conclusion ("the developers made a mistake") to a profound structural understanding of our delivery system ("we underinvested in DevOps infrastructure"). Now, let us compare how we would write the action items for this issue:

Securing Business Buy-in: The "10% Improvement Tax"

Clients and business sponsors are often reluctant to invest capacity in systemic improvements. They want to see new features, not pipeline configurations or automated test improvements. To secure this buy-in, the Delivery Manager must frame these improvements as a direct protection of business value. If UAT was delayed by three days due to deployment failures, that represents a tangible cost in idle QA resources, delayed business feedback, and potential slippage of the production release date.

A highly effective delivery mechanism is the 10% Improvement Tax. The Delivery Manager should negotiate a standing agreement with the business sponsor: 10% of the team's capacity in every sprint is reserved exclusively for technical debt reduction, pipeline optimisation, and delivery process improvements identified in retrospectives. If the team's total capacity is 100 story points, only 90 points are allocated to business features; the remaining 10 points are dedicated to the retrospective action log.

This institutionalises continuous improvement. It ensures that retrospectives are not merely an academic exercise, but are actively funded and integrated into the delivery roadmap.

The Major Milestone Post-Mortem

While routine sprint retrospectives are essential for micro-optimisations, major programme milestones — such as a large-scale release, a global rollout, or the conclusion of the Hypercare support phase — demand a comprehensive Post-Mortem Retrospective. A milestone post-mortem is a complex strategic event. It looks across multiple months of work, hundreds of deployments, and the interactions of dozens of stakeholders. The objective is to capture macro-lessons that can reshape the organisation’s long-term Salesforce delivery capability.

1. Stakeholder Segmentation

Unlike a sprint retrospective, which is restricted to the immediate delivery team, a milestone post-mortem must capture inputs from three distinct stakeholder groups, each with their own unique perspective on delivery success:

• The Delivery and Implementation Team (Architects, Developers, BAs, QA): Focuses on technical execution, pipeline reliability, requirement clarity, environment stability, and work-life balance.
• The Business Sponsors and Product Owners: Focuses on value realisation, scope management, speed-to-market, budget adherence, and steering governance efficiency.
• The End Users and Operational Support (Helpdesk, Operations): Focuses on system usability, performance, training quality, documentation clarity, and the stability of the system post-go-live.

To capture these inputs without creating an unmanageable, emotionally charged workshop, the Delivery Manager should conduct pre-workshop interviews or distribute anonymous surveys to each group. This allows stakeholders to express sensitive concerns privately, which the facilitator can then synthesise and present as aggregated, anonymous themes during the main workshop.

2. Analysing Delivery Telemetry

A milestone post-mortem must evaluate the programme's actual performance against its initial quality and speed targets. Delivery leaders should compile and present the following telemetry:

• UAT Defect Analytics: Total defects logged, defect distribution by severity, and defect reopen rate (indicating how many bugs had to be fixed multiple times).
• Production Deployment Health: Total deployments, success rate on first attempt, average deployment window duration, and count of emergency patches or hotfixes.
• Hypercare Ticket Volume: The volume, category, and average resolution time of support cases logged by end users during the first two to four weeks post-go-live.
• Estimate Deviation: The variance between estimated story points during initial release planning and the actual story points completed during execution.

3. Institutional Learning and Knowledge Management

A retrospective that does not document its findings in a searchable, permanent format is a wasted opportunity. The lessons learned must be institutionalised so that future project teams do not repeat the same mistakes.

• Create an Architecture Decision Record (ADR) Library: For any major architectural pivots made during the project (such as migrating from an old custom apex sharing solution to Restriction Rules), document the decision context, the alternatives considered, and the final rationale.
• Build a "Lessons Learned" Repository: Maintain a centralised, tagged repository of delivery lessons. Tag issues by platform domain (such as CPQ, Omnistudio, CI/CD, Marketing Cloud) and delivery phase (Discovery, Build, UAT, Cutover). When a new project starts discovery, the project manager and lead architect must review the repository as a mandatory governance step.
• Update the Organisational Salesforce Playbook: The standard delivery standards — such as the Definition of Ready, Definition of Done, coding standards, and deployment runbooks — must be treated as living documents. The systemic actions identified in the post-mortem must be immediately codified into this master playbook.

By formalising this process, you transform the retrospective from a brief, post-project meeting into a powerful engine for organisational maturity and long-term delivery excellence.