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 DevOps.com. 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 DevOps.com.
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.
