devopsy.kinsta.cloud

Tag: business culture

How Systemic Approaches to ITOps Impact the Business Culture

We are at an inflection point in the rise of big data. Enterprise IT infrastructure is producing data at a scale like the world has never seen before. IT operations (ITOps) management has accelerated past the notion of data storage and processing (vis a vis the Hadoop model) and into the world of analytics-as-a-service. We now need systems to drive insights and manage change on-demand. In fact, we need a new operating model for IT in the face of these new effects.

Can a New System Save Us?

The key to transforming into a responsive, data-driven enterprise—while avoiding a flood of unnecessary processes and over-staffing—is to adapt automation to intelligently consolidate information flows. At the same time, the dynamic nature of today’s IT environment requires IT teams to become literate in a completely new approach to technology, one that spans all functions of the business. Consequently, risks that previously stayed inside organizational units now leak across domains, influencing decision-making for the entire company. These factors will try to pull the organization in multiple directions at once; only a unified data management system with the intelligence to extract operational insights can drive positive business change.

Culture Has Got to Change, Too

Agile processes such as DevOps and AIOps offer mechanisms to control the flow of data and turn it into actionable results. For example, continuous application development and deployment gathers data about functional use, user sentiment, efficiency and various other metrics to inform the overall process and improve the product. Such rapid dev cycles let organizations identify and fix issues more quickly and with fewer resources, ultimately delivering greater business value.

The resulting streamlined collaboration among IT, development and customer teams improves capabilities but also introduces dependencies that must be managed effectively. It changes the culture to adapt to the system, and thereby, the system of service delivery will fundamentally affect how organizations are structured, built and run. Eventually, there will be increased digitization of every human process, and that means human impact slowly will be replaced by AI impact. This doesn’t mean that machines are coming to take our jobs; instead, it means the modern enterprise IT organization must address a new future. How will it look?

Retraining and Reskilling Is a Fact of Life: In a world of dynamic IT, requirements are no longer static, and teams need to be prepared. Organizational units must be able to work in different ways with new technology, with new skills that include robotic emotional intelligence, cloud-native literacy and infinite adaptability.

System operators become stewards of the business because system operations directly impact business outcomes. It won’t be enough for workers to merely deploy, configure and manage IT while isolated from the goals of the company, because those goals are inextricably linked to how objectives are achieved through innovation. Employees will need to develop new skills for functioning in a dynamic system. Training staff in agile methodologies, service-oriented software design and six sigma-style approaches for process improvement will become critical for success.

Automation Is Everything: Automation by policy won’t be enough; even runbooks will become obsolete. Data and results are always changing, so simple automation will not drive meaningful change. AI can be used to drive automation policies and frameworks, with the potential to reduce errors and integrate disparate systems, which previously required multiple points of oversight.

The trend toward using AI for data understanding is driving intelligent services into other parts of the business, as well. Rather than just for correlating system and operational data, AI is being adapted to business process optimization. Moving forward, IT operations can begin to run themselves, led by deep data analytics. Alerting and response processes automatically will use their own feedback to update the system’s intelligence, identify emergent trends and take actions to deliver improved operational results.

Risk Becomes Universal: Increasing connectivity and generalized frameworks (such as DevOps and site reliability engineering) mean that risk is no longer siloed to one department or function. It’s spread everywhere, and cascading effects become commonplace.

In general, successful engineering outcomes rely on coordinated processes and policies that dictate operational needs, even after deployment. Introducing connectivity between formerly disparate systems can create instability that potentially affects operations in other unintended areas. Thus, broad risks arise if different systems can’t interoperate once unified into a single IT ecosystem. Addressing requirements under a generalized framework helps prevent gaps between application implementations.

The System Drags the Company Forward: Insights-driven action will transform digital business well in advance of executive priorities. Change will happen before anyone is ready. Indeed, with so much complexity, so many tools and processes and so many competing business demands, IT changes now impact culture in entirely new ways.

Business impacts will come from system intelligence rather than manual processes. Efficiency in operations management is derived from the entire system, including the people themselves. What was previously the IT culture is rapidly being replaced with a combination of self-adapting processes and workers who focus more on value than on plumbing.

Transforming the enterprise from silos into integrated platforms will propel the business forward. The resulting system will also drive cultural change at an accelerated rate, perhaps faster than the worker community is prepared to accept, but informed by real data instead of executive intuition.

— Bhanu Singh

June 24, 2019
Want a Successful Software Build? Just Say No

It is a truth which should be universally acknowledged that the most important skill for a customer-facing job in what we laughingly call “information technology” is a cast-iron ability to say no—and make it stick.

The misguided desire to please other humans by attempting to deliver on their every request has sunk more projects than any units mismatch or catastrophic misconfiguration—even more than the justly feared Friday afternoon deployment.

The key to success is an agreed definition of what success is, and how we will all know and measure whether we have achieved it. Let’s take the car as an example.

French Cars Have Always Been Weird

These days, we would consider a car to be woefully unfinished if it were lacking upholstered seating for at least four adults, a roof and windows to keep the elements out and some form of in-car entertainment—an FM radio as a bare minimum, probably a CD slot or USB socket as well. This is on top of seat belts, airbags, anti-lock brakes that are probably power-assisted and more lights and safety features than you can shake a stick at.

Nicolas Cugnot did not bother with any of these features. His design didn’t even have four wheels. It not only didn’t have an airbag in the steering wheel, it didn’t even have a steering wheel. It was controlled with a ridiculous tiller arrangement that unsurprisingly completely failed to catch on. And yet, his vehicle was a success by the stated criteria of the project: It made it much easier for the French army to haul ammunition around.

Nicolas Cugnot’s steam dray from 1769

Admittedly, he was also lucky enough to be constrained by the technology available to him. Even Louis XIV might have balked at adding a four-piece chamber ensemble to provide an appropriate musical soundtrack for the driver. But the key point is this: Monsieur Cugnot stuck to his brief, and concentrated all his efforts on the features necessary to achieve it.

Bringing Apple Into It

In somewhat more recent times, we have Steve Jobs (emphasis mine):

People think focus means saying yes to the thing you’ve got to focus on. But that’s not what it means at all. It means saying no to the hundred other good ideas that there are. You have to pick carefully. I’m actually as proud of the things we haven’t done as the things I have done. Innovation is saying no to 1,000 things.

One reason why Steve Jobs is so famous is that he actually said those thousand nos—often loudly, rudely and profanely. Steve stands out in IT because most technologists have an irrepressible instinct when faced with a question to start to speculate about it, bikeshed possible solutions, build a quick minimum viable prototype and, before you know it, you are armpit-deep in feeping creatures, all of which you are now somehow responsible to nurture and feed. Not being a technologist himself but more of an ideas person, Steve was perhaps better able to take a step back and focus on the end goal.

Let’s Get Concrete

Now, this should not be taken as a license to adopt all of Steve Jobs’ methods (Lesson One: Be a complete arsehole to absolutely everyone in your life), if for no other reason that even Steve got fired for it, and from the company he founded at that. When someone comes to you with a request for just one leeeeetle feature, you and I probably can’t get away with screaming “NO!” and slamming the door in the requester’s face. The polite and career-prolonging way to deal with the problem is to ask, “Why?”

Ideally, in the process of explaining the rationale for whatever the request is, some other solution to the problem will be identified. A good way to improve the odds of this happening is to involve other people in the discussion. Extending the audience in this way creates opportunities for someone to interject helpfully with something along the lines of, “but Carol, we have a perfectly good hammer over there; why are you trying to use a screwdriver to batter a nail in?”

Sometimes, you may need to adopt an iterative approach, which sounds impressive, but simply means waiting until the end of the first explanation, nodding thoughtfully, and then asking, “Yes, but why?” Among people who watch more television than me, this is known as the Columbo approach: “Help me understand, what is it you are trying to do here?” and just keep doggedly repeating the question. Eventually enlightenment will arrive—or the requester will get tired and go away, which is also a perfectly valid win condition.

This method will also help with the tricky situation where the most important question is the one which is not being asked. There is often an implicit question behind that one, where the solution is not to give a glib answer, but to think critically about the proposed or effective solution and ask the questions yourself: “Why are we trying to solve for this?” Or, “What is this thing you are proposing actually meant to do?” And finally, “What was the original problem, anyway?”

People have a tendency to focus on the issue that is right in front of them, even when the real problem is in an upstream step of the process. They observe or experience something about X as the identified problem, and so default to solving for X directly without considering the broader landscape. This leads to convoluted, inefficient and often high-friction solutions—Rube Goldberg/Heath Robinson machines (delete as appropriate to whichever side of the Atlantic you are on), where a simple connecting pipe is all that is required. An artillery piece will make holes in the ground, but there are a couple of collateral impacts you may want to consider—and maybe offer a spade instead.

All I needed was somewhere to plant some flowers!

Unfortunately even the Columbo Method is not entirely guaranteed to work, because on some rare occasions the underlying request is actually valid and cannot be summarily dismissed. This is when you bring out the big guns and start ranking the urgency of what was already agreed as the scope of the project (a nail hammered into the wall sturdily enough to support that lovely picture) as opposed to what is being requested (a fully motorized picture rail, capable of supporting up to 10 paintings on the scale of Guernica and turning them to optimize lighting conditions throughout the day while also keeping them out of direct sunlight). Nobody is saying that the second option would not be nice, but it certainly won’t be done in time for supper.

And that, children, is how you say No. Go forth, and do ye likewise, and may all your projects be huge successes. And, most importantly, not require me to come in and clean up after you.

— Dominic Wellington

January 16, 2019
Reigniting Business Culture: Is Marketing Crippling DevOps?

DevOps, as we understand it, is a set of protocols and value-systems that enable development and operations teams to work in perfect harmony within an organization. Surveys of DevOps response teams reveal that the strategy of building bridges between developers and marketers has helped organizations speed up software release cycles, improve product quality and augment platform security. We know for sure that DevOps improves performance, strategic outcomes, company productivity and, more importantly, the product’s market share. But there is a glitch; apparently, everything isn’t as rosy as we imagined it to be.

There is the elephant in the room, a problem that lurks in the background, an issue that refuses to go away. It would appear that there is a growing chasm between Marketing and DevOps that businesses are struggling to bridge. Some voices would say that developers are opposed to the traditional ways of marketing and the “My way or the highway” attitude that marketers sometimes adopt, which is not conducive to collaboration. Far from helping organizations work harmoniously, is Marketing killing the golden goose of DevOps? Are we in desperate need of reorienting our business culture?

Miromind’s SEO strategist Agnieszka Podemska believes the growing impact of technological change has made it obligatory for developers and marketing professionals to meet on a common platform. As the DevOps methodology takes control, marketers are increasingly joining the conversation and influencing the outcome, and this need not be the friction-ridden, nerve-jangling process it is made out to be. Let’s come to terms with the role-playing we see in the DevOps arena.

DevOps needs marketers to collaborate and provide access to policies for determining the thrust of business growth. If marketing aims to improve the user experience and customer satisfaction levels, marketing needs DevOps to create a strong and reliably efficient IT backbone to facilitate that experience.

The developer working in backroom isolation would be far removed from the battlefront where the customers are changing preferences and deciding product choices at a fast pace. For developers, it’s easy to lose track of what fulfills customer intent most effectively. Without regular feedback from marketing and sales teams, developers wouldn’t know how, when, and where functional gaps need to be plugged to improve the user experience. At the same time, marketers must become aware of what is engaging the developer’s attention so that a coordinated effort can be railroaded to smooth out product promotions and software rollouts.

Whatever misgivings marketers and DevOps teams may harbor regarding each other, both are locked in a mutually interdependent relationship in which cooperation and coordination are necessary to achieve business goals. Can we prevent marketers and DevOps teams from working at cross purposes? Yes, it’s possible if we’re clear regarding the principles and the culture promoting successful business growth.

Marketing and DevOps Can’t Function in Isolation

Marketing and DevOps are like two sides of the same coin that rings the cash registers in business growth. Their aims are the same. If Marketing aims to bring in new customers and plan strategies to target specific audiences, developers will focus on improving the product and speeding up delivery so that customers enjoy a friction-free user experience. This is a symbiotic relationship where the guy promoting products and reaching out to customers is as critical as the dude deploying customized code.

You need Marketing to promote the software and an efficient sales team to improve the customer’s interaction with the product. The paying customer doesn’t stop at engaging the product; they’ll want to talk about it. The marketer will go social, they’ll go mobile, hold webinars, and host trade shows to forge a deeper connection with the paying customer because it’s not just about acquiring customers but of retaining customer loyalty to the brand. The point is that Marketing can’t do this in isolation; Marketing needs IT support and services that only DevOps can guarantee.

Software Development and Product Marketing are Symbiotically Wedded

In every aspect of business development, the software release cycle and sales funnel are mutually interdependent. When Marketing promotes products across social media and blog posts, and through channels such as emails and press releases, every software update launches simultaneously to enhance the user experience across all platforms.

Strategic partnerships lubricate business growth, and partner programs and reseller programs are automatically updated by DevOps to ensure that the product is shareable with prospective customers. Each software update can be programmatically controlled as Marketing gathers and shares customer feedback. DevOps can leverage these insights to improve services.

Marketing feedback is the driving engine propelling software development, and every feature request or design change improves customer satisfaction. It’s possible to make a significant improvement in customer fulfillment levels only if Marketing and DevOps work in tandem.

CRM Optimization Peaks When Marketing and DevOps Collectively Analyze Data

Predictive data analytics is a hugely collaborative endeavor where Marketing and DevOps teams need to get their act together. With the help from IT-driven automation, it should become possible to organize and view data regarding the customer’s browsing history and how frequently the customer interacts with the product. The consumer database mutually analyzed lays the foundation for formulating policies that promote customer retention and sales growth.

The DevOps team should make it possible for customer relationship managers to view consumer usage and responses in real-time so that the feedback enables more satisfactory support solutions that enhance upselling options.

Marketers essentially breathe content and life into digital ads aiming to multiply the number of paid users over time. DevOps, having built the product from scratch, is more aware of the product’s USP and can give a positive direction to marketers regarding the message that is conveyed to the consumer.

What DevOps Ought to Be Telling Marketing: ‘We Believe in You’

A common perception among DevOps members is that Marketing really doesn’t comprehend what the software is capable of doing. What DevOps needs to understand is the consumer is not as focused on the thrills and spills of the cutting-edge software that is packaged and presented to them. The consumer is more concerned about how the software can benefit their business.

If consumers are not personally invested in the product and do not see something that is customized to solve their business issues, they’re least likely to buy the product. This is the reason why Marketing focuses a lot on tailoring the message to fit each demographic to fulfill a specific need. The message may not match the expectations of a developer, but it might indeed be what a customer wants to hear.

For DevOps, testing or updating any kind of software involves strict adherence to a protocol of rigorous standards. The same approach can’t be expected of Marketing. Marketing is more invested in imagery and the message, which may differ drastically when different types of consumers are approached. In Marketing, strategies may change by the hour, if only to understand how different audiences resonate better with the product.

This is where DevOps and Marketing ought to be communicating with each other through all stages of the sales funnel. If, for example, marketing is leaning heavily on mobile software but that happens to be the weakest link in the chain, it is for DevOps to step in and suggest features that deliver more value for the consumer.

What Marketing Expects From DevOps: ‘Plug the Weaknesses and Play to Our Strengths’

Improving Marketing-DevOps relations is vital to any growing businesses. Marketing can’t stop at tabulating requirements and then leave it for DevOps to come up with the perfect solution. The Eureka moment in software development comes only when marketing hand-holds DevOps through each stage of the development process. For example, marketing could become more involved in user model testing.

DevOps knows the strengths and weaknesses of the software; Marketing is better aware of the audiences’ needs. Both teams have access to predictive data analytics that tracks consumer behavior concerning the product that is being improved. If Marketing can pinpoint user models that are not likely to work in a real-time situation, that model can be rejected at the drawing board. Proper communications and effective collaboration mean that the consumer is less likely to be presented with a product that promises a lot but delivers far below expectations.

Conclusion

If the universe of product acceptance and consumer satisfaction is like a gigantic jigsaw puzzle, Marketing and DevOps are the pieces that have to lock in place harmoniously to complete the picture. If parts go missing, it will show by way of an inferior product.

Even if their priorities differ, both Marketing and DevOps have to work in harmony to fulfill business objectives. Mutual trust and communication are two vital cogs that turn the wheel of progress and business growth.

The future will be molded by teams of DevOps, Marketing, and Sales that work together, aggressively analyzing consumer feedback to deliver user experiences of high quality consistently.

What marketers and developers should be asking themselves is, “Am I a Lone Ranger riding off into the sunset?” or, “Am I a team player guiding the company through wild terrain, conscious that there’s a destination to be reached together?” The answer determines your business trajectory.

— Josh Harisson

December 4, 2018
Executive Buy-in May Be Preventing DevOps Success
A common misconception in the executive suite is that an organization can reap all the benefits of DevOps without fully embracing the change necessary. That’s understandable, given that a DevOps transformation is a lengthy, costly disruption for companies of all sizes. DevOps requires businesses to transform, from team organization to culture to development processes. This shift often sparks reallocation of power and influence, which sometimes can make high-level executives uncomfortable. While most companies have begun to recognize the overall business benefits of DevOps, few are fully committing to such a large undertaking. As a result, a hesitant executive suite holds an organization back from realizing the full potential of DevOps.

The key to successful DevOps implementation has four facets. Executing against one element just isn’t enough—an organization must combine all of them to realize the benefits of DevOps:
- Training: Once executives have educated themselves on the importance of DevOps and accepted the disruption that comes with it, they must make sure the individuals are properly trained. Everyone involved needs to be open to learning new skills and new ways of functioning. A big part of DevOps is breaking down team silos, so individual contributors need to be willing to work across functional boundaries.
- Tools: DevOps adoption can be viewed as a cultural and methodological change, and therefore teams also need the right tools that help them work together to create scalable and secure applications efficiently. The executive suite should invest in platforms that support automation and collaboration.
- Support and determination: To provide support and guidance throughout the shift to DevOps, organizations should consider hiring a DevOps expert or bringing in a third-party consultant. This person can help the executive suite map out a DevOps strategy and help train the teams involved. Lack of expertise is one of the reasons businesses often fail to complete a DevOps transition.
- Cross functional and accountable teams: A DevOps team should have all of the resources necessary to implement and deliver functionality to the customer. They should also be accountable for operating and supporting it.
Another important consideration is security. The CISO and security team are responsible for security in most organizations, but developers need to understand the critical role they play in creating secure applications. They need to be accountable for the security of the software they write. It’s up to the security team to train and nurture them until they are self-sufficient. The development organization as a whole must be willing to make security part of the annual goal-setting process and to report on progress transparently at each level of management.

Every DevOps implementation begins with education, from management to the individual contributor. Educational resources increasingly are available as DevOps continues to gain momentum in the industry. If faced with a hesitant executive suite, teams should leverage proof points from other companies that have successfully implemented DevOps. Leadership should be ready to measure, experiment, iterate and, most importantly, stick with it. When armed with the right training, tools and support, organizations can gain a competitive edge with DevOps.

— Pete Chestna
September 28, 2017
DevOps for Small Organizations: Lessons from Ed

Ed was demoralized. He had just heard a speaker who would change his life. He knew he needed to change, and he knew what the end goal was. He just didn’t know how to get there. He needed fresh air. He needed endorphins. What better way to do that than go on a six-hour run through some of the seedier neighborhoods of Vegas to the edge of the desert.

Ed Ruiz (@eruiz06) is the senior director of IT for the Association of Schools and Programs of Public Health (ASPPH), and I heard him share lessons learned from his conversion to DevOps during the marathon All Day DevOps Conference (free, online).

Here’s where his journey started. Earlier that year, ASPPH recognized a need to modernize its membership structure. The organization had ballooned from 31 to 106 members. Ed had a staff of 10, supporting 54,000 students and 13,000 faculty serving in 141 countries. ASPPH was steeped in following the Microsoft Enterprise handbook, deploying via the waterfall method every thee to six months, and recognized it needed to update its IT infrastructure.

There, among the glitter and glam of a ballroom on the Strip, Ed heard DevOps Evangelist Andi Mann (@AndiMann). Ed was glued to what Andi had to say. “This is what our organization needs,” he thought. But he quickly became demoralized because he didn’t know how to lead the drastic change.

During Ed’s run following Andi’s keynote, he realized he need to start with a vision. Spoiler alert: Ed was successful, but not without a few hiccups. Ed shared four lessons he learned during the session to help the rest of us pursuing our DevOps journey.

1) Articulate a Vision. Your team needs to understand what the organization does, why it is important, and how this change allows the organization to be more effective.

2) Start with Culture and Sharing. The DevOps mantra emphasizes the equal importance of Culture, Automation, Measurement and Sharing (C.A.M.S.). Too often people are drawn to automation and measurement first. It is what they know. It is the DevOps tools that are fun to implement. According to Ed, overemphasis on tools is a huge mistake. DevOps is called DevOps because it is implementing a culture of sharing between development and operations. Automation and measurement are tools to facilitate sharing, but if your team isn’t on board with culture and sharing, DevOps will fail.

3) Prune the Bad Apples. We all know that person (they go by many names: Dr. No, Negative Nelly, Milton). You don’t want that detractor in your organization. When Ed decided to keep a Dr. No on his team because of his technical acumen, it took half of Ed’s team quitting before he realized the bad apple needed to be pruned from the tree. Dr. No’s negativity was contagious and led to poor morale that was eroding the culture needed for success. Ed’s advice? You can teach skills, but you can’t teach a positive attitude. Hire for the attitude first.

4) Leadership Buy-In is Essential. Priorities and budgets will change and setbacks will happen. When you have buy-in from the leadership, it creates room to fail. You can pick yourself back up and take another step toward your vision.

We don’t know what else happened in Vegas over those five days, but we do know Ed came home a changed man and he changed his organization. We all can take some lessons Ed learned and apply them to our own transition to DevOps.

http://https://www.youtube.com/watch?v=Kv6PJTp3uq4&feature=youtu.be

You can watch Ed’s full presentation from the All Day DevOps conference here (30 minutes). The other 56 presentations from the All Day DevOps Conference are available online, free-of-charge here.

— Derek E. Weeks

January 23, 2017
Simulation: The ‘Aha’ Moment for DevOps Adoption

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

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

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

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

Creating Successful Change

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

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

The Key to Change

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

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

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

The Power of Simulation

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

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

Simulation Brings Agility to Adoption

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

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

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

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

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

About the Author/Andrew Macintosh

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

May 23, 2016
How DevOps Can Effect Culture Change to Improve Business

The rift between Dev and Ops teams has long been one of the main obstacles for organizations managing their IT capabilities. Overcoming it can be crucial for a successful business. In fact, every company should be able to achieve harmony by improving process automation, implementing better procedures and refining workflow regulations. This is where DevOps culture steps in.

To be successful, your DevOps approach must include a detailed understanding of your culture and learned behaviors that will influence the changes you want to see in your organization.

According to recent Gartner research, DevOps will only work when both Dev and Ops are willing to collaborate. They need to embrace change at a behavioral level to initiate and achieve culture change. If not, there is a 90 percent likelihood that any DevOps initiative will fail.

In discussing the importance of communication in implementing DevOps know-how with Consultancy UK, Gartner’s research director Laurie Wurster explained: “With respect to culture, DevOps seeks to change the dynamics in which operations and development teams interact. Key to this change are the issues of trust, honesty and responsibility. In essence, the goal is to enable each organization to see the perspective of the other and to modify behavior accordingly, while motivating autonomy.”

Theory vs. Practice

In reality, the existing autonomy of the operations and development teams is one of the most common reasons for a possible failure of the DevOps approach. While the business culture of developers is founded on innovation and breaking the status quo, life in Operations can seem unthinkable without a procedure-based routine.

Going further, these two teams can be pushed apart by their own executives. After all, handing out separate tasks and objectives without actually putting the Dev and Ops teams in a room together (even when working on the same project!) has been a traditional approach that dates back decades.

Deadlines and Objectives

With Dev and Ops each being unaware of the business value of the other, the departments end up sharing only two business factors: deadlines and objectives. This often leads to a blame game—explaining a delay or a failure seems much easier when you have someone else to blame and a team with an unknown value is always an easy target.

Putting a stop to this poor practice by initiating cooperation and reminding both they are part of the same organization is the best way to improve efficiency and speed of innovation. IT managers must build bridges and encourage Dev and Ops to discover new ways to accomplish their shared objectives.

DevOps for an Agile Reboot

Modern business has realized that while Agile improves speed and service delivery, it may have skipped some very important aspects of culture change resulting in the birth of “fragile infrastructure.” The term is used to describe the damage that can be caused by Agile’s ‘shortcut policy,’ in which teams may compromise to meet their deadlines.

Many see DevOps as the savior that comes just in time to influence business on a cultural level and unite with Agile toward excellence.

One of DevOps’s flagmen, Mike Kavis, vice president and principal architect at Cloud Technology Partners and a Forbes contributor, points out that “the solution is for dev and ops to collaborate on the environment specs and together build the appropriate automation scripts that can provision environments with a single touch of a button without the need of additional configurations.”

When implementing the DevOps approach, developers can be the toughest audience. They may remember all the arguments and rifts with operations, potentially caused by tentative coding leading to functionality issues within the environment—a destabilization every Operations team fears and detests. So, one question remains: How can you build this collaboration?

Incentivize Accordingly

As stated by Forrester analyst Kurt Bittner, IT companies of today are helping the cultural rift between dev and ops by incentivizing the teams to do different things—developers are prompted to deliver quickly, while operators are targeted to keep the services up and running.

Encouraged to pull in opposite directions, it is only natural that the two business units end up facing a rift, making cooperation seem more illusion than reality.

Because most companies set their priorities based in part on its incentives policy, it is important that those priorities agree with the company goals. In short, once you “go DevOps,” make sure your incentives policy is encouraging rather than hindering collaboration.

Set Shared Goals

DevOps supporters see DevOps as a cultural movement and a philosophy, rather than a framework or simply an approach.

“DevOps is a mindset of moving away from fragile systems that take too long to deploy to reliable software that can be deployed quickly. DevOps requires great collaboration and teamwork, not just within IT, but also with management and product,” Kavis notes.

Identifying a goal that can bridge the gap and make teams work together is a great way to initiate a change in a positive direction. As Bittner explains, “Part of that means measuring devs on stability, and part of that means measuring ops on innovation. But the best thing is to reward everybody on improving the customer experience.”

A recent case study presented by Orbitz Worldwide’s senior software engineers Greg Burton and Ori Rawlings at the Velocity Conference neatly demonstrated how setting a common goal for Dev and Ops can bring actual results.

The goal itself was simple but ambitious: to double the hotel search capacity across the whole website. While achieving it by working closely with operatives, the development team managed to get a hold of many issues plaguing the system on day to day.

In fact, being a back-end developer himself, Burton defined the term “feature guilt”—the belief among developers that any time spent in aiding operations to resolve outstanding performance issues is lost and unproductive, so everything that does not involve new features must be completed quickly.

Like many other professionals, Burton also believes change should be realized as soon as possible throughout the organization to prevent substantial losses for everyone. Working on a shared goal, such as improving the customer experience, for example, can help influence developers to appreciate that maintaining a system is as important as developing new features.

Change the Culture of Fear

As Bittner notes, “If agile was the opening act, continuous delivery is the headliner.” Once the culture change is favorable and the company is running at full capacity thanks to the DevOps approach, favoring innovation and experiments within the organization becomes one of DevOps’s main advantages. Still, allowing it to work might prove unattainable to some companies. What lies beneath is the fear of failure that can paralyze every manager and employee.

Randy Bias, director of the CloudStack Foundation and vice president Technology at EMC, speaks of “a culture of fear” that exists within organizations, which is driven by an “endemic” fear of failure.

This is caused by the widely adopted practice of heavily penalizing every form of failure instead of focusing on how to minimize the potential losses and still allow experimentation for the sake of innovation.

The real question is, How can you make this possible when your business is at stake? The secret to success, according to many industry experts, is creating a structure based on separate components that can malfunction without leading the company to bankruptcy.

As hard as this may be for companies relying on monolithic applications, it is best to adopt microservice architecture that will permit managers to allow developers freedom, even if this means paying the cost for the potential mistakes.

According to Mike Kavis, vice president and principal architect at Cloud Technology Partners, and Etsy’s CEO Chad Dickerson, it is essential to allow people to make mistakes as freely as reason allows and turn postmortems into productive and proactive meetings, not a blame game.

One of the greatest success stories of today’s business practices, the e-commerce platform Etsy is a great example of the benefits of DevOps practices and blame-free meetings.

Senior vice president of Technical Operations John Allspaw, who is in charge of Etsy’s “blameless postmortems,” told Business Insider: “Less-skilled companies name, blame and shame. It’s not about avoiding accountability. In a blameless culture, it’s easier for people to take responsibility for their mistakes and learn from them. Developers already feel quite guilty when they break the site.”

Seeing is Believing

One-on-one meetings with management, prearranged brainstorming and specially made presentations are no longer enough to effectively influence culture change. Encouraging communication between teams with the right incentives is vital, but modern management needs to push even further.

The best way to make developers understand operations and vice versa is to get them together and even share job descriptions.

Companies like OnShape, for example, have taken a big step in reorganizing on-call duty by making developers and operations actually work together. According to Paul Beltrani, webops at MC10 Inc. and former techops at Onshape, this has been a win-win game, as the change has helped both teams.

Developers have gotten a grasp of the after-effect of a faulty code, while operations have gained a better understanding of how the code works. Furthermore, making dev and ops share a responsibility has also proven to be less stressful, as developers and operations were effectively cooperating by exchanging knowledge to handle the issues.

CenturyLink goes even further in this direction, by transforming its dev and ops teams into product teams able to support the entire service.

“It aims to be light on management and process, with each product team assigned each aspect of the product with a laser focus,” explains Jared Wray, CTO of CenturyLink Cloud and head of the development center. “There’s no throwing it over the fence, and there’s no distractions between the two organizations.”

Patience is a Virtue

If you’re willing to transform your organization according to DevOps, you should invest all of your patience and good will; be ready to listen and improve.

As every business is unique in its organizational structure and services, and is counting on many individuals, there is no strict route to follow when implementing DevOps. Of course, there is something all professionals agree on: “Most people think they’re going to snap their fingers and it’s going to happen overnight by doing a reorg. But it’s a full culture shift. It took us three years to make this model, and we’re still evolving it,” Wray says.

According to Chris Nowak, senior vice president and head of DevOps Services at Bank of America, it’s natural to face initial resistance when presenting teams with new requirements and processes and the best way to handle it is with care. Nowak recommends the human approach: finding and encouraging opinion leaders who can influence change and “eventually help other teams let go and embrace a new way.”

So, setting clear goals is the first step to becoming a DevOps success and rushing change has only ever resulted in a temporary workaround. DevOps is gaining more and more popularity, making it possible to gather opinions and learn from the forerunners.

Industry experts have come together to found the DevOps Institute and share a common language through the DevOps Foundation course, so maybe now more than ever is a good time for your business to “go DevOps” and see the value.

February 10, 2016