You can’t optimize what you cannot or do not measure. Without an understanding of your current processes and performance, you can’t assess inefficiencies, waste or opportunities for improvement. And while this concept is pretty simple, actually implementing this type of tracking can be a big challenge for software development teams.
Work optimization for any department accelerates time to value, but most IT deliverables are solely developed to enable other parts of the business. There’s no concrete product to measure; rather, value primarily comes from the increased productivity the business sees when they use the applications and features that IT teams build. The faster a business can leverage new Salesforce capabilities, the faster they’ll realize ROI.
So how can IT get these capabilities to the business faster? First, they’ll need to understand their value stream—their process for delivering business capabilities that drive financial value. When they understand their value stream and performance within it, they gain the visibility and insights they need to address inefficiencies, reduce waste and improve quality.
Value Stream Maps & the Salesforce Delivery Process
Mapping the value stream of your Salesforce delivery process helps you unlock opportunities to drive more value. It’s not a secret that Salesforce deployments can be difficult. Even if your team is working hard, they may still struggle to deliver quality work on time. Since you cannot physically see where breakdowns in your process are happening, you need to map out each stage of your delivery process: planning, architect review, development, testing, change approval, and release.
Once you’ve mapped your process and value stream, you can begin quantifying performance at each stage of the process. The visualization of the map along with performance at each stage helps you quickly identify bottlenecks, inefficiencies and risk. In general, there are four key metrics to assess across the value stream: lead time, deployment frequency, change failure rate and recovery time. Let’s take a look at how these help teams identify waste and opportunities for improvement across the software delivery lifecycle.
Lead time measures how long it takes to release a feature after development is complete. Remember, the applications and features that IT builds are only valuable when they’re in the hands of end-users, so if a company has a longer-than-average lead time, they may not be reaching their highest potential ROI.
Tracking lead time and benchmarking it to your industry peers, previous performance or even other development teams in your organization helps first understand if you have a potential bottleneck. Ideally, your lead time should be minimal with QA teams promoting work upstream on a daily basis.
To reduce your lead time you may need to reduce the size of user stories or the amount of users stories developers are working on. Developers should focus on one user story at a time, finishing and delivering current work before starting a new user story. Agile methodologies are rooted in continually pushing work through the development lifecycle, so when developers focus on finishing work—rather than starting new work or working on many things at once—they’re helping to keep the entire development lifecycle moving forward.
When your development team reduces the lead time for new Salesforce features, the business benefits twofold: you’ll reduce waste in your development process while increasing business productivity.
Deployment frequency measures how often deployments are made to production or provided to end-users. In general, teams that deploy frequently see lower risk and faster time to value. This is because to increase release frequency, teams often release smaller batches at each deployment. When teams release small amounts of work frequently, they can better test, rollback, and ensure quality in each release, which ultimately enables a higher value flow.
DevOps methodologies and tools can go a long way in increasing deployment frequency. If teams simply tried to move faster, they’d likely see a big dip in quality, But with CI/CD, automated testing, and quality gates, your team can move faster while embedding continuous security and compliance into your DevOps processes.
Change Failure Rate
A change failure is a deployment error that results in a disruption to your business, and the change failure rate measures the percentage of production releases that cause deployment errors. It's an essential quality metric that shows delivery leaders how their work affects business.
Maintaining a low change failure rate is critical for delivering not only Salesforce features but business value. Measuring and optimizing change failure rate not only helps ensure business continuity but it also helps mitigate risk.
But lowering your change failure rate can be difficult. It’s often tied to multitude of issues—teams that are manually packaging and testing high volumes of work, often see the highest change failure rates with their Salesforce releases. When you’re using change sets and deploying hundreds of pieces of work, you’re likely to encounter merge errors, especially if you also have admins making updates in production. So reducing your change failure rate to as close to zero as possible comes down to three key areas:
- Process: Increasing your deployment frequency, reducing your deployment size, and reducing changes made directly in production
- Automation: Implementing automated regression testing and CI/CD to eliminate human error and scale deployments
- Tech Debt: Improving your architecture by refactoring complex, non-scalable code that causes recurring problems
Meantime for Recovery
Meantime for recovery tells you how long it takes your team to troubleshoot, fix, and/or roll back a deployment failure after it’s placed into production. Downtime causes low productivity and damage to employee and customer trust, which can have both short-term and long-term financial impact. So the shorter the time to recover, the more trust you retain from your customers and end-users, and the less risk you’ll have to lose revenue.
When companies have long recovery times, it’s often tied to difficulties in identifying the root cause of the issue and struggles to roll back that change. Many Salesforce teams don’t have a mechanism to evaluate all the changes included in a release, so implementing a CI/CD tool that provides change history and version control can be critical in reducing the time in identifying what caused the issue in production. In addition to implementing DevOps tools, consider practicing rollbacks, so your team knows which kinds of changes to roll back, how to roll back a production failure, and how to "roll forward" fixes when possible.
How to Get Started
Mapping your value stream and tracking key metrics throughout it helps your team visualize your process, quantify performance and quickly assess opportunities for improvement. Creating this type of reporting from scratch can be time consuming and difficult to maintain. Copado Value Stream Maps lives directly in Salesforce and can be easily configured to reflect your process and value stream, so you have a real-time look into these key measures at all times.
Salesforce is a critical platform for helping businesses achieve their business objectives. And the work your team delivers on the platform directly impacts how quickly and accurately they hit these goals.
Want to learn more about tracking and optimizing your Salesforce delivery performance, take the Continuous Innovations with Copado Trail on Salesforce Trailhead today.