Tag: DevOps book

  • BVSSH and the Digital Zeitgeist

    BVSSH and the Digital Zeitgeist

    I like the book, “Better Value Sooner Safer Happier” (BVSSH), by Jon Smart with contributions from Zsolt Berend, Myles Ogilvie and Simon Rohrer. It is not only a punchy title that captures much of what we do in IT, but it also has the depth and nuance that is sorely needed. It focuses on outcomes while recognizing the intrinsic unpredictability of the systems (in the broadest sense) that we work in.

    DevOps

    Although it will be of interest to most IT-related disciplines, because of the people who follow Jon and his publisher, the book’s first audience will probably be the DevOps community. DevOps is a broad church, but many of the constitution have a strong focus on getting stuff shipped frequently, quickly and reliably. This is reflected in the metrics that are typically promoted for DevOps: deployment frequency, lead time for changes, change failure rate and mean time to recover. It is good to note that lead time is measured from code commit to production, so very right at the end of development. They are concerned with the tools for, and process of, successful deployment of increments of software. The functionality that is being shipped is often of less interest to those tasked with deployment. The boxes just have to be shipped, whatever their content. Most of the 67 practices in the excellent “DevOps Handbook” reflect this. The principles behind DevOps, however, can be applied beyond the deployment area, and many people do this. But DevOps’ sweet spot in terms of its contribution to improving activities is deployment.

    Agile

    Similarly, Agile also has a sweet spot: developing software increments that are potentially deployable. This definition of done demarcates where Agile guidance defers to DevOps guidance. An equally interesting demarcation is at the start, where the focus is on opportunities, hypotheses, requirements and specifications. Does Agile guidance help when there are unarticulated user needs and ambiguous hypotheses? Or is this the natural habitat of business analysis? Dave Snowden speaks of “pre-scrum techniques,” implying that Agile shows its value when requirements are clear enough for development of the first viable product increment. Just as with DevOps, Agile also embodies principles that can be applied beyond its sweet spot of software development.

    IT Operations, IT Service Management and Value Realization

    At the end of the value stream, we are concerned with ensuring that the potential value of the software products is actually realized. Much of this is beyond the scope of influence of the service provider, where IT operations (including site reliability engineering) and IT service management concern themselves with ensuring that the systems are performing well and that the users have access to the systems. Not only does the information system have to be operationally resilient, but users also have to use the functionality effectively, interpret the information correctly and take better decisions and, finally, act on those decisions.

    The ‘What’ of BVSSH

    Return of investment in digital products and information systems is only realized when people or things actually do something with them (or avoid undesirable action). This extends the definition of done way beyond deployable, deployed and accessible. “Done” is when value is realized, and this is the “what” of BVSSH. As Jon says, “It’s why you are doing what you are doing. It is of value to someone. It could be financial; it could be maintaining public safety; it could be charitable.”

    The ‘How’ of BVSSH

    The “how” of BVSSH is represented by better, sooner, safer and happier. Better refers to quality that is built in from the start. Sooner covers the end-to-end value stream, although I would extend the scope beyond the provider’s “getting it into the hands of a customer.” Safer is about “governance, risk and compliance, information security, data privacy, regulatory compliance and resilience in chaos. […] It is speed and control, not one or the other. […] The better the brakes, the faster you can go.” Finally, happier covers customers, colleagues, citizens and climate. “It is a more humane way of working, with empowered multidisciplinary teams and high levels of psychological safety, enabling experimentation and improvement.”

    Digital Zeitgeist

    I was delighted to see parallels with what we had written in ITIL 4 High-velocity IT. We recommend considering five objectives that help you identify and assess your weakest link across the whole value stream, and discuss which improvements you could make:

    • Valuable investments – Strategically innovative and effective application of digital technology.
    • Fast development – Quick realization and delivery of digital services and products.
    • Resilient operations – Highly resilient digital services and products.
    • Co-created value – Effective interaction between service providers and service consumers.
    • Assured conformance – Adherence to governance, risk and compliance (GRC) requirements.

    Valuable investments and co-created value correspond with value, fast development with sooner, resilient operations with better and assured conformance with safer. Happier manifests itself in co-created value but also in the five key behavior patterns that I believe employees aspire to:

    • Help get customers’ jobs done.
    • Trust and be trusted.
    • Accept ambiguity and uncertainty.
    • Continually learn and improve.
    • Do the ethically right thing.

    As I pointed out in another article, Gene Kim came up with a similar concept to the aspirational behaviors in his book, “The Unicorn Project.” He calls them the five ideals:

    • Locality and simplicity in our code and organization.
    • Focus, flow and joy in our work.
    • Enablement of improvement and achievement.
    • A culture of psychological safety.
    • A relentless focus on our customers.

    This all reinforces my belief that many of us are thinking along the same lines. We have tuned into the zeitgeist. People are increasingly concerned about doing the right thing and doing it well, and I am sure that “Better Value Sooner Safer Happier” will contribute to energizing this community.

  • IT Revolution Announces New Technology Book, ‘Project to Product: How to Survive and Thrive in the Age of Digital Disruption with the Flow Framework’

    Value Stream Network pioneer Dr. Mik Kersten introduces the Flow Framework as a new way of building an infrastructure for innovation to change the way enterprises approach software delivery

    PORTLAND, Ore., November 8, 2018 — IT Revolution (http://itrevolution.com), the industry leader for advancing DevOps, today announced the availability of its latest book, Project to Product – How to Survive and Thrive in the Age of Digital Disruption with the Flow Framework. Authored by Dr. Mik Kersten, founder and CEO of Tasktop, the book presents a new concept called the Flow Framework, which is aimed at unraveling the enigma of enterprise software delivery. Based on his work with Fortune 100 enterprises, Kersten provides a new managerial approach to help organizations better understand the human and system dynamics that underpin their IT infrastructure.

    Paperback and eBook editions of Project to Product will be released November 20. To pre-order, visit: (https://itrevolution.com/book/project-to-product/). More information forthcoming about the Audiobook version can be found at: (https://itrevolution.com/book/project-product-audiobook/).

    “We are thrilled to share this important work from Dr. Kersten, one of leading thinkers on bringing back developer productivity and enabling value stream networks in large enterprises,” said Gene Kim, founder of IT Revolution and co-author of The Phoenix Project, The DevOps Handbook, and Accelerate. “As truly great books do, Project to Product changes how one thinks about software delivery. I think this book is vitally important for every technology leader responsible for helping their organizations survive and thrive in the age of digital disruption.”

    About the Book

    As tech giants and startups disrupt every market, those who master large-scale software delivery will define the economic landscape of the 21st century, just as the masters of mass production defined the landscape in the 20th. Unfortunately, business and technology leaders are woefully ill-equipped to solve the problems posed by digital transformation. At the current rate of disruption, half of S&P 500 companies will be replaced in the next 10 years. A new approach is needed.

    In Project to Product, value stream network pioneer and technology business leader Kersten introduces the Flow Framework—a new way of seeing, measuring, and managing software delivery. The Flow Framework will enable your company’s evolution from project-oriented dinosaur to product-centric innovator that thrives in the Age of Software. If you’re driving your organization’s transformation at any level, this is the book for you.

    To download a free excerpt or the audiobook companion of Project to Product, please visit: (https://itrevolution.com/book/project-to-product/).

    “Project to Product has been a 20-year journey that started with a decade of learnings as an open source developer, and applying those learnings to my last ten years working with IT leaders,” explained Kersten. “I hope anyone who reads my book gains the inspiration to drive the digital innovation initiatives that the industry needs to move beyond ad hoc heroics toward a unified view of software delivery value streams. As IT organizations continue to scale at an incredible pace, Project to Product offers a new approach and business framework for gaining control and thriving in the Age of Software.”

    Book Review Supporting Quotes:

    “During our transformation to a “100% Agile” BMW Group IT organization, we discovered early on that the former project portfolio approach did not sufficiently support our journey. Therefore, we started with a transition from “project to product.” The exchanges with Mik on the topic of product orientation and the Flow Framework was very helpful and a real inspiration for me. The fact that Mik is now sharing his vast knowledge in this book makes me particularly happy. It provides the motivation and the toolset necessary to help create a product portfolio based on a value driven approach. For me it is a must read—and indeed it is also a fun read.”

    —Ralf Waltram, Head of IT Systems Research & Development, BMW Group

    “If you want to get rid of obsolete practices and succeed with the new digital, read this book.”

    —Carlota Perez, author of Technological Revolutions and Financial Capital: The Dynamics of Bubbles and Golden Ages

    “Every now and then, a body of work comes along with such timely precision that you think hallelujah! Mik’s book Project to Product is the perfect antidote for those businesses struggling with digital transformation, broken Agile implementations, and the onslaught of enterprise disruption. In fact, it’s a really important component in the world of flow which is at the forefront of business agility. Not only will this framework help your teams ignite their software delivery cadence but to do it at scale, with high quality, reduced costs, and increased value. And more importantly, with happy teams—with the metrics to prove it.”

    —Fin Goulding, International CIO at Aviva and co-author of Flow: A Handbook for Change-Makers, Mavericks, Innovation Activists, Leaders: Digital Transformation Simplified and 12 Steps to Flow: The New Framework for Business Agility

    About the Author:

    Dr. Mik Kersten started his career as a Research Scientist at Xerox PARC where he created the first aspect-oriented development environment. He then pioneered the integration of development tools with Agile and DevOps as part of his Computer Science Ph.D. at the University of British Columbia. Founding Tasktop out of that research, Mik has written over 1 million lines of open-source code that is still in use today, and has brought seven successful open-source and commercial products to market.

    Kersten’s experiences working with some of the largest digital transformations in the world has led him to identify the critical disconnect between business leaders and technologists. Since that time, he has been working on creating new tools and a new framework for connecting software value stream networks and enabling the shift from project to product.

    Share This: Pre-order your copy of “Project to Product” by @mik_kersten and learn about the #FlowFramework—a new way of seeing, measuring, and managing software delivery. Coming November 20th! https://itrevolution.com/book/project-to-product/ @ITRevBooks @tasktop

    About IT Revolution

    IT Revolution assembles technology leaders and practitioners through publishing, events, and research. Our goal is to elevate the state of technology work, quantify the economic and human costs associated with suboptimal IT performance, and to improve the lives of technology professionals.

  • DevOps Chat: The Kitty Hawk Venture & Continuous Testing w/ Aruna Ravichandran

    DevOps Chat: The Kitty Hawk Venture & Continuous Testing w/ Aruna Ravichandran

    A great new book on DevOps is coming out called “The Kitty Hawk Venture.” In the vein of “The Phoenix Project,” it is a novel about one fictional company’s journey specifically with continuous testing. Based on a real-life airline company, the book is great case study and learning experience around continuous testing and its importance to the entire CI/CD and DevOps experience.

    The book is written by Jeff Schaeffer, general manager of the Continuous Testing business unit at CA Technologies; Alex Martin, CTO of Continuous Testing at CA Technologies (and former CTO of Rally Software); and Aruna Ravichandran, vice president of  Gobal Marketing at CA Technologies and author of “DevOps for Digital Leaders.” Beyond the book, there is a companion ebook on continuous testing, as well as other related content.

    In this DevOps Chat, we speak with Aruna, who is a frequent guest on our chats, about the book, continuous testing and the overall DevOps market. It is an excellent chat and, as usual, Aruna’s passion for what she does and DevOps shines through.

    For those not familiar with our DevOps Chats, the streaming audio of our conversation is immediately below, followed by the transcript of our conversation.

    Audio

    Transcript

    Alan Shimel: Hey everyone, it’s Alan Shimel. devopsy.kinsta.cloud. You’re listening to another DevOps chat. This is gonna be a really great chat. I have one of my dear friends in the DevOps industry joining us. Aruna Ravichandran Ravichandran, VP of Marketing DevOps at CA technologies. But more than that, now a multi-time author as well as a code engineer and a bunch of other things. She’s had an amazing, amazing life and career. Aruna Ravichandran, welcome.

    Aruna Ravichandran: Thank you, Alan. I am very excited to be here with you today talking about my latest book.

    Shimel: Yup. So it’s a new one coming out, hopefully in July I guess is the current timeline. And it’s called, “The Kitty Hawk Venture.”

    Ravichandran: That is exactly right. So you know, I think we chatted about a year ago when I wrote my first DevOps book. It was called, “DevOps for Digital Leaders.” And what we decided to do based upon the substance of the book is to basically to take a leaf from the Phoenix Project and write this book in terms of a real life story about one of our customers. I can’t name who the customer is. And the book is actually called, “The Kitty Hawk Venture.”

    And it’s a novel about continuous testing in the world of DevOps in order to help customers as they’re going through their digital transformation journey. So it’s not written as a continuous testing handbook.

    But it’s basically a real life example which happened with one of our customers and tells the story of the journey they actually went through in terms of how they actually transformed their testing discipline, lines of automation down to continuous testing and how they actually addressed some of the bigger challenges they actually had internally across the board.

    Shimel: Got it. So Aruna Ravichandran, I promised you and I promise our audience, no spoilers on this. So I don’t want to go too much into the actual story of the book, let’s keep it at a high level and say that it is about continuous testing and it is based on a real life customer experience. Maybe an amalgamation of customers.

    But you know, Aruna Ravichandran, you mentioned your first book, “DevOps for Digital Leaders.” So this is then your second book on DevOps.

    Ravichandran: Yes, it is. But this time I’ve actually focused on one of the emerging disciplines within DevOps. the first book was primarily focused around DevOps as a discipline, some of the challenges customers actually face.

    Where do they actually start. Because you know, there is no hard and fast rule in terms of DevOps. you can start with continuous integration. You could start with continuous operations. Or you could start with continuous testing.

    The book was primarily focused around end to end DevOps and gives some amount of coaching to the end reader on where to start, what’s the maturity model, what are some of the metrics, how do you measure the substance of DevOps.

    It also talks about several different customer examples on the journey they actually went through. But and speaking from that, we saw that a whole bunch of our readers are interested in learning more about an emerging discipline around continuous testing. So this book is primarily focused on continuous testing as a discipline and why it’s a very important area within the world of DevOps.

    Shimel: Yup. Now, Aruna , though, you hear it in your voice when you’re speaking to our audience here – it comes through loud and clear. this whole area of DevOps – continuous testing specifically with the book. It’s something that you are passionate about. I get it, you’re a VP in the DevOps group. You should feel an affinity. But this seems to go beyond your title and your job. It’s truly something you have a passion for.

    The book is almost 200 pages from the early view I saw. You don’t write 200 pages, you know, blah, blah, blah. You’ve gotta have sort of a burning passion. What is the passion that’s driving you?

    Ravichandran: So the passion that drives me is my customers. As I talk to my customers in the DevOps space, I am very passionate about solving customer problems. And as I talk to my customers, especially customers who want to make an impact, who are on their digital transformation journey, what I learned was testing is a discipline which has existed for several different decades across the board, the very first time when this actual code was actually implemented.

    But what you – what I actually found is that people have testing practices. But it’s mostly around islands of automation. Very, very few customers actually are doing end to end testing, which I call continuous testing.

    And even though you have islands of automation, what I actually find is that testing still continues to be manual. I did a poll of a whole bunch of enterprise customers across the board, and I was shocked to find that testing still appears to be 70% manual across the board.

    And given all of the – this is my personal reason for why I am very passionate about continuous testing, because I think that DevOps has gained a tremendous amount of precedent, but if you don’t embed continuous testing as a discipline across the software development life cycle, you really cannot go through DevOps.

    So continuous delivery has a lot of what do you say affiliation with the market. More and more people are getting educated on how to basically go through the CICD pipeline so that it can go from code to production in minutes. But what they realize is that if you don’t have the testing discipline embedded across the SCLC, going through the pipeline doesn’t buy you anything.

    And so that’s why this is a very important topic which I am very passionate about.

    Shimel: I mean, Aruna Ravichandran, on some level it’s almost – and I think I’ve heard you say this, continuous testing is almost the missing link. Right? In the continuous delivery, in the software development life cycle delivery chain. Right?

    For a lot of – you know what I mean? Companies, they focus on configuration management, on CICD, even on security. But that continuous testing is – it’s right there. It’s a lynchpin. The other thing I wanted to just quickly mention about it is continuous testing isn’t just a pre-delivery —

    Shimel: It’s truly continuous.

    Ravichandran: You nailed it. I would 100 percent agree with you on everything you stated. It is the missing link within DevOps. continuous testing is a practice of testing across every activity in the software development life cycle with the hope that you can uncover and fix unexpected behavior as soon as it’s ingested.

    So it’s about embedding testing as a fundamental and ongoing aspect of every activity through the application life cycle, going all the way from requirements down into production, while facilitating the pre-exact mechanisms what happens in the world of DevOps to where you can actually fix the problem throughout the life cycle.

    Shimel: Let me return to “The Kitty Hawk (Venture),” here again if I can for a moment. You mentioned earlier you took a page out of Gene Kim’s Phoenix Project book in that this isn’t similar to other books you’ve written and that I’ve even reviewed. That are your typical sort of business textbooks, right? You follow an outline and a table of contents and it goes. “Kitty Hawk” is more like you say – a novel, I think is the right word for it.

    How does that make it different for the reader? Or the listener if it’s an audiobook? For someone reading the book.

    Ravichandran: Yup. So for example – this book “[The] Kitty Hawk Venture” is actually based on the main character in the book is Leigh Freemark and she’s a senior director for quality assurance at a company called Runway Air. So the vertical we actually chose was an airline company.

    The way this book is actually written is it talks about the journey of what they actually went through from a transformation journey. So they experienced a major glitch in terms of quality and which caused a substantial amount of negative reputation for Runway Air.

    So this book actually walks through Leigh’s journey, the journey of her own personal mission of making quality first as a big part of her agenda.

    And the way this book is written – we have so many technical books which basically come into the market on DevOps and on testing, so on and so forth. So we wanted to basically – we took a leaf from “The Phoenix Project,” and we also took another leaf from “The DevOps Handbook,” which is the second book which was recently announced by Gene Kim.

    So this is basically written as a novel which tells you the journey which Leigh Freemark went through with Runway Air, but at the end of each chapter we give guidance in technical terms, of what was the actual continuous testing journey Leigh actually went through.

    Right? So that’s why I said, it’s written as a novel but at the end of each chapter we also have like a handbook around the continuous testing discipline on what changes people actually need to make in order to fully embrace continuous testing as a discipline in the book.

    Shimel: And even beyond that, Aruna Ravichandran, from what I understand and correct me if I’m wrong, you guys are planning on coming out with sort of an eBook companion to “Kitty Hawk” on “The Definitive Guide for Continuous Testing.” Is that correct?

    Ravichandran: That is exactly right and so we just actually published it and it will be out very soon. It’s called “The Definitive Guide to Continuous Testing.” And here, we walk our users through 11 different disciplines on continuous testing.

    Ongoing all the way on small teams [sound drops] _____ to how basically they can go through the transformation journey on continuous testing. And at a very high level, I walk you through eleven disciplines and you will see that completely in the novel because that was the journey which Leigh Freeman actually went through in the book, is the first discipline how do you basically and it will – the – you know, all of your testers.

    It could be a developer who is actually doing unit testing or it could be someone who is doing API testing or it could be load testing. Or it could be reproduction testing. All testing in production, you need to be able to have your environment set up. How do you quickly virtualize your environment becomes a very important part of the mix.

    How do you basically break on your environment, how do you actually create your environments very, very quickly is one of the first disciplines. The second discipline talks about testing management right? So regardless of what testing you’re doing having the right data at the right time is very critical. So how quickly can you generate your data?

    And given the world of GDPR right now, you know, which basically went into a test in May, people have to be even more critical about generating test data. You want to make sure that your GDP are compliant. And so having the test data at the right time is critical but also being compliant with a whole bunch of mandates out there is even more critical. The third discipline talks about test automation. How do you basically fully orchestrate the application pipeline.

    So that if the scripts actually fail, you can orchestrate how you can actually achieve continuous testing. The fourth one is around pipeline orchestration. This is the backbone. Everything is tied to it. everything must be integrated with your entire automation stream. You need to understand how it works, how to interpret the results and how do you make quick decisions in order to find out which part of testing is actually a bottleneck?

    And this is what we actually call pipeline authorization. The fifth one focuses on the various different competences, right? If you are testing, the world is going more towards an API economy. So how do you actually bring API testing discipline so that you reduce the reliance on UI testing? Especially for business logic testing.

    The sixth one is around performance and load testing. Right? So you can’t think about performance and load testing toward the end of the testing life cycle. You need to think about shifting left performance and load testing so that you can enable development teams to actually think about this much more earlier on.

    The seventh one is the around the new emerging practice around security testing. So this is where everybody talks about DevSecOps, it’s all about shift left security. How do you enable developers to actually embed static code analysis as a part of their unit testing?

    How do you basically get them to think about security testing by making it easy for them? By having it integrated as a part of their ID environments, whether it’s intelliga or it’s xless or visual studios, so on and so forth. So security testing is the seventh one.

    The eighth one is accidents of test driven development and behavior-driven development. So you take the accidents criteria for each user and create that to ensure that those were actually met. Right? So this keeps testing focused within sprints and ensures developers develop what the business actually expect.

    The ninth one is around automated test generation. And this is the activity of manually designing and writing manual tests of automated tests which is the biggest bottleneck.

    They are the computing magazine data surveyed very recently and they asked, which is the biggest bottleneck across your software development life cycle? 63% of the practitioners actually said that testing was a bottleneck. And why was testing a bottleneck? Because it takes time.

    Think about it, you have actually created 200 test cases for your regression suite for a vertical feature you are going to launch. Let’s assume you’ve caught a major defect and you fix the vertical defect, it means that you have to go back and recreate all of your regression text suites.

    And if there was an automated way that you could take your requirements and as things changed in production you can recreate your test suite, that will be a tremendous amount of savings for anybody to actually not have to create the test cases manually which then eliminates the bottleneck which we actually have.

    The tenth one is around requirement engineering. You must include all of SDLC stakeholders into your continuous testing journey. This means finding a better way to communicate and collaborate right from the requirements phase. The earlier one includes requirements engineering into continuous testing initiatives, the smoother that continuous testing journey will be. Because team members will be working with the same understanding right from the beginning.

    And the last but not least – the eleventh discipline talks about feedback loops. This is the heart and soul of DevOps, it still continues to be the heart and soul of continuous testing. These are critical to ensure that you can have successful continuous testing.

    Shimel: Excellent. You know, Aruna Ravichandran, sitting here looking – I want you to talk about quality, I don’t know if we have time. Maybe we’ll do it on another show. But the 11 disciplines, you did a great job laying them out here. I’m just wondering if someone listening says to themselves, oh my goodness, where do I begin? This is daunting. There is eleven of them. What is your advice to someone just starting out, listening in here – do I do eleven at all at the same time? What do I start with? What – do I take the path of least resistance? How do I get started with this?

    Ravichandran: So I break it up into six different areas, so this is a question you get asked for DevOps and you get asked the same question around continuous testing. So if I have to give guidance on techniques on how to actually adopt – it’s also a cultural transformation too.

    So the first one is, you know, you need to figure out a way to improve the relationship between the tester and each developer. So keeping the team small and creating inter-team collaboration makes it very easy to actually report and actually share the results between the tester and developer.

    So that would be one important tactic which needs to be adopted from a cultural transformation perspective. Number two, is like I said, people actually have automation within testing, which is what we call test automation. But they really haven’t automated the whole thing. So I would say continue to make automation a priority.

    So figure out where people are spending a lot of their time – it could be around building a regression test suite, because they tend to be manual. So how do you automate? So keeping that automation mindset is important. Figuring out where you’re spending cycles of your time in terms of doing manual tasks is important. So making automation a priority is important.

    Map out within your SDLC and identify your automation opportunity. Number three is make it small – right? Like get small. Break it down into smaller increments so that it’s easier to test after every aspect of the SDLC. So break down increments after coding. Break it after design. This makes it easier to automate the test and it also makes it much more easy to deploy and integrate as a part of continuous delivery.

    The fourth one is you want to keep track of everything. Use metrics. Start-up criteria. Right? So your defect density rate is high, figure out how can you reduce the defect density rate. Continuous testing is all about immediately identifying if things are working or not. How do you basically rinse and repeat if it’s working, or how do you actually pivot and change if it’s actually not working.

    The fifth one is getting the right continuous testing tools. Tools play a big role. So we talked about also transformation, we talked about processes and practices, and also having the right tools is important. Figure out the tools that help you develop tests and analyze continuously.

    Pick the best of breed tools that work together in a way that incorporates very easily into your continuous delivery environment. Choose tools which have community based support, that have open source plans that everyone shares the challenges and solutions and have interesting and lead to interesting use cases.

    And last but not least, the number sixth one, is develop a system to display your results. So do deep dives into the results, because that shows you that if you have your code not working, where the gaps are. define your KPI and your acceptance criteria and make them quantifiable. Create dashboards to track those KPIs, including a baseline so that you can actually track with the sequence changes. So these are some of the disciplines I always share with my customers as well as my clients.

    Shimel: Excellent. And now with everyone listening on here. Aruna Ravichandran we’re almost out of time, one more question if you have a second.

    Ravichandran: Absolutely. I do.

    Shimel: So I don’t know if we’re letting the cat out of the bag. If you can’t talk about it, politely say so. But you’re about to roll out something we hear called continuous testing academy? Launching this summer?

    Ravichandran: Yup.

    Shimel: So what’s that about?

    Ravichandran: So the key thing – going back to the question you asked, this continuous testing is like an emerging discipline. People want to know what do I need to do, how do I need to start? How do I get there. And so last year I launched the – I saw that there was a tremendous amount of need in the market around JMeter.

    And so I launched JMeter academy in order to basically to provide input to the community so they could actually train themselves on JMeter. But this year, knowing that continuous testing is gaining tremendous amount of momentum, I’m going to launch a continuous testing academy.

    This is going to have a basic module, it will also have an advanced module. And people will actually have the opportunity to go through the entire module and get themselves certified. We’re also going to launch a certification and you will have the opportunity to become continuous testing certified by DevOps institute. So this is our way to give back to the community in order to basically get people understanding on how they need to evolve their continuous testing practice in order to make a bigger impact in the DevOps world.

    Shimel: Excellent, again, Aruna Ravichandran – great job. You are just, I mean, literally, what a dynamo. All over the place. Doing so many different projects. All with DevOps and continuous testing as a theme there. Congratulations and hats off to you. One of my heroes. Anyway, we’re about out of time. Thank you so much, Aruna Ravichandran, for giving us a preview. Once Kitty Hawk is available to the public, I’d love to have you back on and perhaps we can chat more about it, sound good?

    Ravichandran: Yep. That sounds awesome. As always, Alan, it was excellent talking to you. I love your energy, I love your passion. And looking forward to partnering with you more as we basically enable our customers and prospects to continue on marching further along in the world of DevOps.

    Shimel: Well stay tuned for some announcements, we’re working on it. Aruna Ravichandran, I will be in touch. Aruna Ravichandran Ravichandran, a VP product marketing, marketing DevOps, CA technology, multiple times author, and really DevOps enthusiast. Thank you for being our guest on DevOps chats today. We’ll speak to you soon. This is Alan Shimel for devopsy.kinsta.cloud. You’ve just listened to another DevOps chat. Have a great day everyone.

    — Alan Shimel

  • DevOps Chat: ‘The DevOps Adoption Playbook’ by Sanjeev Sharma

    DevOps Chat: ‘The DevOps Adoption Playbook’ by Sanjeev Sharma

    Before the recent IBM InterConnect conference I had a chance to sit down and chat with Sanjeev Sharma, CTO of DevOps Adoption at IBM. I have spoken to Sanjeev many times and he is a contributor to devopsy.kinsta.cloud, as well as the author of “DevOps for Dummies.” Sanjeev has a new book out called “The DevOps Adoption Playbook.”

    With no disrespect toward the “DevOps for Dummies” book, the playbook is on a whole different level. This book represents the culmination of years of learning by not only Sanjeev, but by IBM in general, as well as some of the leading names in DevOps that he learned from during this time.

    “The DevOps Adoption Playbook” lays out a clear “how to” for DevOps including topics such as value-stream mapping, how to lead the transformation of culture and scaling DevOps to the enterprise. As Sanjeev himself says, the book started from a power point of best practices that he had started that tried to take in everything he had learned.

    Sanjeev also stays true to the “playbook” paradigm. He makes references to cricket, soccer and other sports throughout. It is a good read and well-organized. As I told Sanjeev, in a field full of “what is,” “The DevOps Adoption Playbook” is a “how to.” I highly recommend it.

    As usual, the streaming audio of our conversation is below, with the transcript of our conversation below it.

    Alan Shimel: Hi, everyone. Alan Shimel, devopsy.kinsta.cloud, here for another DevOps Chat. Today’s guest on DevOps Chat is Sanjeev Sharma, a DevOps author and IBM CTO DevOps. Sanjeev, welcome.

    Sharma: Thanks, Alan. Good to talk to you again and I’m glad to be on this DevOps Chat

    Shimel: Absolutely. Sanjeev, you are of course CTO DevOps Solutions at IBM, correct?

    Sharma: The exact title, not that it matters as much—it’s just nomenclature—is CTO DevOps Adoption. I am client-facing and work with customers around the world, helping them adopt DevOps, primarily focused of course on IBM solutions.

    Shimel: In addition to that, Sanjeev, of course you are the author of both editions of the “DevOps for Dummies” books, which were very successful in introducing DevOps concepts to the world at a time when DevOps wasn’t quite as well-known as it is now. Correct?

    Sharma: Right, yes. It’s hard to believe that that book has been around for multiple years now. We’ve had tremendous success. Bernie Coyne coauthored the second edition with me. We updated it and it’s been very successful. The book came out at a time when people were mostly asking the question, “What is DevOps and what does it mean to me?” That’s what that book is targeted towards. It’s a very short book. You can read it in an hour, an hour and a half. It’s like a dummified version, so pretty short and to the point.

    Shimel: Yes. But really, Sanjeev, I wanted to talk to you about the new book that you just came out with through Wiley and IBM Press and its called “The DevOps Adoption Playbook: A Guide to Adopting DevOps in a Multi-Speed IT Enterprise.” Sanjeev, I’ve read the book and to me this sort of represents the culmination of all of the lessons and the knowledge that you have accumulated over these last few years, in helping organizations around the world with their DevOps. Is that fair to say?

    Sharma: Absolutely, but I would go one step further and say it’s just not my knowledge and my experiences, which are fairly extensive. I’m sure I worked with dozens of customers around the world. I haven’t counted, but some of them very intimately through their multi-year DevOps adoption journey.

    But as you will see in the acknowledgement section of the book, it was also knowledge I gained talking to my colleagues here at IBM, talking to people like you and other business partners, our followers and colleagues in the DevOps industry, and also of course from our customers, because I wasn’t with them 24/7 carrying the tools of the trade and implementing DevOps and fighting the technology and the political and the business battles. They were doing it, and I was learning by observing them succeed or, in some cases, stumble and then figuring out with them how to go around the hurdles they were facing. So I owe a lot to all the people I worked with over these years, including our customers, in putting together what has come in this book.

    Shimel: Absolutely. Sanjeev, you’re being humble. You have worked with dozens of DevOps people. But in that role, as you say, you’ve interacted with many of the thought leaders, if we can call them that, within the DevOps movement.

    More than that though, when you look at the book, what I’ve said about the book and I’m writing a review of it, is that in a world full of books that are “what is” your book is a “how-to.” I think that’s an important reminder. We read too many books around DevOps that are trying to define what DevOps is, trying to put your finger on that slippery fish of, “This is DevOps,” where you spend some time on that right in Chapter 1. We give a little review of DevOps, but you spend a lot more time on good practical how-to DevOps advice.

    Was that your idea with this book? What drove you to write this book?

    Sharma: Absolutely, Alan. If you read this as a “how-to” book and not a “what” book, then I have succeeded in getting my message across. Quite frankly, it’s how this book came together. As I was working with our clients maybe two years, 18 months ago, the questions started changing. People no longer were asking us, “What is DevOps?” They were asking us, “How do I adopt DevOps? What are you seeing other people do? What can I learn from your experiences when you go with that bank over there or that health care company or that telco, that retailer? What are you observing when you’re out there in the trenches?”

    I started actually putting together a PowerPoint deck. This is where this book started, as a PowerPoint deck of best practices as part of the success. In fact, last year at InterConnect, myself and my colleague, Lee Reid, who is actually the technical editor of the book, we did that presentation and we called it “The DevOps Adoption Playbook,” and that’s what I intended this to be, this book to be a playbook which somebody reading it can have or they can learn all about it and then, based on the situation they are facing, pick a play, just like a coach or a captain does or a quarterback does in American football. He can do a read and get an idea of, “Okay. We need to run this play because that’s what’s needed here.”

    So it’s definitely a how-to book. There are certain, of course, strategic areas in the book on how to convince the business that the DevOps is in order to make a business case. Like its name suggests, it’s a playbook on how to go and get in the trenches and adopt DevOps in a large organization.

    Shimel: Sanjeev, first of all, the book is available on Amazon and other sort of traditional bookseller sites. Correct?

    Sharma: Absolutely. This is my first retail book. The first book that you mentioned, “DevOps for Dummies,” was a free book we were giving away, sponsored by IBM. So to me as an author, when the book came out and I knew it would be available, the first thing I did was drive to the nearest Barnes & Noble, which actually is 15 miles from my house, just to go see the book on the shelf. So yes, it is available at all major booksellers, both as a physical book and as an e-book.

    Shimel: Let me ask, and I think I probably know the answer. Did you take a picture, a selfie of yourself with the book on the shelf behind you?

    Sharma: I wanted to do that, but the book was placed at a very awkward angle, so I couldn’t get myself into it. So I just took a picture of the book sitting there with the other books. And, you know, it’s not a selfie if you give the camera to somebody else. This was in the middle of the day. They were letting nobody in the bookstore. It was pretty hilarious. I wish I had videoed the whole thing.

    Shimel: Very cool. Sanjeev, people can get the book. They can see you for themselves. Also, I will mention that it’s the kind of book where if there’s something specific you’re looking to hone in on, a particular issue, problem, topic you’d like to delve into, the table of contents and the way it’s laid out makes it very easy to do so. So you could use it to kind of pinpoint in the kind of thing you’re looking for, or you can take it as an overview around the whole book. Either way it’s pretty good.

    Sharma: Thank you.

    Shimel: But, Sanjeev, there are a couple of terms in the book that I’d like to – one of the things is you talk about this concept of fast waterfall. It was mentioned in there a few times and I’ve seen others mention it.

    Sharma: Sorry. [Audio breaks up]

    Shimel: Did I break up there? I apologize.

    Sharma: Could you repeat that?

    Shimel: Sure.

    Sharma: I’m sorry.

    Shimel: Sanjeev, you talk about this concept of fast waterfall. Did you hear that?

    Sharma: Yes, I did. Thank you for repeating that. We were seeing a very broad spectrum of maturity levels and a spectrum of business needs, and we go with clients and see how they adopt DevOps. So when I go into an organization, no organization is monolithic. No organization is homogenous. You see one part of the organization where nothing is broken, things are going fine, but they’re using a very old-school waterfall approach to delivering systems.                           

    So the question that arises is: What do you do there? Do you disrupt something that is working during maintenance, more to try to introduce agile principles or try to introduce continuous delivery? Or do you just make what they are delivering more efficient?

    My thesis in the book is that you focus on optimization. You look at the delivery pipeline. You do what we call a value-stream mapping, and look at where the waste is, where the bottlenecks are, and look towards eliminating or mitigating those, without necessarily needing an end-to-end sea change to say, “No, you have to stop what’s working for you. Your business doesn’t need you to go any faster. Your business doesn’t need you to be more innovative because this is an application in

    – but you have to disrupt it.”

    That all or nothing approach does not work. It is also very expensive. So how do we make it more efficient? I don’t like the term “fast waterfall.” I would like to call it “optimized waterfall”. You focus on optimization. Yes, eventually your goal should be to move to full Agile. You goal should be to move to continuous delivery, but you cannot do that day one. You cannot do it across every project, every system and every application at the same time, but you can do some things to start everybody on that optimization journey.

    That is to me what I am referring to in the book. Get started. Get started where you are. Understand your end goal. But you don’t have to get there at light speed. You don’t have to get there yesterday and you don’t have to get there all together. You have to make that business decision of how much change to introduce, how much change you can consume, and how much change you can afford at this time. Maybe not today, maybe you can only do it next year. So that’s summarizing some of the thinking behind what you’re really getting ready to do.

    Shimel: Understood. Sanjeev, you mentioned value-stream mapping. That’s a workshop that I’ve seen you perform over the years and it’s great. If anyone ever gets a chance to sit in on one of your value-stream workshops they absolutely should. Can you give us just a little bit of an idea of what’s involved with that?

    Sharma: Sure. Value-stream mapping, I would add, as an exercise is nothing new. It’s been in there in the Lean movement since the last century, probably since the 1950s. It’s a technique by which you look at processes and you try to figure out where there might be some waste, and then do a root cause analysis to determine why the waste is there and make a plan to mitigate it.

    So in DevOps, if you look at your delivery pipeline as a value stream, that requirements are coming in at one end and code running and production being used by a user, getting business value at the other end, we do a value-stream mapping to look at where the waste is. So we look at artifacts going through that delivery pipeline.

    What are those artifacts? Who are the stakeholders who touch those artifacts and perform actions on them, who do processes on them? How does the transition happen from one stakeholder to the other? How does the artifact get transformed as it goes from one stakeholder to the next? What environment or tool or repository does the artifact live in and is it consumable?

    There’s a concept in Lean called percent complete and usable, which tells me: when I get an artifact, can I use it as _____ to consume it? Are the requirements coming from the business usable by developers? Is the code coming from developers usable by the testers or whatever? Are there manual tasks which are causing waste? Are there tasks people are doing which add no value to the product? They don’t add any business value, like status reports. They have some value, but are the status reports really being used to progress the product or are they really being used because some needs a view, and they have to spend time creating those reports rather than having a real-time dashboard somebody can just look at?

    So a value-stream mapping exercise and what you’ve seen is a half-day version of a workshop we do with clients, where we go in and take one project of theirs and do a value-stream mapping to get an idea of where the waste is. Many times, actually more often than not, we do it at a division or a program or a line of business level and look at for that line of business: What does the value stream look like and where are the bottlenecks? Where is the waste?

    Then we spend some time doing root cause analysis on each bottleneck we identify. Then we go away and come back with a recommended adoption plan of what DevOps practices and capabilities and tooling, and organization change also, would we recommend to help mitigate those bottlenecks. So it’s a very powerful exercise we do.

    I have an entire section dedicated to it in my book. And on YouTube, if you Google, search for DevOps Whiteboard, you will find me doing a mock value-stream mapping also. There’s a 30-minute video of me doing it with one of my colleagues. So it’s something we’ve had a lot of success with and I think it’s something every organization should do.

    Shimel: I agree with you and I have seen the video. Sanjeev, we’re almost out of time. I wanted to just pivot from the book for a moment and talk a little bit about InterConnect. IBM’s InterConnect this year is coming up in about two weeks. I know you’ll be appearing there and I would imagine the book is involved in what you’re talking about. Yes?

    Sharma: Absolutely. IBM Press was the publisher of the book along with Wiley. On Wednesday afternoon we will do a book signing. They’ll set one up. So if you have a book, if one of your listeners has the book, they can bring it there. I’ll be more than happy to sign it and have a chat with them. They will also be selling the books there at the IBM Press store.

    And I am told—I don’t know if I’m even supposed to tell this, but if you come to a DevOps session, a track in the DevOps session, in some of the sessions we’ll be doing some surprise giveaways of books also. But don’t tell anybody that.

    Shimel: No, of course I wouldn’t.

    Sharma: It’s one big secret. No, no, no. Personally, I am doing three sessions, one of which is a panel with customers, and there are two other sessions related. Both of them are topics I picked out of the books, individual chapters from the books. One is on building a business case for DevOps, and the other one is a risk-based model to adopting DevOps.

    Then the third is a panel, and the fourth is a workshop I’m doing on driving innovation. So it’s kind of broader than DevOps. That’s going to be an hour-and-a-half workshop. So it’s going to be a fun few days and I look forward to meeting your listeners there.

    Shimel: Absolutely. You know what? We’ll try to get some links to these in the transcript and notes on this podcast.

    But for now, I think we’ll call it a wrap on this DevOps Chat. Sanjeev, congratulations on a great book here. I mean “DevOps for Dummies” was certainly a great read, but this is a book. Kudos to you and the team. You put together a really nice how-to here. I’m looking forward to hearing and seeing you at InterConnect. Of course we run into each other quite a bit during the year and I’m sure we’ll continue to do so.

    Sanjeev Sharma –

    Sharma: Absolutely, Alan. Thanks a lot for having me and I looking forward to chatting again soon.

    Shimel: Absolutely. Sanjeev Sharma, “The DevOps Adoption Playbook,” a new book out, definitely pick it up, by Wiley Press and IBM Press. Sanjeev, thanks for being on DevOps Chat today and we’ll speak to you soon.

    Sharma: Thank you for having me, Alan. I’ll speak to you soon.

    Shimel: Okay. This is Alan Shimel for devopsy.kinsta.cloud and we’ll see you soon on the next DevOps Chat.

    — Alan Shimel

  • DevOps Ascending: Guardrails, Not Guidelines – DevOps For Digital Leaders

    DevOps Ascending: Guardrails, Not Guidelines – DevOps For Digital Leaders

    The season of DevOps is upon us, if not only related to widespread adoption, then certainly in terms of industry emphasis.

    This week, at the CA World ’16 conference, my colleagues and I will be interacting with thousands of practitioners, all of whom have evolving DevOps narratives. Meanwhile, CA was a founding sponsor of the AllDayDevOps conference, held earlier this week, attracting more than 12,000 registered attendees worldwide.

    These events come on the heels of a successful DevOps Enterprise Summit held last week in San Francisco, where many of the industry’s brightest minds gathered to discuss and debate the current state of play. If activity is a reliable indicator of relevance, the growing noise around DevOps adoption has been amplified into a deafening roar.

    All of this stands as further evidence that DevOps is no longer an emerging phenomenon, but rather a ubiquitous movement transforming the manner in which nearly every organization builds and operates software.

    As a result, the DevOps movement is finally ready to move from initial framing of emerging techniques into the domain of defining best practices. Yet, at the same time, given the fluid nature of DevOps itself and its unique correlation with the individual needs of every business and environment, even this notion of best practices is one that mandates flexibility.

    Increasingly, we hear leading experts in the field espouse the need for these practices, but those that serve as “guardrails” that set useful parameters for DevOps adoption and refinement rather than concrete guidelines that dictate specific requirements.

    Such is the tone and goal of the new book that my co-authors Kieran Taylor, Peter Waterhouse and I released this week to help practitioners understand common DevOps challenges, methods and milestones.

    Titled “DevOps for Digital Leaders,” the book examines the genesis and increasing maturity of DevOps, all with the explicit intention of helping to inform further refinement among today’s organizations. After reading it, I’d argue that any practitioner, from total neophytes to hardened DevOps vets, should walk away with a greater understanding of how to bring today’s best practices to bear within their own work.

    Beyond looking at precisely how DevOps has grown in response and parallel to use of agile methodologies in the world of manufacturing thereby transforming the modern software factory, the book offers specific examples of leading adopters that are using these techniques, and related tooling, to re-engineer the very DNA of their business.

    From the core competencies of building, testing and deploying applications to continuous monitoring and management of software to help stay attuned to changing customer expectations, we sought to offer a practical guide to DevOps transformation. Other chapters touch on finer points related to key topics including creation of success metrics and measurement of ROI.

    In one of the analogies invoked throughout the book, we highlight how DevOps-empowered software factories are not unlike the engineering, design and race day teams present in the world of today’s Formula One racing series.

    Pushing themselves and constantly innovating on the fly—clawing for every second in the name of winning the overall title—the comparison fits nicely as we watch this season’s contenders fight it out down to the final race in Abu Dhabi later this month. As with winning customers in today’s applications economy, clearly every little bit counts.

    Again, no matter what—or how much—you think you know about DevOps, we’d like to think that there are tactical “learnings” sprinkled throughout the book that will broaden and deepen your understanding.

    Download your copy today, and let us help drive you down the road to victory. Alternatively, you can order a hard copy of the book via Amazon, with all proceeds being donated by the authors to fund Foundation for Excellence, which provides STEM scholarships to children in India.

    — Aruna Ravichandran