Tag: design thinking

  • IBM: DevOps Begins and Ends with Culture

    IBM: DevOps Begins and Ends with Culture

    Making the transition to DevOps requires as much a shift in cultural mindset as it does new platforms for building, deploying and managing applications. Between the two, however, it’s often the extent of the cultural challenges needed to be overcome that gets most underestimated.

    Michael Elder, a IBM Distinguished Engineer, said one of the most important DevOps philosophies that organizations must embrace is that No Code is Sacred (NCIS). NCIS fosters an experiment-driven culture that encourages self-editing and promotes a “don’t be afraid to fail” mentality. This approach allows teams to form questions, quickly implement means to gather data, try alternatives and incorporate real user behavior and feedback, he said.

    Manage the Scrum (Meeting)

    Other cultural issues that need to be addressed include leadership and how daily scrum meetings are managed.

    An overzealous build champion can wind up adding technologies to the continuous integration/continuous deployment (CI/CD) platform that don’t get adopted simply because the team as a group did not agree to their inclusion, said Elder.

    Daily scrum meetings don’t necessarily need to take a full hour. Non-critical, time-consuming status updates should be eliminated from the agenda. Daily scrum is more about problem-solving and looping the wider team in on critical decisions than talking about updates most team members can already read about for themselves, Elder noted. The goal of the meeting is not necessarily to inform team members of events. They should be expected to know what’s occurred. The real goal of the meeting is to decide what to do next.

    Mindsets Matter

    Elder said DevOps teams be cognizant of Conway’s Law, which says that organizations that design systems are constrained to produce designs that are copies of the communication structures of these organizations. If the goal is to develop a more agile application environment by employing microservices, Elder said, then the organization should create smaller, more independent teams to construct and manage them. However, that doesn’t mean every monolithic application needs to turned into a set of discrete microservices.

    Elder also advised organizations to embrace Design Thinking principles that encourage DevOps teams to focus on what needs to be achieved instead of enabling processes. The focus ultimately needs to be on the experience of the users who are being asked to employ an application, he said.

    The Tools Issue

    The biggest cultural challenge, however, still may be to tooling. Organizations trying to embrace DevOps clearly need new tools. But acquiring new tools won’t drive meaningful change. Too many organizations buy tools in the hopes that processes will eventually be transformed. The decision to acquire new tools needs to be closely connected with the transformation of processes, said Elder. That said some tools, such as an enterprise instance of Github, are core to encouraging the sharing and reviewing of code within a DevOps process, he added.

    Of course, Elder noted the most critical cultural change as far as tooling is concerned is keeping an open mind. Developers and IT operations teams tend to get overly attached to specific programming languages and platforms. A true DevOps culture, above all else, encourages experimentation.

    — Mike Vizard

  • DevOps Chat: Design Thinking w/ Sarah Plantenberg, IBM

    DevOps Chat: Design Thinking w/ Sarah Plantenberg, IBM

    We sit down with Sarah Plantenberg of IBM to talk design thinking. Sarah has been featured on several DevOpsTV videos around the Bluemix Garage. But she recently took on a new role at IBM around bringing design thinking to cloud customers. Sarah gives some great background on design thinking and why it can help you. Have a listen for yourself and we think you will find it informative.

    As usual, the streaming audio of our conversation is below with a transcript of our conversation below that. Enjoy!

    Alan Shimel: Hey, everyone. This is Alan Shimel, editor in chief, devopsy.kinsta.cloud, and we’re here for another DevOps Chat. Our guest on this episode of DevOps Chat is Sarah Plantenberg of IBM. Sarah, welcome to DevOps Chat.

    Sarah Plantenberg: Thank you. It’s great to be with you again.

    Shimel: Great to have you on again, Sarah. As we spent, oh, a good half-hour chatting before we went on air today, just catching up, and it’s always great to hear what’s going on in your world, and, obviously, one of the big things is you now have a new title at IBM. I’m not even gonna attempt to repeat it because I know I’d mess it up. I’ll leave it to you to tell our audience what exactly is your new title, Sarah?

    Plantenberg: My new title is I’m a design lead, the designer for the offering management section of our cloud technical engagement organization, so I’m a senior consultant specializing in applying design thinking to our business and helping our clients apply design thinking to their businesses.

    Shimel: Absolutely. And, though that may not roll off the tongue, it’s actually a mouthful, in terms of how important and how much value IBM puts on this whole concept of design thinking. But, Sarah, some people in our audience may not be familiar with design thinking. Design thinking 101 for people who don’t know what it is, how would you describe it to them?

    Plantenberg: Design thinking is about understanding and then innovating in a really human-centered way. We understand the person that we’re building something for. We understand their current situation. We understand the greatest pain points they have or if you’re bringing something new to the market, what’s the greatest opportunity for your business. And then we innovate around that by really—we have some really great techniques and tools to help people come to ideas that they would not have come to if they were just sitting down, doing what they call a typical “brainstorming session.”

    Shimel: Mm-hmm.

    Plantenberg: Once you have those ideas, you have to take those and put them back in a context of that human being’s world. How many great ideas have we all come across? The example I give is that I have 150 applications on my phone and I use, honestly, probably 15 of them.

    Shimel: Yeah.

    Plantenberg: There’s a bunch of great ideas. [Laughs] But they don’t reach me in the right way at the right time. So design thinking is really a set of—a framework and a set of tools around helping bring all of those things together, and, in IBM, we use it to bring the right technology to the right person, at the right time.

    Shimel: Excellent. And, of course, Sarah, design thinking, while IBM is probably one of the leading advocates in the world for the concept of design thinking, it’s not—this is not a new concept, per se. design thinking has been around for a while. Again, design thinking 101 for our audience—give me a little, if you can, a little of the history that you know of there

    Plantenberg: So, yes, design thinking’s been around for many years. What IBM has done with design thinking is said, “You know, we really need to apply this … ” We’ve done three things. The first one is to say, “We really need to apply this to the way that we work . We need to understand how we’re positioning ourself, how our clients understand us, what they need, and really target IBM’s capabilities towards those.” And, in some cases, even a couple steps ahead of the game, what we see coming in the market, which is really where the cognitive capabilities and the way that Ginni Rometty is steering our company—that’s where that comes from, is understanding that’s really the heart of design thinking.

    The second thing that IBM has done with design thinking is help us use it at scale and teach our enterprises to use it at scale. It’s easy to do design thinking in the small, but to do it when you have a development team of 250 or when you have a development team that’s in India, China and New York? That’s a different ballgame. So IBM design thinking, IBM’s part of that is at speed and at scale.

    And then the third thing that we’ve done with it is what we’ve done in Garage, which is really to take an incredibly lean and integrated approach—you don’t have to integrate design thinking into your development, but we do. And we do that in the Garage and it’s been amazing because it’s helped people use design thinking and kind of allow it to permeate everything that they do, so we put it at the beginning to understand the users and come up with innovative ideas and then design those and develop them for users towards business outcomes, but we also use it to say, “Okay, now you’ve adopted that cloud, Client A.” Let’s pretend. You know, just talk about a client without using their name. “You’ve adopted the cloud; you’ve brought in the IBM Bluemix Garage Method. You’re iterating really quickly. Your agility now means something to the user.” Before that, without including the user, agility more often has strong IT economic benefit, but it doesn’t always follow the business, and so design thinking really connects those two things together.

    And then, once you adopt the cloud, it ripples. The impact of that ripples, so you can’t run your operations organization in exactly the same way that you did before because you have different tools and you’re running at different speeds or maybe you’re running at just one speed that’s a lot faster, and you have somebody else managing your cloud, so what does it mean to do DevOps? So we created a design—we applied design thinking to how people reorganize their operations organization, and that’s been a great tool for us, both to learn, as IMBers, about how our clients need to shift and also to help our clients really take an outside-in approach, a human-centered approach, to how they’re gonna run an operations organization.

    And I think the last thing I would say about that is you can also use design thinking at the business process level as well, so it’s—I could go on and on with this answer [laughs], but I would say it’s—

    Shimel: Oh, it’s okay.

    Plantenberg: —it’s really stepping back and looking at the big picture and understanding, rather than following the thread. You know, it’s taking a holistic approach, rather than a linear one, to operations.

    Shimel: Yep. And, you know, Sarah, one of the things about the Garage and the Garage Method is really kind of taking this design thinking kind of way, if you will, and applying it, in real world, to scaling at enterprise levels and in a agile fashion, right? And by “agile,” we don’t necessarily mean Agile manifesto, Scrum, but agile in a larger sense. And, Sarah, that’s actually something that you and I spoke about off-mic earlier, and that is what I call, or Gartner actually calls, this concept of “agile IT,” but it’s also something, as you pointed out, that has been preached from the highest levels at IBM now for at least the last couple years, which is kind of agile everywhere or, you know, going agile, if you will. Why don’t you, if you can, share with our audience a little bit about what that means to you and what is IBM’s kinda vision on that?

    Plantenberg: You know, what that means to me, I can’t separate my life at IBM from my life as a designer, when I answer that question, ’cause I’m a designer because I think like one—I didn’t choose to be one; it kinda chose me.

    Shimel: Yeah.

    Plantenberg: And, from that standpoint, I think that the only reason to be agile is to be responsive. There’s no other reason you would need to be able to shift quickly, unless you’re in response to something. In my world, that’s a user, and a user can be my manager; the user can be my team, when I was managing a design team; they’re my client. They’re the people I interface with because I’m doing something for them. Whenever I’m doing something for someone that’s my user, I need to be agile. But, as we talked before, where agile meets non-agile, you end up with kind of a mess. It’s a little bit of a—there’s cognitive dissonance. People can’t work together because they’re working in two different ways—it’s a square peg in a round hole.

    And so the concept of agile in the large, “Let’s all operate in the same way and let’s all have that way be inclusive,” meaning we integrate together, we know how to pass information together. We are all aligned around the same priority, so, when you ask me for something and I say I can’t get it done because X, Y, Z, say, “Yeah, I understand that, actually. Let me make sure—let me put this in the right priority.” And are all responsive to changing business needs—I think that’s the most important thing. When the tides shift, we all see it together because we’re aligned together. We can then respond together. And it’s an incredible way of working.

    Jeff Smith had brought this into the CIO’s office, and it’s been incredible, the results. I wish I had them in front of me. The reduction in the amount of time spent getting things done, streamlining the organization, and I literally mean streamline the organization. It got smaller. It’s tighter. It’s faster. It’s more responsive. We’re now rolling that out under Sean Reilley who’s the vice president. Moved over to GBS, our global business services, and that’s now an offering for our clients.

    And it’s very, very interesting to our enterprise clients who are having to do more with less—I hate that phrase, but it’s true [chuckles]—and they’re having to be more responsive because business is changing so fast, the conversations people have now about the cloud are vastly different than they were only two years ago, so enterprises can’t be responsive not only to emerging technologies but to what their users need and how the markets are shifting. They’re struggling, you know? And so this is really a fantastic answer ’cause it’s not a thing that you buy; it’s a way of being and a way of thinking and a belief system.

    And I think the last thing I’ll say about it is it really allows the people on the ground to use their capabilities to help change the business. Instead of being told what to do, they’re leading with what they know, within a framework that gives them a voice and gives them a method of working together. It’s just—it’s fantastic work.

    Shimel: Excellent. Excellent. So, Sarah, as you mentioned at the top of the podcast, you recently moved into a new role, where, before, you kind of really weren’t in the Garage and around design thinking with the Garage and Garage Method. You’re now helping IBM’s sales, marketing team, customer engagement teams both understand design thinking internally there, as well as taking those lessons and bringing it to market, to IBM’s clients. Is that correct, fair to say?

    Plantenberg: Yes, it is.

    Shimel: And, in that role, Sarah—and I’m sure you’re very excited; it sounds like an exciting new role and we all like to embark on new opportunity—what does success look like for you there?

    Plantenberg: Oh, what a great question [laughs]. Success … I often success for myself as having created something that doesn’t need me ’cause if it needs me, than it’s more about me than it is about an outcome, so I will say that that’s the preface ’cause my answer might, without that, sound a little weird. Success to me is that I can stand back and watch our clients move from the beginning of their cloud journey to the point at which they have a hybrid cloud and they’re running in the cloud method and getting tremendous value out of it and hopefully even having spread agile methods throughout their business and adopt design thinking and that human-centered approach, and they’re doing beautifully with IBM’s tools integrated with anything else that they may have. I want it to be easy for our clients to find what they need on the cloud – about the cloud, on the cloud methods, tools, understanding the capabilities on Bluemix and growing their businesses with those and being independent and thriving on Bluemix.

    Shimel: Great. That is great. And so, I mean, the Bluemix and all of that is still there. One—I think we have time for maybe one more question we can go into, Sarah, and that is I wanted to talk to you about the concept of multi-clouds, right? We become more nuanced in our understanding of what it means to move to the cloud. We’re not all moving all of our infrastructure up to Amazon or Azure or one of these public infrastructures, the service providers. Cloud exists in many forms, right? We have public cloud; we have private cloud; we have hybrid cloud; we have lots of flavors, almost as many flavors of computer clouds as there are different types of clouds in the sky. What does this mean to you and in terms of your role?

    Plantenberg: It means understanding the people who are having to make the decisions. I think that your analogy of clouds in the sky is really—it’s a great one because you don’t—we can’t expect people to only want cirrus clouds, and here comes a cumulonimbus cloud. “No, I’m sorry. I can’t have that. It’s not gonna work for me; I only do cirrus.” That’s not how the world is. We have to be comfortable and understand people are making different decisions and connecting these different clouds togethers, and, often, I actually meet clients who have one area of their business using one cloud and then another area, using another cloud because the business folks had a small, little consultant group who’s working on Amazon and the IT organization decided to go with Bluemix, and now they have to figure out how to integrate these two.

    That’s the world we live in, and people make choices for reasons. If we understand, from a design standpoint, “Why do you have these multiple clouds? How are they working together? Where do you wanna take your business?” then we know how to fit these things together and knit them together and do automations. In fact, we have some automating tools that say, “Okay, we can run a dashboard that helps you see all of your clouds,” so IBM no longer believes in backing up the IBM truck and saying, “Us or the highway.” That doesn’t work; it’s not the kind of world we live in. And everything is integrated—it’s really the name of the game—and so, for me, it’s understanding how people got to where they are and understanding where they wanna go and being able to bring them there with what they have.

    Shimel: Got it. Got it. Well, Sarah, we’re about out of time, so we need to end things in a little bit, but I wanted to, first of all, thank you for appearing on this episode of DevOps Chat and, secondly, really wish you nothing but the best of luck with this new role and responsibilities. We’ll be checking in to see how things are. And then, of course, we’ll see you next year, hopefully, at IBM InterConnect, and that’ll give us maybe six months or eight months of retrospective to take a look at and we can see what it’s about.

    Plantenberg: Oh, I count on seeing you there, Alan. [Chuckles]

    Shimel: Okay. That’s—I guess we’ll call it a wrap on this episode of DevOps Chat. Sarah Plantenberg, IBM, design thinking. Thank you so much for being our guest on this episode of DevOps Chat. This is Alan Shimel for DevOps Chat and devopsy.kinsta.cloud, and we hope to see you soon on another DevOps Chat.

    — Alan Shimel

  • Jeff Sussna on Design Thinking and DevOps

    Jeff Sussna on Design Thinking and DevOps

    Jeff SussnaWhat is Design Thinking, and just as importantly to you – why does it matter to DevOps? For answers to that, we recently turned to Jeff Sussna, founder at Ingineering.IT. Sussna combines engineering expertise with a knack to bridge business, creative, and technical perspectives.

    Sussna’s focus is on the intersection of development, operations, design, and business. He has more than 20 years of IT experience, and has led high-performance teams across Dev, QA, and Ops. Sussna is also the author of the forthcoming O’Reilly Media book Designing Delivery: Rethinking IT In the Digital Service Economy. The book is expected this May.

     

    devopsy.kinsta.cloud: You’ve obviously placed considerable thought into design thinking, and it’s a subject that is coming up more and more within DevOps. I’m imagining a lot of people in IT, including developers and admins, wonder what design thinking means in the context of DevOps and IT.

    Sussna: I’d start by simply explaining what design thinking is. The basic idea is that if you look at designers across a wide range of industries, whether it be architects, graphic designers, or UX designers there’s a general way that they approach creating solutions. And what design thinking really does is try and capture that in a way that we can apply it to a lot of different things besides how annual reports or web pages can be designed.

    So how do people do it? The basic approach behind any kind of user-centered design is very simply to try and understand the user and understand them from their own perspective. Design thinking is really centered on empathy, empathizing with the user. The way it works is often by taking an ethnographic approach, which very simply means actually getting out in the field and observing people.

    That means, if you’re an IT person and you want to design some internal application that employees are going to use to track time, for example, or to do some part of their job, you want to start by actually going and sitting with them and seeing how they do their job. This way you can understand their job and you can understand how they see things rather than how you see things. Everything drives from that.

    There’s a lot of focus on iterative design and user testing, but it’s really all focused on centering your solutions on what users are trying to accomplish and how they understand things and what their needs are.

     

    devopsy.kinsta.cloud: How is it applied to DevOps?

    Sussna: We can apply that to DevOps in a very simple way. If you’re in Ops, for instance, you need to think, to some degree, about your customers being developers.

    So what is it that developers are trying to accomplish? How do they see the world? What do they need from you in order to get their job done more efficiently? And even when we look at things like platform as a service, what it’s trying to do is to make it easier for developers to deploy code. If you look at infrastructure as a service it’s trying to make it easier for Ops teams and DevOps organizations to cost effectively manage scalable systems.

    Conversely, if you’re a developer you need to think about things from the perspective of, “How does what I’m doing impact operations?” If I release some code and, A, the code isn’t secure and, B, the code isn’t scalable and, C, it takes 47 hours and 17 people in order to deploy my code, that’s not a very empathetic approach to operations.

     

    devopsy.kinsta.cloud: It is increasingly the case that more of IT has to think about the external customer as well, in the context of everything they do.

    Sussna: IT is in the business of providing services to the company but more and more now to customers as well. And so we need to think of ourselves as being in the service business just like anybody else. It isn’t just an ISO definition of service. It’s really a business definition. If I run a shoe store, I’m in the service business. If I operate a bank, I’m in a service business. I have customers and I need to help them accomplish their goals and I need to think about customer satisfaction and I need to try and empathize with what their needs are.

    There’s a branch of design thinking that is called service design. Sometimes it’s called service design thinking. And it’s really about applying these same principles of empathy, ethnography, and creative problem solving and iterative design. It’s applying them to services. In our case, the services happen to be IT services, both internal and external.

     

    devopsy.kinsta.cloud: How is this approach different than what IT has always done? IT has always tried, or at least stated that, the goal is to build apps and services that the business wants and needs to use.

    Sussna: I think too often we’ve done it from a technology first perspective as opposed to a human first perspective. There is an assumption, and it’s a very subtle assumption, but there’s this subtle expectation that it’s our job to adapt to the technology. And it’s not just about technology, the assumption is that it’s our job to adapt to the process.

    I’ll give you a perfect example. I went through a situation recently where I was having a problem with a laptop and so I filed a ticket in the ticketing system. And the response that came back was, “Well, your laptop, you can’t log in because your laptop got moved to a stale machine domain so we’ve moved it back to the correct domain and we’re closing the ticket.” And there was not even the question asked of, “Well, can you log in now?” It was, “We did the thing that we believe will fix the problem, therefore we’re declaring the problem fixed.”

    So the point is that the process of carrying out actions was central and the question of can the humans solve their problem was secondary.

     

    devopsy.kinsta.cloud: That’s a great example, because it seems like the designer of that system just wanted to close tickets as fast as possible when you go through that example. There’s no indication of thought being given to the user at all.

    Sussna: The irony is that if you look at the back and forth that went on afterwards to ultimately get to the point where the problem was solved, it actually took more time and more energy and more ticket thrashing than if they had simply asked, “Hey, can you please verify that this solved your problem and let us know if it did.”

    So, yes, to some degree, you can say there was a focus on efficiency and volume of ticket closure and operational cost effectiveness and all of that. But I think that what design thinking is really trying to tell us is that if we think through the process and if we design things from a user-centered way, we can actually develop solutions that are more efficient for everybody.

     

    devopsy.kinsta.cloud: What are the primary benefits of Design Thinking to DevOps teams?

    Sussna: I think the benefits are that you can design solutions that help people solve problems more effectively. And effectively both means that the user is satisfied and that the organization providing the service meets its needs as well. Design thinking works with a triangle, which is feasibility, viability and desirability and trying to solve for all of them. Desirability says, “This is the thing that works for me, I want to use it.” Because if I don’t want to use it, it will fail. Because even if IT says you have to do it this way, people will find workarounds if they know of a better way.

    Feasibility speaks to the ability to actually build something. And viability means that it will work from a business perspective. What design thinking does is try and solve for all of those. It’s a solution that’s effective for the users but it’s also supportable for the IT organization.

     

    devopsy.kinsta.cloud: How do folks get started on that type of thinking?

    Sussna: In terms of how to get started, I think it’s very similar to how you get started in DevOps. I think what people are actually trying to do with DevOps, that they may not realize, is they’re redesigning how IT happens. I think with both of them, the way you start, the way I guide people in starting is to just get out of your silo and actually go talk to people.

    I’m working with a client right now and they are trying to build an integrated IT dashboard that will allow everybody in Dev and Ops to visualize what’s the state of their network, what’s the state of their servers, what’s the state of their application, and what’s the state of their data. And they’re getting excited about all of the different types of dials that they need. But I’m telling them, “No, stop. The first thing you need to do is figure out who you think is going to use this and go talk to them.”

    Don’t tell them what you’re going to to give them or maybe come up with some a very, very simplistic, crude fantasy of what you’re going to give them. Go talk to them and learn in detail about what they need to do, what things they are missing, and ultimately ask “Does this work for you?”