In the general business sense, being agile is often used to describe how well a business can adapt to external and internal changes. When an organisation talks about “going agile” they’re talking about reviewing and adjusting everything they do to ensure they can respond to continuous change.
For us at SalesFix, we know the world is not stationary, and your business can’t be either. If the past few months have taught us anything, it is that flexibility, communication and customer experience are key elements to success.
At its core, the agile method has values that drive these elements, particularly when applied to the implementation of a solution like Salesforce. These values are:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
Let’s look at these values in more detail.
| Value | Our take | Impact on projects and clients |
| Individuals and interactions over processes and tools. | We know process and tools are important, but how we interact with you is critical. Communication is key, developing trusting relationships even more so. Projects don’t fail because of technology, they fail because of a lack of communication and understanding. | Before you sign on the dotted line, we want everyone to have discussed and agreed how we’re going to approach things, what our expectations are, and how we’re going to measure success. We need to be part of your team from the get go, so let’s figure out how we work together. |
| Working software over comprehensive documentation. | The key word here is “comprehensive”. We will deliver your documentation, but we’ll deliver you a working solution first. | We’ll deliver a variety of documentation at multiple points during our engagement. But we’d rather get going and build a tangible outcome that you can review and give feedback on, rather than refine words that can be interpreted in multiple ways.
When the project starts, we’ll document requirements into a Solution Design Document, and often User Stories. These will guide our work when it comes to building your solution. But the critical thing is, THINGS WILL CHANGE. At the end, we’ll update our documentation to reflect what was actually built. |
| Customer collaboration over contract negotiation. | The best contract is one that is agreed, signed and left in the drawer, never to be seen again. If we have to resort to looking at the contract, it’s too late, things have already gone south. We would rather work as a team than be protagonists. | During the sales process, our documentation will outline how we’ve agreed to work together and what the expectations are around what we’ll deliver.
BUT neither of us can be 100% sure what we’re going to deliver until we actually start working together. This is why tenders typically don’t deliver the best outcomes. By the time you’ve defined your requirements to enough detail to go out to tender, then worked your way through a tender process, made a decision and started work, what you thought you wanted has completely changed! So, rather than spending weeks and weeks (sometimes months and months) trying to agree on the exact nature of what we’ll deliver together and writing that into a Statement of Work, we’d rather agree on some key fundamentals around how we’ll work together, set some expectations around what will be delivered, and agree a budget to work towards. |
| Responding to change over following a plan. | What we collectively decide as the way forward at the beginning, may not turn out to be right as we move forward. Let’s be open to change, have flexible thinking, and not get stuck doing something just because we said we would. | So we’ve agreed how we’re going to work together, got some agreed expectations and a budget to work within. Next, we document some requirements. Then we start building. As we build, we hit snags, we get feedback, the world changes, a whole heap of things happen that impact what we’re building. What was a priority during discovery, changes because the organisation’s priorities shift and change.
Rather than getting stuck down a rabbit hole, building something that will not fit your requirements at the end of the engagement, we ensure we’re constantly reviewing and revising our approach and decisions. |
You’ll notice in the above that there’s not a single value about having an open cheque book, or lack of clarity over what’s being built. We build to a budget. We deliver to an agreed expectation of what impact we’re going to collectively have on your business.
Does that mean we’ll never go over budget? No, but it does mean we’ll discuss and agree the best path forward. We’ll either de-scope items, re-prioritise or make things more simple. Sometimes we’ll both agree that actually spending a little bit more will result in a good outcome for the business and a change will be agreed.
There’s also not a lot in these values about the technology itself. They’re all about how we behave and interact with each other. That’s because we think the people we work with are far more important than the technology we’re delivering. We know we’ve picked the best solution, Salesforce, now come and pick the best team!
