CRM DevOps Best Practices

Agile methods have improved CRM software development and deployment by delivering more software increments, more often and more aligned with what users' most value. However, the follow-on release processes for planning, scheduling and pushing CRM software increments to test and production environments have generally failed to keep up. DevOps is the solution to systematically remove this bottleneck and increase the end to end agile cycle velocity. Here's some DevOps best practices – some of which I've learned after the fact   – that may remove some challenges and aid your journey.

• If your goal is to upgrade existing applications or release new applications faster and more reliably, begin by baselining your current development to delivery pipeline in terms of release frequency and quality of releases. DevOps is a continuous journey supported by continuous process improvement. It's helpful to measure your current quality and pace at each stage and end to end in order to identify the top impact areas, prioritize efforts, set goals and demonstrate measurable progress over time.
• Recognize that DevOps is much more than software automation. DevOps is designed to bridge what are often departmental divides and improve the teamwork among developers, QA staff and IT staff. Automation is required, but is only one ingredient in the mix. A CRM DevOps framework should include roles, events, artifacts and toolchain. It must also be built on a culture of open communication, team collaboration, real-time information flow, mature development methods and a team commitment (backed with incentives and penalties) to support new processes and end goals. Implementing automation without other key components will simply accelerate poor practices and deliver poor quality code faster.
• When considering the DevOps toolchain, your first tool should be the one that brings visibility to the entire software delivery pipeline. Granted, this will show mostly manual processes and inefficiencies, but these objective measurements provide the basis to know where to find the quick wins and biggest upside opportunities.
• For reasons I'm not entirely sure, new DevOps adopters have a tendency to begin with continuous delivery tools. That puts the cart in front of the horse. Instead, when planning your automation across the software delivery pipeline, begin your toolchain with continuous test processes and tools. Improving testing as part of the continuous integration process will flush out problems that need to be addressed at the source and before downstream delivery automation is applied. It's been my experience that fixing and then automating the testing processes delivers the biggest impact in terms of overall quality and speed.
• Measure the right metrics ― which should include the top three performance measures of quality, pace and productivity. Poor dev quality comes at a high cost. Outages, downtime, and user frustration are significant, but may pale in comparison to unforgiving customers. Accelerating code delivery without corresponding improvements to quality will render a DevOps program useless. Quality can be tracked pursuant to defect types and volumes at each stage of the DevOps cycle. Quality should be measured for recurrence, severity and trending. Pace will be impacted by the combination of process improvements and automation. The pace cycle may be measured as the duration from identifying a new business capability to getting that new capability into the hands of staff so it can be acted upon. Productivity can be measured by role but the most impactful indicator is the shared measure which shows the team's effort required to deliver new business capabilities to users. While productivity is often measured with burn down charts and velocity charts, improvements are best demonstrated by an increasing sprint velocity (i.e., completing more user story points with every sprint.)
• There's another essential metric – the user experience. DevOps delivers the software driven innovation that benefits users and creates competitive advantages for the company. User feedback and measurement are critical to understand how this innovation is received and valued - so the business can prioritize and deliver more of what users really want (not what you think they want). Voice of the Customer (VOC) tools can collect both user and customer feedback, analyze sentiment and route notifications for follow-up when things don't go as planned. They can also catalogue and weight requests, which when applied to product or release backlogs further contribute to the cycle of continuous innovation. It's also possible to use DevOps monitoring tools to track the adoption and utilization of new software innovation.
• Consider one more team performance measure. Developers are pushed for speed and rewarded for fast time to market. IT ops are pushed for stability and rewarded for system availability, performance and security. A divide is created when team members have different and sometimes conflicting objectives. The best way to bridge this divide is for DevOps teams to share common objectives, and the most impactful common objective is customer satisfaction. Customer success is the one measure that aligns all roles, and aligns technology innovation with the company's top priorities.
• Other CRM DevOps best practices that I've previously written about continue to apply – start small, focus on culture before technology, choose tools that are compatible, and make sure agile and DevOps are architected as a single, continuous process; not two processes linked together.