devopsy.kinsta.cloud

Tag: Business

  • The Business Case for DevOps Culture

    The Business Case for DevOps Culture

    Culture is nebulous. It encompasses all the behaviors and attitudes of an organization, from overarching business values down to the individual actions of an employee. Because culture is transient, it’s unique to every business, feels difficult to change and is even harder to measure. This can make it frustrating to see DevOps research continuously name ‘culture’ as the critical factor for DevOps success.

    Many teams are left wondering what a ‘successful’ culture looks like and struggle to pinpoint what changes they should make. While there isn’t a one-size-fits-all approach to cultural transformation since every business is different, there are three key traits of high-performing DevOps teams: Buy-in to the DevOps process, collaboration and continuous improvement.

    But even once you’ve identified how your team can embody these traits, it can still be difficult to put forward a case for improving culture when it’s so difficult to measure its returns. By linking each of these traits to measurable impacts on the wider business, it’s possible to make a strong business case for improving your DevOps culture.

    Buy-In Makes Your Business More Resilient

    No organization can foster a successful DevOps culture without buy-in from the whole team. Buy-in not only encompasses an understanding and acceptance of the DevOps process but is also a commitment to getting it right.

    Without cultural buy-in to the DevOps process, team members are more likely to circumvent established procedures. Following a DevOps process should overcome unnecessary downtime and failed releases, but neglecting the proper release management strategy will stop your team from seeing these improvements and hinder your ROI.

    Team buy-in to DevOps makes your release process far more resilient. With a common appreciation of and investment in DevOps, teams are far more likely to follow the planned and robust process. This attitude allows businesses to see far higher ROI. For example, Veolia, the energy and utilities giant, secured a 500% return on their DevOps investment within one year of buy-in to a new approach. Team buy-in is the first step you need to take in improving your DevOps culture—it’ll ensure the technical resilience of your processes necessary to secure ROI.

    Collaboration Makes Your Business More Efficient

    DevOps doesn’t just encourage collaboration between Dev and Ops teams—it encourages all team members to work together across functions and share responsibility.

    When only one team member has the expertise or responsibility required to move through a stage in your DevOps process, there’s a single point of failure. If this team member doesn’t have the capacity to unblock others, then the process is slowed and time is wasted. Collaboration and knowledge-sharing can overcome this bottleneck by empowering team members to handle a greater scope of the process. This avoids the significant costs that come with increased labor and missed opportunities by removing the pressure on individuals and drastically increasing the efficiency of the whole system. You’ll see an accelerated project delivery, which will be faster in getting value to your end users and see quicker ROI.

    Further, collaboration across the entire release process encourages all team members to remain mindful of compliance, which ensures you’re practicing DevSecOps at each stage of your release. Rather than handing development over to the dedicated compliance team once it’s complete, shared responsibility ensures that it’s baked into the DevOps process, saving time that could be needlessly spent at the end of development reworking to meet compliance stands. In the 2022 State of Salesforce DevOps Report, teams who self-reported as ‘excellent collaborators’ managed to avoid data and metadata loss in that year’s DevOps process, whereas only 25% of very poor collaborators could say the same. Excellent collaborators were much faster to restore when needed and significantly more likely to state that backups were their responsibility.

    To sum up, collaborative development teams are better at supporting the business growth needed to draw in customers. You’ll be able to sustain this growth, as efficient and secure releases will improve customer retention.

    Continuous Improvement for Your Team and Business

    Many teams only think about digital transformation when their process begins to fail, meaning the necessary changes require a disruptive overhaul of their whole system. Teams that nurture a culture of continuous improvement will make incremental improvements to their system, which avoids drastic ad-hoc changes and ensures the business will see continual value from gradual tweaks.

    It’s difficult to identify a singular ‘best DevOps system,’ as best practices are constantly shifting, but it is easy to realize that something could work better. Teams that reflect on their own systems and keep abreast of the latest tech trends can continually implement process improvements that amount to significant adjustments in the long term. This ongoing optimization of the DevOps process means no stasis and no need for disruptive and costly upgrades every few years.

    Developing your own team members not only creates a better DevOps process but also empowers team members to fill knowledge gaps, lessening the need for costly expert hiring or consultancy. Further, hiring and onboarding is a huge cost, which can be reduced by the morale and retention boost that comes with upskilling and collaboration. This will be critical as companies look at hiring freezes in the upcoming recession.

    Proving that small behavioral shifts can help maximize DevOps ROI will strengthen your business case for DevOps culture and create an agile team that can adapt as the landscape changes. Eventually, your DevOps ROI will become synonymous with your culture.

  • Break Open the Black Box of Software Development

    Break Open the Black Box of Software Development

    If you asked an airline executive what their biggest expense was just a few decades ago, they would’ve easily answered, “Jet fuel.” These days, you’d be hard-pressed to find an executive in any industry that wouldn’t answer with, “Software.” But here’s the difference: With jet fuel, that executive would have told you that they can fly x number of seat miles per gallon/liter of fuel (or pounds of fuel, if we’re being technical). With software development, the expense is becoming more material–and far more variable–but the return on that investment is rarely clear. Over the past decade or more, software development has readily assumed its position as the fastest-growing (and often largest) expense line item in virtually every industry. All companies are adding software experiences to or around their products, and they need the people and tools to build, support and continuously optimize those experiences. And that costs money–a lot of money.

    The problem is that the language, the metrics and the world in which software development exists do not translate into operational or financial terms that business leaders can readily understand.

    “We invested X million dollars into software development last year,” a CFO might say. “And what do we have to show for it?”

    Meanwhile, a technology leader might respond with, “We’re doing X deploys a day!” or, “We wrote X thousand lines of code!”

    They might as well be speaking different languages because, in practical terms, they are.

    And the problem is, that you can’t manage what you can’t measure. To continue our airline theme, software development continues to be a ‘black box’—this hidden-in-plain-sight source of information—that financial executives can’t seem to peek into.

    Why the Black Box?

    It’s not likely that technology leaders are being purposefully elusive toward business leaders–it’s more likely that they simply are not aligned on what, fundamentally, they need to do to speak the same language.

    The question at hand is, actually, “Are these investments we’re making turning into our desired business outcomes?” But the question technology leaders feel compelled to answer is, “What do your people do all day?”

    These are questions that Agile and DevOps don’t solve–translating Agile or DevOps metrics (also known as DORA metrics) into actual, actionable metrics for business leaders to understand. Although these metrics are tremendously useful for teams, using them to steer the business is a mistake.

    Misaligned in purpose and using different language, business leaders and technology leaders talk past each other as software development costs continue to rise.

    But the cost of software development is too high for business leaders to continue to tolerate this ‘black box’ of ever-rising costs. It’s the fiduciary responsibility of financial leaders to understand the value of software investments and figure out how they are affecting business outcomes–or their jobs could be on the line.

    In case this seems like a distant threat, it isn’t: I saw a headline recently about a prominent automobile executive who lost their job because they weren’t able to gain the necessary insight into, and business outcomes out of, their significant software development costs and that was affecting the competitiveness of their entire company.

    It’s happening. And it’s on both business and technology leaders to break that black box open and start speaking the same language.

    The next question, of course, is, “How?”

    How to Bridge the Communication Gap Between Technology and Business Leaders

    For far too long, business leaders have made do with the activity metrics provided by technology leaders–they’ve tolerated this lack of visibility and found other ‘strategic’ ways to justify the rising software development costs. Perhaps they’ve been questioning how A leads to B–how an increase in funding for software development might result in greater customer retention or app usage, for example–but they have not had a tangible way to prove to themselves, much less to investors, whether this is actually happening.

    In order to understand and quantify software development costs, we have to start demanding more from our technology leaders: Working with them to establish realistic objectives and key results (OKRs), and holding them accountable to business metrics that actually relate to outcomes. That means insisting on business results–and not accepting activity metrics in their stead.

    Stable-Fund Products, Not Projects

    Here’s a hard pill for finance to swallow: When it comes to delivering software-enabled customer experiences, it’s not about optimizing costs. It’s much more nuanced than X dollars in equals X dollars out. Funding by projects might help make the numbers neat, but it doesn’t reflect the reality of the business.

    Project-based funding also tends to keep project leaders in a cost-center mentality: It makes it seem as though all resources are fungible; as if the work and the people performing it are interchangeable.

    One of the goals of Agile is to maximize value for the customer. But when we fund by project, we often stop funding a piece of work–declaring it done–before it actually starts generating value. We have this false end date that doesn’t reflect the actual ending of the value that we funded to create.

    Instead, finance organizations should move to the stable funding of products: Funding an outcome and giving teams the ability to stop, change or extend their work to achieve the business outcomes of the product.

    This is a shift that one prominent UK bank has been going through in recent years–from traditional portfolio management to lean portfolio management, including the shift to stable-funding projects. You can learn more about how NatWest Group (formerly Royal Bank of Scotland) has made this shift in this webinar.

    Visualize the Flow of Value with Flow Metrics

    Finally, we have to stop treating the collection of technology metrics and business metrics as two separate, unrelated efforts. Agile and DevOps are great at accelerating the throughput of your software development … but vanity metrics around how quickly teams are delivering are not enough to justify the growing and material investment in software development.

    Finance leaders have the opportunity to be the Babelfish between technology leaders and business leaders. As mentioned above, one way to encourage clearer communication between teams is to use OKRs to naturally tie software development objectives to tangible business results. The more we practice drawing connections between technology and business metrics–the closer we get to finally breaking open that elusive black box.

    A key part of this is communicating operational metrics differently: Developing a core set of metrics for tracking the flow of business value in software delivery, and providing a mechanism that correlates the investment in flow for each product’s value stream with the business results for that value stream.

    Visualizing the flow of value in a software development process may not be as easy as watching value flow on a manufacturing floor–but that doesn’t mean it’s impossible. Thanks to the vast number of data and visualization tools at our disposal, it is possible to make software products and their value streams just as visible as production lines.

    The Flow Framework, created by Dr. Mik Kersten, addresses the pivotal challenge of breaking open the black box of software development and bridging the gap between business and technology to optimize the flow of business value to customers.

    Break Open the Black Box with Value Stream Management

    The black box of software development is, at its core, a communication issue. It’s on both business and technology leaders to bridge this communication gap. Business leaders need to demand more from technology leaders and insist on translating activity into business metrics. Technology leaders need to practice tying their efforts to tangible business outcomes to help justify their growing expenses.

    Of course, it’s helpful to have tools purpose-built to facilitate this visibility and communication.

  • A Poet’s Defense

    A Poet’s Defense

  • Tips for Successfully Adjusting to Life as a Project Manager

    Tips for Successfully Adjusting to Life as a Project Manager

    When you switch to a new work environment, it takes time to adjust to the new surroundings. As a project manager, you have to be ready to lead your team on the path to success while ensuring a good system of supervision and support. At this stage of your career, if you are feeling a little tense, you are not alone: Many managers often feel anxious about adjusting to being a business manager. You need to spend more time to develop the characteristics of a good manager so that you can handle the most delicate responsibilities in the business. Here are several highlighted tips to successfully adjust in your role as a business project manager.

    Source – Pixabay

    Learn Team Management Skills

    There is no doubt that independent work has its own importance in an organization, but you cannot ignore the importance of teamwork. The idea of team management is to develop a supportive and collaborative company culture by encouraging team members to work together. Make some efforts to encourage communication within your team and provide a proper channel for feedback. In addition, take the time to organize individual meetings to build trust and a higher sense of responsibility in your team members.

    Implement a Growth-Oriented Approach

    Every project manager needs to work diligently to help employees progress on an individual level as well as on group level. Every great business needs a good leader to grow, so it is important to establish healthy personal relationships with all members of your team so that you can know more about their interests and hidden talents. Effective managers always make efforts to facilitate a growth-oriented approach for overall employee development—this, in turn, pays off in the form of greater productivity and team chemistry.

    Follow an Inclusive Process

    Although you want your team members to take risks and be proactive in pursuing project goals, it is also important to help them feel comfortable in doing so. Make efforts to motivate team members and create an inclusive work culture. Let your team raise their individual ideas, opinions, and concerns so that they can find easy ways to cope with challenging work conditions. When team members have the flexibility to start a conversation and share their feedback, they can be more innovative in tackling challenging projects.

    It is easy to feel anxious as you step into the role of a project manager for the first time. The direction of the team and how projects are completed will be based on your ability to lead. However, the primary approach to reducing these types of feelings is by focusing on building and molding your team. To paraphrase Benjamin Law, owner of Crazyleaf Design: By prioritizing your team interests, highlighting every member’s unique skills and creating an integrated work environment, you can better adjust to being a project manager. These can contribute to being a more successful manager in the long term.

    — Wendy Dessler

  • How IT is More Like an ATV Than a Sedan

    How IT is More Like an ATV Than a Sedan

    There is an analogy for IT being like a car and it often goes something like this:

    IT should run like a well-oiled machine. I don’t get in my car and think about how it works, I just work some controls and it does what I need it to and it goes where I need it to go. No assembly required!”

    When people think IT, it seems they’re hoping for their IT department to work like a Tesla luxury sedan that drives for you. They like to think of IT in this “it should just work” kind of mentality. The internal dialogue of some may be, “I have this goal, IT is this tool to get it done, and I have paid for it! It should just work by itself! Heaven knows, I have spent enough on it!” They want something that’s comfortable, doesn’t require much interaction and gets them where they need to be.

    The problem with the sedan metaphor is that sedans are not really what companies need.

    Sedans are built for paved roads, made to go to places that others often go. The average sedan can’t really explore much else other than what is well-paved and well-traveled by others. They’re a comfortable ride for drivers who want all the amenities of the home wherever they are. Anything too far off of the beaten path and the car is being torn to pieces by the rough terrain. Sedans perform consistently and reliably in consistent and reliable environments.

    This is not to say that IT should not be reliable. By all means, IT has to be reliable. If IT isn’t operating reliably, much like a broken car it should either be fixed or replaced. Why would anyone pay for something that can’t perform the tasks you need it to do?

    However, organizations know they have to take calculated risks, and the larger the risk, the larger the payout. This means going into unfamiliar territory and going down paths that are not mapped out. Even a Tesla is going to struggle over terrain that isn’t already mapped out.

    On top of that, we know customers and technologies are constantly changing. There is very little consistency from the world outside of the enterprise. Every day brings new fluctuations and challenges that companies need to anticipate and adjust to.

    So why do we expect IT to behave in a consistent way when the environment around us is constantly shifting? We can’t act as though our business can succeed riding around in a comfortable sedan! We need something that can be flexible and can still move us forward.

    Think ATV, Not Sedan

    The ATV fits this kind of unpredictability perfectly. ATVs can adjust to a variety of terrain. They don’t need paved roads nor beaten paths. They can go almost anywhere and can get there quickly. These machines are rugged; they can adjust to a variety of terrain and, most importantly, they can go anywhere—if the driver knows what they’re doing.

    But ATVs are not comfortable. An ATV takes knowledge to drive and it takes engagement. One can’t sit back disengaged and hope to have a smooth ride on an ATV that is going full speed. The places these machines are made to go are not for the complacent or for those seeking comfort.

    The business-IT relationship should look more like an autocross driver and his ATV than a suit in a Lexus. In this analogy, both machine and driver are adjusting in unison to the environment around them. The driver (the business) guiding the ATV (IT)  where to go and pushing through hills, mud and dirt to make sure both arrive safely and quickly despite the dangerous and uncertain environment around them. At the end, the driver and his machine will have pioneered places many feared to tread and will be rewarded appropriately.

    To extend the analogy, this is not a problem only between business and IT; this is the same attitude Dev often takes with Ops. Dev says, “Here’s a build, your environments should be good enough,” and Ops is expected to just make it work. Isn’t this the same disconnect as the IT and the business?

    It is so important to collaborate in a large enterprise. It takes investment of not just money but also time. If we have an agile team with no product owner, we essentially have a car with no driver. If we have Devs who don’t talk Ops, don’t we have a car body with no engine?

    In today’s world of Agile and DevOps, the companies that build that bridges between Devs, Ops and the business are the ones who take the calculated risks and succeed. These companies win bigger market shares and know confidently what their customers need. They can experiment fast with different business ideas, use the latest and the greatest technology and not comprise on security. These same companies can leverage their IT function to accurately monitor spending while minimizing waste.

    When businesses interact with IT, they shouldn’t just toss something at them like an external vendor and expect quality. Collaboration and engagement is the key. When all the necessary members in an organization are talking, communicating and engaged with one another, then we begin to see the true power of IT.

    The power of IT is the ability to go over terrain that would destroy other organizations. It is the ability to set any vision and know that your people will have the tools to tackle whatever comes their way. It is the ability to adapt, change and continuously improve while watching organizational goals become reality.

    About the Author / Caleb Wolfe

    Caleb is an IT professional with a passion for DevOps and transforming the way IT organizations work. As a member of Delta Air Lines, Caleb has a variety of experience from working as a baggage handler, business analyst, software developer and as a technical analyst in IT transformation. Caleb uses his multidiscipline experience to identify and remove constraints, create effective throughput and work to break down barriers both internally and externally. Caleb is a perpetual student of process improvement and IT technology and uses his knowledge for the betterment of Delta’s employees and customers worldwide.

  • Lean Security: How Better Development Can Protect Your Business

    Lean Security: How Better Development Can Protect Your Business

    If companies are to reach their strategic goals—reducing time to market, boosting sales, improving product market fit and brand image, and cutting cybersecurity costs—then it’s time for a new outlook on software security.

    Today’s business leaders must learn to see security for what it is: A differentiating factor. Companies with reputations for secure developmental processes and infrastructure will rise above those known for data breaches.

    Security as a Business Strategy

    The road to a more secure company—and realizing the perks associated with it—begins with lean security. This is an approach to information security similar to the Toyota principles of management and production that calls for environmentally aware engineering, simplified coding, automation of security checks and constant incorporation of feedback.

    Although some business leaders believe organizational security is inherently expensive, lean security doesn’t mean massive costs. Much like DevOps, lean security champions process improvements and cultural changes above purchasing new tools.

    Lean security does, however, require engineers to keep its principles in mind throughout the development process. In this way, security is much like sales: A sales representatives’ best strategy is to consider his goals from the beginning. Just as the salesperson isn’t trying to make any sale, the engineer isn’t trying to create just any product. For the salesperson, this means tweaking the sales process—perhaps by vetting leads before engaging them—to make profitable sales. For the software engineer, it means structuring the development process through lean security to create secure products.

    Done right, lean security results in a self-defending, simple system created by people who are aware of a product’s real-world security risks and the company’s business goals. Lean security recognizes your company’s data is always at risk, no matter the size of the company or team, and it works to create value through systemic protection. Here’s how to start:

    Improve Environmental Awareness

    Lean security approaches risk management as a team effort. Think about a hospital. Everybody working there — from the cooks to the nurses to the executives — has a responsibility to take care of patients.

    Software firms must function the same way: Everyone from engineers to salespeople to the CIO must keep data privacy, software security and business needs in mind throughout product development and a product’s life cycle.

    Environmental awareness means addressing security with the same sensibilities that you would your own life. Just as you don’t hand your credit card to random people, neither should you hand the keys to a software engineer who doesn’t know the risks of insecure development.

    More secure coding begins with a change of mindset. Once team members understand a product’s security risks, they start thinking about how to create a more secure environment. If a developer is creating a mobile app for a car, for instance, then they must recognize the app will be used in conjunction with a device that carries human life.

    Simplify Engineering

    Complexity is the enemy of security. Simplification, however, cannot just be limited to lines of code: It means organizing your teams—and thus, your entire system—in a way that improves time to market and tightens feedback loops.

    DevOps is a great way that business leaders can improve security through sensible reorganization. While the integration of development and operations teams has been lauded as a security boosting measure by software leaders at companies including Dell, CA Technologies recently studied DevOps’ business benefits. It found companies that have implemented DevOps techniques are 2.5 times more likely to improve customer retention, twice as likely to grow their revenues and 3.4 times more likely to improve their market share.

    In short, keep teams compact and agile and design with the end in mind. The more lines of code you add, the more complex teams you create and the more times you reinvent the wheel—and, ultimately, the less secure and less profitable your company’s products become.

    Automate or Die

    Automation is an essential component of lean security, and DevOps engineers are no strangers to automation. Threats are constantly increasing, and no engineer—or team of engineers—can discover and remedy them all manually.

    Look to Netflix for a great example of automated security. Once upon a time, Netflix addressed malware alerts by manually creating a help desk ticket and assigning an engineer to investigate the problem. The time from alert generation to eventual resolution, according to Netflix, often spanned more than a week. As Netflix’s security challenges increased in both diversity and complexity, it found itself spending exponentially more time and money combating these threats.

    Then, Robert Fry, Netflix’s senior information security architect, came up with a brilliant solution: He engineered FIDO, an orchestration layer that automatically evaluates, assesses and responds to security threats. FIDO detects threats, then scores them based on the attack’s intended target and other factors. FIDO then attempts to mitigate the event by closing a network port, ending a VPN session or disabling the account.

    Tools such as Netflix’s FIDO automatically detect risks in seconds, while it could take a human months to stumble across them. Think of security automation like a home security system: ongoing, vigilant security without the need for continued manpower.

    Measure Everything

    Although its origins are disputed, many credit English mathematician Karl Pearson with quipping, “That which is measured improves. That which is measured and reported improves exponentially.”

    Development teams should take Pearson’s wisdom to heart, and measurement must begin with identification of goals. Is your goal to reduce application downtime or decrease event response time? Then it’s essential to measure mean time to repair. Do you want to reduce code defect density? Begin by measuring the number of issues per thousand (or million) lines of code.

    Once you’ve identified goals, use software to track progress over time. Etsy’s engineers built a tool they call StatsD. The software helps Etsy monitor everything from login failures to coffee availability. The data is then displayed in handy graphs to help the team make sense of the information.

    Once you’ve taken baseline measurements, be sure to review your metrics on a regular basis. For instance, you might realize an application’s deployment times aren’t where you’d like them to be. Keep measuring results—and keep trying new things—to nudge those values into better territory. Just remember: You cannot improve that which you do not measure.

    The Business of Lean Security

    The value of a secure, simple system cannot be understated: It means getting products to market faster; it means better public perception and press; it means more satisfied customers who feel secure using your product; and it means fewer disruptions in engineers’ work schedules. At its core, lean security lowers a company’s overall exposure to risk and reduces its expenses.

    Companies are already staking their futures—and consumers’ safety—on code that facilitates transactions, drives vehicles and manages power plants. The Internet of Things will soon run everything from toasters to jet engines, and security will grow even more important. Protect your company from within through lean security.

  • Changing the Culture of Metrics Analysis

    Changing the Culture of Metrics Analysis

    You could say the development and operations teams gave birth to the idea of DevOps, as it is believed the chief benefits are garnered in those two functional disciplines. Because of this, metrics nearly always are conducted from the points of view of cost reduction, speed and efficiency. This makes perfect sense when business treats IT (and IT sees itself) as a service- or cost-based organization. But what if DevOps has a few more characteristics that could actually change that culture? What if, for the first time, DevOps could enable IT to become a real partner with the business organization it serves?

    To make this happen, business and IT must begin to share attainable goals. Imagine the impact of a highly functioning, enterprise-class DevOps service within IT; upon the time to market of products and services the business is looking to launch. A proven, consistent ability of IT to deliver on time or ahead of schedule (i.e., reliability) then begins to change the dynamics of what marketing proposes and delivers. Time then becomes a valid metric to consider when looking at customer adoption rates. DevOps usually does not directly impact initial market demand, but the impact of delivering new services or features months or years ahead of previous projections can dramatically impact time to market. For example, if your business is able to change its billing model or billing methods six months to a year ahead of every one of your competitors, what impact might that have on market adoption? At that point DevOps becomes a key business differentiator, until the rest of the universe has it.

    Consider an additional impact of a highly functioning DevOps service on feature delivery or the feature road maps themselves. The implementation of DevOps inherently delivers smaller units of change on a higher frequency, reducing risk and allowing iteration and alteration of future plans based on the real-time feedback of change success. Marketing focus groups may provide an original road map, but the impact of DevOps can be integrated back into those same focus groups. Instead of imagining what might be possible, DevOps allows delivery of what is possible to see, feel, touch and prompt further imagination. The net impact is an increase to the pace and depth of innovation itself. You know what your customers really want, and you can give it to them quicker. What kind of impact does that have on the reputation of your business if it becomes a market leader because of this? Or what happens when a large organization is then able to deliver with the speed, agility and flexibility of a small firm?

    Cost Reduction vs. Revenue Generation

    Now consider the value of cost-reduction metrics compared with revenue-generation metrics. It is easy enough to determine that the pre-DevOps delivery cycle might have been 12 weeks per feature as an example, or that each build took six hours to complete and now post-DevOps takes only 12 minutes to run. Metrics like these will begin to show an increase in productivity by existing development staff—or, maintaining the same feature delivery rate, a reduction in the number of personnel needed to achieve them. Similarly, it is easy to show a reduced number of trouble tickets post-DevOps, and a concurrent reduction in the average time to resolve each ticket. DevOps then has enabled the CIO to continue to take arbitrary budget cuts demanded by the business each year. This is not partnership—over time this is a recipe for the reduction, pace and quality of innovation (the smartest people leave first during layoffs; they don’t need to stay).

    However, even significant cost-reduction metrics pale in comparison to revenue-generation metrics. As an alternative, imagine what the net growth in customers of a given product might be, over a six-month period of time, because a desired feature set was delivered early? And what if it is two to three years before your competitors can implement the same high-functioning DevOps services you already have in place today? If a business makes $2 per-widget profit and captures 20 percent additional market share over six months, equating to “x” million new customers … well, you begin to get the idea. All of the sudden IT is no longer viewed as a cost center by business; it is viewed as a revenue-enabler. The immediate business response is, “If I allocated more budget into the types of staff facilitating DevOps services (running the gamut from coding to operations to marketing), could I gain even faster delivery rates or deeper feature sets or more market share by pioneering what has never been pioneered?”

    The two main reasons this realization hardly ever occurs in business today are that 1.) IT has failed at delivering on promises so often it has trained the business to believe it “cannot” deliver on time or on budget; and 2.) few businesses conduct accurate time-to-market metrics measuring the delta of what additional “time” does to the equation, largely because they never had to. DevOps provides the catalyst to begin to re-examine both of these phenomenon.

    But it goes deeper than that. Changing the culture of innovation, in which I am eager to test new ideas faster, means I need more ideas all the time. The competitive advantage our nation, our businesses and our careers have always benefited from is our ability to create and innovate. Other nations around the world, or other organizations your company competes with, may be able to do repetitive tasks faster or more efficiently. But rarely do worker-drones create or produce a wealth of ideas. But if we begin to focus on the long-term impact of fostering innovation in our own country, and in our companies, we will remain perpetually out front. The goal of DevOps is not merely efficiency, it is also to spark the imagination. When our focus and our metrics reflect this, we all win.

    If you would like to continue a conversation on how to create and implement a highly functioning enterprise class DevOps service, feel free to contact me.

  • The Business Value in Software Quality

    The Business Value in Software Quality

    Software is taking over the world. You would be hard pressed today to find a company without dedicated software development efforts. But even in traditional business models, this is not confined to line-of-business applications. Organizations now have public, contractor and field team applications—as well as end users. And they must consider the results-focused future of software development and the need for faster, higher quality application releases. This is the business value of software quality.

    (more…)