Telling a customer something they may not want to hear is always a difficult thing to do, but no matter how difficult it may be, we mustn’t shy away from our responsibility to provide our customers with “best advice”.
In our experience, delivering a message that doesn’t correlate with the customer wants (or expects) to hear is most likely to happen when consulting in the DevOps space, primarily because of a lack of understanding fuelled in no small measure by the marketing magicians. (On a side note, bravo to the genius who thought to rename VSTS to Azure DevOps.)
When explaining what DevOps is, like so many others, I like to refer to Donovan Brown’s description (https://www.donovanbrown.com/post/what-is-devops).
“DevOps is the union of people, process, and products to enable continuous delivery of value to our end users.”
The key point here is that DevOps is so much more than tooling.
A little while back, we were engaged by a customer to plan the rollout of Azure DevOps. The brief from the customer was simple; plan its technical implementation and adoption to achieve CI/CD. The initial call raised some questions – no, concerns – with regards to the customer’s maturity and, as a result, the suitability of Azure DevOps let alone a move to CI/CD.
First things first, we facilitate a structured workshop that enables us to understand our customer’s current landscape (the “as is”) and establish what good would look like (the “to be”). As is often the case, this workshop led to a reset of expectations, and the customer agreed that the first engagement should be a review of the Software Development Lifecycle (SDLC). This would provide an independent, considered view of risks, issues and opportunities for improvement, and a set of prioritised recommendations.
To cut a long story short, we presented our findings and recommendations to senior stakeholders. It’s fair to say, the response was a little flat – disappointed even. We were presenting our “best advice“, the message they needed, but it was clear from their reaction, it was not the message they wanted. Not surprising really – we were presenting them with some uncomfortable truths. Not least the fact they had a lot of work to do creating a single, consistent, repeatable end-to-end process before they should consider introducing Azure DevOps to the mix.
It would have been very easy for us to present a plan for the rollout of Azure DevOps, to keep to the original brief, and in doing so, overlook the issues and risks with their approach and processes. But this would not have benefited our customer. It would have made an already challenging situation worse. There was far more benefit through the iterative improvement of maturity across development, testing, infrastructure, etc. than there was to the introduction of Azure DevOps.
Fast forward the clock a couple of months and we received an update from the customer. Having taken time to reflect on our findings and recommendations, they faced up to the reality of what was needed, and our customer embarked on the recommended incremental improvements that will not only provide significant immediate benefits but will also provide a foundation for their adoption of Azure DevOps.
Needless to say, it was a welcome call. As consultants, we sometimes feel that we are failing the customer by presenting a message that they do not want to hear. And, at Expert Thinking, we will always deliver our best advice, regardless of whether it is what the customer wants to hear. The good news… we’re now in discussion about helping the next step in the journey.
