post 2-17 c

Making Salesforce Agile

Recently there has been more and more call for custom Salesforce development, prompting teams to explore how they can adopt Agile practices on a declarative platform.

For many of the enterprise and Fortune 500 teams I’ve worked with recently it’s becoming a pressing problem. Bluewolf’s State of Salesforce report for 2016 found

“77% think their company could be doing more with their Salesforce investments.”

Salesforce is of course aware of the problem and just this month, launched their answer (DX) in pilot mode. But it’s still a ways off for the typical customer.

While that solution is still rolling out, teams have turned to third party tools such as Flosum, AutoRabit, Copado, Gearset, and others.

The Cloud Is Heavy With Customization

In recent years, Salesforce has expanded their offerings to help businesses port more and more legacy applications to the cloud. From their flagship Sales cloud they’ve added Service, Data and Collaboration clouds,, RememdyForce, Heroku, IoT, AI and more to come!

Not only is there more standard product to configure manage, but each leads to more business requests for customization. Then there is the call for custom apps on top of the rest!

“79% of IT teams are currently developing apps for customers, partners, and employees.” -Salesforce State of IT report.

This extra complexity and demand for apps by itself is enough to raise the call for tools. But when coupled with increased security and compliance requirements that the older legacy apps carried, it is creating some real IT migraines.

Some teams respond by slowing things down in order to maintain control. That of course kills ROI and the reason for moving to the cloud in the first place. Other teams gallantly try to cobble together something reminiscent of an agile process they knew from outside the Salesforce world, using homegrown or third-party tools.

The Devil is in the Declarative Details – what about the admins?

When trying to make Salesforce development more agile, teams quickly bump into the issue of how to integrate the non-programmers, the declarative programmers and point & click admins into the mix. Both need to work on the same objects for instance, without overwriting each other’s work.

The non-programmers are there, they’re adding plenty of value, and they need to work alongside their counterparts. They can amount to 50-90% of the members on teams relevant to this discussion. Other teams are 100% point and click, and even they need more tools to do a better job.

Where does the point & click admin fit into an agile development process? Can we have “Agile Point & Click” or some sort of hybrid dual-track Programmatic and Declarative Agile Process?

What does that look like? Ideally the tools would be as simple to use as Salesforce itself. They would offer a simple UI, but with enough flexibility and power to do the job, both now and into the future as complexity continues to build.

Right now that space belongs to Flosum alone, with its native SFDC app providing a familiar and easy UI.

Salesforce DX hopefully will fulfill that mission too – an easy UI on a powerful tool – but it’s not available yet and is likely a ways off for the Point & Click crowd. They can’t neglect the core constituents who made Salesforce what it is!

#SFDC #Salesforce

0 replies

Leave a Reply

Want to join the discussion?
Feel free to contribute!

Leave a Reply

Your email address will not be published. Required fields are marked *