Develop in production: insane or inspired?

Accelerating implementation

We all know the benefits of accelerating and streamlining the release cycle; the business is more agile and reduced development effort. But there are even greater benefits if you think about the entire implementation lifecycle, which includes improved analysis that engages the end users to discover what they really need, not what they thought they wanted. It is best summarized by OrgConfession 751

“Spent 3 hours putting a change in production after weeks of designing and testing. By the end of the day, we had to turn the new process off again as the whole sales team up in arms about the process that they hadn’t been consulted on.“

Insane or inspired?

One way to accelerate changes is to develop straight into Production. This concept has definitely divided the audience. It seems to be philosophically wrong. It is such high risk that it is ridiculous to even consider. And, you are right. It is madness if you have no way to reliably assess the risk of a release.

We apply a risk-based approach to our Org development at Elements. We have a highly customized Org with integrations to external systems. Assessing the risk-based of each release management has enabled us to drive rapid change that keeps the business agile and engaged. And that drives up adoption.

We use a different development path based on the assessment of the risk of the changes. This means we optimize the development path:

• LOW risk changes we can develop straight into Production. This is quicker, easier and cheaper.
• MEDIUM risk changes, we develop and test in a Sandbox and roll straight into Production.
• HIGH risk changes, we develop in a Sandbox, we move it to the Integration-Test Sandbox for rigorous testing before we roll in into Production. This is the most expensive process, so we only use this approach for changes that have the risk that justifies the effort.

The more releases that can be taken through the low and medium development paths then the faster and more cheaply releases can be delivered. The development team is more effective. The business is more agile. Everyone wins.

Assessing risk

We have developed a very simple risk assessment approach that is applied to every change with relatively little overhead. We assess every change, because there is a huge ROI if we can put changes through the low and medium development path vs the high. For a small change, our assessment could take just 5–10 minutes of analysis giving us the confidence to develop straight into production, saving hours of deployment effort.

Releases are made up of a number of user stories. We assess the risk of each user story by looking at both its impact and the complexity. This is by looking at the metadata items in each user story. The overall risk of the user story is the combination of assessment of both the impact and complexity. This is a simple matrix.

We consider the 3 different impact types for a user story (in this order)

• Technical: what metadata items will be touched and how interconnected are they
• Organizational: how significant a change to the operational working practices
• Regulatory: will this put the business at risk from a regulatory compliance perspective.

Technical Impact

We have a picture of the overall impact of the change down multiple levels with our Dependency Tree for metadata items. This is built using the MetadataAPI, the DependencyAPI and custom code. But we are also very hot on documentation of why we make changes to metadata. This could be a link to the requirement, user story, a process diagram, a photo of a whiteboard or links to documents. This helps future technical impact analysis. Below is an impact assessment of the field “Close Date” on our “Opportunity” object showing all the dependent metadata items. Any item in the tree can be clicked on to drill into more detail.

Organizational Impact

The organizational impact is assessed by looking at the business processes that are going to be changed. These are the process diagrams linked to the metadata items. If you don’t have any process diagrams, now is the perfect time to start drawing them as it will also help you validate user requirements and they can be embedded in page layouts for training. The activity boxes with a “corner” have lower level diagrams.

Regulatory Impact

The regulatory impact can then be assessed by considering how the change affects ISO27100, GDPR, CCPA, FDA and other regulatory standards. Again, the process maps can help with this, plus a data privacy assessment for fields.

Complexity

Now you have the impact assessment you need to assess the complexity of a user story based on the number of metadata items that need to be created or changed, and their complexity. This is not a simple count of metadata items, but an educated guess based on how you are going to deliver the change.

Release risk

Then you need to decide how the user story risks are aggregated into the release risk. We take the highest level risk of any of the user stories and this risk level of the release. You could build your own algorithm, but simple is best.

Show me the money

There are huge benefits to the business and to the development team of adopting this approach. The good news? It takes relatively little effort and cost:

• Drive out waste in development processes which are identified in the process reengineering exercise,
• Cost savings in the development team as they are not wasting time forcing lower risk changes through a more rigorous process than needed,
• Lower risk releases are delivered more quickly, so the business is more agile and gets the benefits earlier,
• Reduce of release failures that have to be rolled-back due to better analysis,
• Less rework as more structured business analysis means the requirements are better understood, first time.

Whilst this sounds like a tall order — documenting your development processes and establishing the risk parameters — it is a small one-off activity compared with the daily, weekly and monthly effort of pushing changes around the implementation lifecycle only to have them explode or be rejected and need to be rolled back.

I will leave you with OrgConfession 707

“I deleted one custom field that blew up 40+ reports, 3 dashboards, and two weeks of my life”

Wanna see our Development Processes?

We’ve documented our entire implementation lifecycle and you can access / copy them. They are here https://diagram.q9elements.com/diagram/5f1afe49a60d750007ad553b?v=master