devopsy.kinsta.cloud

Tag: transformation

  • 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 Chat: Justin Vaughan-Brown, AppDynamics

    DevOps Chat: Justin Vaughan-Brown, AppDynamics

    This episode of DevOps Chats is with Justin Vaughan-Brown of AppDynamics. This was recorded just prior to the announcement of Cisco’s intent to acquire AppDynamics for about $3.7B. So sorry, folks no insight into that deal here.  Nevertheless, Justin is a DevOps veteran. While at AppDynamics for just a few months, Justin has worked and helped lead several DevOps tool and consulting businesses. He has some great insights that he shares here with us.

    As usual, the streaming audio of our conversation is immediately below, followed by a transcript of our conversation. Enjoy!

    Alan Shimel:                Hey everyone, Alan Shimel, devopsy.kinsta.cloud here for another DevOps Chat. And our guest for this edition of DevOps Chat is Justin Vaughn Brown of AppDynamics. Justin, welcome to DevOps Chats.

    Justin Vaughan-Brown:          Thanks Alan, glad to be with you.

    Alan Shimel:                Glad to have you here. Justin, you are a DevOps industry veteran, if there is such thing, in a relatively short time. But you’re hanging your hat at AppDynamics now. How long have you actually been with AppDynamics?

    Justin Vaughan-Brown:          I’ve been with AppDynamics since – it was the very last day of October, so kind of two to three months in now.

    Alan Shimel:                Perfect, just enough to get I guess the lay of the land there. And as we spoke beforehand Justin, and as I think most of our audience, it’s been a busy two to three months, you know, between the end of the year and everything going on in the market you’ve had a good chance I would imagine to get a flavor for not only what AppDynamics is doing but really kind of where the market is heading a little bit in terms of DevOps APM and stuff like this. Correct?

    Justin Vaughan-Brown:          Absolutely Alan. I think what was very interesting was – actually a few weeks after joining – was spending time with customers and partners and colleagues at App Sphere in Las Vegas in November: that was absolutely fascinating, so that was a real eye opener in terms of how APM customers – you know, those of AppDynamics are actually using DevOps and adopting it and how they’re leveraging our technology to help them in their DevOps adoption.

    Alan Shimel:                Yes, I was actually at App Sphere as you know – I was at App Sphere myself and it was a great conference and it was a great customer-focused conference in that there were a lot of users there – real live users, right? – the rare, endangered live user at these conference – not a Biz Dev first and not a sales person but real users and I had some fantastic conversations myself.

    Justin, I wanted to spend a moment a little bit talking about APM because sometimes when we look at software development life cycles and kind of where the action is around DevOps you know a lot of people get all hot and bothered and hyped up around configuration management, right, the puppet and the chef and the ansible and salts and these kinds of things. And then, you know, they move from configuration management to CICD and of course that’s a world unto itself.

    But then when we look at let’s say post deployment, you know, okay, so now we delivered and we’re delivering continuously, but what impact is that having? How are things going? Are our customers happy? Are we delivering better products, right, and are they performing as intended?

    And you know all of these things you would think would make APM sort of king of the castle, top of the heap. But a lot of times it doesn’t: it kind of gets subsumed within the whole DevOps conversation or is maybe a little bit outside.

    I’m interested in what’s your opinion on that?

    Justin Vaughan-Brown:          That’s an interesting perspective and I can see where you’re coming from. I think it’s possibly because, you know, from historically a lot of the vendors are more and more what you call classically the dev side and have generated a lot of interest and adoption. But ultimately we’ve seen the company grow from strength to strength, and I think what was really eye opening was – at App Sphere – was seeing how critical app dynamics was in enterprise DevOps adoption.

    And I think what most particularly – you’ve hit the nail on the head there – if you look at for example the impact of those applications in production how are they actually performing, where our issues lie, where the – the apps themselves can be fine tuned and ensure that you have the best customer experience possible.

    I think in the main – and this is a generalization of course now, there are exceptions – I think we’ve gone beyond the state where applications – with the exception of certain tougher cases like say, you know Black Friday and so forth where sometimes some organizations can have challenges – but in the main I think what we are seeing is most applications perform at what I would call a base level – what we’re really now into is tuning them: is identifying absolutely the tiniest little bit of latency or glaze or issues wherever they may lie so that the performance of those applications, irrespective of where they’re delivered – you know, on a tablet or mobile device, on a PC or whatever – are highly high performance, and again, irrespective of platform, operating system or so forth – all of those – I think that’s become one of the overriding demands.

    And I think it’s evolved even more so now – you know, we recently launched Business IQ which actually drills it even further and actually looks at the business benefit of the application you’ve released where a consumer’s using the application, where are they located, where are they on the user journey, where are they on the purchase cycle. And you’re finding lots of consumers are going through to about to purchase and then there’s a delay in the actual purchase process as the transaction is going through or not going through.

    So I think it’s definitely evolved and I think we’re seeing certainly an absolute relevance for APM now.

    Alan Shimel:                Got it. Absolutely. Justin, let me – as I said earlier you’re a DevOps industry veteran though and AppDynamics isn’t your first stop on the DevOps train.

    Why don’t you, if you can share with our audience a little bit – we’d like to hear your views though on – so that’s APM and what sets it apart – what other kind of – let’s look at trends in the DevOps space and maybe how it relates to APMs.

    What other kind of trends are you seeing?

    Justin Vaughan-Brown:          I think one of the interesting ones that we’re seeing is – you know, you’ve seen the evolution of Docker over the last kind of 18 months to 24 months, and I think that and the overall rise of containerizations in general is having a huge impact.

    I recently saw an article by a bank – folks who were going to report that they’d recently issued on the – I would say the stellar rise of containerization and adoption, and it’s almost a case of, you know, there’s no going back.

    So I think it’s really down now to where you’re adopting containers and to what degree, one or another, if, for example. And that’s where we’ve seen our ability to help that; for example in terms of their integrating and monitoring docker container performance easily to ensure that you’re optimizing and maximizing the potential there and that doesn’t become a black box area where you’re not getting the granularity of insights that you’re looking for. So that’s one area definitely.

    I think also, you know, with cloud adoption as well, to be able to monitor across multi cloud environments – and that’s just not one vendor only, you know – as I said multi cloud – whether it’s Amazon AWS, Microsoft Azure,  and so forth.

    So I think there’s a need to be, you know, platform and cloud agnostic going forward. And that’s something recently I’ve seen at analyst conferences where they talked about so many enterprises now from an operations point of view being cloud brokers and then looking at not just one vendor – not being locked in – but being able to switch and change dependent on which particular application they’re working on or initiative and so forth. So I think those are two clear areas.

                                        I think the last one probably I’d highlight is micro services where, for example, the ability with APM to automatically monitor in micro services, you know, deployed in an elastic infrastructure so you can look at issues around say threat contention and then zoom in and identify and address their root causes.

    So seeing all these kind of technologies orbiting around that APM can absolutely assist in the adoption. And if you adopt this properly obviously they’re hugely advantageous. If you struggle with them then they can actually set you back and you’re worse than if you hadn’t embarked on that journey. So those are three that immediately come to mind Alan.

    Alan Shimel:                And I don’t disagree with any of them Justin, I think they’re all dead on.

    Let me throw another – and this might be a bit of a curveball at you – but as a fellow observer of the DevOps space Justin what I find interesting is that when we first started talking about DevOps everyone sort of said, “Oh yeah, DevOps is great for startups because it’s in their DNA and they do it by – you know, not by choice: they have to. And this is – DevOps was made for these folks.”

    Where you know this whole issue of “enterprise DevOps” was almost like a different animal or a different set of stripes. And you know I was always one of the ones that argued DevOps is DevOps, you’ve got to recognize who your customer is and who your organization is, but the principals of DevOps apply across small and large organizations.

    But low and behold here we are now, you know, a new year and we’re a couple more years into this DevOps thing and it almost feels like DevOps is a big organization way of doing business, maybe even more so than the startups. What’s your feeling on that?

    Justin Vaughan-Brown:          I think you’re absolutely spot on Alan. I mean I think we’ve both been on that journey where we’ve observed certain trends and how the markets evolved.

    And if you look at, for example, at the DevOps Enterprise Summit that took place last year in San Francisco and London – both extremely well-attended – and then if you look at those agendas on both of those the vast majority from my perspective of those presenters presenting from the end user side were representing enterprise organizations – household names – in fact if anything those smaller organizations were the minority, and equally even the – you know, there’s also I think with the larger organizations it was those that were not just the, you know, the purely kind of online shop equivalents where they’ve got no legacy infrastructure that they have to deal with: a lot of these are, you know, 50-, 100-year-old companies that have been around a long time yet are making that brave journey.

    And I’d like to just kind of re-quote an observation made by Gene Kim last year when he said what really impresses him is – it makes him really think of people who are being heroes within these large enterprises, within these organizations, who are, you know, probably I’d say mid-level advanced in their career and in age and during their career who are making these brave decisions, who are doing things differently: they could carry on as normal.

    And in doing so they are trying different things, they are embarking on new journeys and they’re bringing their teams with them, they’re collaborating more closely.

    And I think that’s – it’s those kind of – I think Gene Kim is absolutely spot on in it’s those kinds of heroes, those catalysts to change – and I think frankly DevOps is absolutely for the enterprise and will continue to be so.

    Alan Shimel:                Makes sense. Justin we’re running a little low on time. Let me turn this back to App Dynamics if you don’t mind. What are you – so we’ve talked about these trends, we see the market kind of taking shape – what does it mean for AppDynamics?

    Justin Vaughan-Brown:          I think it means a lot of opportunities to continue to help the enterprise customers. Most of all I think – you know, from a personal level I’m very excited by the recent release of Business IQ because I think that enables DevOps teams now to take information relating to how that application is being consumed, where and in which way of these visual user journeys – to actually then take that information and present it to the business – and that moves it from purely a DevOps conversation to a business one just to say, “Look this is – you know, we’ve all be slaving away the last couple of months on this application. Here’s the actual impact to your business; this is what’s happening, this is the value.”

    And then maybe the business turns around to say, “You know what? Interestingly sales in this region are going really well but not in this region or this group of customers, you know, our gold card member carriers are absolutely loving this promotion but our silver card holders aren’t. Maybe we need to incentivize them in some way,” you know, and so forth.

    So that’s moving, as I said, the DevOps teams into a more business conversation. We know about this topic such as Citizen Developers and obviously Shadow iTeam – more and more and more the businesses are being involved in these decisions, and that’s the way for DevOps to help drive that dialogue rather than being on the receiving end and taking requests from the business, that they’re actually driving that discussion which puts them in a really good position.

    Alan Shimel:                Excellent. Justin, we’re just about out of time here but I want to ask you one last question and that’s the kind of question I ask a lot of our guests here on DevOps Chat.

    For our audience listening out there if you had to recommend one book – and not the usual, you know, Gene Kim Phoenix Project that you would expect from a DevOps podcast – what book would that be?

    Justin Vaughan-Brown:          I think I would go back to a book and a course that I took almost 20 years ago which is The Seven Habits of Highly Successful People by Steven Covey which pretty much broke down most of everything that I knew and rebuilt it another way and gave me a fresh perspective, so I strongly recommend that.

    And if you’re pushed for time I think there’s some YouTube videos where you can go in and get the canned insight in 15 minutes, so that’s well worth taking a coffee break.

    Alan Shimel:                Absolutely. But that’s a classic. And for any of our listeners who have not read that one it really should shoot to the top of your list.

    Hey, Justin Vaughn Brown, AppDynamics, thanks for being this episode’s guest on DevOps Chat. Look forward to having you on again soon and sharing some more market insights.

    Justin Vaughan-Brown:          My pleasure. Thanks very much indeed Alan.

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

    — Alan Shimel

  • Customer Demands Outpacing Business Requirements

    Customer Demands Outpacing Business Requirements

    As more organizations adopt agile and DevOps, many recognize quickly that the related gains are significant but further business efficiencies can be realized.

    IT and the business now are working closer than ever. No longer is the business throwing requirements over the wall into the IT “sausage factory”—they’re now an integral part of the entire process. IT has finally transitioned into a profit center.

    In the application economy, it’s not the layout or cleanliness of your brick and mortar store nor the friendliness of a customer service representative that makes your business successful. It’s the application’s user experience.

    As a result, the gains we’re seeing must be optimized continuously. One of the biggest challenges we face today lies in how we get business requirements translated into IT output, at the speed of business.

    In the old days, it was easy to move your best-selling, highest margin products into the ideal location or open another checkout when the lines got too long. With today’s virtual stores, the question becomes, How can we quickly pivot to tend to our real-time customer needs and shareholder expectations?

    We must be able to deliver software faster, and to do that, we need to marry our strategy to execution and delivery. We must optimize across the entire business to create true agility that paves the way for reactive and proactive acceleration.

    Case in point: If you optimize execution but not delivery, you’ll be creating software that cannot realize value at the pace of development. In reverse: If you optimize delivery but develop software slowly and poorly, your efficient delivery process will merely sit waiting—or worse yet, deliver poor quality software quickly.

    As a result, we must optimize all three of these areas while working in conjunction, overlapping and providing constant feedback and properly timing the impact of revenue and potential risk to customer experience.

    Unsurprisingly, to support all of this, we’re also seeing broader adoption of an end-to-end solution stack that supports acceleration of process from ideation through outcome. Let me walk you through this scenario:

    Your business is managing your strategy through the lens of its portfolio. As changes are set in motion at the highest levels, that data must be tracked—how much it costs to implement new functionality, how much time it should take and what ROI looks like—along with constant reviews to inform ongoing decision making.

    Your portfolio decisions are then loaded and tracked systematically at the project level, with resources assigned systematically to deliver the designed functionality through epics and user stories. Related data must also be made available in real time to be viewed at the program, project, epic or user story level, providing complete visibility from the level of developers all the way up to the board of directors.

    Simultaneously, your user stories must be imported into a system that turns them into test cases and test automation assets, then builds the test data synthetically to validate each test case. Once the data is generated, it’s imported into your service virtualization system, where application behavioral virtualization eliminates the need for constrained and non-existing back-end systems, simulating an end-to-end environment for any application that is being tested. This also should update your virtual services automatically with the data required for the test cases and any planned test automation.

    Let’s pause and review what we just did.

    We’re now managing our new functionality items across portfolio, program, project, user story and resource levels, all in real time. We’ve automatically created our test cases, test automation, test data and virtual services, all from the epics and user stories.

    So what have we done? We’ve provided the visibility and insight necessary to make business decisions in real time and track progress. We’ve also also minimized the need for test-case designers (or the business analysts that create them), test automation engineers, test data engineers and the DBA support for test data, freeing these experts to focus on other activities.

    Hopefully, we’ve achieved the desired result of massive reduction in resource allocation, acceleration of the entire software development life cycle, elimination of error-prone manual tasks and, most importantly, elimination of the ambiguity involved in translating actual requirements into test cases.

    Finally, we’ve now got all the necessary elements—team execution, prioritization by value, connection of value to execution, a platform that provides a single source of the truth, communication, and metrics—that will allow you to focus on creating value for your customers, instead of simply creating process.

    Transformation is difficult. Culture/environment eats process for breakfast. However, by focusing on changing your entire approach instead of merely recasting process and teams, you can truly change how you provide value to your customers and shareholders.

    This is how we translate business requirements into innovative software at speed.

    For added perspective on all things DevOps and Continuous Delivery, join my colleague Aruna Ravichandran for a live webcast highlighting the details of her new book “DevOps for Digital Leaders”—it’s sure to be an exciting discussion.

    — Ron DeCanio

  • Overcoming Objection to DevOps Adoption

    Overcoming Objection to DevOps Adoption

    The advent of the application economy has made software arguably one the most critical and valuable assets of organizations across a broad spectrum of industries—financial, telecommunications, entertainment, and government, just to name a few. In the era of “app store ratings” and an unprecedented ability of the consumer to easily switch suppliers of whatever they’re consuming, delivering application feature updates as quickly and as safely as possible while maintaining high quality is absolutely critical.

    Most of us with a pulse in the IT world are aware that the concepts and practices we know as “DevOps” and “continuous delivery” continue to dominate the software delivery conversation in IT organizations everywhere. Almost every business my company works with has some sort of continuous delivery or DevOps initiative in flight (with, naturally, varying degrees of maturity and success). And yet, we frequently encounter organizations where these ideas are anathema to many within, are considered overhyped buzzwords from consultants and vendors or, most frequently, simply do not apply to their organization in meaningful way. Others maintain that they have tried and failed so it’s back to business as usual. Many are swayed by a number of DevOps “myths” that often stop initiatives before they even get started. So, what is the objection over and some myths about DevOps that keep some organizations from taking the steps to improved software delivery? We’ll take a look at a few that we have seen firsthand and, in subsequent posts, suggest some ideas and strategies for getting past them.

    Objection: “DevOps may work for some greenfield apps or startup but that’s not us.”

    Many of our most reluctant customers acknowledge the benefits of DevOps and continuous delivery but maintain that their systems are too old, too monolithic, mainframe-dependent, etc., to reap any tangible benefits from a transformation. In other words, “it doesn’t apply here.” This point of view is especially frustrating because the benefits to organizations like these can be just as dramatic and transformative to the culture and IT “psyche” as found among the “unicorns.” Maybe even more so. As the 2015 “State of DevOps” study stated, “It doesn’t matter if your apps are greenfield, brownfield or legacy—as long as they are architected with testability and deployability in mind, high performance is achievable.”

    Sometimes these groups will look to hybrid strategies such as bimodal where greenfield projects, innovation labs and other internal IT incubators are chartered to use new technologies and methodologies such as DevOps while the rest continue on as always. Opinions differ here, but these strategies generally are fine as a “way station” within an overall transformation road map with the potential to impede progress if accepted as the status quo. If legacy applications still change with some frequency and if deployments are painful for those involved, then those, too, should be included in the DevOps road map. We’ve done it at my company, a 40-year-old software company, and our mainframe team led the way.

    Objection: “We are doing fine as we are.”

    Another common category we encounter is the sense that, after some measure of improvement, perhaps the successful adoption of a toolset, that we’ve done enough. Things are better than before, our deployment pain has diminished so we have accomplished what we set out to do. A corollary to that is “we’ve implemented [Jenkins/Chef/Puppet/Cloud/etc.]” implying a belief that implementing one or more of these  tools is, in effect, “doing” DevOps.

    Successful DevOps is not about adopting a tool or even making measurable progress in organizational goals. DevOps is actually about embracing a culture of continuous improvement, collaboration and, perhaps most importantly, focusing first on maximizing value for your customers. It’s about adopting patterns such as the Deming cycle—Plan, Do, Study, Act—as a core tenet of the way you approach how you think about what you do. No matter what we do, no matter how well we do what we do, there’s always an opportunity to do better.

    Objection: “Implementing a major change like continuous delivery is simply too large and complex an undertaking.”

    When large, well-established organizations seek to undertake a major change, it’s often a task so daunting, so frequently met with skepticism and cynicism across the spectrum of stakeholders, that the initiative, no matter what it is, appears doomed from the start. Couple that with the culture-shift generally required to affect a successful and genuine DevOps transformation, and it’s no wonder that some senior IT leaders either severely limit the scope of these initiatives or, in some rare instances, veto DevOps outright. Regardless, the belief that their teams are too entrenched in current methodologies to make meaningful progress and the seemingly overwhelming weight organizational inertia stops change cold.

    Transforming organizations that have functioned in, more or less, the same fashion for years, even decades in some cases, is practically incomprehensible for many. Organizational cultures generally evolve over time and changing them is not something that can be accomplished by decree and certainly not overnight. The barrier to even starting is often the sense that “we have too much work to do right now and balancing that against some intangible future state is not something we can take on.” Of course, the problem with that line of thought is that there will always be too much work to do now.

    And, of course, there are many other obstacles. Barriers to entry against meaningful transformation like DevOps frequently emerge when new ideas and thinking collide with the status quo, especially pre-existing processes governing the software development and deployment. These processes generally emerged from the best practices of the recent past coupled with reactions to major problems encountered years ago that linger on as faint echoes of bygone errors. Most of these rules were put in place with good intentions, applicable at the time of implementation but may have outlived their relevance. Others may be regulatory and not optional. Regardless, if there ever was an area where DevOps and continuous delivery can deliver benefits, this is it.

    Many large “traditional” IT shops have, indeed, transformed their culture and fostered environments that continuously improve. So, what do you do? Perhaps the most important step is to decide to take the first step. First, understand why you are seeking to change in the first place. What is the ultimate driver and does everyone, top to bottom, the organization have a clear understanding of that “why”?

    Recognize that transformation is an ongoing process where successes and failures are to be expected in equal measure. Learn from both. Don’t attempt to roll DevOps out as a big bang strategy. Work incrementally.

    In upcoming posts we’ll explore some strategies for moving past objection and making real strides toward meaningful and lasting change. What are some of the challenges you have faced in your company’s transformational journey? How did your teams get past the obstacles that inevitably appear?

    — Jeff Bradley

  • Tales of DevOps Discovery Part 2: Definitions Matter

    Tales of DevOps Discovery Part 2: Definitions Matter

    Definitions Matter: Step Two in a DevOps Transformation

    The first post in this series on DevOps Discovery discussed the importance of asking fundamental questions of stakeholders to facilitate alignment on priorities and establish a mission statement when beginning a DevOps transformation. Part 2, below, reviews definitions of common DevOps-related terms and provides examples of how failure to agree on such terms can hinder your transformation.

    The industry is full of terms such as continuous integration, agile, continuous delivery, DevOps, etc. The practices described by these terms often are defined differently by various industry “experts,” resulting in stakeholders in the software delivery process having different understandings of what constitutes these practices. Some will state they are already following the practices; others will state they do not. Some will believe the objectives unachievable, while others will be bullish on the prospects; differing interpretations blocking agreement on the organization’s current and target states. If stakeholders cannot agree on the current state (or the start point) and the target state (or the destination), it is impossible to “map a route” for the journey to DevOps.

    For example, let’s look at how some define continuous delivery:

    Continuous Delivery – Definition 1:

    A software engineering approach in which teams produce software in short cycles, ensuring that the software can be reliably released at any time. It aims at building, testing and releasing software faster and more frequently.

    The approach helps reduce the cost, time and risk of delivering changes by allowing for more incremental updates to applications in production. A straightforward and repeatable deployment process is important for continuous delivery.

    Source: Wikipedia

     

    Continuous Delivery – Definition 2:

    Continuous Delivery is a software development discipline where you build software in such a way that the software can be released to production at any time.

    [Continuous Delivery Blog Post by Martin Fowler]

     

    You may read the above and initially think there is no difference in the definitions but, note that the first definition addresses deployment of software with the statement: “A straightforward and repeatable deployment process is important for continuous delivery,” whereas the second definition addresses deployment of software with the statement: “Build software in such a way that the software can be released to production at any time.”

    This distinction may seem trivial, but it is the often the source of confusion between the practices of continuous delivery and the practice that is commonly called continuous deployment. In contrast to continuous delivery, which states that every software build “could be released,” continuous deployment is loosely defined as “the practice of releasing every good build to users.”

    When establishing your target state for the DevOps transformation a seemly slight confusion such as this can result in pushback from stakeholders concerned that continuous deployment is unachievable or too disruptive. These sentiments include:

    • Business: “We cannot gather, spec and track our requirements at that rate.”
    • Operations: “There is no way we can support daily delivery into production, ensure security, uptimes and perform our day-to-day work. It takes us an entire weekend and multiple attempts to deploy today.”
    • Customers: “Our compliance team needs three months to review and approve every new version of our accounting system.”

    The confusion and potential pushback exemplify the need for establishing baseline definitions and alignment at the start of a DevOps transformation, and doing so in the specific context of your organization. The importance of points such as how far it deploys varies with the organization—some organizations can support continuous deployment to production multiple times a week or even multiple times a day, such as Netflix does. Other organizations, such as providers of critical financial systems, may never pursue this cadence of deployment. Be sure to apply these industry practices pragmatically as fit for your organization, not dogmatically based on generic industry definitions.

    Let’s look at a couple of definitions of DevOps:

    DevOps – Definition 1:

    “DevOps (development and operations) is an enterprise software development phrase used to mean a type of agile relationship between Development and IT Operations. The goal of DevOps is to change and improve the relationship by advocating better communication and collaboration between the two business units.”

    [Webopedia]

     

    DevOps Definition 2:

    “DevOps (a clipped compound of “development” and “operations”) is a culture, movement or practice that emphasizes the collaboration and communication of both software developers and other information-technology (IT) professionals while automating the process of software delivery and infrastructure changes. It aims at establishing a culture and environment where building, testing, and releasing software, can happen rapidly, frequently, and more reliably.”

    [Wikipedia]

     

    Like the example with continuous delivery, these two definitions also are very close. Yet on detailed observation, it is clear the first definition describes DevOps as being focused on relationships (i.e., culture and collaboration). The second definition extends this to include the “automating the process of software delivery and infrastructure changes,” giving consideration to tools and technical practices such as continuous delivery.

    Does this matter? Yes. Often if the executive sponsors and key stakeholders do not account for the need to establish tools and technical practices and only focus on relationships, there is a high chance for unrealistic expectations for timeline, budgets and results. Conversely, if the need for changes in culture and process are not considered and the DevOps transformation focuses only on tools and technical practices, the efforts are also unlikely to yield the expected results. A DevOps transformation must account for the trinity of “People, Process and Tools.”

    When considering DevOps, it objectives and the objective of its component practices it is useful to establish a clear idea of the relationships between theses practices. It is often useful to visualize them as below:

     

    DevOps Transformation Triangle
    The DevOps Transformation Triangle

     

    DevOps is the “What,” the target state as defined by a set of guiding principles. Agile development, continuous integration and continuous delivery are the “How,” a collection of process, practices and tools that together build the foundation for a sustainable DevOps implementation.

    In the next section, we will review some of the initial discovery questions asked when beginning on a DevOps transformation, provide real-world examples of answers from various stakeholders in real organizations, and analyze those answer to better understand the journey to DevOps.

  • Simulation: The ‘Aha’ Moment for DevOps Adoption

    Simulation: The ‘Aha’ Moment for DevOps Adoption

    Every IT transformation requires that people, process and technology align and work together to achieve success. As organizations begin to appreciate the benefits of a DevOps approach and look to change to a DevOps model of software development and release, there will be significant pressure on people, process and technology to support that change properly.

    The technology and process changes required to enable DevOps to work efficiently shouldn’t be underestimated. Considerable time and investment is required in embracing the automation technologies that support a proper DevOps environment, and in developing the processes that make best use of that technology.

    But DevOps cannot work unless your people are ready to change. Development teams and IT operations—who traditionally have worked in silos—must work together, integrate seamlessly and understand not only their roles and responsibilities within the new environment but also the roles and responsibilities of those around them.

    And therefore, like every change, the real key to success is your people.

    Creating Successful Change

    The benefits of taking a DevOps approach are numerous: By moving toward more frequent delivery with reduced elements of change, you lower risk and increase system stability. Although automation is costly to implement, it allows teams to work far more efficiently, increases reuse, reduces errors and brings development teams closer to the customer. New functionality released continually and rapidly can be validated in the market, feedback can be received, lessons can be learned and improvements implemented quickly.

    But in making such a radical cultural shift, how do you ensure you change the mindset of people who have been used to working in a certain way? How do you provide your people with the helicopter view of what that future state will be, instill in them your fervor for change and provide them with the understanding and motivation necessary to embrace new ways of working? How do you ensure everyone is rowing in the same direction? Because without that, your change—already difficult and challenging—will become impossible.

    The Key to Change

    The key to any successful change is communicating your vision to your people. But providing your staff with a clear vision of what that future state could be is enormously difficult. You can outline the benefits of change, explain to them what good will look like, tell them what is in it for them, and all of these are hugely important.

    But there is no substitute for allowing people to actually feel what your future state will be like.

    Nothing compares to parachuting them into a situation where they can work through the changes required in a risk-free environment, experience the pitfalls and live the successes. As you move them to a fully functioning and productive DevOps environment, you will accelerate buy-in from your team rapidly, and give them a much more profound understanding of your vision and future state.

    The Power of Simulation

    Simulation training is one of the most effective tools to explain complex concepts and operating models quickly and convincingly. A presentation on DevOps—or almost any other topic—is not a productive method of showing someone the difference it can make to their work or their business. It’s the difference between reading a script and performing a play. More and more, companies are using simulation training as a shortcut to inform, educate and convince their teams of the value of large-scale organizational change—and DevOps is a prime example. 

    One of the key benefits of the simulation model is that people learn together. Your team learns at the same pace, working toward the same goals—and, as a result, they collectively show each other the value of change. With a traditional change program you need each employee to go on his or her own journey to recognize and adopt your vision. With a group simulation you take everyone present down the road toward a collective “aha” moment. Once that moment has happened you have an instant group of advocates who can go out to the business together and begin to effect change on a much more fundamental level.

    Simulation Brings Agility to Adoption

    Providing a simulated environment in which to train is not new; it has been used extensively and successfully by the military for decades. Commercial pilots train on simulators to provide them with as close to a real-world experience as possible of some of the life and death decisions they may need to make in an emergency. They understand the power of experiential learning.

    Simulating a DevOps model brings that power of experiential learning to your business, allowing you to immerse your people in a concentrated and deeply focused environment where they face the same challenges as they will in the real world.

    In one short morning they get to experience building a culture of DevOps themselves, making mistakes, understanding them and learning from them. It demonstrates the business value and positive impact of a DevOps approach in only a few hours, and can accelerate the adoption of DevOps across the enterprise, successfully turning DevOps opponents into advocates.

    In a world where the quality of your software can make or break your organization, it is critical to create an environment where developers and operations are not only aligned and more efficient, but also empowered and able to concentrate on developing and releasing products that add the most value to the business.

    Rome wasn’t built in a day, and you can’t effect convincing organizational change in a single morning. However, by immersing your team in a simulation, you can take a giant step forward and create a team of advocates who will go out and sell your vision for you.

    About the Author/Andrew Macintosh

    A_Macintosh_PhotoAndrew Macintosh is a Creative Solutions Director for G2G3. He works with clients across the globe, helping to understand requirements and craft technology based solutions to engage staff and customers, internally and externally. Prior to joining G2G3 Andrew ran a production company and worked within the TV industry for 12 years.

  • DevOps Chat: Mustafa Kapadia, IBM DevOps Transformation Workshop

    DevOps Chat: Mustafa Kapadia, IBM DevOps Transformation Workshop

    I always enjoy listening and speaking with Mustafa Kapadia of IBM. Mustafa is one of the leaders of the IBM DevOps services team. As such he gets to work with dozens of different organizations in helping them on their DevOps journey. As a result Mustafa has amassed a ton of experience and knowledge on the correct patterns towards successful transformations.  He had developed a workshop around this that I think is a really great exercise for any organization thinking about DevOps to go through.

    I recently sat down with Mustafa for a DevOps Chat. We spoke to him about the workshop and process.  Below is the soundcloud audio of our conversation. Below that is a video of a workshop demo Mustafa recently delivered at our DevOps Connect: cdSummit SoCal event in Los Angeles this month.  I think you will find them both useful.

    Also the transcript of my conversation with Mustafa is below that.  Finally, below that is an interview I did with Mustafa at the recent DOES 15 event as well. Hope you enjoy.

    [soundcloud url=”https://api.soundcloud.com/tracks/237701095″ params=”auto_play=false&hide_related=false&show_comments=true&show_user=true&show_reposts=false&visual=true” width=”100%” height=”150″ iframe=”true” /]

    Transcript

    Alan Shimel:                And we’re here for another DevOps Leadership Chats. Today’s guest is Mustafa Kapadia of IBM. Mustafa, welcome.

    Mustafa Kapadia:       Thank you, Alan. Good to be here.

    Alan Shimel:                Yes. So Mustafa, of course you and I know each other for some time now. But for our audience who may not be familiar, what is your role with IBM right now?

    Mustafa Kapadia:       Sure. I am the service line leader for our DevOps Consulting Practice.

    Alan Shimel:                And a great job you do of it. I’ve seen you in action.

    Mustafa Kapadia:       Thank you.

    Alan Shimel:                Happy to have you here. Mustafa, one of the biggest issues we hear from executives of enterprises especially is well, this DevOps sounds great and we can understand how startups and smaller companies do it because they are doing it on a green field or from the get-go. But how do I turn the ship here? How do I get started in DevOps? How do we lead the transformation if you will?

    Mustafa Kapadia:       Yeah, Alan, that’s a good question. In fact, that is probably the most popular question we get asked from our clients.  DevOps has so many arms and legs and it’s so hairy and it’s such a big topic, getting started is hard and the way to get started to get the biggest bang for the buck is even harder. And that’s where we start bringing in something that we call value stream mapping exercise. And that really helps our executives figure out what is my end-to- end picture looks like? What are my bottlenecks? What are my low hanging fruit? And probably one of the most important outputs of the exercise is what are my metrics? What is it that I can improve through using DevOps?

    Alan Shimel:                Yet. And Mustafa, of course I’ve seen you talk about this and you have developed a whole workshop around this value stream method.

    Mustafa Kapadia:       That’s correct.

    Alan Shimel:                And recently we were out at our DevOps Connect CD Summit event in Southern California and you had an opportunity to actually do this live, right, on a white board. No slides or anything.

    Mustafa Kapadia:       That is correct.

    Alan Shimel:                But why don’t you kind of walk our audience, if you will, and again we don’t have a lot of time but let’s walk them through a little bit about what you do in this kind of workshop.

    Mustafa Kapadia:       Yeah. Well, first of all, Alan, thank you for inviting me to the Summit. It was actually great to catch up with you… It was great to be there and present… But to answer your question, what we start off with in a value stream mapping exercise is just ask the audience or ask our clients How do you do thing folks from point A to point B. Who does it? How many people does it take to do? How do you set up a DevOps environment? What kind of tools do you use? How long does it take? What processes do you use? And depending on how much time we have with our clients, we can go very deep, in the Summit itself, we were very high level since we only had an hour and a half. And what that does is A) Even for the clients, it gives them a complete point of view about how you actually get an idea to market from the time the development team starts coding to the time that it actually reaches the end customer or as we say, moves into production? And it in many ways it is simply a conversation. It’s a facilitated conversation with a goal in mind but it is a conversation about how do you do things and where are your problem areas? And in many cases, for a client, this might be one of the first times that development and operations are actually sitting down in the same room and talking to each other. In many cases, operations is a separate environment and then the development team has to go in and do their own stuff to get the environments ready, to be ready for the developers to start using it. So value stream mapping exercises in many ways is the first time that they are collaborating on the big picture. And that’s what DevOps is all about. It’s about getting the dev and the ops teams together.

    Alan Shimel:                Yep. And Mustafa, typically when you are doing these in the field with real live enterprise customers you’re dealing with, what’s the feedback from the executives that you are working with?

    Mustafa Kapadia:       The two that come to mind is that number one, most executives are amazed at how long it actually takes them to develop code and actually bring it out to the market. It is not uncommon in a large enterprise for the entire lifecycle from the time an idea has been generated and approved to the time that it actually meets the customer or the end-user. It could be as much as 300 days. We were at a bank in which it took them almost 390 days to get some type of a release out to the client. So number one, it’s first just – they are surprised at how long it takes. Number two is, the honest dialogue that they can generate, not just with us but more importantly within their own team, is probably the most valuable key of that exercise.

    Alan Shimel:                Agreed. And Mustafa, I know some people are listening and they’re saying oh great; here’s an IBM services guy who’s going to be pushing us to buy IBM product…But the fact is or maybe it’s not the fact, it’s my understanding the fact is that that’s not the case in this exercise in these kinds of engagements that you work in, correct?

    Mustafa Kapadia:       Yeah, definitely not. In fact, a lot of I would say close to 99% of the time, maybe even 100% of the time, we rarely talk about IBM tools or any system tools for that matter. It doesn’t matter if it’s open source, or if it’s proprietary. That exercise is more about understanding the…process and the…pain points. So it has nothing to do with IBM or it sets of tools but more about clients understanding the end to end workflow.

    Alan Shimel:                Yep. And so Mustafa, let me throw something else at you. I’m going to throw the big C word out there, culture. Because that’s the other thing we hear from execs, correct? How do I change my culture? So everyone talks about this DevOps thing being a cultural sort of leadership thing. How do I do that? What do you do – do you do anything around the culture as part of this exercise?

     

    Mustafa Kapadia:       We do, we do. So cultural behavioral changes, that’s what we call it here, is a big part of this exercise. Part of it is that I’ve mentioned earlier is people sitting down and talking and sitting down at a table and talking about the entire workflow. But the larger question is a lot of the cultural change happens is actually go through the transformation journey together. So instead of just the operations team doing their fees and development thing in doing their feeds, when we start putting solutions together for our clients, we bring both these teams together and sell the solution together that both of them can support. And that is where the cultural and behavior change starts happening. Not just what they’re doing but how they are doing it, how they are communicating. A lot of the change happens by doing as opposed to just somebody coming in and say well, you need to change or organize your structure this way or you need to put a new metrics and so on and so forth. Our customers that succeed in DevOps do it primarily by actually doing some of the stuff together as opposed to doing organizational realignment.

    Alan Shimel:                Makes sense. So Mustafa, my next question to you is sort of the classic consultant’s dilemma, right, and that you come in, you identify the pain points. You identify new processes, new ways of doing things. You advise the client. You may even stay there on a short engagement timeframe to hopefully see these things starting take root. But what happens after the consultant leaves? What’s the success rate of this stuff really taking hold?

    Mustafa Kapadia:       To be honest with you, a lot of the bread-and-butter at IBM in our service lines is actually what happens after the consult engagement. What we sit down with the client and actually help them execute the roadmap that we had developed together from A) building the platform to integrating disparate capabilities into the platform, supporting that platform and even training. In fact, one of the things that we are rolling out right now with some of our clients is actually training our customers, our clients, on how to start using some of these DevOps platforms tools and so on and so forth. So our longtail…believe it or not, is actually sitting down with the customer and helping them through the entire journey as opposed to just coming down and putting things down on PowerPoint. In fact, the consultant piece is a very small part of that business. Our real business is about hand-holding them through the journey.

    Alan Shimel:                Great. Makes sense. So Mustafa, we are coming close to our time limit but I have another question or two for you. I was on a webinar this afternoon with Gene Kim and lady named Shannon Leitz from Intuit. And it was on security DevOps. But we got a couple questions from the audience in there. It’s a reoccurring theme here at devopsy.kinsta.cloud. One gentleman wanted to know this is all fine and dandy for tech firms. But do you have any examples….chemical or energy-related firms that were doing DevOps? Of course, another person wanted to know did you have any white papers on financial related firms doing DevOps? And you and I were both at the DevOps enterprise. We saw all kinds of companies from presenting there…

    Mustafa Kapadia:       Yep, definitely.

    Alan Shimel:                But your own personal experience, Mustafa, is there a particular vertical that is more suited to adopt this or less suited to adopt these kinds of ways?

    Mustafa Kapadia:       Yeah… So the general rule of thumb is that anytime you have a system of engagement application, that is the best place for us or for you guys to start DevOps. That is where you get the biggest bang for the buck. And that is where this whole idea of being agile … to market makes a difference. Now, with that being said, there’s actually three key industries taking up or adopting DevOps faster than all the other sectors that we have within IBM. First is financial services. Second is retail and third is believe it or not, actually software development companies. So it’s these fast-paced companies that are trying to get some more features and product out to their customers and clients. We see those three sectors taking up DevOps or adopting DevOps much faster than the rest of the industry. But that doesn’t mean that the other parts of the industry are not doing it. In fact, we are right now working with healthcare clients. We’re also actually working with an energy client who is trying to figure out how to bring DevOps into their mix.

    Alan Shimel:                Excellent. The next question is I’m actually working on a report that I want to put out next month on my prediction for 2016 that this is the year of the great divide where we are really going to see the gulf widen between companies who are adopting DevOps patterns and not just DevOps but the Cloud, hybrid Cloud, big data, IOT, the open enterprise if you will versus companies who are sort of digging their heels in the sand… Do you think this is the year we see….real gulf starts opening up or old-style companies skate by still?

    Mustafa Kapadia:       Yeah, I unfortunately think it’s more of the latter than the former. I think some companies, especially in traditional industries, are still going to stick to their guns, so to speak, and think DevOps is just a fad. But then the industries that I’ve just talked about, I think those is where the gulf between the doers and the not doers is going to start widening especially when you get a retailer who can now push out enhancements to their e-commerce website, we’ll definitely see them picking up the benefits of DevOps as opposed to somebody else who just chooses not to do it. I think that’s where it’s going to happen this year or I should say next year. And then if that does happen it, 2017 becomes a really interesting year because that’s when everybody starts to catch up. A lot of our customers are trying to get on the ground in 2016 so they are not in bad shape in 2017.

    Alan Shimel:                I think otherwise it could be fatal to their business. Mustafa, one last question and I usually ask all my guests on the podcast near the end and we’ll let you go. For our leaders out there who are wanting to maybe dive deeper into DevOps or just want to lead the transformation at their organization, if you had to pick one book for them to read, what book would it be?

    Mustafa Kapadia:       Oh, that is a very tough question. There is actually a book called Competing Against Time. It was published in I believe 1975 by a managing partner at Bing. …While it doesn’t talk about software development or application lifecycle, it really talks about how you can start thinking about time as the element of competition. And it’s what other companies are doing or perhaps have done in the past to actually help you actually use time to kind of gain not just an advantage but almost an inhuman advantage over companies, right? So that one comes to mind…Dell comes in mind. This idea about DevOps is not a new idea. It’s new to IT. But the idea of us drinking time has been around for quite some time. And I really like that book because it kind of, a lot of the principles that we talk about now in software development can be found in that book in examples outside of IT and in other industries.

    Alan Shimel:                Fantastic. That’s a new one to our book list and great suggestion. And it just goes to show what’s old is new and some things never go out of style, right? Anyway…

    Mustafa Kapadia:       That is correct.

    Alan Shimel:                Mustafa, we are over our time, I apologize. It’s hard to do these things in 12 minutes. I apologize. But thank you so much for appearing on this episode of DevOps Chats. And thank you so much for helping us whether it be at CD Summit or DevOps Enterprise Summit or at so many locations we run into each other. Not to mention writing press here at devopsy.kinsta.cloud.

    Mustafa Kapadia:       Thank you. And Alan, you’ve always been generous and I appreciate that. I also, if I have a few seconds to make another offer to all of your audience. Three things, actually. So this value stream mapping exercise that we’re talking about in many cases, will actually do it for free for some of our clients so you guys can reach out to me. And Alan, you have my card…

    Alan Shimel:                Yes, we’ll put it in there.

    Mustafa Kapadia:       So that’s number one. Second is, we have this IBM conference call, Interconnect, which is in Las Vegas. It’s on 2/21-2/25. It’s a great way to learn about DevOps.

    Alan Shimel:                I will be there, Mustafa.

    Mustafa Kapadia:       And last year we had 300 or so DevOps sessions. Perfect, perfect.

    Alan Shimel:                Yes.

    Mustafa Kapadia:       And the last thing, if I’m not running out of time, is if you guys can’t wait until Interconnect, I actually publish a monthly newsletter and if you can just email me, I’ll be more than happy to put that on as well.

    Alan Shimel:                What’s the email, Mustafa?

    Mustafa Kapadia:       Email is M.A.Kapadia@US.IBM.com.

    Alan Shimel:                Fantastic. Mustafa Kapadia, IBM. Thank you so much for being today’s guest on DevOps Chats.

    Mustafa Kapadia:       Okay, thank you very much, Alan. I appreciate it.

  • Companies Failing to Innovate or Evolve Legacy IT Infrastructure

    Biggest hurdles to innovation include lack of skills, no long term planning, poor funding and collaboration, survey finds.

    We’ve been writing a lot about what it takes for IT organizations to transform their business-technology systems to drive agility and innovation. Interestingly, according to a recent study conducted by the Business Performance Innovation (BPI) Network, most IT professionals think their businesses are failing, or pretty close to failing, when it comes to driving forward with IT transformational efforts.

    The report, Bringing Dexterity to IT Complexity: What’s Helping or Hindering IT Tech Professionals, found that those on the front-lines making their organizations networks, cloud deployments, data centers, and applications work believe that a serious lack of planning, skills gap, lack of budget, and poor communications and collaboration with business managers remain serious obstacles in their organizations to innovation and the IT transformation they need. This is despite most organizations, CEOs, CIOs, repeatedly citing the importance of technology in their efforts to innovate and compete.

    The survey is based on responses from 200 IT workers in North and Latin America (38%), Europe (23%), the Middle East/Africa (20%) and Asia/Australia (18%). The survey was sponsored by IT infrastructure and services provider Dimension Data. However, IT workers say their organizations’ biggest weaknesses are long-term planning, application development, data analytics and software engineering.

    The survey found that roughly 80 percent of IT respondents spend more than 50 percent of their time maintaining and troubleshooting older IT systems. Important findings from the survey include more than 80 percent of frontline IT workers say they spend over 50 percent of their time troubleshooting and maintaining legacy systems instead of driving innovation. And 17 percent say they spend 90 percent of their time on routine maintenance tasks.

    “Instead of ushering their companies into a new age of highly agile innovation, IT workers are hindered by a growing list of maintenance tasks, staff cutbacks and aging infrastructure. All the while, growing tension between IT and their business colleagues has proven a roadblock to the type of communication that fosters collaboration, innovation and true IT transformation. Some 43 percent identified serious communication issues,” the report stated.

    The survey’s major findings reveal:

    • Only 35 percent of respondents rate their company’s ability to adapt to new transformative technologies as good or very good.
    • Over 70 percent of IT workers report they have not even begun or are just “getting started” on the road to IT transformation.
    • Just 15 percent have a clear and detailed plan for transformation. Over 80 percent say their plans provide only general direction, need updating or don’t exist at all.
    • Almost 45 percent said improved collaboration between IT groups and business leaders is critically needed. Only 18 percent said there are active cross-functional teams in their companies today.  Another 14 percent said they rarely speak with business managers or speak only out of necessity.

    The survey also found that respondents believed (52 percent) the business managers who own a new initiative or application want too long too bring IT or developers into the process, and 48 percent say that business managers fail to properly fund their initiatives. The survey indicated that roughly half of respondents believe business managers think poorly of the IT team.

    Also interestingly, about one-third of respondents reported that their organizations have yet to move to cloud computing. Only 13 percent think they will move all of their systems to the cloud, while 37 percent foresee most of their systems moving to cloud. While 34 percent use the cloud for data storage and 45 percent for software-as-a-service applications.

    Finally, 11 percent of respondents said the cloud “doesn’t make sense” for their business.

  • To Be Continuous w/Special Guest Kris Gale: Effective Team Structure for Continuous Delivery

    To Be Continuous w/Special Guest Kris Gale: Effective Team Structure for Continuous Delivery

    In this segment of To Be Continuous, Edith Harbaugh and Paul Biggar talk with Kris Gale about effective team structure for continuous delivery. This podcast is brought to you by Heavybit, a 9-month program for developer startups.

    Screen Shot 2015-11-13 at 9.33.45 AMKris is co-founder and CTO of Clover Health, a unique health insurance plan focused on driving down costs and producing improved health outcomes. Formerly, Kris was VP of Engineering at Yammer.

     

    Edith Harbaugh, CEO LaunchDarklyEdith is CEO and co-founder of LaunchDarkly, a continuous delivery tool of “feature flags as a service.” LaunchDarkly powers software teams to quickly launch, measure and control their features.

     

    Paul Biggar, CEO CircleCIPaul is founder of CircleCI, a continuous integration and deployment platform that automates development workflows and IT operations, allowing developers to ship quality software significantly faster.

     

    [soundcloud url=”https://api.soundcloud.com/tracks/232834454?secret_token=s-3aRuL” params=”auto_play=false&hide_related=false&show_comments=true&show_user=true&show_reposts=false&visual=false” width=”100%” height=”166″ iframe=”true” /]

    Edith: So, Kris, what do you like best about continuous delivery?

    Kris: So, I like continuous delivery, because I think it’s sort of the first step of building a learning organization. It’s sort of a fundamental capability that a team needs to be able to learn collectively about what it’s doing in the world. The first step is being able to sort of ship increments of value continuously.

    The second, I think, is to be able to measure the result of any incremental change you’ve made, so you can back out of a bad path that you’re on, or sort of refine what you’re doing and know that quantitatively.

    The next step then, is to move from a sort of historical corporate planning, so this is a our six-month milestone, our two-year roadmap, our marketing commitments for Q3 of next year, into sort of an assumption that if we are shipping continuously and learning continuously because we’re measuring what we’re doing, whether it’s quantitative or qualitative measurements.

    The next step is really being able to assume that in your planning, and know you’re going to have more information in the future than you had in the past. So your plans that you made six months ago are necessarily lacking information than plans you would make today would have, so sort of institutionalize that.

    And then kind of the last part, and this is all kind of enabled by continuous delivery, the last part is building organizational fluidity.

    So as an organization, whether it’s your project planning structure, or your accountability to your work flows, are fluid, so if you learn something new, you’re not locked into, oh we have a sixth person, I don’t know, sign-up flow team, and we just discovered that we have no levers for moving engagement right now in the sign-up flows, so we’re committed to that and we’ve got this implicit prioritization that’s built into our org chart. So, to have organizational fluidity where you’re adapting the organization to what you’re learning continuously.

    Edith: Oh. You know that’s fascinating. Paul and I have talked a lot about, I think, more the mechanics of continuous delivery. We put it as kind of the last step to software org, when you’re really talking about how that changes entire organization beyond software. So, this would be a great time for you to introduce yourself, and tell us more about you.

    Kris: Yeah, so I’m Kris Gale. Most recently, I was the VP of Engineering at Yammer. I heard you talking about Yammer in a previous episode. I’d love to dig into any of that, if you’ve got questions. Currently, though, I’m the co-founder of a company called Clover Health. So, what we’re actually doing is offering health insurance for seniors, with the idea that we can fill gaps in care, and actually prevent hospitalizations.

    We’re not trying to be people’s doctors, but we’re trying to look across their consumption of health care and say, “Oh, here’s an opportunity ‘to inflect the probability with which ‘this population of people will be admitted to the hospital.” So, for example, making sure they get treatments regularly, get follow-up visits with specialists, that particular bio-markers don’t deviate outside of a specific range. And all this stuff is really interesting to me, because the health care industry as a whole doesn’t change what it does continuously.

    We’re sort of locked into what people learned in medical school, or what people learned on their first day on the job at, say a big health insurance company, or something like that. But, to be able to power workflow with software, you’re able to continuously iterate and continuously refine and optimize the intervention protocols that are leading to these prevented diseases.

    Edith: Yeah, I mean, I heard that you were pretty good at data loops, and that this is just basically using data loops for good, I think is how you say it.

    Kris: See, the way we were talking about data loops, we were actually talking a little bit before we walked up here, is this idea that there’s something you intend to do. There’s data that you collect in doing it. There’s your objective assessment of that data to determine whether you’ve added or removed value or improved something.

    And then closing the feedback loop, to get back now to actually modifying what you’re doing, and form find out new data. So, that’s sort of the data feedback loop, is from doing something to measuring it and deciding to do something differently the next time.

    The tighter you can close that feedback loop, the more opportunities you have to optimize in a short amount of time.

    Paul: So, it’s kind of what you might call the shipping loop, if you implicitly believe that data is a key part of shipping.

    Kris: Yeah, yeah, and I would say that I think I do.

    Edith: No arguments here.

    Paul: Well, I think it is interesting, because I think that a lot of people don’t actually have measurements as part of their feedback loop, and especially, I think this especially happens in a small organization, where you have a start-up that sort of comes out of a founder’s vision, or something like that.

    And so, one of the questions that I’m very interested about is, you were doing a big thing, with lots and lots of people. And now you’re doing a very small thing with, I presume, a small handful of people. How much of what you’ve learned still applies at that very small scale?

    Kris: 

    So, yeah, a lot of the project workflow strategy that we came up at Yammer was really about how do you maintain that agility, that velocity of value delivery, and ability to react to new information, and not be locked into, “Well, this is just the way we do it,” in the face of new information. At scale.

    So, Yammer’s whole process was really about, how do you take these advantages we had, when there were like four or five of us in the really early days, and not have that big bureaucratic company, “Oh, we know we should be doing something better, “but we’re not,” because of momentum, inertia, bureaucracy, all these things. Like, how to break that. So, what’s cool about starting over with a much smaller team is, we’re just there again. We’re back at that five person size.

    Edith: You’re a lot bigger than five people.

    Kris: We are now, yeah. So, like nine months ago, we were. We’re like 65 people now, already. It keeps growing really, really fast. It’s been really helpful to me to have been through the process of scaling a software engineering team and seeing what that looks like. So, it’s like, “Oh, I’ve seen this problem before, “not worried about this.”

    Paul: So, when you started, did you immediately set out organizational goals, and mission, and values, and that sort of thing that would help the company scale it?

    Kris: Yeah, no, that’s a great question. I’m obviously a really big believer in the way we approached this problem space at Yammer, but I didn’t want anything to be dogmatic. I didn’t want anything to be–

    Paul: You wanted it to grow organically.

    Kris: Yeah, I wanted it to grow organically, to a certain point, but there have definitely been times where I stepped in and I said, “Nope, I’m buying a physical board “to track our projects, “because, just the way we’ve been doing this “with sticky notes, “I know that it needs this other dimension “of information capture. “I know that we’re suffering because it’s not there.

    “So, I’m gonna actually pull the boss card and do this.” There have only been like three or four times I’ve done that in the last year, but it’s things where, like– Okay, I’ve seen where this goes off the rails, if we don’t address this right now.

    Paul: And is that a result of knowing, sort of directionally, how the company should be doing things, or setting things up in some way that you didn’t get, that you didn’t end up in these bad places?

    Or was it all sort of retroactive, and you know, a couple places where you pulled the boss card?

    Kris: Yeah, it was mostly, like, observing patterns, saying, “Okay, we made this mistake three or four times, “and I’m noticing that our process or our approach here “is divergent from a known good approach “that I’m aware of.

    “So, let’s at least–” I still wanna give the team full empowerment to iterate and own the process themselves, but let’s at least just pull the boss card, get it back on the rails, and then say, “Okay, let’s see how this works.” Just give everybody a chance to work in a way that I know to be okay for a few iterations, and then give them the keys again, and say, “Okay, take this where you want.”

    Edith: Also, Kris, what I’m dying to know now is, what are those three or four key things where you gotta play that card?

    Kris: Yeah, so, one is single project focus. Really, really important to me for software engineering teams. So, what I mean by that is, if you are on a project, that is your only accountability. You are not being split between three deliverables.

    The other is that everybody work in cross-functional teams. So, that means not giving, for example, I might tell you, “Build out the back end for this feature, and I’ll do the front end.” So, in order for us to do that, we would have to agree to the abstractions ahead of time.

    And again, I’m pretty opposed to planning, and locking in planning, because the information that we have now, when we’re trying to lock in those abstractions, is going to necessarily be incomplete.

    Edith: I love that quote, because it’s so true. I think you put it more, it’s like you always know more in the future. It seems so obvious.

    Kris: Yeah, I was actually– So, we had Parker from Pivotal Labs over at the office yesterday, and he said that there was this saying they had a Pivotal, that I really, really liked. He said somebody there would always say, and I wish I could remember who it was, would always say,

    “You will always make better decisions with more information, and you will always have more information in the future.”

    This is so much more concise than any way I’ve ever said that. But I think it exactly captures it.

    Edith:

    But, on the other hand, my old boss, Gregg Brockway the founder of TripIt, he always said, “A good enough plan today is far superior to a perfect plan tomorrow.”

    Kris: Absolutely.

    Edith: He’s like, “You just gotta start moving.”

    Kris: Yeah, but I think the key is not locking yourself into that “good enough” plan. To allow yourself the mutability of changing that plan over time, so you’re not constrained by that.

    Edith: Yeah, but that was TripIt. I mean, I think he’d seen so many, because he came out of the travel industry, where people just got paralyzed. Like completely paralyzed. “Oh, we need to plan for five years, “and what business travel will be like then.” It’s like, well, nobody knows.

    Paul: I think the kind of key point to that is that in order to get that information, you have to get moving today with whatever information you have available. Otherwise, you’re just not gonna have that future information. You’re gonna be in the same place.

    Edith: Well, look, sometimes, though, it’s painful. Sometimes you move backwards, then. Like, you don’t always move forward. Sometimes you start moving, and when you’re looking back, you’re like, “Actually we took, like, three steps back “before we started moving forward.”

    Kris: It can definitely happen.

    So to complete that thought, when we assign teams, we would always assign a cross-functional team with a business objective. So, it would never be I give you a back-end task, and I take the front-end task. It would be collectively, let’s accomplish this business goal.

    So hopefully, we’re iterating day by day on the abstractions. So, we are collectively accountable to one another, and to this business goal we’re trying to deliver. Not onto some specific set of tasks that we broke off when we first decided to assign out the work.

    So, that’s one of the other ones, is always cross-functional teams. Always single project focus within those.

    Paul: So, there’s an interesting thing that you’re talking about there. It’s not just cross-functional teams, but it’s also that those cross-functional teams get put together for a specific project, is that right?

    Kris: That’s absolutely right.

    Paul: So, are those teams teams that will have worked together in the past? Is there explicitly trying to make sure that the people know how to work together?

    Kris: Yeah, so this is one of my other core principles that I am pretty, pretty set on, which is rotation, is this idea that cross-functional teams are rotational and ephemeral. So, that would mean that maybe the three of us come together to ship a feature.

    We’re all within the same organization, but when we’re done shipping that feature, we’re gonna break up.

    You might be the back-end person that goes onto another iteration of this feature area, or maybe, you know, the two of us work on some other feature. Maybe it’s three completely different people. But constantly rotating people around, I think is really important in an organization.

    I have totally heard the arguments about, you know, you can build high trust teams if they’re stable and stay together. But I’m trying to optimize for trust across the entire organization. So, across Yammer, we had 220 people in engineering. They would all rotate through these two to 10-person cross-functional teams together.

    Which meant that you, basically within three to six months, would work with a pretty significant portion of those 220 people, and would start to build trust across the larger organization. Whereas had we just torn off four people and said, “You’re a team,” they would– And I’ve seen this throughout my career in engineering, where it’s like, “We do everything right, and that team has no idea what they’re doing.”

    Edith: It’s their API’s are bad.

    Kris: Yeah, yeah they use this weird language, or this approach, or we use this style guide, or whatever. So, it sort of forced that rotation, so that we’re all sharing best practices among one another and building, maybe lower trust, maybe not getting to that very, very, very highest level of trust among a group of four people, but across the entire organization, getting to like 40% or 60% of what’s possible versus 0% if you don’t ever work with those people.

    Paul: So, interested in structurally how that ends up, because one of the things you got when you split people up by team is you end up with a sort of microservices architecture.

    And this team works on this repo, or this project, or whatever works on this service or this API. And when you have those teams that are forming and splitting up and they’re ephemeral, and it’s only a small period of time, architecturally, what does that do to your application or your architecture, you know, across your entire product?

    Kris: Yeah, no, totally. It was actually very intentional that we ended up with that kind of architecture for working this way. For two years, we had a big monolithic Ruby on Rails code base, and for two years we said, “This is a big problem. We should break this up.”

    And everyone agreed, and everybody was on board with breaking it up, and two years later, we had never done it, because we continued to work in such a way that supported that sort of architecture.

    So, the key for us was to say, well one of, the– So, something to dig into here a little bit, is these cross-functional teams are made up of representatives of what we call functional teams. So, front-end engineering might be one.

    Paul: Right, right.

    Kris: We had one called Core Services, which I actually owned the service-oriented architecture that you’re describing. Or there’s little micro-services that collectively made up our service-oriented architecture.

    Paul: And this is sort of a matrix style, where you’re a member of the team, but you’re also a member of the back-end team, or you’re a member of the front-end, or the core services, or whatever.

    Kris: Yeah, so I might be a member of core services. My manager is one of the core services managers. But all the work I do is going to be within the context of the cross-functional team, with the front-end engineer, maybe a client’s engineer, whoever’s necessary to get end-to-end with a value proposition.

    And then, I’m always going to be a core services member, when I go into these cross-functional things, but it’s the fact that all the members belong to functional teams that makes that team cross-functional.

    For more on Continuous Delivery and to find out about new episodes you can follow the show on Twitter at @continuouscast.

  • DevOps Chat: Sunil Rajasekar, CTO of Lithium

    DevOps Chat: Sunil Rajasekar, CTO of Lithium

    hero-sunilContinuing our DevOps Chats, Leadership Series I recently sat down with Sunil Rajasekar, CTO of Lithium.

    As Chief Technology Officer, Sunil oversees core product, development and delivery of Lithium’s enterprise platform. Sunil is a seasoned technology executive who brings more than 15 successful years of enterprise, small business and consumer software experience. Prior to joining Lithium, Sunil served as Vice President of Engineering, Operations and Program Management at Intuit Financial Services and held a variety of senior roles in the Intuit Small Business and Central Technology groups. His passion is building innovative and successful web and mobile offerings that companies and end users love. Previously, Sunil worked at Oracle, Cisco and several startups.Sunil holds a MBA from the University of Toledo.

    Sunil and I had a nice chat about what it means to lead transformation at at organizations today using the many tools and options available. Regardless of tools though, Sunil emphasized what leaders have to do to enable transformation. It was a great chat that I hope you enjoy!

    [soundcloud url=”https://api.soundcloud.com/tracks/230736526″ params=”color=ff5500&auto_play=false&hide_related=false&show_comments=true&show_user=true&show_reposts=false” width=”100%” height=”166″ iframe=”true” /]
    Alan Shimel:                Hi, Alan Shimel at devopsy.kinsta.cloud here for another Dev Ops Chat in the Leadership Suite. Today’s guest is Sunil Rajasekar, CTO of Lithium, Lithium Technologies who are helping people with their social customer service software and social software in general. Sunil, welcome to Dev Ops Chats.

    Sunil:                           Thank you, Alan. Happy to be here.

    Alan Shimel:                So Sunil, for those of our listeners who may not be familiar with Lithium, can you give us just sort of a quick background on what it is Lithium does?

    Sunil Rajasekar:          Sure. So we’re in the business of helping companies engage with their customers in new patterns and what they’re dealing with now, right? Where consumers have all the power, they have access to all the data that they need and companies don’t own their brand anymore. The consumers are the ones that determine the brand. So we help companies deal with this environment in this reality that they are dealing with by helping them engage with their customers at scale through social channels and also facilitate conversations between customers.

    Alan Shimel:                Sure. And Sunil, I thought this was such a great topic for our Leadership Suite because I’m sure many of our listeners are grappling with this issue right now. There’s just a new way of doing things including a new way of engaging with customers. A new way of presenting your brand in the marketplace. And so much of it is wrapped around the social media and social communications that we see today. And companies who aren’t grasping this are quickly becoming dinosaurs. People tend to think of it’s the Unicorns, the Googles, the Facebook, the Twitters who are getting this or the startups. But that’s not really who your customer base is, is it Sunil? You guys work with some large customers?

    Sunil Rajasekar:          We do, yes. So we work with a wide variety of customers. We work with companies that have been a really long time so AT&T, Telstra, Cisco, HP; these are all customers of ours and they’ve seen a lot of success _____ [inaudible]. And we do work with a lot of the new companies that have been born in the “digital age” as well. So we work with companies like FitBit. We actually do work with Google, they are huge customer of ours as well. So we actually have a variety of customers across the spectrum, those who are new who get this new reality and those who get this reality but are adapting their business to adjust to it as well.

    Alan Shimel:                Sunil, I’m sure we have some people out in our audience today who are leaders in their respective companies and they are faced with an evolve or die reality. What, as a CTO, as someone who founded companies and so forth and you are background, what would your advice be to them?

    Sunil Rajasekar:          I would say three things, Alan. So one is make sure you have a diverse network. And so and the reason I bring that up first is we were talking about this earlier as well. Things are changing so fast in the tech world right now, it’s hard to keep pace and it’s hard to know whether it’s a passing trend and what’s here to stay. And it’s hard to digest all this data and then figure out the _____ [inaudible]. And if you’re going to try to do it by yourself, I would say it’s going to be next to impossible. And if you stick to just your countered network, right, the people you work with day in and day out, you’re probably getting the same level of information and you do end up with a group think type of situation. So making sure that making the time to engage with people in other industries, similar roles who are probably trying to figure out the path forward just like yourself. I think that’s the way to do it. You want to make sure you’re plugging into these other networks, you’re sharing your learnings and learning from others as well. So this is something that I’ve made a conscious effort to do in the past couple years and it’s been invaluable so I would say that’s one.

    In the second thing is, it does boil down to good old change management as well. Yes, there are some great trends that are out there and you should probably thinking about implementing it. But at the end of the day, you’ve got to know how to take this trend or new technology or new process and make it work for your organization. And that’s good old change management, right? So you need to know about your team. You need to know about the business needs and make sure that you can tailor whatever transformation you want to drive to the needs of your company. So what does boil down to change management?

    And then the third thing I would say is just resilience. And anybody who has made it up the ranks, they probably know this already but it’s a good reminder. Anytime you’re driving a large transformation, there are going to be challenges along the way. And you need to make sure that you are resilient and your team is resilient and the rest of your executive staff has bought into the transformation you are driving and they come here to support you and there are roadblocks as well. So as those are the three things. Make sure you have a diverse network, focus on change management and make sure you don’t forget about being resilient.

    Alan Shimel:                Sure. Sunil, I have questions I’d like to follow up with you on two of those points you’ve made. First of all, in terms of a diverse network which as you said you have pursued over the last couple years, what advice can you give our listeners on what kind of group should they be looking for? Where do they find them? How do you make that a reality?

    Sunil Rajasekar:          Sure. So there’s three ways I’m going to do it and there’s a plan to do it, I would say, here as well. One is of course your personal network. There are people you’ve worked with in the past who you admire, probably have gone on to do other things and have other experiences. So making sure that you really cultivate your network and you reach out to people and check in and if you have a situation you’re dealing with, reach out and ask for advice. Or if you’re contemplating a big technology decision or a business decision, reach out to these folks who are in your network and get the advice.

    Another thing that we’ve done is we’ve set up a technology advisory board so we have course have the board for the company. We’ve got a special technology advisory board that we’ve set up as well. And this has people from companies like Google, LinkedIn, Netflix. So some very, very strong background for all these folks and we’ve use this technology advisory board extensively for some key decisions that we’ve made. So that’s been invaluable.

    And then the third thing I would say is plug into meet ups that are going on. Chances are whichever city you’re in, there are a ton of tech meet ups that are going on and if there’s not that many, start one and get people from other companies to come and share their learnings on different topics. So we have a _____ [inaudible] ops meet up that we set up and we meet pretty regularly in our office and it started off as a small thing and now we have members who participate from again, the Googles of the world, the Air B&Bs of the world and we have over 1000 members. And that’s been great as well.

    Alan Shimel:                Yeah, no, that’s fantastic. Sunil, jumping to one of the other points you made which was about change management, so something else – just my opinions, observations and advice is sometimes it’s about embracing change. Too many people look at sort of the new technologies, the new ways of communicating, the new ways of doing things as oh my goodness, I’ve got to learn something new. Or this is changing what I do and no one likes to change what they are used too. I get all that. But sometimes embracing change is what makes the difference. Right? Embracing this change, looking at it as how can I make it a positive rather than just defending my turf if you well? Way too often people are just defending their turf, it seems, instead of embracing the change and running with it. And that would be my advice as well is don’t think of these changes as yet another thing you have to do. Think of them as ways that are going to make your life easier, make you more successful, make your organization and those around you more successful. So I –

    Alan Shimel:                That’s part of it.

    Sunil Rajasekar:          That is so true, Alan. There was a time when I think leaders were looked up to for stability and making sure that things stayed stable. But I think that paradigm has changed. In this time and age, the leader is looked at primarily for their ability to predict change and guide the organization on the path that they can adapt to this change and be successful in the future as well. So as a leader, that is one of our key responsibilities, looking at what’s coming around the corner and making sure that you are guiding the organization in the right direction. So it’s changed in my opinion.

    Alan Shimel:                Absolutely. Well, Sunil, the problem with changes sometimes it moves too fast and so does the time we have for our web chats unfortunately. We are well over our 10 minute kind of target so were going to have to wrap it up. But for people who want to find out more about Lithium and kind of how you guys can help, where can they find you on the web?

    Sunil Rajasekar:          Oh, it’s easy; www.lithium.com. And from there, you can connect to a lot of good information and hopefully you know me as well; if you have follow-up questions or comments.

    Alan Shimel:                Fantastic. Sunil Rajasekar, and I may have messed that up; I apologize. Thank you for appearing on this episode of Dev Ops Chats for the Leadership Suite. And continued success with Lithium.

    Sunil Rajasekar:          Thank you very much, Alan. Thanks for having me.