Last year we looked at Salesforce DevOps (Part 1 & Part 2), where, in a nutshell, the aim is to enable a fast flow of planned work into production (tens, hundreds, thousands of deploys a day), whilst having top stability, reliability and security.
Easier said that done, right?
As teams enhancing the Salesforce platform and beyond, we don’t just care about features being ready to ship. But also that those things can go though the value stream into the hands of users without chaos and disruption, so that it becomes of value.
That’s the aim, but unfortunately for most teams, the system of work is broken.
Symptoms of a Broken System
- Critical activities take too much manual effort and and/or too many hand-offs
- Extremely long lead times to get anything done
- The quality of work is problematic
- Needing to firefight deployments
Let’s start with the end in mind. The goal is to increase throughput of value. Things delivered into the hands of users bring value, things in progress do not.
Value finishing over starting.
Using the lean principles I suggest you go through this motion: Define value, map value stream, create flow, establish pull, pursuit of perfection.
You can use things like value stream mapping (zoom out exercise to scale the concept of epics)
Use Kanban boards as a visual representation of your flow. Starting by understanding your main bottleneck, and what is your actual throughput rhythm looks like.
Count what matters
We often hear about continuous delivery and all the detailed capabilities you want to embed as your foundations of development. Let’s hold on a second, today competitive advantage is based on two things:
1) Fast time to market: in an ever changing environment and
2) Relentless experimentation: test quick business ideas to inform if you will pivot or persevere
So here is your “homework” (well, your work-work, please don’t do this in your free time, its called free for a reason) measure the following four things with your team:
Find out what is your LEAD TIME, which is composed of all the time that passed since a task (i.e. piece of work to increase value) is created, the work itself, all the way through to it be completed, meaning in production and in use.
The part of Work Started to Work Completed is called CYCLE TIME, which is also useful to measure and reducing it helps to achieve fast flow, BUT is not the whole picture. Focus on reducing lead time, or at least to start measuring it so that you know where you stand. Create reports and agreggates so that you can see it.
That’s your second measure, how often do you send things to production?
Similarly create reports, where you can see over time where you stand. Work with your team to answer this question: How can you increase deployment frequency? Experiment with a few options, learn from it, inform your next experiment.
Remember delivered things that are in hands of users bring value, things in progress do not.
Look at it as a percentage. So from your deployment frequency, out of those sends into production, for every single one map its outcome to either PASSED or FAILED, i.e. it cant be ‘almost went perfect’.
Work with your teams to spot the reasons and what can be done to ease the pain. It’s a constant pursuit of perfection rather than a destination. Whilst you are continuously delivering value, it can only get better. As you have a healthy tension between reducing lead time and increasing deployment frequency, keeping an eye on change fail percentage is key.
MEAN TO RESTORE
This one measure it in minutes. Out of the above failed changes, how long did it take to get it back up and perform?
Create a dashboard, look at this metric, and see how it performs over time. You do not need a fancy magic tooling nor external god to save you, you can today measure this and polish each one to become better at what we do.
Food for thought
To reduce lead times and increase throughput we need to continually identify our system’s constrains & improve its work capacity. Bake in ‘safer, harder, better, securer’ into your product, which overall supports the increase of throughput which after all is the goal.