We finally bring our look at the foundational principles of DevOps to a conclusion by taking a deeper dive into the ‘S’ of CALMS – Sharing.
So, what exactly are we sharing, how and with whom?
The short and facetious answer is simply ‘everything’. However, once we start to analyse it, maybe this isn’t such a flippant response after all.
We obviously want to share all the good we’re doing with our stakeholders and customers so there should be regular outgoing communications highlighting major (and possibly minor) new features, bug fixes, etc. that have been successfully deployed.
We also want to elicit feedback from those stakeholders and customers, so we want them to share feature and enhancement requests and commentary with our developers so as to drive future development work to be added to the Product backlog.
Internally, we want to be sharing details of what we have developed, details of what has been deployed, what has worked, what has not worked, issues, problems. If we want to be completely transparent, we should also be sharing these with our customers and stakeholders via public dashboards, so they have the complete picture.
Consider investing in a collaboration portal by which your IT teams can communicate easily with stakeholders and the business as a whole. And crucially, they can also communicate back to your IT teams in a more informal setting. You’ll find that by setting up conversations in this manner, you’ll drive out the real stories of what the business wants to see, couched in the language and terms that the rest of the business understands. These can then be routed back into your development backlogs/project/ideation pipelines as necessary for future development work and enhancements.
The key thing is that this runs full-circle into the no-blame, transparent culture that we looked at when we talked about the ‘C’ in CALMS. By bringing our analysis of the foundational principles full-circle, we also highlight the feedback mechanism by which we should also be striving to continuously improve the team, and the way they interact not only with one another, but also with their clients and stakeholders.
A key part of the beauty of DevOps is that it is not a static methodology. It should be constantly evolving from the lowliest of personnel right to the highest tier of management, stakeholders and even customers, no-one is an island, everyone involved with a Product should strive to make it the best it can possibly be; and embracing these core values can go a long way in making a DevOps environment a success.
~
This brings a close to this series of articles focussing on DevOps foundational principles.
In the next article I’ll discuss briefly the three ‘ways’ of DevOps – pillars that are built upon these foundational principles.
