Go to portal
Salesforce is a CRM platform to enable organisations to close more deals with contact management, collaboration, marketing tools, and more! It’s actually a very powerful platform beyond a CRM, where you can build and run enterprise software applications. And with that it can of course be used for running your agile projects in Salesforce and within your agile teams. Although there are a number of apps to do this in the AppExchange, Salesforce has a managed package called the Agile Accelerator, which we will be using here to illustrate some of the examples.
Let’s explore how and why it’s beneficial through three easy to adopt steps. Interaction, timeboxing and collaboration.
Individuals and Interactions Over Processes and Tools
If you are familiar with agile values you’ll recognise this!
Through using agile processes to deliver Salesforce projects you are automatically shifting your mindset to having conversations with the team daily. Daily’s are everyday at the same time to answer three key questions:
- What have you completed since our last daily?
- What are you planning to complete until our next daily?
- Is there anything that hinders you from being able to achieve this?
This gives individuals and teams the optimum moment to commit to the team and to oneself to get stuff done. And note these are small chunks of work that will build towards the teams end of sprint goal.
How is this helpful in delivering Salesforce projects? The biggest impact in adopting Salesforce for through interactions is a visual representation of the work in progress enabling teams to see what is complete, what’s in progress and what’s not started so the team can pick up user stories throughout the sprint.
Through the eyes of the Agile Accelerator it looks like this:
As you can see you can customise columns as needed to meet the individual Salesforce projects.
Responding to Change Over Following a Plan
Let’s reflect again on the agile values. What this means is that rather than planning and designing the entire project with the minimal knowledge that you have in the initial stages as you would in a traditional project process; you are breaking down the product into a minimal viable product (MVP) that has the potential to be released at the end of a set amount of time, known as; timeboxing. But most importantly breaking the product down in an iterative design allows you to respond to change quickly from feedback of your end users, so you are not accumulating waste through time, quality or in monetary terms.
Every timebox being from either 1-4 weeks, you deliver your user stories that build the MVP of which ‘the what’ has been developed by your users and then organised by the product owner. Here you are able to adapt to change with regular feedback from customers, in which the development team self organises to deliver in that agreed timebox.
How is this helpful in delivering Salesforce projects? One of the benefits of Salesforce is that declarative development is first and foremost. So when a new user story comes in or an enhancement, support ticket… ask the team what is the very minimum that we can deploy to gain the fastest feedback from users and gain the early return on investment? And following best practice of Salesforce, ask first; can this be done using “click not code”?
And following this if the user stories are not a priority to be brought into that sprint, it should then be put in the a one dimensional backlog, which takes the form of a backlog manager in Agile Accelerator.
Customer Collaboration over Contract Negotiation
Lastly, collaboration. A fundamental value to beginning an agile journey. Without collaboration agile doesn’t exist. Inturn with customers projects don’t exist. We are part of an ever evolving world, with fast action and new requirements which develop hourly, daily, weekly but most definitely within the project lifecycle. Without continuous collaboration with our customers we head towards a high chance of project failure, a failure to meet the customer needs.
The pressure of delivery, keeping within scope, budget and quality blinds us from the real purpose of which is giving the customer what they need in order to improve users experience and return of investment. And this is where agile thrives, when using agile cycles this gives you a detailed scope, budget and quality committed by the team but with the added bonus of being delivered within that 1 or 2 weeks timebox. The flex being in the features, where the MVP lays.
Step by step thinking and literal illustrations out ‘the What’ needs to happen, then ‘the How’ to design & build it, regardless of that being; flows, sharing or validation rules, new fields, page layouts, new profiles etc. it’s important that the customer and the development team collaborate in understanding and building the requirements together.
How is this helpful in delivering Salesforce projects? This is where your product owner role comes to play again. They are a powerful role to emphasize the product vision. The why we are doing this, what value does the organisation gain from this. The product owner represents the customers wants and needs ultimately so working closely with them is imperative to ensure that the team is aligned on the business vision.
Final Thoughts
And for a bonus round, let’s take a quick look at the fourth agile value: Working software over comprehensive documentation. This focuses on documentation being valuable where and when needed, but it should not impede on software development. Documentation gets stale, and long winded documentation rarely gets referred to, let alone read. When running your Salesforce project, make sure you document what is needed in order to meet the deployment and legal requirements. Not nice to haves, wants or documenting items that within days will become obsolete. Realise that yours and the team’s time is precious. Focus on those that will bring value and return of investment to your organisation.
I hope this has given you better insight into how agile and Salesforce projects are a successful journey to embark on.
What have you found to be best practice in deploying Salesforce projects?
