How to Scale Trust in DevOps at Day 2 of DevOps Days Amsterdam
In his talk during the second day of DevOps Days Amsterdam Sam Eaton from Yelp highlighted the importance of trust within an organization as it increases predictability and helps create a sense of community and shared work. For DevOps to succeed in an organization trust has to scale beyond individuals and teams directly involved in related activities. But scaling trust is hard because of the MonkeySphere phenomenon which limits people’s ability to relate to an increasing number of colleagues.
On one hand trust between dev and ops requires aligning their often conflicting incentives (application stability vs. delivering functionality). On the other hand trust at management level must be gained by showing the value that DevOps can bring to the business.
Sam pointed out that building trust requires consistently meeting commitments and establishing open and honest communication between the two parties. When there’s trust it becomes easier to accept exceptional requests (e.g. a technical need to temporarily slow down functional delivery and work on reducing technical debt or a business need to urgently deliver a change to support a pressing customer request) given the past history of trust.
In order to gain respect from other teams Sam suggests one needs to consistently measure changes from a business perspective, display idempotency when dealing with people (nondeterministic reactions are hard to trust) and strive for immutability (controlled and automated changes only).
Techniques like continuous integration and delivery pipelines promote trust across teams by exposing failures early in the process and giving visibility to the changes being implemented. Failures become more predictable and help improve a collaborative working environment instead of installing a blame culture for break downs late in the delivery flow.
Contracts are another technique to deal with lack of trust. Having internal contracts within an organization can help give people the predictability they need to trust each other. Sam gave the example of an application infrastructure contract which developers can follow to get their code deployed automatically to production.
Other recipes for scaling trust proposed by Sam included:
- production-like environments for dev and test (including replicas of production data and traffic)
- focusing on MTTR instead of MTBF
- frequent retrospectives including other teams
- evaluating flow between teams and removing duplication of activities (a sign of mistrust)
- monitoring performance against pre-defined expectations
- increase transparency and share knowledge using tools such as wikis, chat rooms or even messaging queue for all activities in the delivery process (commits, deploys, test results, etc)