In this section, we are going to introduce the book, where it came from, and how it's organized.
Chapter 1, Introduction – Start with Why focuses on the book's purpose and the target audience. Chapter 2, Introducing DevOps and Some Tools explains, in our words, what DevOps is and how it helps speed up the value chain of product development. We'll explore what this chain is and the bottlenecks that DevOps culture and practices address. We'll introduce a couple of important tools that we'll use throughout the book to navigate around the use of many different types of practices we're going to apply. In Chapter 3, The Journey Ahead, we will introduce how we use real-world stories and the case study we'll use throughout the book that will outline how the remaining six sections of the book are organized.
This will set us up to build a foundation and start a journey of continuous discovery, options, and continuous delivery.
You've picked up this book and have started reading it — thank you very much!
Perhaps you read the back cover and it gave you just enough information to be inquisitive enough to open the book up and read some more. Maybe a friend or colleague told you about it and recommended it to you. Maybe you have stumbled upon it for another reason. Whatever the reason, we're very happy you've taken some time out of your day to start reading this and we hope you get some value from it and want to keep reading it.
Before going into any kind of detail regarding what this book is about and what it's going to cover, we want to start with why. This is a practice we use to create a common vision of purpose. Why have we written this book? What problems is it trying to solve and who is the intended audience?
Figure 1.1: Creating a common vision of purpose
Why — For What Reason or Purpose?
While this book may have been positioned as a book about technology, it is, at most, only one-third about technology. DevOps is really all about collaboration. We wrote this book because we want to increase your understanding of DevOps, collaboration, and cultural and engineering practices on a container platform such as OpenShift. We want to make moving to DevOps easier and provide a clearer path for you to apply DevOps using OpenShift. We want to excite you when reading this and give you some inspiration as to how you can apply DevOps principles and practices. We want to equip you to go out and try these new techniques and practices.
As you progress through this book, we want you to continually measure the usefulness (impact/value) of using these new techniques. In fact, every time you try something out, we want you to think about and measure what impact it had.
That impact might be at an individual level: What impact did trying that thing out have on me or a customer or a user? For example, has it reduced my cycle time to complete a set of delivery activities? Alternatively, it might be an impact on a team or a department you work in: Has team satisfaction been increased? What did we, as a group of people, achieve from that? The impact might even be felt at organizational or societal level: Has it reduced the number of operational incidents impacting customers? We believe you will quickly start to see positive effects in all of these aspects. As a result, maybe you'll leave us nice reviews and tell all your friends about this book. If not, perhaps you can pivot and use this book as a doorstop or a monitor stand, which, of course, will give you a different type of value!
If you don't know where to start with how to go about measuring value, read on — we promise we'll cover that.
What we've just done is started using one of the practices and techniques used in writing this book. We have used the Start with why practice, which is something we always strive to do with every team or organization we work with.
So, what is a practice? A practice is an activity that helps teams achieve specific goals. It's not just an idea; it's something that you do repeatedly in order to hone or polish a skill. Practices have the following attributes:
- Empowering: The practices in this book will help teams discover and deliver iteratively.
- Concise: They can be read in a few minutes.
- Agnostic: Practices don't require the team to follow a specific framework.
- Proven: Practices have been tested in the real world.
- Repeatable: Practices can be used more than once.
Hopefully, throughout this book, you'll see examples of us practicing what we preach through the experiences, stories, and tips we will share from our real-world delivery experience, which includes stories such as these:
- The story about when we worked with an insurance company to rebuild one of their applications using DevOps and OpenShift but had a stop the world moment (a practice we'll talk about in the next section) when we realized we were redeveloping an app that users did not want and were not using!
- The story of when we worked with a European automotive company and kick-started modern application development and agile practices with one of their teams, only for the product owner to question how they were going to prove to management that this was a better way of working when management only work with spreadsheets and numbers.
- The story of the telecom company that suffered huge outages and non-functional problems over a festive period and were keen to learn new cultural and engineering practices to drive an auto-scaling and self-healing approach to their infrastructure and applications.
Why Should I Listen to These Folks?
Before you read any more from the four folks writing this book, perhaps it's worth taking a step back and sharing a bit of background as to where all our anecdotes, theories, stories, and tips come from.
We all work for Red Hat. In particular, we are all a part of Red Hat's services organization, which means that we all regularly interact with, and deliver professional services to, Red Hat customers. This ranges from helping with installation and supporting the early adoption of Red Hat technology to driving large transformation programs underpinned by Red Hat technology and Red Hat's culture.
Red Hat's culture is relatively unique as it is entirely based on open source culture and open organizations (of which Red Hat is one of the largest examples). This means that the Red Hat organization is run under a set of characteristics that are closely aligned with open source culture and philosophy. They include collaboration, community, inclusivity, adaptability, and transparency. We highly recommend learning more about Red Hat's open organization philosophy by reading Jim Whitehurst's The Open Organization.
A lot of the experience that has informed this book and the stories and tips we will share emanate from engagements led by Red Hat Open Innovation Labs (or Labs for short). Labs provides an immersive and open approach to creating new ways of working that can help our customers and their teams develop digital solutions and accelerate business value using open technology and open culture. The main offering provided by Labs is called the residency, which is a four- to twelve-week timeboxed engagement where client's engineers are matched one-on-one with Red Hat's technology and culture specialists.
Between the four authors, we've been involved in over 50 Open Innovation Labs' residencies around the world, in addition to many other professional services engagements. Due to the relatively short nature of Labs residencies, we get to learn very quickly different techniques, different approaches, and different practices. We get to see what works well and what doesn't work so well. We get to build up a huge collection of stories and tips. This book is all about sharing those stories and tips.
Where Did This Book Come From?
The title of this book is an evolution of a training enablement program that the authors have developed named DevOps Culture and Practice Enablement. This is an immersive training course run by Red Hat, providing enablement to Red Hat customers, partners, and employees.
We initially created the course because the services area of Red Hat we are working in was growing, and we needed a way to consistently increase the enthusiasm and shared understanding behind the practices and culture we were using globally, with our customers, and within our own organization. We wanted to do this by exploring all of the principal practices we had found to be successful in taking many products to market with our customers. This included practices to help understand the why and drive the discovery of products, as well as practices that would help us safely, securely, and confidently deliver in an iterative and incremental manner. And then there was the third outcome, which was having fun. We really couldn't see the point in all of this if you couldn't have some fun, banter, and enjoyment as you went along — it's one of the key ingredients of that mysterious word culture.
One of the key success factors behind this was injecting lots of experience and real-life stories into our delivery and using a lot of our practices on ourselves to deliver the course. Every time we run the course, we use the definition of done practice to explain to participants that every practice we are going to teach on the course will be presented in a consistent way, following this process:
- Introducing the practice with the theory and an overview of what it is, why you should use it, and how to use it
- A hands-on practical exercise so everyone participating can leave the course having had a go at using the practic...
