Developing a Successful DevOps Operating Model

Implementing DevOps successfully is always perceived to be something that is extremely complex, requires deep technical know-how, access to tooling, and is obstructive to the day-to-day working of the project/implementation team but is that true?

Is that all true?

Today, I kick off with the first in what will be a series of articles that will help you understand the strategy, processes, and tooling necessary to be successful in your DevOps implementation in bite-size chunks by understanding the paradigm shift in how DevOps adds value to the business with a minimum set of tooling, establish ways of working, and best practices. In this article, I will cover in detail the fundamental paradigm shift in Salesforce DevOps and how the Salesforce release management landscape has evolved; my recommendations on how the industry can evolve to maximize value out of their Implementations.

Where is the Gap?!

Most DevOps implementations focus on the tooling necessary to release features to production or other environments and involve some combination of version control to manage code and metadata, a delivery tool to deploy features to these different environments after the build passes the necessary quality gates. In this entire process, the most important catalyst that is responsible for making any DevOps implementation successful is entirely missed, PEOPLE.?

Traditionally release management on Salesforce has been playing catch up to industry standards; now times have changed. As Salesforce continues to invest in moving the source of truth from Orgs based to version control, the advent of DevOps Center, Salesforce DX, tighter integration with Visual Studio Code, specialized release management products like Copado, Gearset, and Autorabit automating deployment; releasing features has never been easier, in theory.?

With boots on the ground, I often see a different story. Development to deployment is still plagued with issues, teams still struggle with merge conflicts, advanced tools are still used as a replacement to changesets, multiple validation failure, and that rogue field or apex class still finds its way into Production. The reason behind all this is that even though our tools have evolved our approach towards using them has not. This is where I have spent the last 3 months condensing my years of experience releasing successful and highly complex Salesforce solutions to develop a maturity model that can help small and enterprise teams alike to be successful in their Salesforce DevOps journey.?

The DevOps Maturity Model?

The DevOps maturity model starts by understanding a few key variables about your enterprise Salesforce delivery landscape:

1. Your current path to Production
2. Number of concurrent teams and dependencies
3. Teams' maturity with the tools and processes in place
4. Understand your as-is peak time to market performance

And if you are wondering, does this take weeks? The answer is NO! Using the service design methodology we can document your existing release management process and flush out the key risks, opportunities for improvement, and best-suited maturity model within a matter of hours. The end goal here is to help your Salesforce delivery teams to deliver quality features for your business, faster. From my experience, the road to success involves the following:?

1. Set Best Practices - You start by measuring and logging your current time from build to release, issues reported, debt, and code smells. Start by ensuring your teams follow best practices
2. Establish Clear Communication Channels - Create a release train so that your Build, Q.A., and Support teams are aligned for when a release will be made available to test and establish clear communication channels so all participants are kept in the loop?
3. Set Clear Roles & Responsibilities - Define clear boundaries and expectations so all team members are very clear on the role that they play to ensure a smooth build pipeline and quickie resolve defects as they arise?
4. Support Multiple Business Value Stream - With simple changes noted above you can start supporting more than 1 team, based on the business value. For example, team A is responsible for developing new features for an upcoming launch in parallel to team B which is supporting BAU enhancements & production issues.?
5. E2E Release Automation - All teams must strive to achieve a minimum level of release automation at each maturity model. At level 2 you start automating end-to-end releases and build a foundation to set up the model to scale to the next level where Production releases and hotfixes are automated.
6. Measurement & Acqualisation of Value - As your team grows and delivers business value faster, telemetry is of utmost importance. Start tracking your baseline (captured in the Setting Best Practices phase) vs current performance metrics this helps deduce the time, cost saved and value delivered.??
7. Governance & Continuous Improvement - Together with your team and our industry expertise we establish a continuous feedback loop to make sure we can retrospect and forecast issues, pain points, identify and implement strategies to alleviate them.??
8. Faster Alignment to Business Repivot - Business priorities change, and to support that change successfully your tools and processes need to be able to re-pivot and evolve. Tapping into our governance and improvement structures we atomize your DevOps landscape to transmogrify as per your business priority.
9. Enterprise Multi-Pod Value Stream - Salesforce is an amazing agile platform that complements the ever-changing business landscape. To deliver end-to-end value to your business it’s important to recognize that each team might be sitting at various levels of maturity. The DevOps Maturity model allows different pods broken down by value stream, business function, etc. to sit at different levels of maturity and still deliver value to their stakeholders at the expected pace.?

Conclusion

The key is to understand the operating maturity your team sits at, once identified you can begin the process of transforming your DevOps outcomes and align with your wider business goal. Each step in the assessment helps you move closer to that alignment.?

Using the above table you can map out which maturity model applies to your team at a high level (off-course there are more nuances to this assessment) but this is a really solid first step in the assessment. As we progress in this journey together we learn about,

• Using the right tools for the job
• Establishing baselines, and setting clear communications channels for teams
• End-to-end release automation
• How to track and measure improvements in your DevOps maturity.

If this resonates with you, have feedback, or have a story to tell hit the comments section and drop me a note.

Appendix

1. Multi-pod value stream
2. Salesforce DevOps Center

Nadeem Shaikh is a technology leader at the forefront of delivering innovative solutions that solve critical business problems across a variety of domains ranging from Financial Services, Energy, Human Resources, Health Care, and Social Impact. Enabling customer success by establishing efficient, performant, and cutting-edge technology solutions. Connect with Nadeem on LinkedIn, Twitter. Got ideas? Or wanna talk about #Strategy #Marketecture #Cricket #EnterpriseArchitecture set-up a call using Calendly