devopsy.kinsta.cloud

Tag: roi

SmartBear Adds Computer Vision Capability to Testing Platform

SmartBear this week extended its ability to apply artificial intelligence to application testing with the addition of a computer vision capability that can be used to detect objects in applications.

Prashant Mohan, vice president of product at SmartBear, said the company’s TestComplete platform now combines computer vision and optical character recognition to help automate the testing of highly visual applications such as CAD/CAM applications that have 3D components.

Historically, those types of applications relied heavily on manual testing processes that created a bottleneck that slowed the rate at which more complex applications could be deployed, he added. Computer vision capabilities, in effect, now allow machines to visualize these applications in the same way that humans see them, noted Mohan.

As a result, the SmartBear platform is now able to test how an application is supposed to behave, rather than how its underlying code is supposed to function. That not only makes tests more resilient to subtle application changes, it also serves to make them easier to maintain because DevOps teams can automate regression tests to keep pace with application changes without having to revise code, said Mohan.

As the pace at which these applications are being constructed accelerates in the age of AI, the need to apply computer vision to test them is becoming that much more pressing, said Mohan. The challenge is providing that capability within the context of a platform that is already being used to test a wide range of other classes of applications, he added.

Mitch Ashley, vice president and practice lead for software lifecycle engineering at the Futurum Group, said as AI compresses how fast applications get built, regression suites anchored to code structure accumulate maintenance debt with every release. Perception-based verification narrows that gap, but the harder problem is folding it into a platform already testing many other application classes, he added.

A recent Futurum Group survey finds well over a third of organizations (37%) have adopted AI-assisted testing, a percentage that should steadily increase as various forms of AI are incorporated into automated testing platforms.

In the meantime, DevOps teams should revisit workflows because more untested code is finding its way into production environments than most DevOps teams would care to admit. As it becomes simpler to both create and run tests, there increasingly becomes fewer valid reasons for not running those tests. After all, one issue discovered in production can negate return on investment (ROI) that a DevOps team might have delivered using AI tools to write code faster.

Of course, not two DevOps teams have the exact same level of maturity. There are a few organizations that have dedicated teams that religiously test every line of code, while others assume individual developers have taken on that responsibility. While developers should test their code to some degree, there is always going to be a need for third-party validation. No developer is going to understand all the possible permutations of a potential vulnerability in their code. The issue, as always, is determining how best to strike the right balance.

June 4, 2026
From the Trough of GenAI Disillusionment – a Bright Spot?
“GenAI: too much spend, too little benefit?”

That’s the question Goldman Sachs asked in an influential report this summer.

It’s safe to say we’ve entered a trough of AI disillusionment. Some companies are laying off staff, while others are being targeted for acquihire (for example Character AI by Google, Inflection by Microsoft, and Adept by Amazon). These factors combined with swings in tech stocks indicate that the market has yet to make up its mind when it comes to valuing AI.

Despite the uncertainty, genAI has gained traction in several sectors, and engineers in particular have embraced AI coding tools like GitHub Copilot. Stack Overflow’s 2024 Developer Survey found that “76% of all respondents are using or are planning to use AI tools in their development process this year.”

With AI coding tools, software companies took the approach of testing first and asking questions later. Those companies are now taking a microscope to their investments and need to justify whether their spending on coding assistants is paying off.

Continued Uncertainty Around Performance and Pricing

Earlier this summer, Jellyfish introduced the Copilot Dashboard to measure the impact of the most widely adopted genAI coding tool. We’ve since gathered data from over 4,000 developers at more than 100 companies, giving us a representative sample of how engineering organizations are using Copilot and what impact it’s having on production. No two teams are the same, but the aggregate data can help engineering and business leaders understand whether they’re getting adequate return on their AI investments.

Without measurement, engineering teams can only gauge the value of their investment in terms of engagement. Are the engineers using Copilot? Sure. But are they faster or more productive? Is the code better, or is that speed coming at the expense of quality?

Pricing for these tools is another potential variable. In October 2023, The Wall Street Journal reported that Microsoft was losing $20 per month per user on its GitHub Copilot product. GenAI coding assistants like Copilot rely on LLMs to drive their service, and the cost of querying those LLMs isn’t cheap! Providers of AI coding tools will inevitably make corrections to their pricing, and software companies will have to decide all over again whether they’re getting value for their investment.

After analyzing aggregate data from Jellyfish’s GitHub Copilot Dashboard, here’s what we found:
- Coding is faster, leading to time savings: Across the board, developers are writing code 23% faster. This impact varies by role. For example, mobile developers and backend developers experience more substantial gains, with coding speeds improving up to 42% and 38%, respectively.
- Coding throughput is increasing: Engineers using Copilot saw a 20% increase in pull requests (PRs) created across all engineering work, meaning, in layman’s terms, that these engineers are pushing more code (and therefore more product) out into the world.
- Junior developers see the largest increase in speed: Across all engineers, Copilot is giving junior developers a 4X boost in coding speed. This implies that Copilot is more useful for automating entry-level tasks and less useful for the more complicated work tackled by senior developers.
Where We Go From Here

We’re in the trough of disillusionment of the genAI hype cycle but there is a bright spot. The technology will continue to develop, and more targeted solutions like AI agents have the potential to disrupt markets more than general AI tools.

Copilot is a transformative tool for software engineering, but organizations must be realistic about its limitations. Coding is only a fraction of what engineers spend their time on in the entire software development life cycle. The first measurements we’re seeing of Copilot adoption show meaningful boosts across different roles and workflows in software organizations. Taken together, these boosts add up to time and cost savings that more than justify the investment now while setting organizations up to realize larger downstream gains in the future.

Regardless of what happens in the months to come, companies can’t afford to experiment without measurement. The “trial and error” phase for genAI is over; we need to verify whether the investments are paying off. Experiment, measure, adjust, repeat.
October 9, 2024
Does More Money Improve Open Source Security?

It sounds simple: If you pay developers more money, they’ll improve the quality of their code, right? The evidence isn’t so clear.

There has been little direct evidence that paying open-source developers results in more secure code – until now. The Atlantic Council’s Digital Forensic Research Lab (DFRLab) recently showed a correlation between funding for maintainers and the security of open source code.

Specifically, the researchers found “prima facie evidence of a positive effect of general open source software funding on open source software security.” They looked at the 1,000 most downloaded Python Package Index (PyPl) and npm JavaScript packages. Using Open Source Security Foundation (OpenSSF) tools such as “funder-finder” and the “Security Scorecard” the researchers saw a connection between financial support and security enhancements.

That may sound like an obvious conclusion, but the evidence was not as clear as you might think. The researchers report with only “moderate confidence” that a meaningful connection exists “between more open source project funding and improved security posture. …[M]ore funding generally correlates with more dramatically differentiated security practices.”

This seems to go against common sense. As Dana Wang, OpenSSF’s Chief Architect, said, “Balancing the security, reliability, availability, performance, and cost of open-source software is not trivial. Maintainers sometimes have to choose between new features, bug fixes, and less critical security patches.” And, even after such open source project security fiascos as Log4J, as we all know, security all too often comes too low on developers’ priority list.

Still, other research, such as programming security company Tidelift‘s 2023 State of the Open Source Maintainer Report, showed that “paid maintainers were 25-30% more likely to have completed the [security] work or plan compared to unpaid maintainers. On every development practice surveyed, paid maintainers were significantly more likely to implement it than unpaid maintainers.”

Sometimes security fixes are needed and available, but corporations aren’t adopting them. In another study from Synopsys, the 2024 Open Source Security and Risk Analysis Report, not quite half of codebases contained open source components with no new development in the last two years; 91% contained components ten or more versions behind the latest version. This is a failure by open source users, not underpaid open source developers. Bad companies! Bad!

Returning to the DFRLab study, its researchers also found that diversity in funding sources appeared to be beneficial. That is, projects with multiple supporters apparently do better (with security at least) than those with a single backer. This suggests that investors should look at a variety of support mechanisms rather than solo-source funding.

One reason why the results are so fuzzy is that we don’t have enough data. As the DFRLab crew observed, the “OpenSSF Scorecard tool itself has several quirks… Scorecard does not necessarily capture all the security improvements that might occur during a project. For example, a security audit, paid for voluntarily by maintainers who received funding, might look for and remediate new vulnerabilities while likely not directly improving any Scorecard metric. Some practices may also meet OpenSSF criteria in principle but be missed by the automated scorecard check. For example, a project might include a strong security policy but with a different filename than what the scorecard search is looking for, and thus not pass the subcheck.”

As DFRLab states, we need more research to understand how funding affects security. No one can really doubt that more money helps, but the most effective way to fund projects, maintainers and developers – and how we should measure the results – remain unclear.

Given how critical open source security is to all of our technology, the sooner we figure it out, the better.

Photo credit: Jonathan Kemper on Unsplash

May 13, 2024
Paying Your Dues

April 24, 2024
Leaders in Resilience See ROI From Observability

Observability is maturing throughout the software industry. Observability is often defined as merging metrics, logs and traces to get a fuller picture of an application’s state. This can help pinpoint disruptions or security incidents and offer a clearer path to remediation. Observability is touted to advance the application monitoring practices of yesteryear, but are investments paying off?

According to recent findings, many organizations are using observability tools and seeing a positive outcome. A full 73% of organizations reported using observability tools for over a year. And impressively, 86% of observability leaders said the ROI on their observability tools has exceeded their expectations. The practice appears to be paying dividends for organizations that have gone “all-in” with mature observability processes.

The State of Observability 2023 report released by Splunk demonstrated how observability leaders are reaping a positive return from observability tools. According to the report, observability is helping to meet performance expectations, avoid downtime and enhance resilience in general. However, not all organizations are on the observability maturity bandwagon. Below, we’ll examine some of the key trends from the report and consider the benefits of refining your observability efforts.

Trends Around Observability Efforts

Now that observability is more commonplace, dedicated roles are emerging to support these initiatives. In fact, 87% of respondents now employ specialists who work exclusively on observability projects. Site reliability engineers likely make up a portion of these experts, as observability data can be used to advance efforts around meeting service-level objectives (SLOs).

But although observability might be more common than a few years ago, not every observability practice is mature or standardized. Just 40% have a formal approach to resilience that has been institutionalized organization-wide. Because of this, only 43% are confident in their team’s ability to meet its application reliability and performance objectives. It should be noted that this number increases significantly for those with more mature observability adoption, which we’ll expand on below.

Furthermore, not all applications are cloud-native. Organizations reported operating and maintaining, on average, 165 internally developed business applications, half of which are hosted in the public cloud and half of which are on-premises. Due to the persistence of legacy modalities, observability tools must continue to support a hybrid architecture if they are to be comprehensive and useful.

And although we’ve previously covered how many organizations are drowning in a sea of observability data, observability leaders now say their ROI on observability tools far exceeded their expectations. Perhaps this indicates that, with more open standards, analysis centralization and fewer false positives, teams are finding ways to avoid observabiliy tooling sprawl.

Lastly, the report unveiled desires to loop AI and ML into the observability pipeline. In fact, 66% of observability teams already use AI/ML, while 26% are in the process of deploying the technology. And 91% said AIOps is an important enabler of their observability goals. Certainly, AI is becoming a pervasive instrument to accelerate many areas, including observability.

Benefits of Observability

An impressive 64% reported that their investment into observability has exceeded their expectations. So, what are some of the top benefits of observability? Well, the report found the topmost benefits to be areas like decreasing problem detection and resolution times, identifying “true positive” incidents, and enhancing application security.

Observability is being deployed as a tool to evolve traditional security efforts, as it uncovers a deeper understanding of application behaviors. This can help security teams correlate errors to specific diagnoses and spot potential threats in a quick manner. As such, 59% said observability helps them uncover security issues thanks to the intelligence capabilities of observability solutions. And 55% say they can uncover more security vulnerabilities thanks to the visibility afforded by observability.

Observability can also be used to improve visibility into hybrid architectures. A full 86% said it’s important to have flexible observability solutions that cover hybrid architectures, though half identify this as an area for improvement. Although we like to think that cloud-native development is the status quo, many enterprises still oversee a mixture of on-premises, private cloud and multi-cloud environments. A unified, agnostic observability layer is thus essential to peek into all these disparate environments to grapple with disparate data outputs.

The Leaders of the Observability Pack Win

Service interruptions can have negative consequences for organizations, including lower customer satisfaction, loss of revenue and loss of customers. In fact, 76% of respondents reported downtime can cost up to $500,000 per hour.

Thankfully, observability has emerged to help improve overall resilience and avoid these negative repercussions. But, to truly reap the benefits, you must have a mature practice in place. As defined by the report, “observability leaders” have a more formal approach to resilience and have standardized this across their organization. And 89% of those leaders are completely confident in their ability to meet their application availability and performance requirements. The catch-22 with observability is that you must invest more energy into formalization and knowing when the effort is worthwhile is a moving target.

A solid observability practice is supported by standardized metrics, logs and traces across the organization. Furthermore, to make observability behave correctly, you will need flexible tooling that can leverage data from multiple sources, such as the network, infrastructure, servers and databases.

The State of Observability 2023 report surveyed 1,750 observability practitioners from around the globe, making it the most extensive study on observability to date. For more insights, you can pick up a copy of the report behind an email gate here.

June 20, 2023
DevOps Ascending: Guardrails, Not Guidelines – DevOps For Digital Leaders

The season of DevOps is upon us, if not only related to widespread adoption, then certainly in terms of industry emphasis.

This week, at the CA World ’16 conference, my colleagues and I will be interacting with thousands of practitioners, all of whom have evolving DevOps narratives. Meanwhile, CA was a founding sponsor of the AllDayDevOps conference, held earlier this week, attracting more than 12,000 registered attendees worldwide.

These events come on the heels of a successful DevOps Enterprise Summit held last week in San Francisco, where many of the industry’s brightest minds gathered to discuss and debate the current state of play. If activity is a reliable indicator of relevance, the growing noise around DevOps adoption has been amplified into a deafening roar.

All of this stands as further evidence that DevOps is no longer an emerging phenomenon, but rather a ubiquitous movement transforming the manner in which nearly every organization builds and operates software.

As a result, the DevOps movement is finally ready to move from initial framing of emerging techniques into the domain of defining best practices. Yet, at the same time, given the fluid nature of DevOps itself and its unique correlation with the individual needs of every business and environment, even this notion of best practices is one that mandates flexibility.

Increasingly, we hear leading experts in the field espouse the need for these practices, but those that serve as “guardrails” that set useful parameters for DevOps adoption and refinement rather than concrete guidelines that dictate specific requirements.

Such is the tone and goal of the new book that my co-authors Kieran Taylor, Peter Waterhouse and I released this week to help practitioners understand common DevOps challenges, methods and milestones.

Titled “DevOps for Digital Leaders,” the book examines the genesis and increasing maturity of DevOps, all with the explicit intention of helping to inform further refinement among today’s organizations. After reading it, I’d argue that any practitioner, from total neophytes to hardened DevOps vets, should walk away with a greater understanding of how to bring today’s best practices to bear within their own work.

Beyond looking at precisely how DevOps has grown in response and parallel to use of agile methodologies in the world of manufacturing thereby transforming the modern software factory, the book offers specific examples of leading adopters that are using these techniques, and related tooling, to re-engineer the very DNA of their business.

From the core competencies of building, testing and deploying applications to continuous monitoring and management of software to help stay attuned to changing customer expectations, we sought to offer a practical guide to DevOps transformation. Other chapters touch on finer points related to key topics including creation of success metrics and measurement of ROI.

In one of the analogies invoked throughout the book, we highlight how DevOps-empowered software factories are not unlike the engineering, design and race day teams present in the world of today’s Formula One racing series.

Pushing themselves and constantly innovating on the fly—clawing for every second in the name of winning the overall title—the comparison fits nicely as we watch this season’s contenders fight it out down to the final race in Abu Dhabi later this month. As with winning customers in today’s applications economy, clearly every little bit counts.

Again, no matter what—or how much—you think you know about DevOps, we’d like to think that there are tactical “learnings” sprinkled throughout the book that will broaden and deepen your understanding.

Download your copy today, and let us help drive you down the road to victory. Alternatively, you can order a hard copy of the book via Amazon, with all proceeds being donated by the authors to fund Foundation for Excellence, which provides STEM scholarships to children in India.

— Aruna Ravichandran

November 16, 2016
The Real ROI of DevOps

Many established enterprises are stuck in reverse. Dragged down by legacy IT systems and sclerotic software workstreams, these businesses simply cannot adapt and get up to speed in the continuously changing, high-velocity global marketplace of the 21st century. Delta Airlines’ recent technology crash, for example, dramatically illustrates how aging and inflexible IT systems can cripple a company in 2016 and lead to millions of dollars in lost revenue, as well as the dissipation of a hard-won reputation among customers.

But an increasing number of organizations are accelerating their cultural transformations to become software-led companies that can consistently deliver new products and services as a result of automated and collaborative workflows. Alaska Airlines, which focuses relentlessly on measuring the innovation velocity of its business, is a powerful case in point.

This is DevOps at work, and it’s how IT must operate to be the business engine of our quicksilver digital economy.

Measuring the return on investment (ROI) from DevOps is critical to convince organizations falling behind that they can still shift course, transform and head to the IT future. Measuring DevOps ROI is also essential for companies that are embracing the industry’s forward movement, so they know if they’re on the right track and can keep turbo-charging their DevOps efforts.

The most proactive approach for measuring DevOps ROI is to gauge the impact of products and services on customers. But, to get there, we must also assess and analyze the efficiency and effectiveness of the software development process.

Which brings us to the one metric that’s truly relevant in business today—velocity. Without velocity, you can’t quickly recognize and remediate problems. More significantly, you’ll fall behind in the marketplace because you can’t innovate fast enough to keep pace with competitors and customer demand.

Enter DevOps: The culture of innovating at velocity.

Of course, that’s easy to say, difficult to measure. The real ROI of DevOps is how rapidly you can ship your new ideas to customers—and, importantly, understand if those ideas meet customer needs.

Many may look at cost savings and headcount as their first DevOps metrics. These are important barometers but don’t measure long-term value back to the business. Two places to start for value-oriented metrics are time to delivery and quality of release.

Measuring time to delivery shows how long it takes to get new product from code checking to production. Ideally, you want to see your time to delivery drop from months to weeks to days, and then literally to hours and minutes.

Quality of release reveals how many bugs and errors are found in each iteration of the product. Companies should look to remedy these immediately and to develop a pre-production environment and workflow of automated testing for issues.

It’s equally important to measure how rapidly you can get feedback from customers and incorporate that into the next development cycle. Development teams must get clear, direct and actionable feedback about whether their products are moving the business forward. For example, did the two-week sprint to build a new landing page for a bank’s website increase customers’ online banking sessions? Did it generate more cross-sell for the bank’s product portfolio? How soon can we see an uptick in customer satisfaction? This is significant information, and the question is, how fast do the developers respond to this feedback?

The bottom line is that DevOps metrics should always connect back to the business; they need to show a measurable improvement in the customer or staff experience. This could be more quality touchpoints with customers, an improved customer satisfaction score (such as a Net Promoter Score) or increased customer activity in areas such as online billing or account management.

“Delivering on the final product is key,” says Adam Mikeal, director of Information Technology at the College of Architecture, Texas A&M University. “Your job’s not done if the customer can’t accomplish what they want. If the customer can’t do it, it doesn’t matter if your section of the code was good. The customer experience is all that matters.”

Another important part of this equation is measuring your team’s efficiency on the road to velocity. To truly ship ideas at speed, and positively impact your business and its customers, you also need to understand how smoothly your teams are working—in addition to how quickly they’re delivering.

Banks Cash In on DevOps

Westpac Bank in New Zealand fully grasps this imperative, for example, and it enacted DevOps practices to deploy a new pricing engine for mortgages in just three months—from concept to customer. In the past, this project would have taken Westpac 18 months.

Additionally, Westpac measures how well it’s using resources—for every $1 spent on a problem, how much is chewed up by politics and how much actually goes to solving the problem? Before adopting DevOps practices, Westpac was delivering a return of about 20 cents to 22 cents. Now, that number is just shy of 40 cents. That’s a near-2x increase in the value delivery. Westpac’s goal is 3x. In addition, Westpac has increased the amount of work its development teams accomplish by more than 40 percent over the previous year.

Like Westpac, Standard Bank in South Africa has boosted efficiency, thanks to a thriving DevOps culture. The cost of production at Standard, for example, has dropped from about $4,000 to $700—a 300 percent improvement.

The goal for companies in every industry and economic sector around the world today is clear: Accelerate your business so that you create and provide greater—and faster,—value for the customer. But, to drive a robust ROI on this journey, it’s crucial that you carefully measure the true velocity of your organization, whether you’re just beginning with DevOps or you’re well along in the transformation.

— Justin Arbuckle

October 26, 2016
State of DevOps Report: Reaping Results

The newly released 2016 State of DevOps Report concludes that DevOps is “no longer a mere fad or buzzword,” but rather an established set of practices and cultural patterns. Yet, a closer look at this year’s findings reveals progress is far more substantial than any matters of perception.

The report was conducted and analyzed by the experts of DevOps Research and Assessment (DORA) and sponsored by CA Technologies. Among its findings is proof that high-performing organizations that have embraced agile and DevOps methodologies deeply are outperforming massively those that have not. And the gap is widening.

The State of DevOps Report also shows leading DevOps practitioners are appreciating benefits that span nearly every area of their business. If I know my colleague Gene Kim, he will assert this point exuberantly on our upcoming State of DevOps Report Webcast.

It’s noteworthy that high performers are surpassing incredible milestones related to core elements of the applications life cycle. Examples include deploying code 200 times more frequently than low performers, driving 2,555 times faster lead times, 24 times faster recovery times and producing three times lower change failure rates. This is evidence that DevOps is having the desired outcome on applications delivery, software quality and organizational velocity. It also shows organizations truly committed to wholesale transformation of culture and process are actively succeeding.

At the same time, the State of DevOps Report shows employees working at organizations enjoying this success are more satisfied with their jobs and more closely engaged with their companies. Chalk this up to the halo effect of operating in a fundamentally more sensible, innovative fashion. Cultural change is undoubtedly the greatest hurdle to DevOps advancement. Here’s proof that if you can navigate the process, your workers will be happier and more productive.

Using Employee Net Promoter Score (eNPS) as a barometer, the report finds that employees in high-performing organizations were 2.2 times more likely to recommend their organization as a great place to work. They also were 1.8 times more likely to recommend their team as a great working environment. Previous studies have found that such an air of positivity can be directly correlated with improved business outcomes, researchers noted.

Shifting the manner in which you build applications to better adapt to changing customer expectations is a necessity. That’s what began driving this movement years ago. That said, proof it also makes it easier to keep valued software engineering and IT operations employees should not be overlooked.

In addition to positive conclusions on the impact of continuous delivery and improvement of test data management, the report offers some important metrics related to return on investment. This is nothing short of landmark, as for decades we have struggled to make a hard case for IT investment beyond implied competitive advantage. It actually was impressive that last year’s report highlighted such a “predictive relationship between IT performance and organizational performance.”

One such new measurement of note is that high-performing teams occupy the least amount of time responding to unplanned work and rework—efforts widely recognized to be results of flawed processes. On a related note, DevOps leaders spend 49 percent of their time on new work‚ surely, in many cases, the next “must-have” feature which impacts competitive standing and, ultimately, the bottom line.

This report is fantastic. It reaffirms powerfully that so many of the promises made about DevOps over the last few years are neither hype, nor overstated. The gap between the leaders and laggards is growing. Industry landscapes and business models are being redefined.

This is critical transformational work that every organization must adopt to survive.

Are you on board? Download the full State of DevOps Report here.

June 23, 2016
Budgeting for DevOps Success

One concept that seems to be universal across all IT departments is the admins lament of “how do I convince my boss that we should spend the money.” Whether it is security, QA or development tools, technical professionals have a difficult time talking the language of the business to justify the expenditure of always scarce dollars. So why should it be any different with DevOps?

The good news is that in DevOps unlike some other IT disciplines we can actually show some ROI (sometimes anyway). Nothing will convince a financial stakeholder that spending money is OK faster than if you can show it will allow the organization to either save money or make more money. But how do you show ROI with DevOps. There is more than one way to skin that cat.

This coming week I am hosting a webinar that will explore the various ways of showing ROI using DevOps. We will also be looking at some case studies where ROI was demonstrated successfully. One of these organizations is HM Health Solutions. One of the interesting things in this case is that as a health care related organizations the usual compliance issues such as HIPAA often make things like automation and continuous delivery more complex.

I will be joined by Valerie Scott, Manager of Shared Services Division, HM Health Solutions who is going to relay first hand what she and her team have done to show their executive team how DevOps delivers a real, tangible and measurable ROI. Valerie is a seasoned exec and I am sure she will have some great insights.

In addition to Valerie I will also be joined by Rick Slade of IBM who has lots of experience with different organizations in showing the ROI of DevOps. I expect this webinar to be very informative. If you are grappling with how to justify a shift to DevOps in your organization I invite you to join us next Tuesday, June 2nd.

This webinar is sponsored by IBM. It is the third in the series we are doing on Variable Speed DevOps. Our previous webinars in this series have all been very interesting. You can listen and follow along to those here and here. The series deals with how organizations can do more faster even though not parts of the stack run at different speeds. It is not how fast they run individually, but how well they work together is the key.

So join me Tuesday as we discuss DevOps ROI and Variable Speed DevOps.

May 30, 2015
Communication: Who is to blame for misunderstandings?

Communication is everywhere and it is far more than only the spoken word and its origin meaning. Communication is one of the most complex and also complicated topics in human relationships: most of the time very thrilling, sometimes frightening but always important!

As we all grew up with communication, you might think, we should be used to communicating very well. But daily life shows us that misunderstanding is the companion of communication. We all know from our own experience how hard it is to clear up such misunderstandings and how much precious time is wasted on them!

The more people with different personalities are trying to communicate with each other, the higher the probability of misunderstandings.

To take a closer look at all those cross-functional teams like devops or agile scrum teams you will recognize at once that there are lots of individual issues because of misunderstandings in every team. Each single issue on its own is disrupting daily work, something we all know from personal experience. Now try to imagine how much of a team´s efficiency is taken away by the sum of all issues caused by bad communication and misunderstandings! It is unimaginable!

Communication is the link between all stakeholders: it determines the atmosphere in a team, the relationship between all parts, the understanding as well as the knowledge and information transfer. It influences the project times, the employees´ identification with the company or their work, individual responsibility and how to deal with mistakes. This list could go on and on.

Time in IT projects is one of the limiting factors. To save time and avoid mistakes, new tools are be developed again and again. Companies invest money in these tools; sometimes tools are integrated in the teams, sometimes the teams are arranged around the tools or systems. But the very human part – the communication – which is important for every team, no matter which tools or which systems are used, is seldom the focus of IT education! You can changes methodologies, systems and tools, but if you do not get beyond bad communication, you won´t reach the full potentials of all those efforts. No matter if you have already chosen your tools or systems or if you are still searching for the right way for your team, you should always think about the communication within your team. Instead of always asking what the ROI of communication courses will be, you should better ask what the ROI of all those tools and systems could be with optimized communication!

Before optimizing the communication you first have to find the bugs in the individual and in the team communication and eliminate them. Due to the inherent complexity, the support of an expert is sometimes useful. Just as not all people using computers are IT experts, not all people are experts in communication – even though they are communicating the whole time, sometimes even by saying nothing. Some are more gifted than others, some are able to learn by studying on their own and others need a little more time and support. Changing communication mostly means to change personal habits and this is always an extremely challenging requirement. Particularly for “brain-workers” like developers or other people from IT, it is very helpful to have some background information in combination with practical applications given by experts. First little steps of debugging the communication will soon be honored by success.

“First do it right, than do it fast!”, is a developers wisdom. Concerning the communication this wisdom could be changed into: “First debug your communication, then optimize it!”

Coming back to the question in the headline, it is not important to blame anybody for a bad communication. Everybody is responsible for it and instead of searching for the guilty one, you should start working on it. Be brave, start debugging you communication!

May 12, 2015