International DevOps Certification Academy™
How Should You Enable Your DevOps Feedback?
In your IT ecosystem where demands and requests from your clients constantly become more challenging, you and your DevOps team need to strive for continuous quality improvement of the work you are doing. In order to achieve this, you enable fast, continuous and reliable feedback loops from right to left in your value stream.
These feedback loops will help you quickly deal with impediments while they are small, cheap and easy to remove. They will help you create an organizational learning culture while you do your work. When problems occur, you and your DevOps team treat them as opportunities to learn and improve the quality of your software products and services.
Why Do You Need Built-In Quality Enabled By DevOps Feedback Loops?
From your experience in software engineering industry, you must be so far pretty clear that in a complex system, no one is able to know everything. Even doing the exactly same work twice does not yield the same outcomes. Because this level of uncertainty of outcomes is not tolerable in any business, organizations tend to build control and reliance with quality assurance mechanisms by deploying checklists, audits, compliance, quality assurance professionals and micromanagement. And yet, all these measures are not sometimes sufficient enough to avoid mistakes and errors.
Therefore, building an organization which builds built-in quality starts with accepting mistakes and errors part of your daily job.
Design A Safe System Of Work Culture
You design a safe system of work culture. Nobody in your DevOps team is afraid of making mistakes because you and your DevOps team know that errors are quickly detected and fixed while they are small and before they cause catastrophes such as significant defects, downtimes of services and negative client reviews.
By building a safe system of work culture you, your DevOps team and your entire IT and business organization will enjoy following benefits:
- Complexity of your systems will be managed, so problems in designs and operations will be quickly detected.
- Problems are quickly resolved while they are small. Resolving problems will result in spontaneous construction of new organizational knowledge and experience.
- New knowledge and experience are spread around and distributed towards your entire organization.
- Leaders in your DevOps organization develop other leaders who create and continuously improve safe systems of work.
Identify Problems While They Occur
If feedback mechanism in your organization is slow, infrequent and late it also late and expensive to prevent undesirable outcomes. Like good old waterfall software delivery days when applications are built for a year before they are for the first time shown to clients, and then rewritten for another year, none of businesses today have luxury to work with this modus operandi.
Your goal is to create fast feedback loops. When your work moves from left to right in your value stream, it should continuously provide feedback from right to left. Building quality in your DevOps organization is all about building quick feedback cycles. When an issue is introduced, your DevOps team identifies it about while it is first time occurring in your value stream. You and your DevOps team quickly fix issues and you constantly validate correlation between client expectations (internal clients, external clients and all other stakeholders in value stream who are impacted from your work) and your implementation to fulfil these expectations. Quick feedback cycles do not only enable you to quickly fix issues, but they also enable you to learn from them and prevent from doing same errors again in the future.
Undo Your Errors When They Are Easier, Quicker and Cheaper To Fix
Quickly finding problems enable you to quickly fix them too. Otherwise,
- Cost and effort to fix them exponentially grow and you allow technical debt (workarounds on the top of workarounds) to accumulate.
- Errors proceed to downstream work centers in your value stream which most likely contribute construction of other errors.
- Errors happen again and again far away from the work center they were first introduced and they will require more fixes and work from you to be undone.
- Memories about why errors did happen in the first place fade and circumstances contributed construction of errors change. If errors are first identified months after they were introduced, you can’t really find out true root cause and worst of all you can’t learn from them. You would do a workaround to save the day and move to the next workaround. You already know that this is exactly what you want to avoid with DevOps.
Encourage your DevOps team and yourself to raise your voice and to build continuous feedback mechanisms to identify and quickly fix errors. Do NOT introduce erroneous work on the top of erroneous work. In other words, don’t let your DevOps team build new features before fixing errors which would negatively impact construction of these new features. Continuously improving quality of your work and continuously removing errors while they are happening will ensure that you build best software products and services in your particular market.
Don’t Push Quality Control Decisions Further Away From Where The Actual Work Is Performed
Pushing decisions about quality controls further away from where the work is performed lowers quality, increases delivery lead times, decreases the strength of feedback between cause and effect and reduces your ability to learn from your mistakes.
In a nutshell:
- Don’t require your teams to do manual quality control work that can be automated.
- Don’t require approvals from busy people who have no to limited knowhow about the work that is being performed.
- Don’t create large documentations for approvals which will soon become obsolete due to nature of your work.
- Don’t push large batch of work to authorities for approvals.
Instead, every single member of your DevOps team should be finding, fixing, sharing, talking and teaching about errors in her or his own area of control. Pair programming, peer reviews, automated testing, inspection of code check-ins, internal checkpoints, very frequent demonstrations should make quality assurance responsibility of everyone instead of responsibility of a dedicated quality assurance department.
CONCLUSION
You and your DevOps team are always conscious that you are getting paid to serve your clients. Therefore, you should be always working for the best interest of your internal and external clients.
And yet, the next work center in your value stream is particularly important. You should optimize your work for them with empathy. You should build fast and reliable feedback flows with them to enable fast, smooth and high quality flow in your value stream, so that your DevOps team is able to identify and resolve problems as quick as it is possible.
DEVOPS-CERTIFICATION.ORG
