DevOps - The three ways

In my current company, I am working on our product. This product consists of many, different moving parts which need to be built, shipped and deployed on the customer side. Let's see how "three ways" help me with this challenge.

DevOps - The three ways
Photo by Alex Ghizila / Unsplash

In my current company, I am working on our product. This product consists of many, different moving parts which need to be built, shipped and deployed on the customer side.

So, I am thinking a lot about questions like "How to prevent damage?", "How to become faster?", "How to involve the customer more?"

These questions reminded me of something described in "The Phoenix Project", a book by Gene Kim. It describes three ways of work, that are focused on the above questions. I want to share these ways and my thoughts with you.

The Phoenix Project

Before going into details, let me give you some background. The book "The Phoenix Project" is a novel, co-authored by Gene Kim. It is discussing ideas of DevOps, proposing changes and metrics and also explaining methods and strategies to work from a paralyzed IT workflows to an agile, DevOps centric company.

Cover - The Phoenix Project

The main character Bill works for Parts Unlimited, a company selling car parts and maintaining several shops where you can bring your car for repair or spare parts. The company is on the edge of collapse, and we can see how it slowly evolves.

I was able to identify with the characters in the book. Sometimes it was like looking back on some of my prior work places. I also learned a lot, about myself, changes and how one can tackle certain problems. It was so entertaining and meaningful to me, that I also bought other books from the authors like "The Unicorn Project", "Accelerate" or "The DevOps Handbook".

The first way

The first way is about flow. The flow from development to operations, to be precise. But, this may need a bit more context.

When talking about development, I mean product development. If our company is about tomato processing, this is all the work we are doing to plan our products, buy tomatoes, process them and can them. Operations on the other hand is the shipping process. It is also about monitoring the product and how it works for our customers.

The first way

Now, the idea is, that this process must be in a flow. We must establish a continuous stream of new tomato products to our customer. In software development, you might say "new releases". Establishing this flow can be done with methods like Kanban, Lean, SCRUM and many more. It can also be supported by automation, processes or whatever is needed to establish flow.

You might ask: "What is flow?" Well, this is worth another article, but let me summarize it quickly. The best definition that I have seen comes from Mihaly Csikszentmihalyi. He describes it as the state of being in a cognitive state of concentration and full focus. In a more process oriented meaning, it indicates a state where it is easy to proceed smoothly and readily.

The second way

The second way is about customer and user interaction. It is about amplifying feedback loops, so we can fix quality at the source and avoid rework.

The second way

It is about getting feedback from customers/operation, but also making use of this feedback. Do we know how many cans of our tomatoes are having issues? Do we gather feedback from customers and enhance our products, maybe invent new ones for them? Do we know how our tomatoes are used, so we can add products that support this use case?

These and many more questions are part of the second way. One might say "Listening to customers", but also monitoring, market research, interviews, surveys, bug reports, customer complaints and many more things can be considered here. And if you gather these things already, make use of them and enhance the next product lifecycle with the insights from your customers.

The third way

Create a culture that simultaneously fosters experimentation, learning from failures, and understanding that repetition and practice are the prerequisites to mastery.

That summarizes the third way so well, I can only add some minor things here. It is about improving, experimentation and getting better. You can improve existing processes, your skills, your culture, your products or your communication. This way needs to be part of your culture to become better.

Let's be honest, if you don't learn, you will still forget things. What does this mean? Without constant and continuous improvement, you will become dumber every day. Therefore, we need to improve every month, every week and every day. Just a bit, but enough to avoid stagnation.

This can be done in many different ways. You can do proper retrospectives, postmortems, ideation about new skills, experimenting with new frameworks, workshops or even by just reading a book.

You can establish learning sessions in your company or create personal development plans. You can foster a community, where knowledge sharing becomes a habit, or join another team to see how they work. As a manager, you might join one team and work with them for a week or two, just to see where they might need help with.

Conclusion

The three ways are only a small part of a successful DevOps culture, but for me, they are very important. Having in mind, that we need to create flow, involve and amplify customer feedback and improve daily is helping me a lot to design new processes and ideas.

What about you? Do you live the tree ways? Do you want to share your ideas and feedback about your experiences? I would love to hear how this is applied in your daily life or your companies.