Description
Catch up on this webinar with Claudia McPhail (Sales Engineer at Gearset) as she discusses how to identify how mature your DevOps strategy is, the steps that your team can take to improve their maturity, the value of robust processes and tools and great tools and resources that can be used to measure your maturity.
Topics covered:
- The key components of DevOps maturity
- Measuring performance
- Maturity of processes
- The different stages of maturity
- How to identify your own maturity
Learn more:
- Salesforce DevOps—what is it, and why’s everyone talking about it?
- 5 ways to improve your Salesforce DevOps strategy
- Salesforce DevOps maturity assessment
- The State of Salesforce DevOps 2024
- See how Fluence progressed from deployments to full DevOps maturity with Gearset
Related videos:
Transcript
So first of all, hello. Thank you for taking the time to join us today for our talk about DevOps maturity. We're going to be looking at how measuring DevOps maturity and performance can elevate Salesforce teams. Let me start with an introduction of myself.
I'm Claudine MacPhail. I'm one of the sales engineers here here at Gearset. I've been with Gearset a few years now, and I partner with our customers and our various, existing prospective customers as well as well as other parts ecosystem to talk about how we can consult on current Salesforce DevOps practices and how we can assess maturity and current performance to really elevate that to make people's lives easier and, make teams more productive as well.
So you're probably aware by now of the value that DevOps can bring in business, and most likely, you're taking steps to improve your DevOps strategy. But you may find yourself wondering, how advanced is my team? Am I doing DevOps right?
In this session, I'll be helping you to identify how advanced or mature your own DevOps strategy is.
To do this, I'll first discuss what we mean when we say maturity.
Maturity can be measured in two ways, your DevOps performance as well as how advanced your processes are. So we'll take some time to explore how to measure these two aspects.
I'll then run through five stages of maturity and outline what characteristics a team at each stage might have.
This will include identifying key actions that teams can take to become more mature in their DevOps processes and also why it's important to implement robust DevOps processes and tools.
Finally, I'll briefly discuss resources that you can use to measure your own performance and maturity to help you identify what next steps need to be taken to advance your own DevOps processes.
Before we start, here's a quick definition of DevOps. DevOps helps Salesforce teams to drive business growth by making release cycles faster, more secure, and less error prone.
Teams with a robust DevOps strategy will be embracing practices such as version control, continuous integration, automated testing, and backup.
When determining how advanced a team is when it comes to DevOps, we need to look at two things.
First, there is your DevOps performance.
This is a measure of how well you actually release and is based on standard industry metrics.
We'll go into these metrics in more detail in a moment.
Second, we look at the processes and tools you're using and measure how advanced they actually are.
For example, how are you currently testing your code? What tools are you using?
Typically, a team's maturity of processes will affect its performance.
As you adopt more DevOps processes, you will perform better.
So let's first look at performance.
There are a lot of metrics you can look at to determine your DevOps performance.
A good starting point are the four key metrics used by Google's Dora report to assess DevOps performance.
Those metrics are deployment frequency, which is how often your organization releases to production, lead time, the average time it takes to get a change into production, time to recover, which is the average period between an outage or production defect and the restoration of normal service, and change failure rate, which is a percentage of deployments causing a failure in production.
Take a moment now to think about what these four metrics are for your team.
How often do you release production? What is your lead time and recovery time? What percentage of your deployments cause a failure in production?
You can either note them down or share them in the chat.
We can broadly split these metrics into two categories, velocity and resilience.
Deployment frequency and lead time are measures of your velocity.
Time to recover and change failure rate are measures of your resilience.
Teams not only need to be fast but also resilient against disaster for truly effective DevOps.
But remember, metrics should be a means to an end, not an end by themselves.
It's possible to boost performance in an artificial way by getting fixated on metrics.
You should always have in mind what the real value is to the business that these metrics are designed to measure.
Shipping dozens of minuscule improvements in one day might look great according to these metrics. Does it really add real value to the business? Is it really making the business more agile?
The question you might be asking now is, how do I improve my performance?
Well, performance is really dependent on you, and it's really dependent on what DevOps processes you use in your release cycle.
For example, you won't have a good change failure rate or true org resilience without a robust backup and restore process.
Adopting more advanced DevOps processes should lead to a better performance.
So as well as assessing DevOps performance, you'll want to judge how advanced your tools and processes are. There are certain practices that will hold back your DevOps maturity just as there are new workflows that will help advance your DevOps maturity.
There are lots of processes that come into play here, but I've noted a few key ones here.
A mature team will be using automated unit testing, version control, static code analysis, CICD, automated end to end testing, and disaster recovery measures, including both data and metadata backups.
Like with performance metrics, have a think about your own team. Which of these processes are you already using? Feel free to just note them down or pop them in the chat as well.
When you have an idea of both your DevOps performance and the maturity of your processes, you can start to determine how mature your team is when it comes to DevOps.
We've broadly categorized DevOps maturity into five stages, novice, beginner, intermediate, advanced, and expert.
Of course, not everyone will neatly fit in to one of these categories, And DevOps adoption isn't always a linear process, but it's a rough starting point and helps us to identify the likely challenges and possible next steps to take.
The first stage is novice.
Teams in this stage haven't really started DevOps adoption. They deploy to production very infrequently, and long running in org projects mean changes often wait for a long time before being released.
When the changes are released, there's normally a lot to deploy all in one go, which means deployments are tricky and time consuming, and a higher likelihood of post deployment issues occurs.
These teams are almost always using change sets, and pretty much everything to do with the perform with a deployment is performed manually.
Moving away from change sets is an important way to graduate beyond the novice stage, will dramatically speed up deployment time as well as increase deployment success rate.
For example, teams using gear set for their deployments do so up to twelve times faster than change sets. And on average, ninety two percent of their deployments exceed the first time that they are attempted.
Next, we have the beginner.
Beginner teams have realized that change sets can be a bottleneck for them, for teams wanting to make more frequent or complex changes.
They're usually using a third party tool for their deployments instead.
They still don't deploy that frequently, and when they do, it's still directly org to org. But it happens more frequently than before because their talks have made it less painful.
In this group, there's still no true version control adoption or other types of automation.
But beginner teams occasionally use version control as a metadata backup, where they periodically commit the metadata from production to version control.
Although this isn't using version control for true source driven development, it does help teams familiarize themselves with the basics of interacting with Git.
To move to the next step here, teams need to adopt version control more fully.
Version control lays the foundation that will unlock all the benefits of a mature DevOps process.
So stage three here is intermediate.
These folks are a good way along the DevOps journey.
They're usually releasing at the end of weekly or biweekly sprints, But long running projects aren't always released in slices, so some change can still be left waiting to deploy for months.
These teams normally use version control as a source of truth for at least some metadata types.
Some changes are still made outside of a source driven process, usually due to siloed admin and dev teams.
Teams that are new to using version control might be using it in a slightly unconventional way that mirrors their old process rather than the way that it would be most impactful.
However, version control opens the doors to automation, and it's common to see continuous integration and a move towards the process of continuous delivery at this stage.
At least the earlier environments in their release pipeline, such as integration or UAT. Naming convention will, of course, vary from team to team.
But teams are probably still struggling to get automation to work fully or maybe experiencing stalled CI jobs.
The key to moving beyond the stage is to make the most of automation and adopt robust version control workflows across all areas of the team.
Teams in stage four are advanced.
They release at least once per sprint and features rarely languish for longer than a sprint without being released.
Their lead time may be slowed down, however, as they often depend on external teams for approvals.
Version control is used as the source of truth, and most metadata types are deployed via version control.
On the whole, the entire team are following the same process using tools that suit them. Some might use the DX and Git CLIs.
Others might use third party tools like Gearset to get their changes into and out of Git.
But regardless of the exact tool they use, the process is the same.
They've also unlocked the benefits of end to end CICD, which saves time and increases agility for them.
Key way to move beyond the stage is to make sure the process is reliable and resilient with automated and on demand backups of meta data and data integrated into the DevOps cycle to allow for a rapid and accurate recovery when things go wrong.
The last stage is expert, and it's actually quite rare to find a team ticking all of these boxes.
A team like this has managed to overcome the organizational challenges that hold teams in the advanced category back, which means they have few or no external dependencies slowing down the change process.
They ship regularly, often daily.
And whenever they've got new changes to deliver, they will be able to ship those immediately.
The frequency of shipping dramatically reduces the complexity of their process because they only rarely need to hold on to subset of changes back at release time. I'm sure you've all experienced this where you have a set of several changes, And although the majority of them are ready to go, they're being held back by a subset of changes which have actually not passed the requisite testing or are erroring for some unknown reason, and the entire process has slowed down.
Backup adoption is this group in this group is high. Having robust backup and restore tools, processes, and strategies ensures business continuity in the case of a disaster and gives teams the confidence to introduce innovative solutions because they trust their release process and its recoverability.
Hopefully, running through those five stages should help you identify your own maturity and think about what new processes should be to focus your next step.
It's important to remember, DevOps is a marathon and not a sprint.
Improving your DevOps maturity will involve a gradual process of adopting these best practices.
Certain practices like continuous integration jobs are really only effective when other processes like version control have been mastered.
With each incremental improvement, a team will move towards a more agile and automated release cycle and closer to that expert level of having the robust and resilient development and deployment process.
A final thing to note, although potentially the most important thing, is the cultural challenge of DevOps.
The more I work in DevOps for Salesforce, the more I think that this is actually one of the most fundamental things that holds teams back from becoming truly high performing.
Even if your processes look great, if your performance doesn't match up, you may be facing cultural challenges.
And I'm sure many in the audience can relate to these items.
There are two key challenges that I see teams coming up against over and over again.
People and teams will have patterns of working that can be hard to break out of.
What can sometimes happen is the teams add in technological improvements without critically assessing where the difficulties in the original process lie.
Also, some team members will be more likely to deploy outside of their defined release process if they don't understand why that process is in place. Having buy in from the entire team and understanding why we have this process is essential to making sure that everyone is deploying using the same pathway and the same method so that we're all using these processes properly.
Once the team is working effectively, the biggest bottleneck then can become interaction with other teams.
For example, acceptance testing.
In the handover between the dev team and the business users who perform acceptance testing, this means that features can get held up in UAT because at this point, we're exchanging responsibility, and we're also being having to introduce an element of communicating our findings back and forth between those two teams.
Of course, this absolutely isn't the fault of anyone doing the acceptance testing or the developers themselves. It's just a simple lack of alignment between those two teams. And sometimes we can see that processes like these that require handoffs between silos experience a time sync at this stage in the process.
It is important to keep the cultural team aspect of DevOps in mind when optimizing your processes and making sure that everyone has bought into the new workflows.
Like I said before, the buy in is one of the most essential parts of all of this. Making sure that we have the cultural shift in addition to processes and toolings being introduced into the process is what will really elevate the teams as a whole.
Coming back to the final point here, assessing and identifying your team's DevOps maturity and performance is an important step, and you have to carry this out so that you know where you stand.
Only then can you figure out what next steps can be taken to improve.
We have a few resources that can help you with this, and I would encourage you to check them out as soon as you can, to allow you to assess your own team's maturity and to better and more precisely target where you could improve on the performance, the tooling, or the cultural shift.
At Gearset, we're currently working on a reporting API, which will analyze how you are performing across the four key DORA metrics, which I mentioned earlier.
If you are already a gearset user, which I think many of you probably are, you can switch on the reporting API now from the pilot features page in gearset.
You can also find support documentation there, which will help you to get started.
If you're not yet a Gearset user, sign up for your free trial and give it a go.
You can do this at gearset dot com. It will have no obligations, and it's very easy to do.
The reporting API will be going general access very soon, at which point it will be available for all enterprise license holders.
One more helpful resource to see where you stand is our Salesforce DevOps assessment.
This assessment will ask you a number of questions about the current tools and processes that you use in your release cycle as well as key details about your performance.
This will then generate a report that you'll get access to instantly, which will show you where you are on your DevOps journey, how you're currently performing, and suggesting the next steps you can take.
To take the free assessment, you can go to gearset dot com forward slash assessment, and the link is on screen at the moment as well.
I'd encourage everyone who's on this to take this quiz and to find out where you stand in your current, DevOps maturity. I believe you'll find it very insightful in terms of judging how you might go about bringing your teams up to a higher level on that maturity matrix.
The session has been a whistle stop tour of DevOps maturity as well as how to measure both your DevOps performance and how mature your processes are. Hopefully, it has become clear that assessing these two aspects is crucial to helping you plan the next steps and your path to DevOps maturity.
Once you know where you're at, you can identify the practical changes that you want to achieve.
Think about what your company is looking to get out of Salesforce and create some goals, and think ahead.
Your current release process might just about support your current workload, but it may not do so as you continue to grow and scale.
Ideally, you want to mature your approach to DevOps to keep pace with business demand and not just to resolve acute pain points.
Implementing good practices now will pay off in the long run.
Next, you can build a road map to success.
Split the work up into manageable chunks. It's important not to rush ahead and layer on DevOps complexity too quickly.
It's a stepping stone approach to success.
Make sure you know what you want your process to look like before choosing your toolset.
Evaluate what you want to get done and then choose the right tools for the job.
If your tools and processes look mature, but your performance is lagging behind, the problem is most likely cultural.
Don't overlook culture as you aim for DevOps maturity. Make sure the team is aligned on what you want to achieve and understands why you're making a change.
New tools and processes will be essential, but it's your team who will make success of them.
Thank you for joining me today. If you want to chat about any of these topics more, you can reach out on gearset dot com, or you can send me an email, claudia at gearset dot com. Thank you.
Thank you so much, Claudia.
We do have some questions. So, the first one is, what are the most compelling arguments to actually encourage teams to move to the next stage of maturity of the maturity matrix?
Certainly.
I think Frank touched on this quite a lot actually earlier in his talk with, Paul Watkes.
And one of the main reasons that a team might want to move on to the next stage of maturity metrics is actually just quality of life improvements.
When we begin to use more advanced tooling and we see these cultural shifts in our teams that allow us to be more agile, we actually see significant time saved. We see less stress, placed on the developers or the admins who are making the changes. And we use this principle that we see in a lot of Google Store Institute reports, in fact, where we shift left.
Instead of everything coming down to the point of release day where we're merging our changes and then discovering issues, we want to discover those as early in the process as possible, and that's what a mature and well developed CICD process can give us. Likewise, we feel secure in making changes or innovations because we know that we have robust systems backing up our, backing up our process. So that when we are working as a team, we feel secure in our work that we're not going to lose it. We have great visibility into what our teammates are doing, and we know that we have checked and validated our work at the earliest part of the process rather than having to dread and worry about deployment days.
Thank you so much, Claudia, for answering that question.
Do we have any other questions?
Next one is for the those rare organizations that are in the top tier of DevOps maturity, are there any that are not in the tech space already? Is it achievable for organizations where tech isn't their primary focus already?
A fascinating question. Yes. It is possible. Absolutely. So we work with a wide range of customers, and I have worked with many teams myself in context of being a sales engineer. And, yes, regardless of whether or not a team is, sorry, or whether a company itself is in the tech space, it's absolutely possible to really elevate your process and make sure that your Salesforce development is at the highest level possible. Regardless of whether you're a manufacturer or you are creating, goods or services or you are in the tech space yourself, the implementation of good Salesforce DevOps can be done in any of those spaces.
All you really need is buy in from the team that are making the changes from the business to understand why you're making these changes as well to your process, And then the results will speak for themselves, and everyone will be able to benefit from that.
Someone has a question about the ROI and cultural challenges. Do you normally start working with the business and admin stakeholders during the very beginning stage of the DevOps process, or do we first achieve a type of process within one team and then ask other teams to adopt them after showing them the results?
It's a fascinating question again. So it will vary really depending on how we work with those particular teams and how they want to work as well. Quite often, we will see that where a team will initially adopt, ensure DevOps process. They'll get it working perfectly.
And in a sense, they become the center of excellence for the rest of the company. They become the model on which other teams within that company will be able to build. Obviously, this is specific to companies with multiple Salesforce development teams. We work with a wide range of customers who maybe have one large Salesforce team or multiple multiple smaller ones spread throughout the organization.
But it is useful often to have that one initial team who has a process that works really very well, and then from there, the expansion out into other areas of the company. Once you have one process working well that could be used as a model for others, they can see how those quality of life improvements are kind of filtering through to the people who are actually working on the platform, and they can see how they might want to implement that in their own teams as well.
Next question is how long should it take a team to get from novice to expert?
That's an that's an interesting question. So it's kind of how long is a piece of string, isn't it? So the phrasing of that is interesting as well. How long should it take a team to get from novice to expert?
So a team could get from novice to expert as quickly as they're able to start start using all these new tools and processes, adjust to it, learn how to use them. I don't know. Maybe if they're really clever, it could take a week. But, realistically, when we're talking about shifting these kind of larger business things, we might want to take a more slow and steady approach and say, okay. Well, we're going to start with an assessment. And I think that's always the most important part. Saying I want to level up from novice to expert is a great goal, but it has to begin with this really key part, which is assessing where you are currently.
Once you look internally and introspectively critically at how you currently work, you can say, well, there's a bit of a time sink here in my process. Well, this is a bottleneck or we're staying up late because of this particular kind of component.
Once you've analytically looked at your current process and you've understood it, then you can target your responses. And then once you see, well, actually, if we in integrate, automated unit testing and now we're no longer being held up from production deployments from test failures because we're doing all of our unit testing at a much earlier stage, maybe you're immediately leapfrogging your way up to, you know, the fourth stage already. But if it's something more, complex than that, then it might take longer. So, really, it will depend on the team itself. It will depend on the business and how much time they're willing to invest in this kind of critical self assessment.
But, within that kind of framework, if you're able to invest in looking at yourself critically, introspectively, and being willing to change, then it can be done very rapidly.
Great. Thank you for that answer. We should have time for one or two more questions.
What sort of questions do you ask teams to determine their maturity level?
That's an excellent question, and you can see them all in the DevOps assessment.
But a good example is how often do you release to production, or how many sandboxes are you currently using? If you're using hundreds of sandboxes, but you actually only actively developing a couple of them, but you're not using the others because it's been a while since they refreshed and they've got some legacy code in them, that's normally a sign that maybe there's less slightly less maturity there because you don't have a good system of, you know, back propagating your changes into the sandboxes or keeping them all active all at the same time. Another sign might be, are you using version control?
That's probably the most, telling factors. Are you using version control? Are you using a project management system? So whether you've adopted certain tools is a good gauge of, how mature, how, far along a team is on that matrix.
But also other things like how often your change is failing when they go to production, what's your change failure rate. It's a really, really key metric that we would look at.
