Salesforce + Agile: The Delivery Model Most CRM Projects Skip
Salesforce implementations consistently overrun and underdeliver not because of the platform, but because teams default to waterfall delivery. Applying Agile principles to CRM projects changes outcomes dramatically.
Why Salesforce Projects Default to Waterfall
Salesforce is a mature, configurable platform with extensive documentation, a rich ecosystem of certified consultants, and a decades-long track record in enterprise CRM. And yet Salesforce implementation projects fail or significantly overrun at rates that surprise even experienced IT leaders. A 2023 Gartner report found that more than 50% of CRM implementations fail to meet their original business objectives. The reason is almost never the platform. It is the delivery model. Most Salesforce projects are run as waterfall programs: a requirements phase that attempts to specify every process, field, workflow, and integration in advance; a build phase that translates those requirements into configuration and development; a testing phase that discovers how much has changed since requirements were written; and a go-live that drops a largely unfamiliar system on end users who had little input into its design. This model was already struggling in custom software contexts. Applied to Salesforce where business requirements evolve rapidly, stakeholder expectations shift continuously, and the platform itself releases major updates three times a year it is almost guaranteed to produce outcomes that disappoint.
How Waterfall Specifically Hurts CRM Delivery
The damage waterfall does to Salesforce projects is specific and predictable. Requirements gathered in month one are based on how the business currently operates but by the time those requirements are built and tested six months later, the business has changed. Sales territories have been restructured. A new product line has been added. A key process owner has left and their replacement has different views on how the pipeline should work. The waterfall plan has no mechanism for incorporating these changes without disrupting the build phase, so the project either absorbs scope creep informally (driving cost and schedule overruns) or ships a system that reflects how the business operated at the start of the project rather than how it operates now. CRM is also one of the most stakeholder-intensive systems in any enterprise sales, marketing, service, operations, finance, and executive leadership all have opinions about how it should work. Waterfall's front-loaded requirements process cannot surface or reconcile those opinions in a way that produces durable decisions. End users who were not consulted during requirements gathering routinely reject the delivered system, driving the adoption failures that are among the most common and costly outcomes of waterfall CRM programs.
What Agile Looks Like Applied to a Salesforce Project
Agile Salesforce delivery replaces the big-bang requirements-and-build model with iterative releases that put working software in front of stakeholders every two to four weeks. The project begins with a Discovery sprint: a focused, time-boxed effort to align on the highest-priority business outcomes, identify the value streams the CRM must support, and define a product backlog that represents the team's current best understanding of what needs to be built without attempting to specify everything upfront. That backlog is then delivered sprint by sprint, with each sprint producing demonstrable Salesforce configuration or development that stakeholders can review and respond to. Feedback gathered in each sprint review shapes the next sprint's priorities. Features that turn out to be lower-value than anticipated can be deprioritized. Features that emerge as critical based on what stakeholders see in working software can be pulled forward. The delivered system reflects the business as it is at go-live, not as it was described twelve months earlier. Crucially, end users engage with working functionality throughout the project, not just at UAT which means adoption issues surface and are resolved long before they become go-live crises.
Structuring Sprints Around Configuration vs. Custom Development
One of the most important architectural decisions in an Agile Salesforce program is how to handle the inherent difference between declarative configuration page layouts, validation rules, flows, process automation and custom development: Apex triggers, Lightning Web Components, and platform integrations. Configuration is fast to deliver, fast to change, and carries low technical risk. Custom development is slower, carries higher risk, and is significantly more expensive to revise. Agile delivery disciplines should treat these differently. Sprint planning should deliberately front-load configuration-based features in early sprints, for two reasons: configuration delivers demonstrable value quickly, building stakeholder confidence and generating useful feedback; and early configuration work validates the data model and process assumptions that custom development will later depend on. Custom development should be pushed as late in the backlog as confidence in the underlying requirements allows. Any Apex or LWC work driven by requirements that are still evolving is likely to be rewritten a predictable and avoidable waste. The Salesforce-specific principle is: configure as far as the platform will take you before writing a single line of code, and use Agile iteration to discover exactly where the boundary is.
Change Management as an Agile Discipline in CRM Rollouts
Change management is where more Salesforce implementations fail than in any technical dimension. A system that works correctly but that salespeople do not use delivers zero business value. Agile delivery changes the change management equation in a fundamental way: instead of a change management program that runs in parallel to a build phase and attempts to prepare users for a system they have never seen, Agile puts users in contact with working Salesforce functionality from sprint two or three onward. They see their actual process reflected in the system. They provide feedback that shapes the build. By the time the system is ready for full deployment, they have been using versions of it for months. Resistance drops dramatically when users feel that the system was built with their input rather than imposed on them. Sprint reviews should be designed as stakeholder engagement events, not just status reports the goal is to surface concerns, validate design decisions, and generate the kind of specific, actionable feedback that drives a better delivered system. Change management in an Agile CRM program is not a separate workstream; it is what the iterative delivery process is, done well.
Handling the Salesforce Release Cadence Within an Agile Cadence
Salesforce releases three major platform updates per year Spring, Summer, and Winter each of which can affect existing configuration, introduce new functionality that supersedes custom-built features, and require regression testing across the org. This platform release cadence is a significant planning challenge for waterfall programs, which have no natural mechanism for incorporating it mid-build. Agile programs are structurally better equipped to handle it. The sprint cadence provides a natural vehicle for pre-release sandbox testing: the team can evaluate a forthcoming Salesforce release in a sandbox two to four sprints before it reaches production, identify configuration or code changes required, and absorb those changes as sprint work without disrupting the overall delivery trajectory. More importantly, the Salesforce release cadence is actually an Agile opportunity: new platform capabilities delivered in seasonal releases frequently make it possible to replace custom Apex code with declarative configuration, reducing technical debt and ongoing maintenance cost. Teams running Agile programs are positioned to evaluate each Salesforce release against their backlog and incorporate relevant new features something waterfall programs, locked into fixed requirements, structurally cannot do.
What a Well-Run Agile Salesforce Program Actually Delivers
The business outcomes of Agile Salesforce delivery are consistent across organizations that have made the model work. Time to first value is dramatically shorter: instead of a twelve-month waterfall program followed by an at-risk go-live, the first production-ready capabilities can be in end users' hands within six to eight weeks of project start. Adoption rates are higher because users helped shape the system. Scope is better controlled because the iterative model makes trade-off decisions visible and deliberate rather than hidden in scope creep. Total cost of ownership is lower because configuration is favored over custom development and because requirements changes are absorbed as they occur rather than discovered at UAT when they are most expensive to address. And perhaps most importantly, the CRM actually reflects the way the business operates because it was built in continuous dialogue with the business rather than against a requirements document written before the project began. Salesforce is an outstanding platform. The organizations that get the most from it are the ones that deliver it the Agile way.
Ready to take the next step?
Talk to our experts about how we can help your organization apply these insights in practice.