Tag: kevin behr

  • Q&A with Kevin Behr on DevOps and Enterprise Excellence

    Q&A with Kevin Behr on DevOps and Enterprise Excellence

    When we want to get an inside peek at the trends within major corporations when it comes to continuous integration, continuous delivery, and DevOps, we turn to Kevin Behr, the chief science officer for the CXO and Board Advisory Practice at Praxisflow, where he consults, mentors, and coaches IT organizations and executives on how to increase their business effectiveness. Behr also is the of seven IT management books, including the bestselling “The Visible Ops Handbook”, which he coauthored with Gene Kim and George Spafford. His most recent book, The Phoenix Project, also coauthored with Kim and Spafford, has helped to spark discussion about DevOps globally.

    Today, we sparked a discussion with Behr about how smart enterprises are using DevOps to further differentiate themselves and enterprise excellence.

    devopsy.kinsta.cloud: There seems to be a lot of misconception out there about what DevOps is – and I’m increasingly hearing it referred to as a software methodology. Are you seeing this?
    Behr: Definitely. DevOps is not a software development methodology. I think that is a big misconception out there. It was a big misconception in the in WSJ post, DevOps is great for startups but for enterprises it won’t work yet. The author had that completely wrong: DevOps doesn’t tell us how to develop software. DevOps literally is collaboration between IT operations and development. So DevOps could be about developing software. It could be about fixing bugs. It could be about fixing integration issues. It could be a whole bunch of different things they’re collaborating on. But it doesn’t necessarily denote how you would develop software.

    devopsy.kinsta.cloud: But there’s no prescriptive connotation to the word at all, is there?
    Behr: Exactly. My whole point is that the only prescriptive connotation is “Can’t we all get along?” Can’t we work together to do the work we do? I think sometimes that means we’re not developing software that means sometimes we’re doing a lot of different things. In some cases, software developers are helping sys admins write better scripts, and do better sys admining. And vice-versa: sys admins are helping software guys understand requirements better, and understand the end delivery point, the people that are going to use software or service this, better. That’s not telling us how we must develop.

    DevOps is about asking: what can we do to improve, what can we change, and what does this change mean? We’re talking to CIOs like crazy right now about this. We’re trying to figure out how can they leverage DevOps without causing all kinds of organizational trouble. On one hand, we’ve got people in the enterprise that are happy with an ill-defined DevOps. To be honest with you some are saying it’s all kinds of things because that creates a subterfuge where they don’t have to do things to make it work. “If DevOps is confusing, if it’s impossible, or if it’s stupid, maybe we won’t have to actually do it,” they think.

    It’s kind of pathetic to watch. We are watching them and wondering: “Wow. Do you really think that doing these in Ice Age speed and style deploys and old school change management that takes 30 people in a room, once a week, to decide what changes are going to get made is okay today?

    devopsy.kinsta.cloud: That’s just insane to hear and think that it is going on. Outside of IT, how are business people responding to DevOps and continuous delivery.
    Behr: I’m telling you, the coolest part about it for me is the business people have reacted to the DevOps message. They’ve done so because we’re talking about changing the business payouts. They’re drastically different now. Organizations that can do these deploys, not just because they’re putting out more software, but because the organization as a whole is focusing on delivering more software to the end user. Even the commercial software companies are way behind what a lot of DevOps companies are doing now when it comes to driving innovation and better outcomes.

    When you look at these big software companies that are still releasing software every eight months, they’re really slow and terrible. We’re all suffering from the quality and the slow feedback loops, and the disconnectedness of regular commercial software. These smaller companies, a lot of them are start-ups albeit, but not all of them, and a lot of these banks that have embraced DevOps are drastically changing the old-school cycle time game. They’re getting faster. They’re reducing cycle time, and they’re reducing defects. That adds up when it comes to better applications and producing a lot less waste.

    devopsy.kinsta.cloud: What does this mean when it comes to impact, can the deficits be measured?
    Behr: Yes, because it ends up taking you forever to get anything out. You’re now suffering from that nasty cycle of unplanned work. It’s similar to all of the work that they call failure demand, where the failures in the quality of what you build are creating demand for work. You’ve already got competition for that work, because your company wants to release new value features, but you can’t because you’re cleaning up the old messes. It’s ugly.

    Now, and the other thing that’s interesting too, here, is that when you move to SaaS, you’re moving to more release cycles per year. The average SaaS provider is going through four major platform upgrades a year. They’re doing four releases. Think about that change from a traditional model, where you’re adding three more releases a year, essentially.

    And every release requires maintenance releases, so now you’re going to have patches. A lot of these companies have been putting SaaS into place, but there’s not a whole lot of SasS that’s profitable from a business perspective right now. There are a lot of companies doing it, but there are not a lot of companies that are in the black. What’s interesting is that they’re spending a lot of labor to maintain the software. It’s expensive, and you have to build it before the customers come. That’s why we see so many people come and go out of that space.

    devopsy.kinsta.cloud: What does that mean for business then, when it comes to success and IT’s relationship to business success?
    Behr: I think what’s interesting is that you’re hearing business people’s expectations change. The business always used to say, “Well, I need that thing tomorrow.” And IT would say, “Well, you’re going to get it when you get it.” Now the business is coming back, saying, “No, I need that tomorrow, because my competitor already has it.” Those rushed cycles used to be crying wolf. But today there is legitimacy to the pressure. They’re actually crying wolf because the wolf is there.

    The dinosaurs are going to be in big trouble, because they are competing with organizations that can do 10, 15, 20 or 40 deploys a day.

    Some are deploying with feature switches, as dark code, so all of those deploys that they’re doing may not even be active features that people are using. But they’ll turn on a feature, see if it works, and if it doesn’t they will turn it back off. No customer impact. They test it in production. They can also then roll out code that nobody even knows is there, and also be testing it on actual, live infrastructure. What they’re doing is improving so much faster than everybody else this way.

    These organizations are going to separate themselves from the pack because of how efficient they are becoming. This is how DevOps is one of those approaches that a lot of organizations are using to make it harder for other people to catch up with them. If they’re a super-predator, in other words if they have a breakthrough idea that nobody else does in some sort of technology, why not spend the dollars and couple that technology with a service approach, or a design from an organizational perspective, so that you can continue to out-improve everybody? DevOps does this.

    You’d be insane not to. So now you have a dual threat. You’re not just offering a better product, but you’re a better product that’s actually iterating faster and separating at a rate that’s going to be hard for other people to deal with. This is how the slow moving enterprise is losing right now. It’s content to think that it’s not losing that bad. The thing is, the game is changing so fast in organizations that are able to do this that they’re able to separate so much faster, and outcompete those that can’t.

  • Lean versus the bandwagon, lean wins

    Lean versus the bandwagon, lean wins

    I’ve just finished reading “The Phoenix Project,” by Kim, Behr and Spafford. To be honest, it was on my reading list but had I not picked up a copy at Camp DevOps I don’t know that I would have ever read the book. My main issue with books of this ilk, such as “Who Moved My Cheese” and “The Energy Bus,” is that the story is often contrived for purposes of delivering the learning points. So, I was surprised by how much I was able to relate to the issues in Phoenix giving it an air of reality I was not expecting.

    Phoenix follows the life of a new VP of IT Operations through his early weeks on the job. Plucked from obscurity as the Director of Mid-range Computing after his management chain was seemingly asked to depart the company, Bill’s eyes are opened to a world of heroics and chaos that surrounds him in IT and has had detrimental impact on the company’s financial and competitive performance. For anyone who has logically questioned, “how can that happen?” in their own companies, the authors do a great job of illustrating the paths that lead to the unimaginable outcomes we see every day in our own IT world.

    That said (spoiler coming), I ask the authors, did we really need to make Bill’s dad an alcoholic? Sorry, completely tangential point, but interestingly, one of the few times where I thought the authors had reached into their “drama box” for reasons that are still unclear. Nonetheless, after reading this book, I reflected upon the content that is being created around DevOps movements and realize that there is a polarization effect occurring.

    Camp 1 I categorize as the “lean camp”. This camp represents those that believe DevOps should be the application of lean manufacturing principles on IT. In this perspective IT is represented as a critical hub through which business is enabled and transacted. In accordance with this perspective, work enters the hub through multiple endpoints and must be prioritized and coordinated in order to ensure that a) critical IT resources are sourced appropriately and with maximum value to the business and b) constraints and bottlenecks are minimized, thus allowing work-in-progress to complete successfully. Anyone who has studied any aspect of logistics, manufacturing or supply-chain management understands the number of variables involved in this type of scheduling, but applying this to IT is significantly more challenging since it requires the cooperation at both the 30,000 foot view and the 10 foot view, with the latter required to understand the impact of scheduling conflict and help foster collision avoidance that could lead to outages.

    Camp 2 I categorize as the “bandwagon camp”. This camp represents individuals that are using DevOps as a lever for their careers. Certainly, DevOps is the hot topic of the day and having it on the resume is certainly good for a few extra brownie points and higher salaries. Ask these individuals what DevOps is about and you hear answers, such as, “it’s about changing the culture in IT,” “it’s about getting development and operations to cooperate more effectively,” or my personal favorite, “it’s about automation.” The truth is that DevOps needs aspects of all of these factors but driven under an umbrella of work described in the Camp 1 description above. Acted on independently under the guise of DevOps and we will see DevOps nose dive into Gartner’s trough of disillusionment very quickly.

    Will things get fixed in Camp 2? Probably. Certainly implementing controls around who can make changes and when they can occur may help many businesses limit the unplanned work that is crippling their ability to address other work efforts. However, since this is not the focus of the DevOps effort, unplanned work will continue to come from other areas, it’s just the nature of the beast and without correcting the actions that foster unplanned work, it will continually have a negative impact on the business.

    The authors of Phoenix have done a fantastic job of providing IT leaders with a goal for their DevOps programs. If they are wise, they will rapidly adopt the principles defined therein and make sure that all other so-called DevOps efforts in the company are aligned for purposes of reigning in the chaos and free-wheeling efforts of rogue IT employees. I recently met with a VP of IT for one of the major food distribution companies. I was awed by how effectively his IT organization operates, but now I realize, that his company is primarily a logistics and supply-chain company that happens to move food. It only makes sense that the principles they use to run their business would be adopted for IT as well; especially with their IT leaders coming from other parts of the business. In combination with Phoenix, the meeting locked it for me that the lean principles are key to positioning IT as the business enabler needed to be competitive in the current era.

  • My DevOps Bookshelf

    My DevOps Bookshelf

    Aside from the many technical manuals on our bookshelves, I bet everyone has a few that are more process or philosophically oriented which hold a special place in our hearts.   To me, these are the ones we continue to go back to and that have helped develop us as engineers, software, operations, quality assurance or otherwise.  In no particular order, the following are the top four, not strictly technical, books in my library.

    Web Operations by John Allspaw and Jesse Robbins

    Allspaw and Robbins cover many topics in this text ranging from monitoring and metrics to databases and operations development relations.  I appreciate this one so much it is required reading material for anyone who joins my operations teams.  In my opinion, it illustrates many best practices for an operations organization.

    Continuous Delivery by Dave Farley and Jez Humble

    This book bridges the gap between good software development practices and getting to continuous delivery.  It made me really think about testing and quality assurance, which in my opinion is one of the most difficult parts of a continuous delivery world to wrap your head around.  While there isn’t one right answer, you should really think about the role testing plays in the overall process.

    The Phoenix Project by Gene Kim, Kevin Behr and George Spafford

    “The Pheonix Project” is a relatively new addition to my library.  While it may sound strange, this book was an absolute page-turner and I really related to it.  It presents many Agile and DevOps concepts via a fictional story that doesn’t seem fictional because we have all been there.  Despite the fact that it is fictional, the concepts presented and techniques are applicable to each of our real-world situations.

    Etsy – Moving Fast at Scale

    While this isn’t actually a book, but a video, to me this is a pivotal piece of information has continued to guide my pursuit of DevOps methodologies and practices, so it holds a special place on my figurative bookshelf.  In the video, the guys at Esty discuss a number of topics including deployment processes, application toggles, metrics and more.  Most importantly, they not only discuss the why but also the how and I find myself frequently referencing this video.

    For me each one of these books or videos has played an important role in pursuit and real-world implementations of DevOps practices.  What are the texts digital or otherwise that you hold dear and/or have influenced you?