Aymeric Zito is the CEO of ProQuest Consulting. In this article, he discusses how ProQuest have been so successful using the Agile project methodology to deliver Salesforce projects.

Before we learn more about how Proquest uses Agile, can you tell us about your background and how you got started with Salesforce?
My background is in neuroscience and software engineering. I started my career programming enterprise web applications in Java J2E and moved to consulting after a few years. After working for two years as a Senior Consultant and Solution Architect at Macquarie Bank in Sydney, I had the opportunity to join ProQuest’s Salesforce team in 2012. That’s how I got started with the most powerful enterprise cloud platform in the world.

Can you tell us about your current role and typical day involved in Salesforce projects?

As CEO, I keep a finger on the pulse of our ongoing project execution. At ProQuest we’ve been delivering Salesforce solutions through a disciplined Agile Scrum framework for five years now. To date, we have completed 267 successful sprints and counting. Our current record is 38 sprints (with the same client) but we are just about to break it as we are currently running Sprint 36 with one of our fantastic customers in New Zealand.

‘Scrum’ and ‘Agile’ have become insanely popular terms in the IT space over the last decade to a point where most companies today pretend they are Agile. ProQuest doesn’t do ‘hybrid’ or ‘wet-agile’ or any of these different flavours of waterfall-with-a-daily-standup. We pride ourselves on being extremely aligned with the Agile Manifesto and the values of Scrum. We work hard to educate and show our clients the outstanding advantages of following this methodology to get their Salesforce implementation done. When we receive this type of feedback from our customers, it proves that we are on the right track:

Would you say Salesforce is well suited to using Agile? / Why?

The honest answer is yes and no. Of course yes, because Salesforce is an amazing platform where you can implement complex requirements in a matter of minutes through point-and-click configurations. It’s fantastic to get features ready for review, capture feedback, adjust, validate and deliver. All tedious infrastructure, security, and even UX design are mostly taken out of the equation. We go straight to the business value, and that’s what Agile is all about.

The main challenge when running agile delivery with Salesforce is continuous integration. Any efficient agile software environment should have automated build, testing and release launchable in the click of a button. With Salesforce, due to its multi-tenant cloud nature, it’s a little more complex . ‘Source code’ may be scattered across files, metadata and database entries and complexity can increase with installed packages that have their own way of storing their configuration. All in all, we have to manage the challenge of fully automating processes like releasing from one environment to another. Salesforce is starting to make big improvements in this area which is exciting.

Based on your experience, if an organization is just starting to use scrum to manage Salesforce projects, what would you recommend to focus on?

Educate yourself first. I always recommend to start by reading The Art of Doing Twice the Work in Half the Time from the co-creator of Scrum, Jeff Sutherland. Then attend the two-day Certified Scrum Master course from AxisAgile. This should give you a clear picture of what Scrum is all about and its non-negotiable core values that a lot of pretended ‘agilists’ don’t know about. There’s no point putting post-it notes on a whiteboard if you don’t understand the fundamentals. At the same time, reading hundreds of books won’t make you a Scrum Master. I like to say, ‘Scrum is just like meditation. We can tell you everything about it, you can read a lot about it, but until you’ve experienced it yourself, you will never really understand what it is about.’

To get started, focus on your Product Backlog. The key of Scrum efficiency is to continuously refine and prioritise the Product Backlog so the team can work on top priority items and deliver the highest possible business value at each of your two-week iterations. Empower your team to work together, take ownership, and make them responsible for delivering a high-quality, potentially shippable product at the end of each Sprint. Stick to the book, at least initially, and don’t try to bend the rules. Use the framework ceremonies and artefacts to support the process. You’ll see the magic happen very quickly.

Although it is possible to develop and deliver quickly with Salesforce, more and more Salesforce projects include integrations to other systems that cannot deliver along the same timeline. How do you suggest managing those situations?

Ha! That’s one of our Scrum Master interview questions. It depends how likely the team in charge of the other side of the integration is keen to work iteratively. Fail fast: a good practice is to start with one simple end-to-end stream. Allocate a Sprint to complete data mapping, handshake, connectivity, data flow and exception management. You will learn a lot from it. It will give you a clear picture of the pace you can expect for your integration implementation.

ProQuest uses the concept of a ‘successful’ sprint? How do you define a successful sprint and why is it important to measure successful sprints?

Again, we want to ensure across all our teams and projects, ProQuest has a consistent way of executing Scrum and complies with core Scrum principles. At the end of each Sprint, we go through a questionnaire with the client to confirm that quality, transparency, collaboration, business value, and continuous improvement have been delivered. Everyone knows that these items will be assessed, so the team keeps a strong focus on their elements. So far, all of our 267 sprints have been successful, and we plan to keep it this way.