[Guest Post] – Agile and CRM

[Guest Post by Tommy Ball, Agile BA, ScrumMaster and CRM Specialist]

Can SCRUM be applied to CRM?

I find it difficult to work in an Agile way with the typical teams involved in a CRM deployment. However… I have developed a highly effective way of making it work.

One challenge is wasting time treating each little sequential task (e.g. in Salesforce setting up validation rules, roles, field level security) as a separate story, requiring MORE time documenting things in a tool like Pivotal Tracker, then actually performing the tasks themselves. Because there are many sequential tasks with CRM. So many that documenting as individual stories takes an excessive amount of time, thus hindering rather than helping progress. What happens is when you apply true Agile, I’m finding, is that organizations STILL get hung up in too much PROCESS and DOCUMENTATION especially with new Agile teams, which almost all Salesforce CRM teams are. And what does the Manifesto say about a little concept about less documenting, more deliverables, less process, more collaboration, don’t get hung up on tools??? Right??? It’s important to stick to the principles we all live by, but with CRM, allow for flexibility in order to keep things moving effectively.

I’ve been addressing this on-going issue of applying Agile to CRM for years now. Running a Salesforce project is drastically different from a Rails project. And both need its own approach. Alistair Cockburn and people in his realm have many Agile offshoot methodologies specific to software dev, but no one has tackled using Agile for CRM. Ironically, Salesforce themselves us Agile and have a very successful internal adoption model.

Basically, all the sequential tasks (aka theme or mega-story) that need to occur in order to establish a key piece of functionality, often a with group of sequential tasks that other parts are codependent on, it’s important that all the tasks for that major function (e.g. establishing field level security for all CRM users, which involves several tasks) be grouped together in order to complete the function or “theme” if you will.

So, in this case combining sequential tasks into mega-stories, or themes, and still assigning points and tracking velocity, but group tasks within a large process or function (theme), all together, with story points assigned to the entire theme, incorporated into a sprint (analyze, configure and setup, test, release, demo), still have daily stand-ups like usually works.

The key for me is the ability to be flexible, sticking to a 1 week sprint, mainly because Salesforce can be setup that quickly if the team approaches from a theme level, often working in parallel with other teams (aka paired teams or XT-extreme teams). However the database migration team may take a different approach although working on the sale project together.

Often times 2 teams work in parallel, one focusing on process analysis, defining business rules, workflow, building use cases, setting up 3rd party integration, and often, even developing custom Salesforce aps. The other team focuses on the data – cleansing, scrubbing, duping, field source mapping, etc.). It’s good to align each group so team 1 working on business logic, can test each function (aka theme) against the data being brought over. I call this paired teams, or XT, similar to pair programming or XP, but on a larger scale. A situation involving data migration with BAD data may lend itself a waterfall, depending on the integrity of the data you are migrating.


As long as you group stories that must follow a sequence into themes, treat as mega-stories, and finish each after every step of the sequence has been completed, then test, and release, and demo every 2 weeks, this version of Agile I’ve developed, called CRMSCRUM, is highly effective, sometimes to the point where you sometimes can move with UNLIMITED VELOCITY. It just takes the right combination of team commitment, solid well-skilled Salesforce SME’s serving multiple roles, and a flexible mind set, but not to the point where you break key Agile principles, This technique I call CRMSCRUM used to deploy systems such as Salesforce with has proven to deliver with exceptional speed, efficiency, and perfect alignment with stakeholder vision.


Thoughts on this? Let me know in the comments!

12 Replies to “[Guest Post] – Agile and CRM”

  1. Agile brings an interesting approach to CRM based on themes instead of individual. What I do not understand is how this is done in practice in an ERP environment(eg. Salesforce). Are the themes selected from pre-determined tasks in the system?

    1. Yes, and all story-related tasks must follow proper sequence in order to achieve desired function, thus the story grouping (themes). Salesforce communicates CRM2ERP (e.g., J.D. Edwards) often, bi-directionally, for billing and pricing synchronization. CRM2ERP integration is (often) so complex, from a billing and pricing integration perspective (ERP2CRM), data specialists from both (ERP & CRM) sides work together on the same Scrum teams, openly addressing some of integration challenges required to keep CRM2ERP and ERP2CRM in synch.

  2. Please, can you explain the organization of the group?. For example, where are the business analysts?
    And, do you make a WBS before to run the sprints? How do you know the scope? How do you prioritize it?

    1. Angel, thanks for the note.
      FUNCTIONAL Saleforce teams, all Saleforce expertise to some extent, that looks something like this:
      Product Owner, Scrum Master, BA, SME, SFDC ADMIN, UAT Team, that can also serve as pilot group. This way EVERYONE can contibute simuntaneously (NO WAITING FOR YOUR NEXT TASK ON OUR TEAM) and keep the sprint on track. I’ve been a SME, Project Owner, Scrum Master, and BA, often at once :-), so regardless of WHAT ROLE I play on the team, I can always contribute. As can everyone else on the team ideally.

      FYI, strong BA’s with strong Saleforce skills are GOLDEN! They can really help with the WBS, among many many other things.

      And yes, extensive WBS, or BPR Anlysis (aka business review & process analysis), as I call it, is done prior to any design work and is the blueprint in which to work from. Detailed Process Analysis and sometimes, even re-engineering, is required prior to commenement, with stakeholder sign-off of course.

      This keeps you at Sprint Zero a little longer. However, it speeds up delivery time by eliminating design decisions (that can take FOREVER)that were aleady ironed out in Sprint Zero.

      With Salesforce, there are 2 areas to consider:
      1. Major functions MUST be sequenced in the proper order – that helps dictate the SOW and priorities to a major degree. It’s technically “ready made, out of the box” so is fairly easy until higher functions like workflow rules and triggers, assignment rules, approvals, etc, are added. And each function (e.g. Setup Cases Object with proper assignment rules so that IT Help Desk Users will recieve initial support requests) are prioritized and scoped the usual way – priority is given functions that will return the most value to the business.
      2. Custom Saleforce Applications are treated like any app and prioritized the same way.


Leave a Reply