Demystifying Agile: a guide to working successfully with your Salesforce consultant
Did your Salesforce consultant tell you they are using the Agile Methodology and you’re not quite sure what that means? Did your Salesforce consultant not mention Agile at all? Either way, we’ll help you understand what Agile means for you and why we think it’s the best way for you to get the most out of your Salesforce consulting project.
The Agile manifesto is simple:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
In a nutshell, the Agile approach is about getting you what you need to do your job as efficiently as possible. Agile recognizes that you probably don’t know every detail of what you need up front and builds in the flexibility to adapt to changes as they emerge. What organization would not want a system that works and is responsive to the changing business needs?
Our goal is to help you understand how your organization can harness the benefits of Agile as you embark on your next Salesforce project. We’ll give you an overview of the process and define some basic terms while highlighting how Agile helps you, the client, get the most out of your project. We encourage you to respond with questions. We’re here to help!
So why should you want to hear your Salesforce consultants talking “Agile”? Simply put, it puts you in control. You decide what’s most important to you; you get to make changes when you need to; and, most important, the project becomes a truly collaborative process where you and your consultants work as partners toward the same goal.
The Team is the foundation of any project. It, of course, includes you and your consulting partners, but we also encourage you to think of your team as including (maybe by proxy) any other direct or indirect users of Salesforce. People like your fundraising and/or program management teams, your executive team, your donors or program beneficiaries, even other systems (e.g. email marketing, financial, website) that might interact with Salesforce. You may serve as proxy for some members of your team (especially those external to your organization), but by thinking broadly, you make sure everyone’s needs are considered.
The Agile method is driven by User Stories, brief statements each of which articulates a specific goal and identifies who the goal serves and what it accomplishes. Here are a few examples: 
As you write them, you’ll add User Stories to the Product Backlog. The Product Backlog is the list of all the ideas you might want to tackle during the project. You probably won’t get to all of them – some of them you’ll decide aren’t such good ideas after all, others might be nice to have, but you’ll ultimately decide they aren’t worth the cost or don’t fit in your current budget. Agile gives you the flexibility to decide what’s most important to you.
That all sounds nice, you might be thinking, but when do we get to the part where we actually get stuff done? That’s where the Sprint comes in. A Sprint is a short development cycle – it might be as short as a week or two on a very small project and even on the largest, most complex project, probably won’t be longer than a couple of months. A small project may have as little as just one Sprint, although most projects will have at least a few and bigger projects could have lots. 
Which brings us to the final key element of the Agile approach: the Working Product. Unless you are starting from scratch with no system (in which case it will take a Sprint before you have something going), one of the most important advantages of the Agile method is that you always have a working system and that at the end of each Sprint, the newly completed User Stories are added to the Working Product. Unlike more traditional development approaches, with Agile you don’t have to wait until the end of the project to start reaping the benefits. Do you really need that large donation list from our example above? Add it to the next Sprint and you’ll have it ready to go very soon – you don’t have to wait until everything else is done, or even until the change it appears to depend on is done.
DaizyLogik 