Three Core Principles of DevOps

In this post, I would like to write about three fundamental principles of DevOps. Organizations looking to embrace DevOps transformation should consciously bring in these elements in their day to day work.

Flow

Flow is all about accelerating the delivery of completed work. In other words how fast one can move the developed work to production.

Make the work visible: In software systems, it is very easy to get lost in the complexity. Hence a visual representation of the flow of work (Ex: Kanban boards) will help in gaining a common understanding on progress of work. This visibility helps us identify bottlenecks easily.

Limit Work in Progress: Value is determined only for work that is completed and not for work that in progress. Hence in order to derive maximum value, it is vital to measure and minimize "work in progress". Maximum attention should be on how fast we can move the developed work to production.

Reduce Batch sizes & Handoffs: Smaller chunks of work helps in faster movement to production, which in-turn allows us to realize the value faster. Hands offs to multiple external teams most often cause information loss, delays and hence should avoided as much as possible.

Feedback

Feedback defines how soon the developer knows that there is an issue with the code he/she has developed. Though it is obvious that feedback should be provided as soon as possible, often organizations struggle in building faster feedback loops

• Work safely with in complex systems: Often developers working in complex systems are unaware of inadvertent effects of their work. This affects their ability to bring-in new changes with confidence. An automated feedback gives them assurance in making the changes.
• See problems as they occur: A mechanism that provides instant feedback on code developed allows developer to immediately fix the issue. (Ex: Developers taking the responsibility on the quality of code)
• Swarm and solve problems: Problems arising from the code should be fixed with highest priority than any other work. An automated feedback mechanism that fails the build is quintessential to bring the issue to every one's notice.

Continuous Learning & Experimentation

Building a learning culture allows employees to take risks in order to improve their day to day work.

• Institutionalize improvement in the daily work: Explicitly reserve time to make improvements in the daily work. Example activities: Reduction of Technical Debt, Automating manual activities, Refactoring problematic code etc.
• Transform local discoveries into global improvements: Build a mechanism that helps promote local improvements to be visible at an organization level, so that these improvements can be adapted by other groups/teams.
• Introduce Resilience into your daily work: Introduce planned disruptions that will challenge the work and and help us bring resilience into the overall system. ( Ex: Netflix chaos monkey kills random process and shutdowns random servers)

References: The DevOps Handbook

Disclaimer: Most of these are my views/gist of my learning from various books & readings on the web.

Feel free to leave your comment in case you want to add to this.