Main Menu
Home / IT Governance / Legacy Support / The Three Ways of DevOps

The Three Ways of DevOps

The Theory of Constraints

Professor P. Ross S. Wise uses the theory of constraints and a book (The Phoenix Project by Gene Kim) to show the underlying principles of the DevOps movement. The principles fall into three “ways”:

The first way concerns workflow. Making sure that work moves from the business to the customer is essential, of course, but it’s also important to make sure that workflow is moving as quickly as possible. This can be achieved by clearly defining the work that should be done, and making sure that work is highly visible to both the team and to the customer.

Feedback and Reciprocation

The second way is about feedback and reciprocation. Responding to the needs of internal and external customers requires communication loops and embedded knowledge, according to the post. The third way is to experiment:

Not only experimentation but also to foster a culture where it is OK to FAIL!  We need a culture where it is okay to optimize risk but also one that can reach in and grab us when we have gone too far and bring us back to safety.  Practice makes perfect.  When you are practicing you will have failures.  This is a required element to mastery.  A pattern that results in this third way is one where we break things as often as possible while in the pipeline to production. In conjunction with this culture of experimentation and innovation is the power of transparency that propagates an environment of trust and ongoing success.

DevOps can work—but it requires process and methodologies to do so. Read this blog post to learn more about the three ways and how you can apply them to your team:

About Matthew Kabik

Matthew Kabik is the former Editor of Computer Aid's Accelerating IT Success. He worked at Computer Aid, Inc. from 2008 to 2014 in the Harrisburg offices, where he was a copywriter, swordsman, social media consultant, and trainer before moving into editorial.

Check Also

COBOL Is Still Around Because Nothing Better Has Replaced It

When COBOL was made in 1959, no one could have dreamed that it would outlive …

Leave a Reply

Your email address will not be published. Required fields are marked *

Sorry, but this content
is for our subscribers only!

But subscribing to ACCELERATING IT SUCCESS is FREE and only one click away!
Join more than 40,000 IT Professionals and get the best IT management articles to your mailbox with Accelerating IT Success!

Unsubscribe at any time