Effective communication is integral to success in DevOps transformations
Ever since the dawning of mankind, or should I say “humankind,” we, as a species have invented ways to communicate with our fellow men and women and gender-neutral colleagues (and, soon to be included, robots). From grunting and bashing (bashing gets the message across quite effectively, albeit rather limited in scope) to cave paintings, symbol-based languages such as Cuniform and Hieroglyphics to modern complex languages that evolve across cultures.
Fast forward a few thousand years …
With the emergence of IT professionals as a species, we took a step back into the caves (data centers) and reinvented our own grunting and technobabble language to fit our own IT culture. Our cave wall images became PowerPoint slides, and we would “bash” users with SLAs. Symbols became replaced by acronyms: SLA, UPC, CI/CD, XML, and our modern languages became the language of the “framework” (e.g for the purpose of this article, DevOps). IT evolved and became embedded and entwined in every aspect of business and society, and we have been forced out of our caves and are now expected to “communicate” with these other alien cultures. Yet, our business colleagues feel we still cling to our technospeak to confuse them. (Read “Communication between IT and Non-It is a state of crises” – it was written in 2015 but business leaders I speak to still recognize this).
Even within IT we have our own sub-tribe languages, spawned by the frameworks and practices we adopt. The framework becomes the “Word.” Framework fundamentalists and framework dogma rule, as we throw terms at each other “incident,” “problem,” “defect,” “release,” “deployment,” “User … pain in the neck.” Sometimes the framework and language becomes a brick in the invisible wall that divides us into IT silos.
We defend our language as it becomes part of our identity and what binds us together. In fact even the framework name itself takes on a meaning and life of its own. When we say “ITIL,” some interpret this to mean “Bureaucratic set of control processes that stifle innovation.” When we say “DevOps,” some take this to mean “Cowboy developers trying to push lousy code on to us without any controls.” (More on this framework interpretation shortly, as it is central to my rambling).
There seems to be one term that is common to all frameworks, something that binds us together. Finally something we can cling to and ALL understand. It is the word “Yehbut!” Whenever anybody from a different silo tries explaining something we say, “Yehbut” (“Yes, but,” meaning in fact “No, because”). In fact, to speed up the flow of communication (as speed and flow are now catchphrases in the age of Agile and DevOps, we even say “yehbut” before the person has finished speaking, thereby eliminating “waste” (wasteful words).
We in IT do not need to hear everything to know what was going to be said or even the intention, we have our own “artificial intelligence” engine built in—it is called “assumption intellect (AI).” We apply “Assumicide”: assuming that we know what the other meant when communicating to us and assuming the other understood what we said. This is obviously a core IT capability, as we see it consistently applied in just about every team in our latest “Phoenix project” DevOps simulation. It would appear that we don’t listen to understand, we listen to give an answer. Shift left. Give an answer before the question has even been asked.
It is the same with the word “DevOps.” People assume they know what it means and interpret the term in their own way. In our simulations we strongly urge BizDevOps, the importance of the role of the business. This receives criticism from experts; quite rightly from their perception, interpretation and intention, they declare that DevOps always included business, sec, QA and the rest of the stakeholders. However, that original intention has gone through the “assumption intellect” filter and has come out primarily as Dev and Ops when it comes to adoption, with the business somehow plugged in, on and somewhere in the middle—if we are lucky. Which is why we make it BizDevOpsBiz: to make it explicit. Mark Smalley has written a thought-provoking DASA whitepaper around this topic. Gene Kim, at a recent Executive Connections session, also stated that product owners also need to shift their mindset from “features” to “business outcomes.”
There also seems to be a common “taboo word” that binds us all together across frameworks. It is a common agreement to avoid asking or answering the question “Why?”—”Why are we doing this framework?” The framework becomes the “goal” in itself. “We are going to implement DevOps, ITIL or any other framework.” We send the different silos onto framework training to learn the latest “terminology” so we can confuse other teams and departments who don’t follow the training.
It seems that our motto is, “Ours not to reason why, ours but to do and die.” (Alfred Lord Tennyson)
The Importance of Communication in DevOps
Why am I ranting on about communication and words?
Three reasons:
Communication and collaboration seem to be critical enablers or barriers for DevOps success.
The word “DevOps” seems to have taken on a meaning and life of its own, which is limiting the potential value.
Communication issues are very costly (see this article from Forbes).
I recently played a Phoenix Project DevOps business simulation with a group of senior leaders at the start of a DevOps transformation. These were their key takeaways. I decided to try and analyze their discoveries in terms of communication.
Answer the questions “What’s in it for me?” “What if we don’t?” – make this clear to all to ensure the “Why?” (are we adopting DevOps ways of working) is understood and felt. Remove the current FUD (fear, uncertainty and doubt) caused by the latest reorganization.
“We noticed in the simulation that poor communication leads to assumptions, assumptions in an environment of FUD are negative, and lead to poor decision making, lack of trust, resistance and lack of buy-in.”
We recognized the “yeahbut, yeahbut”! People were not seeking to understand and explore before answering. People were not confirming understanding or soliciting feedback and understanding. “We recognize that people listen to give an answer, not listen to understand.”
Coaching for teams in start-up phase. Not “telling teams what you expect and what to DO,” asking teams questions about “behavior” and “impact” (help them to learn to apply continual learning and improvement, to organize effective stand-ups, to apply active listening). Learning new behaviors and letting go of old ways of communicating and behaving requires practice and feedback.
Tell teams (including product owner) we support and commit to reserving WIP time for them to learn, create cross-functional teams and improve.
Applying “consequence” management—verbally recognizing, rewarding and reinforcing “desirable behaviors.” Directly communicating and giving feedback on “undesirable behaviors” and “falling back into old behaviors.”
Fostering open feedback on “undesirable behaviors,” asking questions about feedback and behaviors. (When nobody says something about it, it is implicitly accepted behavior).
Foster a culture of active listening, understanding. “Good ideas when not heard or acted upon are ‘waste’, and demotivating when not given recognition or heard.” Not recognizing and giving room to innovative ideas will stifle a culture of experimentation.
Have teams develop own visual management systems together with coaches, to aid insight into workloads and priorities, communication and decision making—The MT (Management teams) must communicate guidelines around priority (portfolio, strategic goals). The visual management board became the modern cave wall painting, a new language of post-its, tape and swim-lanes.
Start capturing and understanding WIP, WIP limits and constraints to flow. Start capturing and visualizing team pain points and improvements. This will aid communication, open discussion, decision-making and expectations.
Foster a culture of “measures to improve” (not measures to punish): measures to show behavior change, measures “DevOps” metrics (releases, time to release, quality of release), agree measures of “value” and “outcomes” with product owners, measure team skills and growth, measure impact of iterative “improvements” (see 8-field model).
Introduce FUBAR of the month with rewards for most impactful learning and improvement. (Remove fear and blame associated with failing). Talk about failures, impediments, constraints, waste. MT will start with own!
Revisit VSM (value stream mapping) training and make visible value streams with all stakeholders, Pin these up where they are visible to all, ask people to put “pain point” stickers on VSM (allows all to communicate continual learning and improvement needs, focusing on eliminating waste). This also helps recognize the “information” and “communication” flow through the value stream and foster dialogue.
Calling “Stop” is a very effective communication tool, if “respected.” Calling “Stop” to discuss and agree to eliminate “waste” and improve “flow” through the value stream.
Engage and involve end-to-end stakeholders in these simulation sessions to foster a dialogue, to practice effective communication, reduce assumptions, create buy-in and stop the “yeahbut, yeahbut” responses.
Although DevOps success clearly relies up technology for the continuous integration, automated testing and continual delivery, it is underpinned by effective communication and collaboration. Communication is not just about terminology or language: Listening is probably more important than talking. It is also about demonstrated behaviors—walking the talk, leading by example. This is what ultimately creates trust. And trust is the foundation for effective collaboration.
Nike’s DevOps transformation has had a lasting impact on its culture and productivity, while allowing the company to connect with its customer in ways it never could before. Its journey down the path to DevOps was shared at the DevOps Enterprise Summit (DOES UK) 2018, in London.
For a company of its size and success in the current market to take a giant leap of faith and come out even more successful takes incredible courage, hard work and collaboration. But that’s Nike for you: Shoes, apparel or DevOps—it doesn’t make a difference to the company. From day 1, Nike has lived its mantra, “Just Do It!”
Imagine this: You’re a high-level IT employee at a non-technology-focused company with a market value of just over $110 billion. All of a sudden, the newly appointed CEO makes the most significant announcement in recent history of the company, essentially saying, “We are entering a new era of growth and we expect to use technology as our main way of getting closer to the customer.” Pretty crazy, huh?
This was reality for Randy Lyons, a longtime employee at Nike with an extremely strong taste for competition and the opportunity of a lifetime in his hands. Based in the EMEA region, Lyons teamed with global Nike CFO Michelle Power with one goal in mind: to bring customers closer to the products, available at any of their 7,000 branded stores globally, through a digital platform. The aim was to tap into consumers’ need to check our phones before making a purchase. The scale was momentous; arguably, larger than any other company achieving a successful DevOps or Agile transformation before. To pull this off on the scale CEO Mark Parker had intended, a complete culture shift was necessary.
Luckily, the unlikely team shared the motto, “Culture eats strategy for breakfast,” and they were eager for the challenge. To start, they needed to change the self-identity of the IT branch. For too long had the underutilized IT staff heard the narrative that “technology helps the business succeed,” rather than existing as a part of the business. Lyons and Power placed a heavy emphasis on the new role of cross-functional IT teams as an integral part of the company rather than a useful helper. They adopted the hashtag “#OneTeam,” which promoted interaction and alignment of the tech team with all other teams, and showed everyone working for them that they were fully invested and energized in positively changing the culture and structural hierarchy of Nike. Additionally, they sought to point out the impact each person’s work was playing through the lens of the overall strategy. The “How is what I’m working on going to effect the direction of this company?” question versus “What else do you need me to do?” was a significant change—it boosted the overall motivation of the teams to work together and even raised individual production significantly.
However, the transformation was only beginning. Early on Power and Lyons discovered a fundamental flaw in the company they sought to transform: Their employees didn’t feel rewarded for their work. While it might be easy for some companies to blow off this issue in favor of dealing with “bigger” issues, they wanted to promote a company culture that would foster growth and speed, which would not—or could not—happen unless their teams felt beyond satisfied with their workplace environment. So, instead of the annual award ceremony Nike regularly used to reward and congratulate its employees, Lyons and Power decided to implement a simple change they felt would satisfy everyone: They added 15 minutes to the end of their weekly Friday staff meeting to give shout-outs everyone who had performed above expectations on a project. It was awkward at first, Lyons admitted. He also described it as “quite American” (ha ha)! However, this simple idea created a complete culture shift. Suddenly, the tech team was being praised by the supply team, while the supply team was being praised by the sales team, and the sales team was being praised by the tech team. This weekly validation of a job well done turned into more jobs well done!
Ultimately, the agile teams were motivated enough and aligned in such an efficient way that they were able to produce five separate software systems fully integrated into a single one-member profile:
com (full selection of products sold in store)
Nike app (for a more personalized experience)
Sneakers (collection of shoes sold in store)
NRC (for running products)
NTC (for training products)
These software products were incredibly effective in creating an emotional attachment with the brand and the products. Finally, the goal of getting the customer closer to the product through a digital interface had been achieved. The process to get there wasn’t easy. There were many problems to overcome and many things that changed drastically to allow for a newer and more efficient way of doing things. However, Lyons noted this transformation was the most influential on a personal level for him: Before undertaking this project, he didn’t feel as though he could effectively serve as both a team leader and participant. He could easily take orders and sometimes give them out, but it wasn’t until he partnered with Power that he learned to become a not just a team player, but the best player on his team.
The DevOps journey was a transformational process for both the company and the people involved. Today, “Just Do It” means exponentially more to Nike than just a slogan—it’s a way of adding value and efficiency to business.
This was just one of many of great presentations at this years DevOps Enterprise Summit UK this past week. We will be highlighting others in the days ahead.
There may be nothing more difficult in a DevOps transformation than aligning the business with its technology organization—and vice versa. Dealing with skills gaps and information gaps, while addressing communication breakdowns and cultural hurdles can keep even the most seasoned practitioners and leaders up at night. How do we align disparate business units accordingly? What practical tips can people take and implement along their journey?
These are topics we immersed ourselves in during a live video podcast ahead of the DevOps Enterprise Summit (#DOES18) in London. I was able to sit down with Carmen DeArdo of Nationwide and Jayne Groll of DevOps Institute to take a deeper dive into the DevOps transformation patterns and practices. This discussion centered on a major theme of DOES18 this year: business and technology alignment for the modern enterprise.
We hit on many important issues that I think we can all learn from and apply in our organizations respectively. One of the things we’ve learned over the course of the years is that, in DevOps, the focus is heavily cultural, but it has to be squarely on nurturing and getting buy-in across the organization. But at the same time, we need to be orchestrating our strategic alignment initiatives between the disparate functions and organizations within the business. That’s a tall task.
Watch the full video replay below, and/or read through the full transcript to see what key points were made and how we can adopt best practices to move our businesses forward.
Carmen and Jayne will both be speaking at DOES18 London this year and I will be leading video panels that you can see exclusively on DevOps TV / devopsy.kinsta.cloud. Hope to see you there!
Alan Shimel: Hey, good day, everyone. Thanks for joining us. This is Alan Shimel of devopsy.kinsta.cloud. And I’m here to talk to you all today with a few friends of mine about the upcoming DevOps Enterprise Summit in London. This will be a live panel discussion ahead of the London DOES event, which, by the way, is June 25th to the 26th at the Intercontinental Hotel, sometimes called The O2. Our panel today, I’m happy to say, are two really good friends of mine. Well, one is one of my business partners at the DevOps Institute: Co-founder and CEO of DevOps Institute Jayne Groll, and a speaker at DevOps Enterprise Summit London. Jayne, welcome to our hangout today.
Jayne Groll: Hi, Alan. Hi, Carmen. Thanks a lot. Really looking forward to it.
Shimel: Okay. So Jayne has already sort of introduced our next guest there, another good friend of mine, a recognized DevOps leader for many years. He really kind of kicked off a lot of the kind of groundbreaking DevOps work that we’ve seen at Nationwide over the years. Also a great Pittsburgh Steelers and Pittsburgh sports fan, Carmen DeArdo. Carmen, welcome.
Carmen DeArdo: Welcome Alan. Welcome. Hi, Jayne. It’s always great talking to you.
Shimel: Thank you. So all kidding aside, both of you are kind of experts and leaders within the DevOps Enterprise community, and you’re both presenting at DOES London this year. You’ve actually both presented at previous DOES events as well. So thank you for coming here. You know what? When you guys first started kind of preaching in the wilderness about DevOps and so forth, it was a bit of the wilderness, but it’s becoming commonplace in businesses and organizations throughout the world now. Our goal on this chat, guys, is to learn about the patterns and practices that leaders have identified for business and technology alignment, and really what we’d hope is just to share your experience and thoughts with our audience so that maybe they can learn something and they could integrate or assimilate that into their own transformational journeys and escapades.
And just again a reminder, this is about DevOps Enterprise Summit London, June 25th to 26th, and you can get more information on the event at events.itrevolution.com. You’ll find on there, by the way, the entire conference agenda, and beyond Carmen and Jayne, it is a gangbuster lineup of speakers. If you’re interested in DevOps and any kind of related type of technologies and frameworks, etc., it’s really a can’t-miss one for those of us, you know, who follow this space, or even for those of us just getting involved in it.
That being said, though, I’ve spoken enough. Let’s get started. I’ve given a little bit of your background, but maybe I haven’t said everything that needs to be said. So, Carmen, since I see your lovely face on the screen ahead of me here, why don’t you go first? Give us your background, your company role, etc., professional accomplishments.
DeArdo: Okay. Thanks, Alan. So I actually spent most of my career in telecom working for Bell Labs. Thought I would retire from Bell Labs like everyone else at the time, and then the telecom bust happened, and we all had to figure out what we were gonna do with the rest of our careers. But it served me well, because I think a lot of those concepts, even though we didn’t call them DevOps, but, you know, certainly, creating high-availability, high-reliability capacity systems, you know, those concepts are still, I think, pertinent obviously today. I moved into Nationwide to really help with trying to get Agile set up about 12 years ago, and then, you know, as I think you see the case with a lot of companies, they start somewhere in their value stream. They may not even think of it at that point like an end-to-end value stream, but they’re starting somewhere. They start with Agile.
You know, we were very successful getting all our work done there, but then realized, okay, that’s only part of the story. The cards getting into the backlog through iterations is great, but we aren’t getting flow of work from the business into the teams, and we certainly aren’t releasing into production frequently. So about, I’d say, five years ago, you know, somewhat in affiliation, some of the work I was doing with, as you know, Rosalind Radcliffe, Hayden Lindsey, you know, started to talk about what’s this DevOps thing. Was lucky enough to end up at the first Gene (Kim) conference speaking with Hayden. Wasn’t sure what I was getting myself into, but it’s been a wonderful experience. You know, got to meet you, Jayne, and lots of great folks from Gene’s community.
In Nationwide, we’re just continuing to work, how do we make that end-to-end flow and lead time, you know, what do we do to make it better? What DevOps practices can we bring? But as you noted at the beginning, how do you get the business more online? How do you get work to flow? And how do you address culture, which we know is probably more important than technology?
Shimel: Excellent, dead on. Jayne, how about you? You have more hair than both Carmen and I. You’re the lovely face we should see on the screen here. Give us a little background and accomplishments.
Groll: So I call myself an accidental technologist. So I started my career, got out of school, ended up in the legal field for about 15 years working on the business side. So I wasn’t a lawyer, but I was one of the early paralegals for a big Wall Street law firm that adopted UNIX a long, long time ago. I don’t even want to say when, but screens were black and green back then. And so everybody had to learn UNIX. And so I was very fortunate to be given an opportunity to accidentally become a technologist, and I know even with my technical skills, I’m a little self-taught. Was able to move up into some senior management roles across several different verticals, leaving the legal space.
And then in 2004, kind of fell on ITIL and really started to see a paradigm shift in IT that technology is important, but your practices, your principles, your processes are important as well. And people, process and technology became a mantra. And so co-founded ITSM Academy with Lisa Schwartz and really saw the growth of maturity in IT. You know, I always say we love our frameworks. IT, we love our frameworks more than any other business unit, and really started to see that percolate. Met Gene and some others through that experience, but really, landing where we are today. In 2012, I was able to attend an early DevOps day, frankly, at Gene’s invitation and really saw something percolating there that was pretty much common sense, but not common practice.
So we started to see, you know, should Dev and Ops collaborate better? Should there be a faster flow? Should there be less silos? Yes. Should we use automation more? Yes. We automate the rest of the world, we don’t automate ourselves as much. And really started to see something grow there, and, Alan, as you know, in 2015, we launched the DevOps Institute primarily because the practices around DevOps unlike other frameworks were really emerging in the wild. You know, you said it before. They were emerging in the wild and making some sense out of that, you know, as it crossed over into the enterprise space was important and requires a lot of research.
So, you know, we don’t have a single body of knowledge in DevOps. Thankfully, we have a collective body of knowledge in DevOps. So for me, I think part of my, you know, pride is my journey has not been a linear path. Really blessed to be, you know, where I am today, and, you know, DevOps Institute right now is, what, 32 countries that are talking about in doing DevOps. I mean, that’s really kind of surprising and remarkable all at the same time.
Shimel: Yep. And just to excuse, I don’t know if you guys can hear. We have a train, the 11-08 Cannonball Express, going via the office here.
DeArdo: Just like my cousin Vinnie here, Alan? Is that like …?
Shimel: That’s “two yutes.” The way I talk, we’re not far off. Anyway, though, guys, let us move along here. You know, one of the things that I’ve learned in my own exploration of DevOps and digital transformation, etc., is that a lot of businesses, large enterprises, they may think they do, but on the whole, they don’t really understand technology. Yeah, some of the guys in IT understand some of it or what have you, but do you think most businesses understand technology? Carmen?
DeArdo: I think it’s … Obviously, people are exposed to technology. In fact, I talk about this all the time, that sometimes we’re still in the book writing business or book production that we still feel like we got to produce manuals of paper material … The disconnect comes as, How we can effectively utilize the technology that we have to meet the business needs? And I think that’s maybe where the disconnect goes. It’s not that, you know, people certainly are … they have Alexas. They have stuff in their home. They may be even, you know, great at programming their home devices, but how are we actually taking advantage of that to serve our customers? And I still think thinking about things kind of in this … you know, Jayne talked about silos, but I actually think the last frontier really of DevOps is in the left part of the value stream, not the right part.
I think they code the cloud. There’s patterns, maybe not everybody’s done it. I know it’s not easy to do. That’s pretty well-defined from a pattern. The front part is not, and I think understanding that, you know, you have to basically be an IT business. We hear this all the time. If you’re not an … consider yourself an IT business, someone who is good at IT is gonna disrupt you. So it’s not that I don’t think they understand technology. They’re certainly capable of it. It’s just, do we really understand how we can use it the best way in order to meet business needs? And, you know, things like the system of engagement. Well, the system of engagement is gonna change. We’ve already seen it change. It changed from web to mobile. It’s going to voice. It’s gonna go to different engagement models.
That’s fine, but you still have to have the back-end technology, and the microservices, and the APIs, and the ability to deliver more quickly, and I think that’s the part of it, the gap we still haven’t bridged. And how can we actually get …? You know, one of the things that Nicole and I are talking about at the conference is the project-to-product model. And I think large companies like ourselves are kind of flailing at what … you know, that makes sense. It makes sense to align around a value stream, but how do you really define what those value streams represent so that you can actually get that flow and then use technology to help get that quick deployment and, you know, feedback? So I think that’s where we see a lot of the gaps, you know, from that perspective.
Shimel: Sure. Jayne, before I have you answer on that, you know, I got an email of pitch. I get a lot of pitches as you can imagine, but I got one the other day that, to me, really nailed the issue. The issue was they pitched me about how great their solutions and their services are, and they said it makes IT costs less. Instead of … so they’re still thinking of the IT department as a cost center instead of a profit generator. And to me, when you say that, that means you really don’t understand technology, you don’t understand the role of IT in the modern enterprise, and you’re just not doing it right. Jayne, your thoughts.
Groll: So I think you’re right. I think, you know, the modern enterprise has a few challenges ahead of it. Carmen, I absolutely agree with you. I think every business knows they need technology and they need to accelerate their use of technology. I think they don’t understand how to apply that, and more importantly, I think the big paradigm shift, and, Carmen, you said it, is that most companies don’t realize that they are now technology companies. It isn’t even just IT does for you, is the core company as a technology company. And those that kind of recognize that, I think, are those that move ahead. Those that are still kind of hanging on to a legacy … Now, you know, I’ll add kind of something into that recipe that’s a little scary.
With the way technology is moving and how fast it’s going, I mean, the acceleration is remarkable, and, you know, Carmen, you said it. It was cloud. It was mobile. Now it’s voice. That it feels like, you know, this kind of moving target that if I’m a business leader, not a technology leader, although Lord knows that, I think, has a plan here, you know, where do you put the dart? You know, do you invest in mobile? Do you invest in voice? Do you invest …? So it’s such a moving target, and it’s going so fast that I think it can be very daunting to figure out, okay, where do we make our play, and, you know, where do we use our technology spend? And I would say something funny, Alan, because you’re right.
You know, in my years in senior IT management, I almost always reported to the CFO, because I was a call center. And so it was nobody understood quite what I was spending money on, but they figured if I reported to the finance guy, that somewhere along the way the cost would be controlled as opposed to let’s optimize the capability. Let’s look at this in investment. So I really think organizations are trying to figure out, first of all, are we a technology company? And I would say unequivocally the answer is yes regardless of what vertical you’re in. And then where do I invest? What technology do I start looking at? And if what I do today is gonna be obsolete tomorrow, how do I make that investment for my company further?
Shimel: Excellent. So, guys, you both have a little bit of a background, more than a little bit, in training and so forth. Do we train people outside of the IT organizations on what technology can do for you? Do we put up sort of Uncle Sam’s “We want you. What can I do for you?” posters? How do we get the business to understand the technology aspects, the technology side of things? Go ahead.
Groll: I mean, you know, the “we want you …” unless you can promote something that says what’s in it for me, me as an organization, me as an individual, me as a leader, I think that’s difficult. You know, doing road shows on here’s what technology can do for you isn’t something that you can tell. I think it’s something that you have to prove. And I think IT sometimes runs into an uphill battle trying to prove that, because it is costly and it does change a lot of the way people perform on a daily basis. I know what I did today, and tomorrow you want me to do something differently, and I may not be as successful as I was yesterday.
So there’s a little bit of a proof of concept usually, you know, done through piloting, whatever, but I think the, “How do we tell them?” I don’t think we tell them. I think we have to show them.
Shimel: Fair enough. Carmen?
DeArdo: Yeah. I mean, I think we’ve gotten a lot of appreciation. I mean, I’ve told … you know, and Cindy Payne and Jim Grafmeyer told the story at the last conference about Hurricane Harvey and how the business was able to respond within a day to what was a wind event and came a rain event with all our flooded cars and how we got the website optimized to handle those, to take the load off of our customer service center. They’re starting to get that, “Gee, having this capability to deliver things more frequently …” We now have some of us who deliver daily whereas before everything was going into a monthly release. So that’s a great accomplishment.
On the other hand, we’re running into the things that, you know, Topos talked about with compliance, with legal, with … and just, you know, how do we … Most of our time now on lead time is going from the idea to the backlog of the team, not from going from the … you know, the team getting the work to deployment. So I think going into, you know, that view of how do we start to think more about, you know, the other things that are getting in our way of lead time, because it’s not just the IT part of it. It’s now the business part of it, and we have a couple areas now who actually have true product owners sitting with their lines and are almost at the point now where they can deliver, you know, stories and storyboard them and move them all the way through production, you know, much more quickly.
So I think that’s an example, and I think that’s what you need. I always talk about you need stories, you need examples of how this can actually be done at your company, because reading about it, hearing about it is great, but then when you see the team next to you doing it, and even if it’s not perfect and even if you know it can be improved, that’s where really you start to change the culture of not just IT but of the business. You want something like that. And then, you know, I think you got something going that you can really build on top of. Jayne.
Groll: Yeah. I mean, I think that conferences like DevOps Enterprise London, Las Vegas, other events, local events, I think, also let individuals and organizations know they’re not alone in this journey. You know, part of the challenge in DevOps right now, I think, is we’re going from what is DevOps to how do we do this. And it’s not finite. It’s not, you know, you open a recipe book and it says, “Start here. Add these ingredients. You know, stir, bake for 350 degrees, and you have DevOps.” It requires a lot of higher-level thinking, requires some experimentation. And so I think that, you know, access to what have other people or organizations done … Carmen, I think you’re absolutely right, what have other teams done, really kind of making it a community of enablement is very, very important in this space, because everybody’s trying to figure out where do they start. And unfortunately or fortunately, the answer is it depends. It depends where you are, it depends what you’re trying to achieve. So I think that’s part of it as well.
Shimel: Yep. So, guys, let me try to tie a bow on this section before we move on. The reason I asked about the technology and technology education issue is I think it’s imperative for organizations to understand that in order for us to get what I call business and tech alignment, and what I mean by business and tech alignment is that we’re all pulling in the same directions for the same reasons with the same goals, and we’re following hopefully a road that we have agreed upon, and we all know the road we’re traveling, because, again, you get back to DevOps, guys. You know, when you guys are out there talking about it and we were covering it at devopsy.kinsta.cloud, what do we always hear? What exactly is DevOps?
There’s no real definition. What does it mean? You know, how do we define DevOps and so forth? And I think one of the things we’ve learned over the course of the years is that, you know, in DevOps, the focus is, you know, heavily cultural, but it has to be squarely on nurturing, buying across the organization for this “DevOps initiatives,” you know, that we’re starting. But at the same time, we need to be orchestrating our strategic alignment initiatives between the disparate functions and organizations within the business. And that to me is business and tech alignment. If you guys don’t agree with that, speak up, but if you do, let’s move on to our next part, but can we wrap up, Carmen, Jayne? Are you fair to say that what we’re really talking about here is business and tech alignment?
Groll: So I’m gonna jump in just for a second, because … So you know I come from the ITIL space. And so in the ITIL space, they were coining the term BITA, business IT alignment. And so for years and years and years, there was a lot of conversation about BITA and its semantics. But alignment means that we’re kind of standing side by side in lanes next to each other. The reality is it isn’t alignment. It’s really unification. It’s really we don’t need to align with the business, we need to become the business. And, again, I know it’s semantics, but that word alignment gets tossed around a lot, and it implies something like, “Well, I’ll drive my car next to yours, and we’ll travel at the same pace, and we’ll get to the same journey,” as opposed to, “Let’s be in the same car.” And so you understand what I’m saying?
Shimel: Yeah.
Groll: And I said the term BITA is sort of falling away a little bit, but it was thrown around a lot during the years when ITIL in particular, you know, was kind of front and center.
Shimel: Yap. Carmen, any thoughts on that before we move on?
DeArdo: No, that was great points. And, you know, I refer back to Mark Schwartz’ last book, “The Seat at the Table,” and where he really talks about IT really should move beyond trying to get a seat at the table and move towards, you know, as Jayne said, you’re actually moving together, and you have to merge really these concepts of what the business wants, you know, has to be very much aligned, more than aligned. It’s part of what IT need to be doing. So that merging has to take a fact, and I think as much as we’ve seen the culture issues in Dev and Ops, that’s gonna be an interesting culture issue. But we’re seeing the companies who are successful are already doing it. They are working together. And, you know, if you walked up to some of the teams I just talked about, you wouldn’t be able to say, “Oh, well, such-and-such is a business person, and, you know, Jayne’s a business person, and John’s an IT person.” No, they’re a team working together to achieve something for the good of the company, and that’s the way it has to be.
Shimel: Yep. Guys, let me broach another subject then, because I think we’ve covered this one. You know, I read an article yesterday about AI, and automation, machine learning, and we’ve all seen these before, and, you know, how it’s changing. But automation really is changing the job market, especially for people younger than the three of us. I mean, we’ve both seen our … all three of us have seen our 21st birthday recently and …
Groll: Just recently.
Shimel: Recently, but really the folks coming up behind us, and we’re talking about our children and so forth, automation and the job market that they’ll grow into is paramount. And one of the reasons is that we have a tremendous skill gap. You know, my background is obviously in infosec, and now we call it cybersecurity. I hate the term. But there’s a tremendous gap in the security space. There’s also a tremendous gap in the DevOps space, obviously, and that’s one of the reasons we see such a high demand, even for people who may not be certified or classically trained in DevOps, I mean, take some sort of DevOps class. If they’ve learned to work Puppet or Chef or Jenkins, you know, they’re in high demand here.
And so with this skills gap, it doesn’t hinder our DevOps transformation. Is it a drag on the entire DevOps industry or community? Jayne, I’m gonna ask you to take first crack at that. I mean, you must see this with DOI stuff.
Groll: I do, and, you know, it’s kind of like good news, bad news. So the great news is, where else do you get to work in an industry or an environment where you are now encouraged to learn something other than what you’re essentially good at? I mean, you’re now encouraged to grow new skills to evolve. Organizations are funding skills modernization programs. So, you know, we groomed … and Carmen referenced that. You know, we groomed an IT based on silos. And in every silo, you were a developer, or you were a QA person, or you were a security person, and you lived in your silo with other people who had the same skills as you did. And now, cross-functional skills and, you know, what they call T-shaped people where you need to still have a specialty but you’re absolutely required to have very large breadth of different skills means that organizations are supporting and funding that.
So the continuous learner is more the norm today than it was before where you will be a developer … experience, and I think it’s a great day to be in technology truthfully, because you are encouraged to think, and learn, and practice, and train, and do, you know, all sorts of other things. And I think companies are starting to see that. I hear the term “skilling” a lot. We not only talk about training, we talk about skilling. We need to skill our force. We need to skill our teams. We need to reskill or upskill. You know, those are really terms that are starting to enter our common vocabulary. And the day of the generic, “I’m a master, I’m an expert, I’m a practitioner,” and I’ve got a few of those credentials as well, those are so ambiguous that now the skills are very, very tangible, and organizations are hiring, I think, hiring and funding individuals to develop not only technical skills but practice and principal skills, too. So we’re all gonna be upskilled, maybe outskilled.
Shimel: Perhaps both. Carmen, how about you on this one?
DeArdo: Yeah. I mean, automation is obviously nothing new. I mean, I’m really dating myself, but I can remember when people didn’t trust the output of compilers. Like, are we sure the compilers are producing the right machine language or assembly language? I don’t know. I can bring the assembly language better than this compiler. I mean, I think automation and learning is just … obviously, you know, if you spent, you know, four decades like I have, and, you know, none of us are spring chickens, but you’ve got to learn a lot and keep learning. Now, I think the great thing, and I agree with you and Jayne, the great thing about Nationwide is they have invested in learning and upskilling their people. We had this thing called Teaching Thursdays where twice a month we have two hours which is set aside for peer-to-peer learning, and it’s really not … and it’s peers teaching people, and people love to be the teacher.
I mean, at the last forum, Jason Cox was talking about … We had a subgroup focused on operations, and Jayne was there. And talk about … you know, he had some folks on his team, that they have to become engineers. They have to become coders. And one of the guys who initially maybe wasn’t so crazy about it, once they became kind of the expert in their area and they were teaching other people, well, you know, they were really engaged then, because, you know, they were involved and they were the one now from a peer-to-peer learning perspective.
So companies, I think, like Nationwide, Disney, other companies that are leaders in this space need obviously to invest in that. And then, you know, it also means that the associate themselves, you know, needs to take advantage of that. I mean, we can offer those capabilities. We know the jobs are gonna change. We can make those skills available, and then folks need to take advantage of them, but yes, I mean, people have to become more broadly skilled and be able to become more of what I would call problem-solving engineering mindset as we move forward.
Shimel: Sure. So, guys, though, you know, so we have skills over here. And on this side, there’s another thing that creates a tension with the skills, and that’s what I call the information gap. So we have a skills gap, and you guys have both addressed that really well, but we also have an information gap. And I alluded to it when I talked about training. If an employer or an organization thinks that someone who can write a recipe in Chef or has heard of Jenkins is a DevOps engineer, if there’s such a thing as a DevOps engineer, or is someone who, you know, is gonna really help build their DevOps team, to me, that’s not a skills gap, that’s an information gap. How do we understand … How do we make organizations … How do we fill that gap on information so that organizations recognize, A, that there may, in fact, be a skills gap, B, how to fill that skills gap and bring the organization up to it?
I mean, this tension, this chicken-and-egg, if you don’t know it, you don’t know. How are you supposed to know? And so I’ll put it to you. What do you think is more important? The information gap, the skills gap? Are they equally important? Do we tackle them concurrently, individually? Carmen, how do you guys do it at Nationwide?
DeArdo: I mean, I think one of the things that IT hasn’t been good at is treating IT as … we’ve been a very bad customer to ourselves. So if you look at our pipeline, we don’t treat it as a product. If you actually want to get faster at delivering a capability from idea through deployment, you need to consider that as a product, not a bunch of different tools. It’s not Jenkins, and New Relic, and UrbanCode or, you know, the AWS. It’s not that. It’s a pipeline that’s gonna enable you, and it doesn’t start at code, it starts at idea to get you all the way through that deployment. So then what … do you have a team? Are you doing thinking across the pipeline? Are you doing architecture? We don’t do things like value stream architecture or architecting the pipeline as a product. We want to buy a bunch of technologies. We can hire people good in those technologies, but as you said, that’s not really gonna get us where we need to go.
So I think the first thing is, do you really treat your product … One of the first things, do you treat your pipeline as a product? Do you have a team that can actually support that product all the way? Do you have a product owner who can drive continuous improvement across that with funding and prioritization? And do you have one of your best architects, if not the best, to actually create the architecture and do value stream architecture, which is something, you know, that Mik Kersten and I have been talking a lot about. I think that’s one side of it that we don’t get, is teams could … if you ask a team, they can kind of figure out, tell you like a Deming quality circle, how they can go faster. And you can experiment, but then if you’re gonna operationalize that, you don’t want 200 teams doing things in 200 different ways. You can then take that and say, “How do I address that as part of my delivery capability?”
And then I think what you need your leadership to do is apply systems thinking, and that’s a whole another subject we could get into, but I don’t think executives and leaders know how to really address the, “How do I optimize this as a whole?” They want to get into the weeds. They want to get into the tool selections. There’s people that can figure that out. You need to really focus on the strategy and how you can optimize all this great information you’re getting to make sure you’re removing barriers and allowing teams, you know, doing the learning, making sure they can be upskilled, investing in their ability, and allowing them, you know, to be able to innovate and improve your delivery capability. And I think that’s what I just said quickly. It’s easier said than done. And I think that’s where I see a lot of the struggles, and I think where we’re trying to address this is how do we start to put some of those pieces in place so it’s not just a bunch of, you know, divergent disparate technologies we’re trying to bring in and hope that that’s gonna make us get better. Because those things and having skills just around those things is not gonna actually get us to where we need to go.
Shimel: Fair enough. Jayne, I’m gonna give you a chance to comment on the DevOps skills versus information gap.
Groll: So I think the two are really related, and I think Carmen brings up some good points. You know, I think it all comes down to silos. So let’s look at our silos. Well, within our silos, we speak the same language. We use the same acronyms. We use the same tools. We live in a common community where everybody kind of understands what’s going on and what’s happening. And then when we leave our silo and we try to talk to a different silo, we don’t speak the same language. We don’t use the same tools. We don’t have the same processes. So I think the skills gap doesn’t fully overcome the issues with the information gap, but, certainly, there’s help there that if we’re looking to share information, we have to share it in a way that everybody kind of has some type of uncommon understanding.
The other thing with information is, you know, information is really interesting to me, because everyone thinks they communicate a lot. People generally think that they communicate well. You know, teams generally think they communicate … like I told you that. You told it to me maybe in language I don’t understand or it wasn’t clear. It was some report that, you know, I don’t even know where it is. So I think, you know, kind of the flow of information and from a vocabulary perspective, from an understanding perspective, from a “Did you understand what I shared?” is something we all need to overcome. And I think, you know, again, they’re so interrelated to each other that if we start to create a broader set of skills, hopefully, that helps to improve the communication. I think the other side of it is we talk a lot about collaboration, and there’s a really fundamental difference between communication and collaboration.
And so information flows through communication, but communication is pretty much one way. I tell you, you tell me, and somewhere along the way. Collaboration is I start to ask your opinion, and that’s a really big, big difference. And so when we’re starting to share information, there’s a respect that comes across the skills gap. There’s a lot of things that go across that that, again, there’s separate gaps, but hopefully, the long term, and as Carmen said, not easy to fix, is by overcoming some of the skills gaps as well.
Shimel: Fair enough. I think we’ve covered that one well. Let’s move on to another area if we can. We have 20 minutes or so. You know, one of the things that really does my heart good is this concept of DevOps everywhere as far as the eye can see, like the meme with Buzz and Woody. We have seen DevOps move from just Dev and Ops to QA, DevSecOps exploding on the scene where, you know, a couple days, the 28th, a day or two after DOES London, John Willis and team are rolling out our second DevSecOps Days, which I’m involved in, and devsecopsdays.com for those interested. But even beyond IT, we’re seeing what I call DevBizOps, where DevOps’ Agile sort of practices are starting to take hold in HR, in sales, in finance, in, you know, accounting, etc.
And let’s be fair. This is not unique. The fact of the matter is a lot of the lean terminology, a lot of the lean stuff that was built into DevOps didn’t come from IT, it came from manufacturing. And so, you know, it’s like pay it forward. Now we’re seeing these kinds of DevOps principles move into other areas of the business. First of all, is that a good thing? I think it is. I can’t imagine it’s not, but I’ll defer to the both of you. And then, secondly, you know, hey, at the end of the day, remember, it’s all about the culture, stupid. And so what human factors, cultural factors should we be thinking of when we talk about a broader DevBizOps opportunity? And, Jayne, you’re on my screen, so I’m gonna tell you to go first on this one if you can.
Groll: You know, it’s business transformation. You know, it’s not really DevOps transformation. Digital transformation is not limited to IT. It’s really business transformation. And so it goes back to, you know, we talked about a little while ago, where, you know, every organization has to recognize that technology is their business, and so some of the practices from the business start to assimilate into IT and beyond. I saw this in service management where there’s now movement towards enterprise service management, where you’re gonna make changes, you do it the same way.
I think when we start to look … I mean, I can tell you from the content perspective, you know, we use tools in content development, even though it’s not software development, that are very, very similar to that. So I think it’s fantastic. I was talking to a gentleman from an organization on the Netherlands recently, and they actually took the Spotify squad model and applied it to their entire business, and not a small company, by the way. And so they applied it to their entire business where their business is now broken into squads. And, you know, some think that that’s only for a tech company, and by the way, this is not a tech company. It’s a large financial organization.
So I think that’s great. I do think there’s some … I think there’s good news, bad news. I think there’s a little bit of risk that, you know, with DevOps and some of DevOps practice is still emerging that it becomes, “This week, we do it this way, and this week, we do it another way.” And, you know, “Oh, that didn’t work because …” You know, fill in the blanks, but I do think that kind of having a one business and getting away from this we love our frameworks and IT, and every year, we have a new framework that supposedly supersedes the other framework, you know, that’s a maturity issue. And I think if the business embraces it … you’re right, Alan. Lean Six Sigma. That was a business initiative that a lot of organizations underwent that weren’t necessarily manufacturing organizations. So, you know, as we get closer to that, I think the unification becomes stronger.
Shimel: Great. Carmen, how about you?
DeArdo: Yeah. So I think of things like … It is a great thing. So I think of things like lean concepts. We have leaders across the company that we have gone through lean education and lean concepts. So when you talk about value streams, when you talk about lead time, when you talk about wait states, people understand those concepts, whether they be on business or IT. I mean, this whole idea that Dominica, I’m sure, would have talked about, about making work visible, Kanbans. I mean, we actually had an explosion of people who wanted to use some of our tools that initially were brought in for work out of management because they wanted … you know, it’s like, “Gee, who knew, you know, this Kanban stuff would work for us and WIP.” WIP limits. And so people certainly want to apply those kind of concepts.
So I do agree that, you know, the basic concepts, you know, really can spread everywhere, and the whole concepts of even the things, like we talked about it, the three ways. The three ways don’t just apply to IT. The three ways apply to anything that you’re trying to do and get better at. I think when it comes to information sometimes, though, you know, it’s kind of like the robot story and the goal. We have lots of KPIs, but are we actually focused on the goal? So the goal is not around keeping this person utilized or that team utilized. The goal is about, can I get faster from one end of my value stream to the other? And do we have data that shows flow? And that’s why I’m excited with some of the things that I’ve been … you know, that Mik’s talking about. You know, he has a book coming out that is gonna show actual flow of work, because up until now, we have not been able to actually see work flow all the way through that delivery pipeline. And so we guess a lot of times. We think, “Oh, well, if we just add more developers. Oh, we’ll add more testers.”
Well, how do we know? We don’t really know, because we’re making maybe educated guesses, but we’re really not all focused on understanding where the work is and those concepts that can shine a light on it. So I think it all does come back to a lot of those concepts that, growing up in Bell Labs, I was lucky enough to experience with Deming, even going back to Shewhart, around doing those experiments, getting better, seeing the entire end-to-end value stream, but these concepts apply. I mean, “The Phoenix Project” is really not a book about IT even though I teach part of it. It’s a book about how do you get better at doing whatever business you’re in and trying to, you know, stay in business and improve what you’re doing for your customer. So I think those concepts will continue to go, and I think, again, as we’ve talked about today, there’s a thread here of everybody needs to be on board with these concepts: legal, compliance, the business, everybody, because they all play a role in allowing you to do a better job, delivering more quickly to your customers.
Shimel: Fair enough. Guys, let me … You know, Carmen, you hit on some great things there. The Kanban board or even here at devopsy.kinsta.cloud, frankly, we run our entire customer engagement, not practice, but now into farming, on Trello cards, which is sort of an electronic Kanban. And it’s a great project manager. I’ll give you another thing. You know, there’s the cultural aspect of this of taking that sort of DevOps culture and expanding it throughout the organization, but there’s also the bits and bytes and tools aspect of it. Kanban’s a great example. I’ll throw another one out at you. Get up. Why does it have to be source code for programs? Why can’t it be source code for contracts or any kind of digital document or, you know, things that we work on?
So I think we’re just starting to scratch the surface on how we can take that DevOps can do or Kanban and, you know, move it out across the entire organization. And we’ll all … I think we’ll have better organizations as a result, but let me now turn it back around. How can we take some of the business culture positives, some of the things that have worked in other parts of our business, and reflect it back into our DevOps and IT processes? How can we enhance our DevOps by adopting broader business principles and practices that seem to work? Carmen, I’ll let you take first crack at that.
DeArdo: So I think, actually, a lot of our test and learn activities started with the business who had actually hypotheses around, “Well, if we offered a policy in a different way or if we made a tweak to something, would we be able to sell more of those things?” So we had people who … and there’s a lot of statistical rigor that you have to bring to that. So we actually had people on the business side who had these ideas about, “I have a hypothesis. You know, is there a way you can allow me to test that hypothesis to see if it, in fact, will yield some positive result in terms of actual policies being sold?” So it was a very scientific-type experiment that they actually wanted to run, and at the time, we really didn’t have a way to support that from an IT perspective. And it kind of forced us to do some things to support, you know, how could we actually get this out and offer it to only a subset of people, which we now might call canary launch or some other terms that are DevOp-ish terms, but really nobody was reading a DevOps book at this point. They were just trying to figure out, “How can we support the business’s need here to try to adapt more quickly and have a high plan around?”
And that started, I think, some of the things that actually were successful that then led into once we started to get into DevOps, like, “Okay, what we actually did there was DevOps.” We didn’t call it DevOps, but those are principles that really we need to support not just in this one’s case, but for all kinds of business hypotheses that we want to get out and turn around real quickly. And doing that really does bring everybody together, because it’s exciting. It’s exciting if you can sit at a business and you can think up, “I have ideas for this product or that capability. You know, how can we more quickly try to see if that would be a good idea?” rather than writing a 12-month business case and trying to do, you know, a protracted study.
So the whole idea of experiments and gain things out quickly, I mean, everybody will resonate and get behind that if you talk about it in that way. If you start talking about Puppet and Chef and things like that, that’s not gonna cut it. But if you talk about it in terms of business and what it can mean for the business, then that resonates and gets a lot of people excited.
Shimel: Excellent. Jayne, how about you?
Groll: I mean, I think Carmen is right on point. And, Carmen, you said something I think that was … you’ve said a lot of very insightful things, but I think in particular that the experiment came down to, “How can we sell more policies? How can we make our business more successful?” And I think if you look at kind of the past in IT, sometimes, we didn’t know how we were contributing to the bottom line. So we were introducing a lot of technology, and we were doing all this cool stuff. But how did that convert into an increase in revenue, an increase in market share, increase in competitive advantage, things like that? And so I think that this unification with the business becomes more significant when IT sees themselves as an enabler of the goal. The goal of every business is to make money. And so sees themselves, and it goes back to information and communication as well, that they understand that what they’re doing is actually helping to sell more policies or increase market share or stand above the herd or anything along those lines.
Now, again, if you’re the CIO, you probably know that. If you’re in senior management, you probably know that. If you’re a developer and you’re one of a few hundred developers, you may not know that. And so I think that it is that kind of bottom-up top-down approach where understanding that what you do every day is contributing in a very, very substantial and tangible way. And then I think the other part of it, and, Carmen, I think you said it really well, is encouraging those experiments where the business and IT work together. And maybe it is that 1 in 100 coder that’s working as part of that team to say, “You know what? I have an idea.” Everything starts with a great idea. It could be from the business. Hopefully, from the business, that says, “I have an idea. Let’s see if we can, you know, bring that to life and what it will do to our bottom line.” And then there’s really a great collaboration between IT and the business.
Shimel: Agreed. Agreed. So, guys, we’re coming up to the top of the hour here, and I guess we need to wrap up. Otherwise, we’ll just be on air all day, and I know Jayne has a show in Vegas and so forth, and Carmen has stuff to do. But first of all, Carmen DeArdo, Jayne Groll, thanks for being our guests here on this hangout as we, you know, continue to build up to DevOps Enterprise London, DevOps Enterprise Summit London. Just a reminder for anyone watching, it is June 25th and 26th in London. There are still some tickets left, I think. I don’t know how many. I wouldn’t wait. You can get updates about the event as well as get tickets at events.itrevolution.com. It’s obviously on the web.
By the way, this year, as in past DevOps summits, devopsy.kinsta.cloud is a media sponsor. We’re partners. We’ve partnered with Gene from the beginning. We will be doing videos again this year at DevOps Enterprise Summit. I think it’s gonna be a little different this year. We’re doing some interesting roundtables. You’ll see them on our YouTube channel, DevOps TV. So stay tuned for that. All right. Guys and lady, or guy and lady, I had a great time today. I’ve learned a whole bunch. I hope our folks listening and watching this have learned as well. You know, you guys have done, not just today, but, Carmen and Jayne, you’ve been instrumental in helping to bring the gospel of DevOps to the world, if you may, or at least maybe not the gospel, but at least some really good learning and understanding.
So thanks again, guys, for being with us. We’re gonna call it a wrap. Carmen, any last word? Three words.
DeArdo: Three words. Project to product.
Shimel: Okay. Jayne? Last words from you.
Groll: Pittsburgh Steelers. I don’t know.
Shimel: We finally got her. Carmen, we converted her.
DeArdo: I should have said, “Let’s go Tens.” That’s three words.
Shimel: Okay. Hey, everyone. I will see you both in London June 25th and 26th. Hope to see many of you listening or watching this in London as well. If you’re there, stop by, say hello. I always like to meet people who have watched us online. But until then, this is Alan Shimel for devopsy.kinsta.cloud and IT Revolution. Thanks for watching, everyone, and hope to see you soon. Bye-bye.
In adopting DevOps, it’s easy to forget what you know
Have you ever found yourself struggling to explain something that you know how to do without a moment’s thought? I’m not talking about the amygdala, the part of our brain that initiates the automatic “fight or flight” response. No, I’m referring more to the muscle memory-type behaviors that we’ve collected through life and, likely, pay little attention to while executing.
Things We Take for Granted
Muscle memory is awesome. Through the magic of muscle memory I can type fast (occasionally with okay-ish accuracy). It enables me to drive in peak-hour traffic without having a nervous breakdown, and it’s the only way I can ski down a tree-lined path without ending up in hospital.
It’s through training, practice and repetition that we can carry out an increasing list of mundane tasks without being distracted from the bigger picture. In contrast, consider the expanding influence of DevOps across organizations, and how we’re pushing developer principles and practices onto operational facilities that have never been exposed to such. We’re asking people to break a habit of a lifetime and to think like a developer practically overnight. This can create some significant speed bumps in your operation transformation toward achieving continuous deployment pipelines.
Type Mismatch Error
On one side we’ve got infrastructure operations, where we’ve seen two decades of little change in the way services are provisioned and managed. Heck, for the most part, spreadsheets are still the source of truth—spreadsheets without versioning!
There’s no “commit log” trail, no integrated testing and definitely no consistency across the vendor technologies that must be managed. Imagine what root cause analysis after an outage looks like? A team huddle for a round of “Who touched it last?”
To software engineers, it must seem like the Wild West but, it’s important to acknowledge that this problem is largely the fault of the technology vendors. Until the principles and practices of DevOps shone a very bright light on operational inefficiencies, infrastructure operations weren’t challenged to increase the speed of business. Hence, the technology vendors hadn’t been pressured to evolve.
A New Hope (Yes, Like ‘Star Wars’)
Most infrastructure vendors have responded to the DevOps calling by re-architecting products in support of programmability. Many of them have even done an alright job of it, adhering to RESTful standards and publishing API schemas. However, there’s one key element that’s missing, and will be the cause of further challenges if not addressed.
To an experienced developer, operating with declarative interfaces, idempotency and continuous integration is practically muscle memory. But to infrastructure operations, it is completely foreign. Progressing with the kind of operational transformation required to achieve continuous deployment is possible but only though closing this operating model gap.
“Give me a Swiss army knife, and MacGyver I do not become,” said I at DevOps Enterprise Summit 2017.
As the lines between development and operations increasingly blur, be super-aware of the development principles and practices that are just a part of life for the software engineers. To close the operating model gaps, run workshops for your pals in operations. Teach them all the fancy words. Show them how to manage their config files and architectural notes in a code repository, so they can familiarize themselves with the tooling.
In this DevOps Chat we spoke with Prem Chandraskearan, VP of Software Engineering at Barclaycard. Prem led the DevOps transformation there. He sums up his learning thusly:
The best way for an organization to approach DevOps is from a collaborative angle. When development and operations experts actively work together in a cohesive effort, solutions are well designed, efficient and smart from both a development and maintenance perspective. When operations is viewed as a software problem, Dev and Ops can work in tandem to implement a tool that is holistically a part of the process from start to finish.
DevOps is always a work in progress, but the initiative can only improve with quality resources that implement a variety of backgrounds and perspectives on both Dev and Ops working together. Barclaycard has had some interesting challenges with DevOps due to being in the credit card/banking industry, so for example, the “you build it, you run it” mantra doesn’t work as well for us as it would for other enterprises implementing DevOps. It is definitely a learning curve, and our goals and best practices are still coming to fruition, but we are continuing to find ways to automate.
The best way to get teams to work together is to simply ensure that they are not in silos, meaning that if there are distinct dev and ops teams, they must spend time in each other’s sectors to understand the pains, how the functions work, what makes it tick, etc. When the development and maintenance perspective are strategized in tandem, it automatically makes for a better, more streamlined workflow.
The best way to ensure a DevOps initiative’s long-term success is to ensure that the foundation of the program is collaborative and understanding of how each function works. With this, automation testing for failure is imperative to discover problems that are typically only otherwise found in production. If all the bases are covered and the process is streamlined and collaborative, the overall quality of your DevOps function will be much higher.
As usual, the streaming audio of our conversation is immediately below, followed by the transcript of our conversation
Audio
Transcript
Alan Shimel: Hi, everyone, it’s Alan Shimel, devopsy.kinsta.cloud, and you’re listening to another DevOps Chat. Got a great chat scheduled for today. We’ve got a real, live DevOps practitioner. I’d like you to welcome to the show Mr. Prem Chandrasekaran—and I mangled that terribly—Prem, why don’t you give us proper pronunciation?
Prem Chandrasekaran: The name goes “Prem Chandrasekaran.”
Shimel: Fair enough. I don’t think I did that bad then. So, Prem, you are a software group leader at Barclaycard US, correct?
Chandrasekaran: That’s correct.
Shimel: Okay. And, well, before we get into it, let’s make sure that, in case people aren’t familiar with Barclaycard, who they are and what they do, if you wouldn’t mind just giving us maybe a quick little background on that.
Chandrasekaran: Yeah. So Barclaycard in the US is a credit card provider. Our primary business is co-branded credit cards, so, for example, when you’ve got an Apple credit card, if you look carefully, it actually says “Barclaycard” on it, in the background somewhere, but we’ve got a whole bunch of partners like that and we provide credit card services for our partners and customers through the co-brand. We also have a consumer lending business, which is a lot recent, but the credit card business is what is our primary revenue _____ _____, if you wanna look at it that way.
Shimel: Very good. And, Prem, in your role as software leader, what exactly does that mean? ‘Cause it means different things in different orgs.
Chandrasekaran: Yeah, yeah. So my actual title is that of a vice president, but, you know, what I was hired to do was to incept this new line of business. We were coming up with a new line of business called “consumer lending.” And our infrastructure, both hardware, software practices, all of those were on a pretty old legacy system, and we had two choices. One was that we would build on top of the legacy system or create a new platform, as we wanna call it, have all of the modern techniques that we use, including CI/CD, a lot of XP factors, and so on.
And I was brought in as a consultant first when I took the role on full time, two years ago, to lead the launch of that new consumer lending business. And I’ve been doing that. And now we’re trying to apply the same processes, software, hardware, all of those solutions, onto the credit card business, as well as we try to migrate.
Shimel: Excellent. And how long has this project been ongoing?
Chandrasekaran: Consumer lending started somewhere in 2015 and we launched at the end of 2016. It’s been live for the last 18 months or so. And what I’ve been doing after that is, again, I’m still in charge of making sure that consumer lending runs in production, but we’re also building what we call a “global platform” – basically, a set of design patterns and application templates and CI/CD pipelines to allow us to create new services, migrate existing ones, and develop what we call the platform –
Shimel: Oh, sorry. Go ahead.
Chandrasekaran: Yeah, so what I’ve been doing is we’ve been defining the learnings from what we did for consumer lending and making it available to development teams here, so that they can focus more on the business-logic portion of things, solving real problems, as opposed to grappling with a whole bunch of the surrounding stuff, nonfunctional stuff like log-in monitoring, CI/CD pipelines, tracing, and authentication authorization, and so on and so forth.
Shimel: Correct. So, Prem, I didn’t hear you mention security or cyber security, though, and that’s obviously something that’s important anytime we talk about financial services. Where did that play in, in the program here?
Chandrasekaran: I mean, we like to think that it’s something that starts with the code that you write, you know, so we make sure that all of our developers and teams think about security right from the ground up. And we have tests, both static and dynamic and penetration test frameworks, which check the state of the code that you’re developing from a security perspective, right through the CI/CD pipelines. And you’ve got a whole bunch of automation and a bunch of manual penetration tests that the teams do, to make sure that we are producing things that are secure not only for ourselves but also for our customers.
Shimel: Got it. So, Prem, let me ask you a question then. What I think is interesting is this was a project that, as you said, started in 2015, and here we are, 2018, talking about some successes you’ve had. And now rolling some of the lessons and learnings and success from that throughout other parts of the organization. And that actually – no two DevOps transformations, no two experiences, are exactly the same, but that’s right in sort of the sweet spot of how we see DevOps expanding within an organization. You get a project and many people are surprised that, in spite of the speed and automation that we think about in DevOps, it actually takes time. It takes time to launch a project. It takes time to bring a project to market like this.
But, once that’s done and you have good results, part of that DevOps way, if you will, is to take the feedback loops, take the learning, take the lessons learned, and apply them in other places within the organization. Prem, what about executives sponsorship of this, if you will? I mean, you’re a group leader, but, above you, what kind of buy-in or sponsorship did you have from your exec team
Chandrasekaran: Oh, absolutely. I mean, without exec sponsorship, I don’t think we would have progressed to where we are. I mean, we’re by no means done, but, you know, we are still in this journey and we’ve got a very solid leadership team which basically said that we need to operate not as a traditional bank, but as an IT organization, rivaling the best in the world, right? And that’s where we want to be. And it starts from there. And it percolates pretty much every single facet of our organization, starting form hiring to the way that we think. Basically, you know, DevOps is really a means of shortening the cycle of getting a product out of the door reliably and repeatedly, right?
Shimel: Yep
Chandrasekaran: So it does take a huge amount of effort in terms of the automation and the processes that we need to put in place, but, yeah, I mean, we’ve got very strong support from our leaders to help us transform the organization that way.
Shimel: Okay. So, Prem, let me put you on the spot here a little bit. We have listeners out there saying, “Wow, this guy’s done a project where they did this,” right? If you could – and we didn’t discuss it, so I apologize for putting you on the spot – can you give our listeners sorta three things they should avoid? What were the three biggest lessons you learned in the course of this project?
Chandrasekaran: Yeah, so, okay, I’m gonna try to look for three things, right? Okay, so the first thing that comes to mind is that, at least at a place like where we are, in a bank, right, buy-in is very important. So you might have buy-in from the top, but you need to have buy-in from pretty much every facet of the organization, that automation isn’t a threat to their jobs and existence, right?
Shimel: Mm-hmm.
Chandrasekaran: Where, you know, it’s normal that now our time and operations person – “Oh, my job can be automated and now I’m out of a job.” Right? That’s one thing that it’s largely a psychology thing, where you have to address that and give people the confidence that that’s not the motive here. The motive here is to churn out software fast and enable both DevOps, business, QA, information security – I mean, you name a whole bunch of these groups – it’s about collaborating and working closely together to achieve the end, which is putting out software solutions for our customers and our stakeholders repeatedly and reliably, like I said before. That’s one. It’s more of a mental shift that needs to happen. And, unless you do that, you’re going to meet with a lot of resistance.
The second thing is in terms of who you hire, right? Like I said, it’s a mental thing. It’s a philosophy where you need to have likeminded people who want to do the automation, as opposed to doing something that’s manual and error-prone, right? So hiring the right kind of people definitely is second.
And, third, it also needs your business folks to be patient while these transformations happen, where you might not see the benefits of it on day two, right? It takes a while for the benefits to start appearing because it does take a lot of practice. And we’re not there yet in terms of saying that we’ve achieved perfection – I guess nobody can say that – but it does take a few patient stakeholders as well. I mean, those are my three things.
Shimel: Excellent. So, you know, Prem, when we started, I said the 15 minutes go quick – we’re wrapping up here – but, again, for our listeners who maybe are contemplating or in the throes of their own DevOps journeys, I mean, this is certainly a success story to date. What else – I mean, what’s next here, though? Beyond what you’ve already mentioned to us?
Chandrasekaran: Yeah, you know, so, right now – I mean, our next step is to scale this out, right? I mean, we’ve got one product line that is using all of these, and a bunch of the rest of the organization, at least here in the US, has drawn a lot of inspiration from the successes that we’ve gained here. You know, we still operate in a private-cloud environment. We’re targeting going to the public cloud, which basically means that we now allow ourselves to scale a lot more quicker and a lot more faster. So, yeah, I mean, that’s probably the next step, where we’re targeting the public cloud and provide value to our business and customers a lot more quicker that way.
Shimel: Excellent. Excellent. Well, Prem, thanks so much for giving us a little bit of insight into how Barclaycard US has leveraged DevOps here and has started out on their own DevOps journey. We’d love to hear more about it in the future; maybe we can check in.
Chandrasekaran: Yeah. Thank you very much, Alan, for having us.
Shimel: Okay. Prem—and I’m not even gonna mess it up or attempt ’cause I will mess it up—Prem, thanks so much for joining us here on DevOps Chat. This is Alan Shimel for DevOps Chat and we hope to see you soon on another DevOps Chat. Have a great day, everyone.
A transformation can’t come from simply changing some tools or tweaking some antiquated processes to create improved collaboration. This is ultimately setting yourself up to fail. The magic comes from creating a universal change. You want to just improve your DevOps teams? Why not improve your entire organization? Be dramatic—organizational opposed to departmental. It sounds long and hard, and it will be. But ultimately, many companies must disrupt themselves to survive.
Among many other benefits, DevOps breaks down the walls between development and operation teams. But what about the other walls? We (almost) got rid of cubicles and separate offices a while ago. Now, the walls between the wider teams must also come down to become a modern organization.
Change is OK. It’s necessary, it’s powerful and it’s now. Change is about stepping out of our comfort zone and working on new and efficient ways to collaborate, all while bringing new processes and modern technologies to compliment the needs.
“Our only security is our ability to change.” — John Lilly
Take risks or die not trying. In a world of change, we can take a few calculated risks along the way. The status quo has changed and we are continually driving collaboration and communication. When the people get together ideas are born. Let’s give those ideas a shot.
“It is not necessary to change, survival is not mandatory” — Edward Deming
Agilityacross the business. Allocate guilds within the teams to continue to develop and foster this new change of culture. Focus on connecting one small team to another to start, rather than conquering the world, and then roll out to more and more teams over time.
“Success today requires the agility and drive to constantly rethink, reinvigorate, react and reinvent” – Bill Gates
Hire the right mindset and not the right tools. The winning hires are the people who join your organization not just to implement some fancy new orchestration tool and automate a few processes, but those who come in with the “multiple hats” mindset. In DevOps, job titles mean less. An implementation and automation engineer is more than just an implementation and automation engineer. The quicker you understand that, the better your DevOps hires and transformation will be. Here’s a great article from my friend Conor Delanbanque that offers more insight on scaling teams.
“If you don’t understand how to run an efficient operation, new machinery will just give you new problems of operation and maintenance. The sure way to increase productivity is to better administrate man and machine.” — Edward Deming
Constant feedback is necessary. As part of a successful transformation, feedback to the business must be considered as important as the feedback during all phases of continuous integration, testing and deployment. I have seen many successful transformations in which the business side has been actively involved to ensure feedback was effectively passed along to other teams and departments within the organization.
“I think it’s very important to have a feedback loop, where you’re constantly thinking about what you’ve done and how you could be doing it better.” – Elon Musk
Both development and operations teams are popping up in enterprises all over the world, and even though DevOps programs are still in the early stages, our ultra digital world calls for even more software applications. This is why many analyst and consultants alike believe that, in the near future, DevOps will be even more powerful than legacy IT. DevOps will be something businesses of all sizes will not be able to live without and the sooner you initiate the DevOps transformation, the better.
Why DevOps Transformation?
One of the most exciting aspects of DevOps is enacting technology practices and architecture that help organizations create an agile and continuous product flow, from development to testing, operations and all the way to deployment while increasing stability, reliability and security at the same time.
More importantly, adopting DevOps can enact changes in the culture of your business, such as allowing teams to work more quickly with more independence. Back in the days before DevOps, deploying even a minor update, upgrade or bug fix would involve literally hundreds of developers doing weeks worth of work.
Today’s top-performing businesses and DevOps adopters are deploying much faster, and the products they release generally have greater reliability. Still not convinced that DevOps is the holy grail? Consider the following.
Focus on Speed, Not Cost
Do you want to achieve the same capabilities of Amazon and Netflix? Of course! Who doesn’t? It’s easy to make an excuse that they have a lot of money to spend, but, when we look deeper, companies that achieve DevOps success are more focused on optimizing speed, not cost. Organizing and optimizing for cost creates functional silos for networking and database people, server admins and many others.
When you optimize for speed, you are willing to cultivate talent from within, increase engineers’ salary and send them to conferences. You would not necessarily do these things if you were simply optimizing for cost. There are a whole bunch of techniques we can use to optimize for speed, such as using small, cross-functional teams that can deploy value to the customer independently without having to rely on hundreds or, in some cases, thousands of people.
Best of all, you don’t have to be a big conglomerate to make this transition. Even small and medium-sized businesses can choose to optimize for speed, break down silos and get their product to market faster. After all, this is what DevOps is all about.
Software Speed vs. Quality
Businesses that rely on developing and deploying software to support or supply their customers often are faced with choosing speed or quality. If you go to market before your competitor(s), you could be cutting corners in terms of testing and quality assurance, which can ruin your launch. However, if you wait until your code is perfect, you could end up lagging behind in the race for the next big breakthrough. Fortunately, the DevOps approach can resolve this dilemma while improving the bottom line.
Way back in 2015, the “State of DevOps Report” collected the DevOps health and habits of more than 20,000 tech professionals and found that top performers using DevOps show more agility and reliability in their releases and they were twice more likely than non-DevOps users to exceed productivity goals. In the roughly 800 companies that had a stock ticker symbol, the top performers had an almost 50 percent higher market capitalization growth over three years. This indicates that DevOps is great for IT performance as well as organizational performance.
What everything boils down to is that all modern businesses are increasingly more reliant on technology when it comes to acquiring new customers and bringing value to those customers. It is becoming increasingly apparent that agility and speed are key attributes for companies who want to win in today’s marketplace.
DevOps Transformation Guide
With all of the benefits listed above, you are probably eager to get started with DevOps. Here is a simple step-by-step guide to assist you in your DevOps transformation.
Conduct an Enterprise Readiness Audit – The highest probability of a successful DevOps transformation is when it is championed from the very top. The participation of business leaders is just as vital as operations, security and development teams. To get everyone on the same page and to ensure that your DevOps transformation gets off to a good start, seek assistance from an experienced, external consultant or coach. The purpose of this first step is to get executives to buy in, create mutual goals and get an understanding of what an Agile-DevOps program looks like.
Create a DevOps Center of Excellence (CoE) – One of the most important things you must do here is designate an Executive DevOps lead with enterprise authority. There is no use in creating this Center of Excellence at the incorrect organizational level. It must be spearheaded by someone who has the support and trust from all branches of the organization including delivery and vendors.
Create a Program Governance – Such a program will include creating a communications plan, an enablement program as well as establishing program KPIs. In terms of making a cultural impact on your organization, this is perhaps the most important step. The roles and responsibilities of practitioners will change with Agile and DevOps and it is vital that they understand collaborations between structures where historically animosity could have existed so they can break down these organizational silos. The KPIs will also need to be transitioned from individual metrics to holistic customer business results.
Create a Project Intake Process – Project intake really sets the tone for how successful each new sprint that comes into the program will be. What matters here is not the tools and process, but rather the proper sizing of the tools and process. There is a need to fit for purpose when selecting accelerators, toolchain and development methods. Once it is created, the communication of the intake process needs to be disseminated across the organization. Keep gathering feedback and and continuously evolve and mature based on this feedback.
Identify and Initiate Pilots – To achieve the highest probability of success, apply this step to a specific portfolio of applications or a domain solution. The purpose here is to create a value-stream map of a specific application with company wide participation on all levels. This needs to be done with the necessary amount of detail to identify manual and automated processes, end-to-end process tooling and the people and skills that are involved.
The next aspect of the intake project is the collaboration between the subject matter experts from the Center of Excellence with the project team. The goal is to advise on “to-be” processes with proper tooling, reusable assets and automation. As the application goes through the development and test cycle, be sure to identify and capture the KPIs for the program in order to compare with existing KPIs.
Scale Your DevOps Program – This final step involves taking feedback from the pilot metrics and scaling them by taking different application portfolios and running multiple release trains. It is not enough to merely do automated deployments and daily builds. The last, but by no means least, piece of the DevOps puzzle is constant feedback and optimization.
Key Takeaways
To keep up with top-performing businesses and stay alive in today’s ultra-competitive, fast-paced environment, implementing DevOps is an absolute must. DevOps is not solely reserved for giant enterprises such as Amazon and Netflix and can be implemented in any-size organizations.
In the not too distant future, DevOps will become something businesses of all sizes will not be able to live without. To reap all the benefits DevOps has to offer, the sooner you make the transition to DevOps, the better.
With DevOps, there is no longer a reason to choose between speed and quality when deploying your software. When implemented properly, DevOps will allow you to deploy software with both agility and reliability increasing your customer base and the bottom line.
The step-by-step approach mentioned above can and should be implemented in any flavor and variety that best suits each individual organization’s needs and constraints. Pay particularly close attention to large gaps or excessive deviations as they are red flags which will need to be corrected.
About the Author / Stanislav Ivaschenko
Stanislav Ivaschenko is a certified AWS solutions architect at Squadex with more than 10 years of professional experience in building, delivering, supporting and optimizing a broad range of software applications. From bare metal to the cloud, from monolith architecture to microservices his expertise and experience help to meet business needs for startups, mid-sized companies and large enterprises. He has experienced a large number of DevOps and infrastructure related tools, services and management practices.
The 4th annual DevOps Enterprise Summit (DOES) in San Francisco this week was, in my opinion, the best one yet. Lots to report about, but I wanted to call out a new trend I am seeing that I call the DevOps Cha-Cha. You remember the Cha-Cha: three steps forward, two steps back, cha-cha-cha. Actually besides being a great dance with the right beat, that same three-steps forward, two-steps back is about what you would expect from large enterprises that are undertaking profound digital transformations.
I say that this is normal because, despite all the great firsthand accounts of DevOps transformations on display at DOES this week, there was a bit of a whispered undercurrent. More than several people I spoke to talked about the fact that “this DevOps thing isn’t that easy.” Others spoke about the large number of “failed DevOps transformations or implementations.” Obviously, as the editor in chief of devopsy.kinsta.cloud, I might have a skewed view of this, but let me put in my 2 cents and then some on this subject.
DevOps Transformations Are Not Easy
First of all, no one ever said DevOps transformations would be easy. I’m not sure why anyone would even think that. Changing cultures can be gut-wrenching. Sometimes it means replacing people who just can’t wrap their heads around a new culture and way of doing things. Other times it means ripping up the way people and teams interact with job roles and positions. Change is never easy. Frankly, if it was easy, everyone would have done it already. That is just the cultural piece. Imagine coupling that with new tools, new processes and new ways of building, testing and deploying software. Again, I’m not sure why anyone would think such an undertaking would be easily accomplished.
Is anything truly worthwhile ever that easy, though? The real question is, Is the pain and trouble worth it? If you were at DOES this year or have read other success stories around DevOps and digital transformation, I think you will find the answer is, “You bet it is.”
If you go into a DevOps transformation thinking it is going to be easy, you are setting yourself up for disappointment. Doing DevOps is not just a matter of being one of the cool kids on the block or trying something new for kicks. It means you are dedicated to seeing it through. It means you are going to think through, plan, learn and do what needs to be done.
Failure Is Not An Option
Also important to keep in mind—and this is really the meat of it—is that DevOps transformations shouldn’t and don’t proceed in a smooth linear manner. While at a macro level over a period of time you should be able to discern progress (depending on how you define progress), when you drill down you find fits and starts, steps forward followed by steps backward. There also will be steps sideways and sometimes no steps at all in any given moment. But like life itself, that is how DevOps transformations go.
I was speaking with someone at DOES (I don’t remember this moment who), who told me every business plan they had ever seen had revenue growth like a hockey stick—just straight up on sharp angle. The same is true for the benefits realized in every DevOps transformation plan. If only DevOps and life worked that way. It is the rare bird that has shows a revenue line that is straight and angled that way.
Real life is filled with starts and stops. You learn from your mistakes; you get it right the next time. Sometimes you need to take a step back to take more steps forward. DevOps is no different. It is not homogenized and doesn’t always (if at all) proceed smoothly. The real test is whether over a longer period of time you are achieving your goals (did you even define your goals or just thought DevOps would fix everything?). You can’t look at any given moment or event and say, “Our DevOps transformation was a failure.”
Your DevOps transformation is only a failure if you end it before you get started, or before you can overcome the roadblocks in the way. At its heart DevOps means we keep improving. Think of those failures and feedback loops. You do your post mortem, you learn from your mistakes and you keep plowing ahead. It is only a failure if you let it be one by stopping.
The DevOps Cha-Cha
In my opinion, you look at your failures during your DevOps transformation and you make lemonade from those lemons. You learn from them and keep moving forward, one foot after another. Imagine a hot Latin beat in your head. Start moving, one, two, one-two-three, one, two, one-two-three, that’s it—now you’re doing the DevOps Cha-Cha. Keep the beat, keep dancing and keep doing DevOps.
More DOES Coverage
If you are interested in hearing what some of the speakers, attendees and sponsors of DOES 2017 in San Francisco have to say, be sure to visit our DevOpsTV YouTube channel, where we have a DOES San Fran 2017 playlist. There are about a dozen videos up there now, but will be adding to that every day as editing completes.
As DevOps Enterprise Summit San Francisco (DOES17), slated for Nov. 13-15, inches closer, event founding partner Electric Cloud hosted a special episode of Continuous Discussions (#c9d9), featuring some of the conference speakers. During the discussion, the speakers shared some of their recent DevOps transformation stories and a bit about what to expect during their talks at the conference.
The panel included:
John Esser, senior director of IT and data center operations at AdvancedMD;
Gary McKay, scrum master at Somos;
Aloisio Rocha, agile product owner at NetEnt;
Manish Aggarwal, software engineering manager at Intel;
Marc Priolo, global software configuration manager at Urban Science;
J. Paul Reed, managing partner at Release Engineering Approaches;
Marc Hornbeek, principal consultant – DevOps at Trace3;
Gary Gruver, founder and CEO of Gary Gruver Consulting; and
our very own Sam Fell and Anders Wallgren.
Here is a list of the most memorable takeaways from the discussion:
Every company is different, so approaching a DevOps transformation will vary based on the organization, explains Esser. “Every company has a different set of constraints, a different culture, different things they value. So you can’t just say, ‘Oh, I’ve got this DevOps hammer, and I’m going to start pounding away.’ We understand the principles, but how to apply those and how to execute those principles are quite different.”
McKay on the success of moving from mainframe to microservices with his “Team Dragon” concept: “Team Dragon was formulated to make sure that our CI/CD process as well as our deployment and release processes were consistent. Coming from a mainframe environment to, say, a distributed microservices environment, there are differences not only in culture, but processes and technology. We wanted to make sure all that was managed efficiently and effectively, so that we could do deployments when we needed to do deployments.”
Rocha on the NetEnt DevOps journey and what inspired the transformation: “We’ve gone from a place where the business was expanding, but deployments and deliveries were not scaling with the business to working on how to tackle it with automation, working with the deployments and making the deployments visible to everyone.”
Aggarwal will be talking about the DevOps journey at Intel at DOES17: “I will be covering as to how a lot of organizations, including Intel, are trying to board the journey of DevOps. They are successful to an extent, but how to make sure that the quality, which is the sole purpose of this journey, does not get left behind.”
Priolo on his pipeline-as-a-service strategy: “We have a pipeline-as-a-service strategy. That’s where we want to make sure that our developers can concentrate on developing instead of trying to figure out how their code is getting into our production environment.”
Gruver’s simple advice on starting your DevOps transformation: “In the beginning, you need to create some positive momentum. You need to find the things that are the most broken in the development and deployment operations. You need to highlight them. You need to get them fixed. Then you need to market those changes, so that you get some positive momentum for the transformation.”
Don’t forget about the human factor of release engineering, says Reed: “[At DOES17] we’re going to be going through a little bit of the human factors that are related to release engineering. There’s a couple of facets of that. It’s sort of, ‘How do you go about doing the work,’ and then also a bit about how we treat others, the net system.”
It’s important to include all teams on your transformation journey, per McKay: “The secret is inclusiveness. Making sure that the mainframe team is part of the microservices process and making sure that we, in our haste to get things done very quickly and very effectively, make sure that we bring them in. We make sure that their roles are purposeful and that they’re part of the process and not just, ‘Oh, you’re just some mainframe guys. We’re just going to ignore you.’”
Esser on the core values of DevOps: “DevOps as a whole is not limited just to an architecture. DevOps, at its core, is about working better together and increasing the flow of value across the whole value pipeline.”
It’s important to find the right balance between allowing your developers to be unique, but also adhering to the rules, says Priolo: “The real challenge is trying to find out a way to allow developers to still have their snowflake ability, while still complying with the standards of the company. It’s not to make everything stringent and follow the same exact path. It’s to create a pipeline that gives them the flexibility, but still gives us the ability to do auditing, to make sure that the code is being checked at its proper place.”
Sometimes it takes a big mistake or bug to make you realize you need DevOps, explains Rocha: “Our process was intense before, to say the least, especially when some scary bug came or a heavy compliance requirement came in that we had to fulfill in a short amount of time. That made us realize we have to fix this.”
Wow – Aggarwal’s team at Intel went from almost complete manual testing to 100 percent automation in seven years: “When we started about seven years ago, 99 percent of our testing was manual, and everything was repetitive. The work was getting more challenging, and the sheer amount of it was growing with every release. So it was very important to bring that under control. The only way of doing that was end-to-end automation. When I say, ‘end-to-end,’ it’s not 99 percent. It’s 100 percent totally touchless automation.”
Reed on the human factor of versioning: “Versioning really is about humans communicating with each other. They’re trying to encode information into that version number, which is, I think, one of the reasons you see people bikeshedding that a lot.”
DevOps can expose your longstanding problems, says Gruver: “When you start trying to increase the frequency of build/test cycles or deploy cycles, you see inefficiencies repeating. You see the trends. There’s a bunch of tools in the DevOps toolbox that enable you to go after that.”
Moving from monolith to microservices is not an overnight transition, explains Wallgren: “Time and time again we hear the difficulties that everybody has with legacy applications or monolithic applications. The transition away from mainframes is not an overnight kind of thing. They’re not going anywhere, anytime soon.”
There’s still value in mainframes, and getting that to customers is key, explains Fell: “There’s a ton of value locked up in mainframes and being able to get that out to other people in a service-oriented sort of way. It’s a hard migration to do, but that cultural aspect of making teams feel like they’re comfortable working with one another is critical to getting through that part of the process.”
Watch the full episode:
About the Author / Anders Wallgren
Anders Wallgren is chief technology officer at Electric Cloud. Anders has over 25 years’ experience designing and building commercial software. Prior to joining Electric Cloud, he held executive positions at Aceva, Archistra, and Impresse and management positions at Macromedia (MACR), Common Ground Software, and Verity (VRTY), where he played critical technical leadership roles in delivering award winning technologies such as Macromedia’s Director 7. Anders holds a B.SC from MIT.
DevOps is not necessarily a “natural” process. Asking people to function outside of their comfort zones and prescribed roles is a challenging task for any organization, and requires a shift in organizational behavior. At Trace3, we believe that while DevOps is not natural, a supernatural result is achievable with the right cultural transformation supported by good tools that drive collaboration and automated flow between people and tools in the application delivery workflow.
We define DevOps as the application of the principles of continuous flow, feedback and improvement to people, process and technology for increasing agility, stability, security, efficiency, quality and satisfaction. Or, to quote from Michael Schmidt’s article, “Ten ways DevOps will benefit your IT department“: “When implemented properly, DevOps can transform your software engineering process and create value for both employees and customers, producing business performance and value.” These are huge “supernatural” benefits that every business would like to achieve.
Implementing DevOps properly is challenging. DevOps depends on collaboration; smooth process flow from conception through deployment; and feedback between people, processes and technologies. It’s more natural for people and departments to hoard information and centralize control—traits that are contrary to DevOps best practices. People tend to trust their own abilities and are skeptical when they need to trust dependencies on others. People view competition with others as a means to personal advancement. Compounding this, organizations often manage, measure and reward success at the silo level instead of recognizing a successful delivery as a result of successful execution across the end-to-end DevOps value stream.
Breaking down silos through transparency and the free exchange of information helps organizations implement the unnatural DevOps processes needed to achieve supernatural results. Fortunately, the transformation is assisted with technology. For example, continuous automation tools liberate sharing of infrastructure, application and compliance information. Pauly Comtois, Hearst’s vice president of DevOps, describes the role of strong tooling in successful DevOps transformations in his article, “Enterprise DevOps at Hearst Digital Media“: “Tools can be an incredible asset in this regard. We deploy Chef across multiple teams in the value stream, automating the deployment, configuration and state of environments in Dev, QA and Production.”
In scenarios such as the example above, tools support integrated and automated processes for builds, configuration, infrastructure and deployment management. Information managed by continuous automation tools is available for DevOps uses by providing a single “public yet controlled” source of truth for configuration data useful by all processes and tools in the toolchain across the end-to-end pipeline. Those who were concerned and hoarded configuration data can trust that the tools will keep the information secure, reliable and available on demand as readily accessible code.
Moving beyond the natural behavior of organizations and individuals is difficult, but success can create supernatural results for long-term growth and team effectiveness.
Stanislav Ivaschenko is a certified AWS solutions architect at 
Anders Wallgren is chief technology officer at Electric Cloud. Anders has over 25 years’ experience designing and building commercial software. Prior to joining Electric Cloud, he held executive positions at Aceva, Archistra, and Impresse and management positions at Macromedia (MACR), Common Ground Software, and Verity (VRTY), where he played critical technical leadership roles in delivering award winning technologies such as Macromedia’s Director 7. Anders holds a 