devopsy.kinsta.cloud

Tag: communication

Best Practices for Internal Communication in DevOps
DevOps has become a widely popular method of collaboration in the IT world. The combination of development, operations and quality assurance, DevOps requires every project have clear communication channels between development teams and individuals. In this article, we’re going to explore some of the best practices for internal communication within the DevOps structure.

Software development is the game that runs on invention and communication. Therefore, communication methods and channels play a significant role in project success. Better communication between managers, engineers, developers and testers leads to better performance and more satisfying results. Each practice presented can help improve communication within teams and make your work more synchronized and efficient.

Digital Communication Channels

Scott W. Ambler notes in his communication diagram, e-mail communication is noted as more effective than any other documentation options, including paper memos, audio tapes and others. E-mail is the best way to share official documents and company memos, making it more suitable for external communication in the DevOps project. But while most individuals today are able to access their e-mail on their smartphones, and e-mail enables users to send large attachments and contact several team members at once, DevOps teams tend to rely on more interactive communication channels.

Depending on the project needs and the preferences of team members, internal communication can be either through project collaboration apps, an intranet or even the usual communication apps or social media. Since Ambler’s diagram shows that video conversation is by far the most effective form of project communication (aside from face-to-face meetings), most project managers rely on apps with video-calling and videoconferencing functionality.

Regular Meetings

Regular meetings are the backbone of the DevOps communication. They can be organized in-person or through videoconferencing apps. Same as with the Agile Project Management structure, the DevOps team should meet at least twice a week. Preferably, the meetings should occur on a daily basis. The Monday or morning meeting can be used for assigning tasks to each team member and the Friday or end-of-day meeting can be used for assessing completed work and for future planning.

Building Soft Skills

Unfortunately, HR practices in many industries rely on stereotypes. One of the most prominent stereotypes about IT professionals is their lack of interpersonal skills. Although some engineers and developers fall into this generalization, their knowledge and interests go far beyond IT and technology topics. Still, even the most talkative and assertive members of the development team need to work on their soft skills to improve the team’s communication.

Improved soft skills enable team members to collaborate more effectively and to develop strong working relationships. The first task of every manager is to find the soft skills already present in your team. This will give the team the chance to find the best opportunities for further development. After the initial skill appraisal, manager can enroll members in courses for assertive communication, negotiation and conflict-solving, depending on their needs and current capabilities.

Importance of Time Management

The whole DevOps paradigm strongly relies on effective time management. The implementation of the DevOps model often changes the whole development process and wipes out all the previous scheduling and time-management patterns. A good manager needs to motivate his or her team to change their long-held habits and pace their daily routines so they can keep up with the new organizational patterns.

We already mentioned how regular meetings are essential for successful DevOps implementation. When organizing the meeting, schedule managers need to leave enough working time so each team member can effectively work on their tasks. Too many interruptions can break up the work process make it difficult for employees to focus. Effective time management relies on both team and individual needs and gives your team the flexibility to work as efficiently as possible.

Use of Data Insights

Internal communication on DevOps projects needs to be smart. It needs to be specific, measurable, attainable, realistic and timely, and one of the ways to achieve this is to use accumulated data from current and previous projects. The thorough analysis of accumulated data can give managers more details on:
- The average number of working hours the team will need to release a new app, make various updates or make patches;
- How to make the team’s communication more efficient;
- Identifying the areas where the development strategy is losing its momentum; and
- Understanding how each task influences the project delivery.
Constant adaptation and changes in work processes is the base for successful DevOps implementation. This ideal can be achieved only through effective communication between team members. Communication also requires time, so the only way to ensure effective DevOps work is to combine strategic skills, process development, excellent time management and smart data insights.

About the Author / Nate Vickrey

Nate Vickrey is a business consultant and an online author. He is mostly engaged in finding the best solutions and latest trends regarding company management and culture. Nate is also the executive editor at one Bizzmark Blog. You can follow Nate’s work on his Twitter page.
May 22, 2017
Stop Talking About the Number of Times You’ll Deploy

Chrysler Windsor – By Lars-Göran Lindgren Sweden – Own work, CC BY-SA 3.0 https://commons.wikimedia.org/w/index.php?curid=1385155

It’s the late 1940s and the automobile industry is just taking off. You run one of the product marketing teams at Chrysler. Wanting to make the best of an exploding market, your marketing team says, “You’ll drive 1,200 times as much with the new Chrysler Windsor!”

Of course, that advertising never makes it to the public, because it says nothing. So you’ll drive more, so what? It tells the customer nothing about the benefits of driving more. And some customers may make a connection between driving more and “because you want to,” but likely most won’t without context. So into the trash bin the entire ad campaign goes.

Yet, that is what happens in CI/CD every day. Every time you read a blog, pick up a book, listen to a speaker, it’s all about how many bazillion times more you’ll deploy with CI/CD in place. And I ask the same question: So you’ll deploy more. So what?

Most of those making these statements never get around to talking about how that can help with stability and user acceptance, a few get around to it roughly halfway through whatever they’re presenting, when the whole “You’ll deploy 70 billion times more!” statement is long gone. Very few drive the connected point home and make these statements show value.

Particularly if your target audience is people without a strong knowledge of the topic, talk about the benefits, not the act. I can create a script that builds my source tree just as many times as I like a day, but that adds value for no one, absent any other change.

While I’m going on about terminology, the whole “Delivery is not Deployment” topic needs to be made explicit in each and every talk/article/book. Marketing people have actually gotten better on this topic, but influencers have not. It’s time to step up the game, clarify, speak in meaningful terms.

In Short, Pique Their Interest

In the end, if you’re talking to people about CI/CD, you are doing so because you like to educate. So seek clarity. Many an enterprise IT person interested in what CI/CD tools and DevOps in general can offer their organization will be turned off by “You’ll deploy all the freaking time!” with no statement of benefit to them. And they’ll hear deploy and assume “to production.” Don’t do that. Education happens in clear and understandable terms; use them. Help those interested parties understand benefits; don’t confuse and disconcert them.

Oh, sorry, I’ve accidentally found someone’s soapbox. I’ll return it now.

— Don Macvittie

May 18, 2017
It’s About Communication, not Silos

Too often, when enterprise folks talk with DevOps aficionados, we get a loud chorus of “Culture Change” and “Take down the silos,” and frankly that scares any sane enterprise IT person. Not because they fear change, but because they fear that those of us who are fans of end-to-end DevOps have no clue what we’re talking about.

Baby vs. Bath Water – By Richfife (Own work) [Public domain], via Wikimedia Commons
And to some extent, that impression is not misguided. There will still be a development team. There still needs to be a selection of operational specialists. Eliminating these are not changes anyone is proposing for enterprise use. Indeed, if an organization has an investment in Cisco UCS, they still need a UCS specialist. The system is complex, and the more knowledge you have of it, the better it can be managed. Sure, automating as much as possible is a worthy goal for all such specializations, but even automated, the UCS person still needs to be able to expand/modify/maintain the automation. Another good example is NetOps (or whatever we’re calling it today): The person with in-depth knowledge of your ADC will still need to have in-depth knowledge of your ADC.

So, then, what we’re really talking about is increased communication. We’re talking about a small, cross-functional team to smooth the areas that DevOps is very good at, but specialized knowledge is still needed. Increasing communication is key to every DevOps implementation, regardless of tool set; the ability to predict future work based on updates is almost essential in any faster-moving environment. Indeed, Lori and I were discussing this morning, wondering how many of those enterprise Slack channels are being used to provide a running commentary across the team of what is happening upstream. But that’s another blog, I think.

It is not that DevOps people are clueless, nor is it that they want to eliminate specializations (well, some claim to want to, but they have a marketing reason to do so), but rather, it seems that many of us DevOps folks have gotten so wrapped up in change (it is a big change to streamline both Dev and Ops) that the baby is being thrown out with the linguistic bathwater.

If you’re talking DevOps, talk about increasing communication, not destroying silos. Secure DevOps is evolving now, and shows the model more clearly because of it—developers and ops are given more of a role in security and auditing, but they are taught and overseen by the security team. This does not eliminate security, but does increase the security of what is being produced.

While we’re at it, switch from bulk “Culture Change,” too. While there is a fair amount of culture change—moving to proactive and more frequent, with roadblocks minimized or removed and non-essential changes treated as, well, non-essential. But “streamlined dev/operations” might just be a better way to talk about it. After all, the brazen voices still seem to sing of wrecking balls from on high crashing down, and that’s not an effective way to get buy-in for change.

In the end, the point is more repeatable, more stable, more manageable processes and systems. Let’s talk more about that, and less about Destructor, shall we? Sell the concept; don’t force-feed it. There’s a lot of good to be had, and using terminology that is both confusing (Define “Culture Change” in a generic, applicable sense) and often frightening is not helping people understand (or want to understand) how it can help.

— Don Macvittie

May 5, 2017
DevOps: The Innovation Power Couple
If “Dev” and “Ops” are the power couple of tech, “DevOps” is the holy matrimony that takes innovation from trainwreck to fast and repeatable. At most businesses, however, Dev and Ops still sleep in separate rooms and agree only on their mutual contempt.

Dev (Development) and Ops (IT Operations) usually are divorced or ready to serve the papers because their incentives clash. In Ops’ opinion, Dev is an idiot—always out late drinking with friends, he comes up with wild ideas and wants to implement them immediately. Dev can’t make anything work on real servers and can’t write scalable, stable code.

To Dev, Ops is a total code-blocker—she makes Dev go through “change management boards” and slows down progress. She lets the competition get to market first. So every day, Dev and Ops have an angry shouting match that ends in tears.

I wish I were exaggerating. My coworker Brandon Cipes once walked into an interview for a product development position. The interviewer broke down crying because the relationship between Dev and Ops had gotten that nasty. They refused to meet with each other, let alone be in the same room.

When Dev and Ops have a dysfunctional relationship, they struggle to communicate, collaborate and get results. Their organization will fail at innovation because it lacks the cultural, technological and procedural base to do otherwise.

The missing base is DevOps. It’s a unified strategy for Development and IT Operations, and implementing it can have the following effects:
1. Communication Becomes Unavoidable
Normally, Dev and Ops play “telephone” because they’re physically separated and have too many points of communication. Emails, IMs, grudgingly accepted meetings and passing conversations ensure Dev and Ops never get the full message.

DevOps fixes communication by assigning Dev and Ops personnel to the same teams. They sit in one room and work in a single squad (a.k.a. a pod or team) of no more than eight to 10 people. If they turn their heads, they see each other’s beautiful faces. Until promotions or career change do them apart, they can’t avoid talking and working toward common goals.

In essence, DevOps puts “cross-functional” teams together and thereby eliminates hand-offs. Fewer points of contact, less telephone, better communications.
1. Collaboration Gets Automated
For many Dev and Ops teams, “collaboration” is another word for bureaucracy. It’s TPS report-ish stuff characterized by change review board meetings and laborious documents that tell Ops how to deploy new code. Dev and Ops might accidentally (or intentionally) withhold information from each other.

In DevOps, collaboration is automated. Instead of change review board meetings, you use version-controlled software. The hand-offs from Dev to QA and QA to Ops are done by machine. A script deploys the code for Ops so there’s no risk of misfiring.

“Collaboration” is no longer an ordeal or choice. Documenting and sharing the squad’s collective knowledge is wired into the process.
1. Fast and Stable Releases
Normally, a software deployment is like a sloth trying to cross US 101: slow, awkward and soon to be roadkill. That’s all thanks to bad communication and bad collaboration.

With DevOps, you catch problems before they go live. Test automation prevents any need for manual checks. One person corrects the problem in a matter of minutes whereas before, a team of five might spend eight hours tracking down and fixing one bug. Ops feels confident that tested code won’t cause havoc.

Thus, the upshot of DevOps is speed and stability. Before, Dev and Ops delivered maybe a few times a year and faced regular breakdowns. DevOps can deliver multiple times daily without a hitch.

Say ‘I Do’

DevOps is a cultural, procedural and technological transformation. As in a marriage, both partners are responsible for good outcomes. Linked as they are on one squad, Dev learns to care about stability and Ops begins to value innovation.

If “agile” is about making businesses nimble and quick, DevOps is about applying agile principles to technological development and operations. Ultimately, it’s about beating your competition to the next big thing.

Dev, easy on the drinking escapades. Ops, live a little. Tie the DevOps knot and make some innovation babies.

About the Author / Zubin Irani

Zubin Irani is co-founder and CEO of cPrime, a full-service consultancy that focuses on agile transformations and project delivery solutions for hundreds of software teams, including more than 50 of the Fortune 100. Connect with him on LinkedIn.
April 21, 2017
Communicating and Collaboration in a Digital Age

The way we communicate with the world has changed drastically in the last 20 years. Gone are the days of pen and paper, lengthy phone calls and, to a certain extent, even emails. Gone are the days of needing to have your entire team under one roof to accomplish anything. Gone are the days of communicating from one limited perspective.

In our digital day and age, we can move mountains with keyboards, perform miracles via Skype and enjoy a thousand different perspectives of any project. There is one key behind all of this progress: code. Without it, we would not be where we are and couldn’t accomplish any of the amazing interdependent things we do. In fact, STEM (science, technology, engineering and mathematics) is one of the fastest-growing areas of our economy, according to TechRocket. Between 2014 and 2024, the number of STEM jobs will grow 17 percent, as compared to 12 percent for non-STEM jobs.

Unfortunately, not everyone speaks this language, which can lead to a breakdown of communication in the office when the goal is to work as a diverse but cohesive team. It’s infinitely more difficult to collaborate with someone when you can’t translate each other’s visions. That’s why it’s important to have a basic understanding of this vital skill if you want to build successful teams.

Bridge Communication Gaps

I’m not saying everyone on your team needs to have the expertise of a developer, but it is helpful if everyone can learn how to code from a very basic level. This basic understanding helps everyone understand the time and effort involved from their tech peers, the boundaries of what can and cannot be accomplished, and the importance of clear, precise details in communicating their ideas.

It also makes troubleshooting and revising much easier to pinpoint and less time-consuming to correct. You can skip the IT-to-English translation that so often degrades communication on major projects because neither party feels they’ve been heard and understood.

Encourage Collaboration Throughout the Process

A recent poll by Gallup showed that 70 percent of U.S. employees are not engaged at work. Luckily, there are plenty of opportunities for companies to bolster engagement through effective communication channels that keep everyone in the loop and invested in the ultimate outcome.

Oftentimes, ideas flow from conception to initiation to implementation without ever having crossed the desk of the programmers charged with writing the code to bring these ideas to life. That’s the same as asking a carpenter to build a car. Although the carpenter may have a great design, understand the market and even be able to build some pieces of the car, at the end of the day the carpenter’s skills aren’t enough to do it alone and the carpenter’s vision will need to be communicated to someone with a different skill set.

When everyone on the team understands how code works and the resources needed to turn these fantastic brainstorms into reality, the entire process becomes more streamlined and can be executed more efficiently.

Be in the Know

At the end of the day, everyone on the team benefits from understanding how the machine is programmed to work. Whether you’re launching a new website or the latest iteration of your app, somewhere along the line you will need to write code to convey your message in this digital world—and you will want that message to come across loud and clear.

The good news is that it’s easy to harness the skill of coding these days. Employees can participate in a coding bootcamp, online courses or even mentorships with other employees who’ve already mastered the skill. The improved communication among teams and departments will help improve efficiency and help you realize visions.

About the Author / Michael Peggs

Michael Peggs is the founder of Marccx Media, a digital marketing agency specializing in Search Engine Optimization (SEO) and Search Engine Marketing (SEM). Before Marcxx, Peggs worked at Google in business development, forming digital media and advertising partnerships in the United States and Asia. He is also a contributor to The Huffington Post, FastCompany and Business Insider and a podcaster, hosting the iTunes Top 10 New & Noteworthy Podcast You University. Connect with him on Twitter.

February 8, 2017
Increasing Your ‘Bionic Footprint’ with DevOps

“The Six Million Dollar Man” was a 1970s TV series. In the show, NASA astronaut Colonel Steve Austin is severely injured in a crash and is “rebuilt” with bionic features that enhance his strength, speed and vision beyond normal human capabilities. The main tagline was, “We can rebuild him, we have the technology.”

I recently was watching an old episode and it got me thinking about how the show is analogous to the genesis of DevOps—specifically, how individuals with an operations background have to “rebuild themselves” to keep up with the speed and direction of the technology industry.

Over the years, there have been several decrees of “Unix SysAdmins are going away.” I have always firmly disagreed with that assertion. Rather, I believe that SysAdmins have to continually evolve their engineering skills to stay relevant and, more importantly, gainfully employed. It was also becoming increasingly apparent that the manual tasks of deploying infrastructure, keeping it patched, monitoring and the myriad other things a SysAdmin performs every day could not keep up with the demands of the increasing pace of the digital world and the onset of cloud computing. Infrastructure is moving rapidly to being automated and programmatically deployed and the talent needs to adjust accordingly to stay relevant.

With many enterprises adopting the agile methodology and moving toward a continuous integration/continuous delivery (CI/CD) pipeline, the culture of DevOps became a reality. Due to the increased velocity, there became a clear need for the core tenets of DevOps culture, which include culture, automation, measurement and sharing (CAMS). In Six Million Dollar Man terms, this was simply “Better … Stronger … Faster.”

Embracing DevOps through CAMS is similar to the superhuman enhancements that composed the rebuild of Steve Austin, which took him from man to bionic man. Here are the four ways that DevOps can increase your enterprise’s “bionic footprint”:

Improve Culture

Even Austin’s bionic features only got him so far; the bionic man had to rely on his team to complete his dangerous missions unscathed. The same is true in the enterprise: Building a collaborative culture is crucial for success. Culture is paramount in maintaining overall velocity without adversely affecting quality. Developers and operations teams need to function in concert to ensure a resilient application and infrastructure.

Increase Velocity via Automation

Automation greatly increases velocity, akin to how Austin’s bionic legs allowed him to run at high speeds and make great leaps. Automating processes saves time, money and lets your team focus on more complex tasks—a win-win for productivity gains.

Measurement

Steve Austin had a bionic left eye that enabled him to see in the dark as well as detect heat. This provided him precise measurements of his surroundings in any situation, enabling him to gain the upper hand against adversaries. Similarly, measurement gives insight into all aspects of the software development life cycle, application performance and other key metrics. Without insight and transparency into measurement, your team is essentially working blind.

Sharing

Austin had a bionic right arm that had the strength equivalent of a bulldozer. Strength and resiliency are increased by teams that work and communicate effectively made possible by DevOps.

To summarize, I strongly believe that the mantra of “Better … Stronger … Faster” should be that of every DevOps team moving forward. DevOps’ parallel of CAMS upgrades your team’s capabilities to perform more productively. There is no end game; the objective is about continuous improvement, velocity and sustainable growth. Enterprises that want to undergo digital transformation need to adopt this cultural approach to increase their “bionic footprint” to succeed.

About the Author / Mike D. Kail

Mike D. Kail is chief innovation officer at Cybric. Prior to CYBRIC, Mike was Yahoo’s chief information officer and senior vice president of Infrastructure, where he led the IT and global data center functions for the company. Prior to joining Yahoo, Mike served as vice president of IT operations at Netflix, where he was responsible for employee technology and various cloud engineering components. He has been widely recognized for his insightful industry commentary on social media Twitter, and was recently named by the Huffington Post as one of the “Top 100 Most Social CIOs on Twitter.” Connect with him on LinkedIn and Twitter.

January 26, 2017
Should Continuous Deployment Be Renamed?

I’m a technologist turned into a word person. For those of you who know me, I started as a developer, learned ops and security as it was needed, and eventually my love of talking about technology lead me to writing, tech marketing and evangelism. I still develop, though; I can’t stop that—it’s kind of a part of me.

But as a technologist at heart, words are a way to convey concepts, and any that don’t contribute to the conversation in a meaningful way aren’t necessary.

So it is pretty weird for me to be saying, “What if we renamed CD?” But I think there is a real point here that we could address. If you look across the industry, you will find quotes (and in IT departments, the reality) that for most of us, CD is not about continuous deployment. It is about continuous delivery and on-demand deployment. Unfortunately, “on-demand deployment” makes a pretty terrible acronym in the English-speaking world, so perhaps we should use “on-demand update.” Deployment is looking at it from the application’s perspective, but as DevOps, we get to look at it from both perspectives and we are updating the server(s) to run our application(s). So on-demand update (ODU) would work, but I’d be open to alternatives.

In this case, the wording change is useful. There are a few organizations with very special needs that do actual continuous deployment. No one else does. The ability to say, “OK, we’ve got enough together and tested to warrant the disruption this will cause. Update the app,” is what most organizations use CD for. And I think that’s right. While purists will roll their eyes and talk about the advantages of each bug fix, no matter how small, rolling out in a timely manner, most orgs aren’t going to do 15 updates a day. And orgs that like stability don’t want to. Testing doesn’t resolve every issue; otherwise, we wouldn’t need things like Bugzilla for anything in production, risking introduction of new ones 15 times a day. That’s just not on the list of priorities for most organizations, particularly if their CI system is on longer run-times.

So I like CI/CD/ODU. Then you are separating continuous delivery and on-demand deployment, which I would argue is a huge piece of the problem. I’ll quote Georg von Sperling of CA Technologies during the Q&A section of a webinar:

Continuous delivery does not equate continuous deployment to production. If I may be so bold, I would state continuous delivery is a practice to allow deployment to production at any time with a high degree of quality and a low amount of risk with zero downtime and zero touch. A business leader recently said to me that whereas, in the past, ‘Deployment to production was an IT decision, it is now a business decision at a push of a button.’ But, CD certainly played a part in this paradigm shift, as the entire delivery process, including testing, is visible and predictable.

Which makes sense, once explained, but it’s truly a source of confusion in the field, so separating the two makes sense. The point is to communicate clearly, and requiring a further clarification of what exactly CD is says we’re not communicating clearly at all. Indeed, delivery and deployment definitions that are meaningful to IT are close enough in context as to automatically cause the confusion when a single “CD” is presented.

So even though I don’t get terribly wrapped up in wording, I think this is a worthwhile change to consider. Words convey meaning; let’s ensure the meaning they convey is clear.

For those of you knee-deep in CI/CD, yes I am aware of Fowler’s definitions, but this clears up the fact that he has to explain how continuous delivery is different from continuous deployment in the definition for continuous delivery.

In short, we’re being confusing. Stop it. Let’s talk about tools/technologies/methodologies to get there, not keep clarifying confusing terminology.

— Don Macvittie

December 13, 2016
4 Essential Practices to Succeed at ChatOps

We know enterprises are embracing messaging apps and incorporating so-called “ChatOps” into their workflow. ChatOps is, potentially, a powerful way to facilitate more swift decision-making and problem-solving and to receive quick, expert guidance. “With the rise of cloud services that can be easily deployed, and increased awareness and importance given to productivity and collaboration within the workspace, enterprise chat is gaining priority,” says Narain Muralidharan, a market analyst at online customer support software and help-desk software maker Freshdesk.

As most readers are aware, ChatOps has been fueled by the growth of tools such as HipChat, HuBot, Slack and others for chat-style and instant collaborative software development and project management. But these tools also execute scripts and automate tasks and get workflow approvals to deploy code, kick off software tests and more. As an added bonus, within the chat application exists a clear record of all discussions and scripts executed—something very handy for root cause analysis and troubleshooting.

With all of that in mind, how are enterprises embracing chat?

Chatting Down Silos

“At Threat Stack, we’ve long embraced Slack as a collaboration tool that removes silos within the organization and helps busy operations teams to move quickly and have a fully informed view,” says Pete Cheslock, senior director of Ops and Support at Threat Stack. “We’re seeing this migration toward ChatOps with our customers.”

Bhaskar Roy, head of growth at Workato, sees chat being embraced at companies ranging from small businesses to Fortune 500 firms. “There are groups in large enterprises who are adopting different chat products and are always looking for what they can do to make chat the center of all communication. When we talk to these companies we find that they believe that chat is a more natural, human, fast way to communicate—which can help in getting things done faster,” Roy says. Chat, he adds, is becoming a “command center for business apps. [Organizations] are using chat to get information from various applications and are looking for ways where they can easily interact with the application from the comfort of their chat/conversational interface.”

According to the most recent VictorOps State of On-Call survey, ChatOps continues to grow, with 40 percent saying they practice ChatOps during event remediation. That’s up significantly from 28 percent last year.

Getting the Most Out of ChatOps

With the tremendous growth in ChatOps, what practices have enterprises learned to bring the most success? Below we list the four essential practices that will help organizations succeed in their ChatOps engagements:

Embrace adoption: “The main problem that enterprises have in chat penetration internally is adoption. People are resistant to change, and it is usually difficult to change user behavior, especially in the way people work every day,” says Muralidharan. “Some practices are set in stone, like emailing or the good old face-to-face meetings. Start small with pilot teams, get buy in, and create evangelists within the company. A lot can be gained by having a top-down approach to adoption; hence, management buy-in is very crucial.”

Fine-tune notifications: “The biggest problem that we see is that bots and app notifications that are being pumped into the chats today are making things very noisy, resulting in loss of productivity overall,” says Roy. “What we believe is needed is utilizing bots to enhance the overall individual productivity, where people are notified only for things that are urgent, relevant and something that they need to act on right away. And bots are intelligent so that they understand and learn based on user interactions and are proactively prompting / helping as and when required.”

Adopt a DevOps mentality: Eric Sigler, head of DevOps at PagerDuty, suggests that “to make the most of chat within your enterprise, it is important to adopt a ‘DevOps mentality,’ where individual teams are more responsible for, and empowered to maintain, their own services. Without this, it’s too easy for teams to ‘throw things over the wall’ and for ChatOps-based tooling to remain restricted to a limited set of users.

“Existing infrastructure teams need to be a part of this ride as well,” he adds. “If they don’t take the time to understand how their engineers—their user base—want to interact with the tooling and invest in ‘making the easy things easy, and the hard things possible,’ then ChatOps-style tools will get relegated to shiny demos with little practical utility.”

Avoid DevOps fatigue. Chat alerts can be nagging distractions throughout the day, sucking worker concentration and clamoring for their time. “Customizing notification preferences in your chat client can help enterprises reap the benefits of chat. By personalizing notifications, it ensures that they see the most important chats and are accessible when it matters, but still have the ability to focus without being disrupted by constant pings,” Sigler says.

What Does the Future Hold for Enterprise Chat?

What does the future of ChatOps look like? Most of the experts we spoke with say it’s bright. “In an age of digital transformation where slow is the new down, conversationally driven interaction with software is going to play an important role for collaboration and increased agility,” says Sigler. “Overall for founders, hackers and investors, there’s room to innovate when it comes to humans and bots, and there’s a lot of really poor user experiences and bad workflows out there that can be improved by thinking about them through the constraints chat provides.”

— George V. Hulme

November 11, 2016
Wake Wants to Help Streamline Your Collaboration

Effective collaboration is imperative to DevOps success. DevOps has many moving pieces working simultaneously and things happen fast, making it crucial that teams and individuals have an easy way to communicate and keep everyone on the same page. Wake is a collaboration tool that may help you do just that.

“Collaboration across the enterprise is critical for DevOps success,” I wrote recently in an article on the importance of effective collaboration. “Great code and development needs to make it over the finish line to production to benefit customers. The challenge organizations face is how to do that seamlessly and with as much speed and automation as possible without sacrificing quality or performance.”

“Just as open source is associated with cost savings and flexibility, DevOps is associated with speed and responsiveness,” stresses Jay Lyman, enterprise software analyst for 451 Research. “Enterprises are increasingly interested in initiating or growing their DevOps thinking and implementations, but they must be aware of the dramatic change it brings not only for technology and tools, but for people and process as well.”

Wake is a collaboration platform used by teams and developers at Facebook, Instacart, Zendesk and other organizations to communicate effectively and share work with others. Wake was created as an internal project at digital agency Bakken & Baeck by Chris Kalani, a former Facebook designer. Silicon Valley companies Medium and Airbnb loved it and begged to be able to use the product themselves, so it was spun off into its own company. When Wake launched last fall, 350 companies signed up in the first month, including Cisco Systems, OpenTable and Uber.

“Adjacent trends such as cloud computing, DevOps and containers are all speeding up the time it takes to iterate and deploy software and the movement of applications and workloads from test and dev to production, but the reality for enterprises is they cannot simply start fresh with a DevOps approach,” Lyman says. “Existing infrastructure, applications, people and process must be considered and integrated so that the transition to DevOps is not only less painful, but more realistic as well.”

Wake ostensibly helps facilitate the increased speed and agility by simplifying communication and collaboration. It has a bit of a Pinterest look and feel to it, but Wake makes it easy to share your progress on what you’re working on without leaving the application you’re working in. It connects with messaging systems such as Slack and HipChat, and you can find what you’re looking for quickly by searching for specific people or tags.

A Wake spokesperson tells me that Wake will soon launch significant updates to its enterprise product as it builds momentum with bigger brands including Capital One, Netflix and Mozilla. You can check out some use cases of Wake at Instacart, GoPro, Intercom, OpenTable and other places in this post on Medium.

Pricing starts at $125 per month for five contributors and 10 spectators. There is a Plus subscription for $350 per month that includes 15 contributors and 30 spectators. Beyond that, pricing is negotiated for larger organizations. You can try Wake for free for 30 days.

June 24, 2016
DevOps Must Also Mean OpsDev

Why DevOps Communications Need to Be a Two-Way Street

Today, mobile apps have become one of the most important components of brand awareness and opinion. Often considered a company’s “front door,” a mobile app is an important way for consumers to directly interact with a brand, so it’s key for organizations to deliver high-performing, feature-rich user experiences right from the start. The margin for error is low – according to industry statistics, 79 percent of end users will only retry an app once or twice if it fails to work the first time, and only 16 percent report they will give it more than two attempts.

With these requirements in mind, the role of an organization’s development team is more important than ever. In today’s hypercompetitive market, organizations must get applications to market as soon as possible, without compromising functionality and end-user performance. This has led to the emergence of DevOps, a new approach to software development emphasizing greater collaboration, agility and speed across the entire software development continuum – developers, testers and IT ops teams – in order to meet the joint goals of velocity and quality.

An interesting by-product of the DevOps movement is the blurring and blending of roles across the application lifecycle as a result of these condensed timeframes and pressure to deliver new functionality, particularly in the area of testing and quality. This can be a boon, however, as we’ll discuss.

“Shift Left”: Eliminating Defects as Early As Possible

The traditional application lifecycle followed this model – ideation, development, testing and finally, production. It used to be that testers assumed the bulk of responsibility for ensuring an application worked as it was supposed to, before it moved to the production phase. But today, developers are assuming a greater role in testing, ensuring that applications meet basic functional requirements before they move any further down the funnel towards production.

This is known as the “shift left” movement, and ultimately it helps prevent code defects from getting baked into applications as they progress through the lifecycle. The further along an application moves toward production, the more “baked in” defects can become, and the more costly and time-consuming they are to un-do.

Even with their newly added responsibilities, the world of agile demands developers to work within shortened testing cycles. It is a race against time. Fortunately, tools exist today to bring greater testing automation to developers, plugging right into existing developer environments and frameworks. Further downstream, automation tools for testers enable them quickly provision (and de-provision) resources, and tweak testing environments. By reducing sluggish, error-prone manual processes, organizations can better deliver velocity and quality simultaneously.

“Shift Left” Also Requires A “Shift Right”

Ideally, an organization doesn’t want to treat real end users as beta users. But as the saying goes in software development, “the last bug is a mirage.” The reality is, even with all the due diligence on the left, finding some bugs in production is normal, and the “zero bugs” goal – while sounding commendable – can actually kill motivation, hurt creativity and discourage healthy risk-taking. Many developers note they spend much more of their time modifying existing lines of code, than writing new code. In a sense, testing – and the pursuit of better and better applications – never ends.

This is when IT ops teams can start making own contribution to application quality – a “shift right” so to speak. There is a wealth of information in production data that can be fed back to developers, in order to further optimize application functionality and end-user performance. Forward-looking IT ops teams are going a step further by applying data analytics, yielding deeper insights that can then be fed back to development teams.

Consider the case of SpeechTrans, a leading speech translation company. SpeechTrans applies Big Data analytics to end-user experience data – for example, what screens are end-users getting stuck on the most; where are end users exiting the app – so developers can focus specifically on improving these app areas. Previously, it took SpeechTrans up to three weeks to fix an app issue; now, they can address most problems in less than two days. This approach has enabled SpeechTrans to achieve consistent 5-star ratings in mobile app stores, a key driver of new customers and revenues.

Testing will always be indispensable in the development process, but further value can be realized by releasing an app into the wild and collecting real end-user data. IT operations teams can help developers and testers optimize applications in other ways. For example, they can support Canary Releases (or “rolling roll-outs”), enabling developers to roll out an application to a finite number of end users, in advance of a wider release. In addition, another important component of high-quality applications is cost- and resource-efficiency. IT ops teams can share production data on application usage patterns (such as, when during the day does an application come under heavy load, and when does this load taper off). This enables development teams to code applications accordingly – for example, architecting applications to accommodate longer or shorter queues (depending on time of day) which can free up CPU resources.

So in this way, when “OpsDev” happens, IT ops teams are helping developers do their jobs, but developers are also architecting applications with IT ops in mind, helping them utilize resources better. The days of developers simply creating applications and “throwing them over the fence” to testers and IT ops teams are over. Additionally, with real-time insights into production-level data, IT ops doesn’t just point a finger at development when a code-level problem arises. Rather, IT ops can provide deep, data-based insights into problems, giving developers a chance to prioritize and proactively address fixes. Advances in Big Data analytics are an important part of this.

Conclusion: Application Quality is a Shared Responsibility

To be truly successful in the development and testing process, organizations are recognizing that application quality needs to be addressed as early as possible, to prevent as many defects as possible from getting further embedded and ultimately reaching production. But like many aspects of the continuous delivery model, ensuring application quality requires a continuous feedback loop across developers, testers and IT operations teams.

In a continuous agile delivery environment, no one can shift responsibility for application quality to one group or another. The entire DevOps value chain – developers, testers and IT ops teams – must be involved and committed to collaborating as closely and efficiently as possible. In the true spirit of DevOps, lines are being blurred, between not just developers and testers, but also developers and IT ops teams. Silos are being transcended and “left-to-right,” back-and-forth communications streams are taking precedence. When “DevOps” also becomes “OpsDev,” the traditional, linear approach to development is replaced by a model that better supports the common goal – bringing high-quality software and enhancements to market, quickly and efficiently./

About the Author/Eran Schitzer

Eran Schitzer is a director of product management in the Application Delivery Management business unit within HP Software, responsible for driving the direction and release of new and existing products within the Performance Testing and Lifecycle Virtualization product suite.

He has more than 15 years of experience launching cloud, mobile and e-commerce products for consumers and enterprises, at companies ranging from start-ups to large-scale public entities.

Since joining the company, Schtizer has led the acquisition of Shunra Software, a network virtualization company; defined and executed the cloud testing agenda, and driven the move from an on-premise to Software-as-a-Service consumption model, including the launch of StormRunner Load.

Schitzer holds bachelor’s degrees in Economics and Management as well as Information Systems from Technion – Israel Institute of Technology. He also has a master’s degree in Business Administration from the University of California, Berkeley, Haas School of Business

October 27, 2015