Tag: Agile software development

  • How to Optimize Data in Software Development

    How to Optimize Data in Software Development

    Data can drive significant business value for every company. Globally, we are collecting more of it than ever before, and it keeps growing—from 45 zettabytes in 2019 to a projected 175 zettabytes by 2025, according to IDC. However, companies are struggling to monetize all the personal, behavioral, engagement and transactional data from customers and operations and turn it into actionable intelligence to drive their digital strategies. Leveraging insights from your data is critical for success and the development of new digital solutions to better serve customers, grow sales, improve operations and more.

    Data helps organizations develop the right software for the right customer at the right time. Data-driven organizations are 23 times more likely to acquire and retain customers than their peers, and are growing at an average of more than 30% annually, according to Forrester.

    Organizations with a deep and dedicated focus on data and analytics tend to follow three common paths to successfully drive their software development initiatives.

    Discovery Matters

    It is nearly impossible to draw value, understanding, and insights from the massive amount of data businesses collect without a proper discovery system in place. Having a comprehensive process of collecting data from various databases and silos and consolidating it into a single source that can be easily and instantly evaluated is critical for any software development project.

    During client engagements, data scientists perform deep-dive research into clients’ data pools and workflows to support client roadmaps. We recently partnered with a global e-commerce company to create a recommendation system for their customers. The discovery process allowed us to verify the feasibility of recommended products using their existing data before moving ahead with the project. Using machine learning, the team was able to clean and analyze information from multiple angles. With that knowledge and confidence, the rest of the development project proceeded quickly knowing the data was in place and the project was viable.

    Align KPIs

    Software development metrics help organizations and their partners track and measure how an application is performing and how effective the development team is in its work. IT organizations rely on a range of KPIs to fully understand software engineers’ progress, as well as gauge software quality including performance, engagement and user satisfaction. While each engagement is different and requires a different set of KPIs, ensuring that the organization and development team are on the same page is crucial.

    During the e-commerce project, success was measured through conversion and user retention rates. Other KPIs that are regularly used include developer productivity and performance metrics like cycle time and team velocity, and software developer metrics like response time, usability and UX data, among others.

    Deploy Agile

    By using agile methodologies at all stages of development, developers are able to focus on business results, not just architecture and new technologies. A similar agile approach can also be applied to data management. When it comes to data science, it’s all about extracting useful information from raw, structured and unstructured data and implementing machine learning models to analyze vast amounts of information. This process requires more creativity and is a key driver for understanding potential risks and failures over the course of any given project.

    With agile, data models and analyses are broken down into manageable bite-sized chunks that can be built and tested quickly—the same way software is developed. If the analytics do not yield the expected results, data scientists see the failures immediately and can correct their course. They could ask the team to analyze different data sets, adjust the models, tweak algorithms or make an educated decision about the project’s viability.

    A multinational credit company took this approach to the next level when it used agile to develop a new, big data hybrid cloud platform. After anonymizing, aggregating and storing information in a data lake, the team quickly realized the database it was planning to use was limited to a certain number of partitions and entities. By running agile sprints and developing and testing the minimum viable product (MVP) continuously, the team was able to seamlessly switch to a new database that had more scale and functionality.

    The value of data is only going to increase with time. Data-driven organizations embrace the use of data and analytics to gain unique business insights to support their software development projects and overall business. By focusing on the data in each and every development project, companies have a tremendous opportunity to gain a competitive advantage and grow their businesses.

  • How to Successfully Scale Agile

    How to Successfully Scale Agile

    Agile has proved its value to businesses across industries and geographies. In fact, the pandemic elevated it to an absolute necessity for organizations’ success and survival. Business leaders around the world invested aggressively in Agile transformation as they scrambled to meet changing customer demands through newly hybrid and remote workforces. Not surprisingly, the faster they adopted Agile methodologies at scale, the higher the value it delivered for them. Research indicates that the value Agile delivers can be a chance to grow ahead of peers as high as 63%.

    What enterprises in the U.S. now need is to move the right Agile levers to maximize business outcomes. The same research prescribes an agenda to make that happen:

    Mapping Customer Journeys

    This involves assessing what purpose the company’s offering serves and how value flows through the systems that surround it to the customer. By identifying the critical path of value flow and prioritizing Agile investments at the nodes of value, both volume and velocity of value to customers can be impacted. For example, at Marcus by Goldman Sachs, every team, no matter which department they belong to, responds to the question about what they do with an answer that has clear customer focus: Enabling customer onboarding, improving the customer service experience or helping with the customer password journey.

    Using Customer Insights

    This can be achieved through A-B testing techniques and analytics platforms to unearth the attitudes and motivations that cause customer churn, build loyalty and convert emotions to action. This involves gathering customer feedback through surveys, discussions, and, in the case of digital channels, insight from the channel itself. Additionally, this lever enables diverse perspectives as customers are onboarded, with inputs all the way from design to operations. Kraft Heinz, as an example, leverages Snowflake’s platform to leverage data to drive new digital experiences for consumers. Snowflake gives them real-time ability to sense, respond and evolve, with insights resulting in more meaningful interactions with customers.

    Organizing Teams Around Offerings Rather Than Functions

    This involves bringing together skills and capabilities to launch disruptive products in the market and win back market share. Product-centric agile value delivery is especially helpful in scenarios that involve multiple handovers between internal teams that could lead to delays and siloed developments. For instance, Daimler draws on the principles of swarm to pull in expertise from various departments and create cross-functional teams to collaborate when developing new products.

    Upskilling the Workforce

    It’s imperative for organizations to upskill their workforce for continuous delivery, strategic vision and skill alignment within autonomous, cross-functional teams. The rapid pace of development required to meet changing customer needs often creates a skills gap that needs to be bridged. Siemens is a great example. They accelerated their digital transformation journey in 2020 and realized how vital it is for every employee to easily access upskilling and reskilling opportunities. To stay ahead of the curve, they deployed an agile digital learning platform for their employees while leveraging and simplifying their existing learning ecosystem.

    Taking the Minimum Viable Product (MVP) Approach

    This lever assesses real value delivery, validates hypotheses and enables quick course correction as required. Budgets are always limited, and an agile MVP approach also maximizes investment value with faster delivery, optimized processes and increased flexibility. A recent case in point is the approach bp took when started work on an integrated energy-as-a-service (EaaS) offering that will provide end-to-end management of a customers’ energy assets and services. Their first step was to pilot the plan in an innovation center/work campus before exploring opportunities to manage energy more broadly at industrial and business parks.

    Expanding the Agile Workplace

    Companies need to extend and adapt the agile workplace concept for a hybrid reality by creating remote analogs for meetings, sales execution and IT support along with advanced collaboration tools. A great example is GE Appliances; at the very start of the pandemic they accelerated their workplace with automation-driven agile services support across their global command centers and service desks.

    Amplify Agile with Cloud

    Scaling Agile without sound cloud infrastructure is a good job half done, especially when firms want to buttress speed and utility with business resilience. In fact, the very best firms stand to take a good share of the $414 billion in profits cloud generates across industries and regions every year.

  • Enterprises Face Growing Technical Debt

    Enterprises Face Growing Technical Debt

    Technologists are always espousing new, trendy development solutions. More robust frameworks, increased delivery, better integration. But rarely do these proponents consider the long-term side effects of introducing new technologies. As a result, technical debt is an all-to-common occurrence in most companies.

    Nearly a third of IT budgets are dedicated to addressing technical debt. Devoting so much effort to maintaining legacy code leaves fewer resources to support the status quo, let alone develop new solutions. In fact, a recent study found that 69% of IT leaders identify technical debt as a significant threat to their companies’ ability to innovate.

    “The Growing Threat of Technical Debt,” a report from OutSystems, surveyed 500 IT leaders about this conundrum. Below, we’ll explore the top causes of technical debt and consider ways to prevent it from getting out of control.

    What is Technical Debt?

    Technical debt seems counterintuitive. Isn’t technology supposed to help organizations become more productive? Why would it be a burden? Well, technical debt often arises from hasty decisions taken in the short term that have long-term consequences. It’s also often the result of a company juggling many competing technologies, some of which have become outdated.

    Technical debt can carry a hefty price tag. But this debt isn’t so much measured in the cost of hosting legacy technology or running broken code, but in the hours lost maintaining and patching it. The report found that, on average, businesses devote 28% of their IT budgets to addressing technical debt. This number increases to 40% within large enterprises.

    Common Causes

    There is not one single factor causing technical debt. Many issues within an organization contribute to the problem, including reliance on stale technology, pressure to deliver in the short term, constant change, developer churn and incorrect architectural decisions.

    The top cause of technical debt is too many development languages and frameworks, cited by 52% of respondents as a big or critical problem. Legacy technology can weigh an IT department down. But, it’s not necessarily only old tech getting in the way—it could be that IT is supporting too many competing agendas.

    The second top cause is a high turnover rate within developer teams. In today’s competitive climate, quality engineers are in short supply, and hiring can be challenging. It is thus difficult to attract and nourish steady engineering talent. If developers frequently leave for greener pastures, especially before documenting their procedures, best practices can easily be lost and efficient use of technology is stunted.

    The study found that other common causes include accepting known defects to meet deadlines, using outdated programming languages and frameworks and dealing with challenges in serving new markets or segments. At times, teams release software with known defects simply to meet deadlines. The sheer size of a large organization can lead to increased technical debt, and not addressing it compounds the issue further.

    In terms of industries, the report found the health care and social assistance category hit hardest. In this sector, 35% of IT budgets go toward addressing technical debt, on average. The next most-burdened group is the financial category, which was at 29% according to the report.

    The Costs of Technical Debt

    What are the costs of technical debt? There’s a high price to maintain, reduced hours for innovation and a detrimental effect on overall software performance. Team dynamics could also incur adverse reactions from sustaining technical debt.

    Technical debt requires an disproportionately high amount of time to maintain. On average, engineers spend 33% of their time dealing with technical debt, found Stripe’s “The Developer Coefficient” study. This equates to about 13.5 hours of an average work week.

    The more debt you take on, the smaller the budget left for running status quo operations and building new capabilities. Supporting technical debt not only has financial implications but could stifle future prospects; in fact, 69% of respondents said technical debt limits their capacity to innovate. In today’s acceleration economy, not setting aside resources for digital innovation, could break a business.

    “The combination of old code along with the new generation of mobile apps, stack applications and SaaS sprawl are robbing organizations of resources, time and the ability to innovate,” said Paulo Rosado, CEO, and Founder of OutSystems.

    Technical debt could also stunt performance. According to the survey, 61% of respondents said it causes a significant drag on their company’s performance. Stale projects could interfere with streamlining customer experiences and digital transformation goals.

    Lastly, technical debt could also negatively affect morale. Few engineers take pride in repeating inefficient processes or working with obsolete tech.

    Alleviating Technical Debt: Be Intentional

    Similar to financial debt, technical debt comes with compounding interest. This interest could grow exponentially if left unchecked. So, what steps can organizations take to reduce their technical debt?

    To help alleviate the problem, the report recommends reversing the top two causes of technical debt by stemming turnover in development teams and limiting the number of new programming languages and frameworks you adopt.

    Other methods involve taking stock of your holdings to understand the presence and impact of legacy technologies. Next, rethink and redirect your strategy from simply maintaining legacy dependencies to addressing them and replacing them with modern styles.

    “A lot of bad tech debt comes from building too much and getting stuck spending more time on maintenance and bug fixes than expected,” said Jon Thornton on the Squarespace blog. ”The key is to be intentional about what you invest time in and aware of the costs you’re taking on.”

    Of course, enterprise IT must take on some form of technical debt to function—it’s futile to get rid of it entirely. Therefore, as Thornton advises, be intentional about it and stay aware of the costs you take on. When adopting new technologies, it’s best to consider maintenance implications and plan with longevity in mind.

    For more insights, download “The Growing Threat of Technical Debt” report in full here.

  • Broadcom Adds VSM Platform to DevOps Portfolio

    Broadcom Adds VSM Platform to DevOps Portfolio

    Broadcom Inc. today added a dedicated value stream management (VSM) application to its portfolio of DevOps offerings as part of an effort to make it simpler to prioritize software development initiatives.

    Serge Lucio, vice president and general manager for the enterprise software division of Broadcom, said that while the company has previously provided VSM capabilities within its tools this addition to its ValueOps portfolio marks the first time Broadcom is making available a complete VSM application.

    The offering is unique because it combines the IT investment capabilities found in the Clarity project management software provided by Broadcom with the Rally platform for managing agile software development processes, added Lucio.

    In comparison, other VSM offerings don’t provide the same level of depth in terms of connecting software development projects to actual financial costs, noted Lucio. The Broadcom platform, for example, in addition to surfacing dependencies between software projects and potential developer capacity issues, also enables IT organizations to forecast the impact changes to funding will have on software development projects, said Lucio.

    In fact, Lucio noted that tracking code as it is developed is relatively easy. Surfacing the financial implications of software development projects requires an additional level of analytics not found in rival VSM offerings, he said.

    VSM, as a concept, traces its roots to lean manufacturing methods, which called for each step of a manufacturing process to be continuously measured. As software development has evolved from being a craft to a process that is automated as much as possible using DevOps best practices, an appreciation for the value of monitoring the impact of missed software development deadlines on the business is growing as organizations realize how dependent they now are on software to achieve business goals. A VSM platform aggregates technical metrics gathered from DevOps workflows and then maps them to key performance indicators (KPIs) defined by business leaders. Once those KPIs are defined it then become possible to apply advanced analytics to assess the financial impact changes to software development schedule will have on the business.

    In general, Lucio said organizations are evolving their approach to software development as they embrace digital business transformation. Rather than managing individual software development projects in isolation, organizations are now managing software development in much the same way they manage product development. As a result, a collection of related software development projects are now being managed in a way that better aligns to the strategic business initiatives, he said.

    It’s not clear at what rate organizations are adopting VSM platforms, but as the number of stakeholders in an organization that have a vested interest in software development increase there is a need for tools that enables those individuals to more easily track processes in a way that doesn’t depend on them mastering the project management application employed by the software development team.

    Regardless of approach, the appreciation of software development in organizations has never been greater. That same increased appreciation, naturally, is creating a level of anxiety among business leaders that need to make decisions that impact the entire organization based on processes that today they often have limited visibility into much less actual understanding.

  • The Single-Sentence Postmortem

    The Single-Sentence Postmortem

    Do you have four seconds?  In the time it takes you to read this sentence you could be done with your incident’s postmortem.

    “But my postmortem has 8 sections!  I have to construct a critical timeline, restate my followup tasks, show the major milestones, evaluate root cause…”

    Stop right there.

    First of all, your incident management system should be automatically capturing your timeline, follow-up tasks and major milestones as they happen — so you shouldn’t be worrying about reproducing that content at all.

    Second of all, the most critical thing a responder can bring to a postmortem, in the moments right after the incident concludes, is the one-sentence personal context of what actually happened. It’s the same sentence they’d say to a co-worker in the lunch room when asked what went wrong. But to achieve organizational resilience, the knowledge in that sentence has to be captured and distributed. I can’t emphasize this enough – a single sentence can unlock 80% of the value. Writing something, anything, is so much better than writing nothing, and yet, too often, we see companies skip this part of the incident management process.

    Modern incident management, as a practice, was born on factory floors.  Instead of firing the person who was considered accountable for a major incident, having that person write up their view of what happened was more impactful at preventing future incidents. That’s because only the responder has the complete context to shed light on the contextual, systemic failures that actually caused incidents, as compared to the outside view of management and other employees who will often see problems as human-centered or due to obvious oversights (using 20/20 hindsight).

    When asked if he would fire an employee who made a $600,000 mistake at IBM, Thomas J. Watson famously replied, “No! I just spent $600,000 training him – why would I want somebody to hire his experience?”

    The reality is that any amount of your unique perspective as a responder is invaluable when compared to nothing, and without it, the chances of your company learning from these mistakes is slim. That’s why we encourage a unique approach: we tell our customers to spend four seconds on their postmortem.

    Especially for those new to incident response and management practices, it’s important to develop a practice of doing postmortems right away, as soon as the incident closes. As quickly as possible, open up your postmortem, jump to the ‘What Happened?’ section, and write one useful sentence. That’s it.

    Once you do that, we know that one of two things will happen:

    1) You’ll have other things to do, so you’ll publish the postmortem, and that one critical piece of knowledge will be shared throughout the company. That is infinitely better than nothing. 

    2) Or, you’ll realize you have more to say and get it done, right then and there.

    Like putting your running shoes on even if you don’t want to go for a run — at the very least, you’re up and active; at most, you’ll get out there and rack up some miles.

    Working with companies across industries and seeing thousands of incidents filed; hearing the stories of hundreds of companies’ incident management implementations has taught us that the alternative to a quick postmortem often isn’t often a more in-depth one, it’s no postmortem at all.

    So if you’ve just finished an incident– and if you’re about to pick up your coffee and move on to the next task at hand – instead, spend four seconds writing one sentence. It could make all the difference.

  • The Importance of Incorporating DesignOps Into DevOps

    The Importance of Incorporating DesignOps Into DevOps

    Design is a critical software project element that often goes unnoticed by those writing code. After all, coders and implementers tend to take the design process for granted and leave the look and feel of applications to the designers. In the days of waterfall based development, design was one of the first steps in the development sequence of creating a new application. However, with Agile and DevOps development practices, design became disconnected from the overall process.

    “If you look at the full spectrum of AppDev, it becomes obvious that there are many elements that should be part of DevOps. Take, for example, cyber – today, there is a movement to integrate cyber into the DevOps pipeline, which the industry has started to call DevSecOps,” said Mark Troester, VP of strategy at Progress, a software company offering tools for developers and IT. “To make design a part of the iterative process of DevOps, teams need to think about including designers during the complete development process, something along the lines of how cyber has become part of the iterative process. In other words, teams should be embracing the concept of DesignOps,” Troester said.

    To understand the challenges this creates for those looking to include design as part of the DevOps process, one only needs to look at how design, specifically user experience/customer experience (UX/CX) design, was done in the past. Designers would use tools such as InVision Studio, Axure, Proto.IO, Adobe XD, or one of the many other tools available, to prototype the look and feel of an application, or, more specifically, the end-user experience. The term DesignOps was coined to encapsulate the processes around design. However, DesignOps solely focused on the process of design, such as design workflows, design tools, design governance, team management, budgets and so on. 

    The ultimate goal of DesignOps was design creation; that design was then passed on to those who would write the code and develop the logic to bring that design to fruition in the form of an application. DesignOps worked rather well when an organization was adhering to waterfall development methodologies, where each step was clearly defined and the goal was to deliver a complete, finalized application to those requesting it.

    “Larger organizations were able to field large design teams and could afford to implement a complete design system. When you have 50 or more designers, a complete design system becomes critical to manage design,” said Troester. “However, as AppDev has evolved into a more agile process, especially under DevOps, the disconnect between design and development became a significant problem.”

    What Troester is alluding to is the reiterative development cycle used by DevOps teams, where applications are delivered in pieces and then further modified based on user feedback or business operational changes. Businesses today are embracing agile concepts, so they can react much faster to changing market conditions. This, in turn, means modifying applications as quickly as possible to maintain a competitive advantage. Currently, design remains somewhat siloed, and can become a bottleneck for implementing changes if the UX/CX must be modified to address those needed changes. 

    “With the rise of DevOps, teams need to start thinking of reiterative processes, where DesignOps integrates with the DevOps team, so there is collaboration between the designers and the developers, allowing design changes to happen quickly,” Troester said. “Yet, there are still remaining challenges – some created by the COVID-19 crisis – where designers and developers may not even be in the same building, much less the same time zone,” he said.

    To Troester’s point, the COVID-19 crisis has forced businesses to evolve in ways that were once thought impossible. Developers, designers and even operations teams and individuals may no longer be sharing office space, and might be distributed across multiple locations. That complication will drive the need for better collaboration tools that bring design into the DevOps cycle.

    “DevOps teams, as well as DesignOps teams, should be looking into technologies that can bridge the designer/developer divide. It will be critical in the near future to facilitate collaboration between design and development,” Troester said. “Perhaps, the answer lies with building some type of bi-directional API into design systems, which can play a key role in the implementation and support of design-first experiences,” he added.

    Existing solutions to the current divide seem to be few and far between. But, that does not mean DesignOps and DevOps teams should not be currently looking for a solution to what will become a major problem as DevOps accelerates in the enterprise.                  

  • Hybrid Low-Code: The Next Step in App Development

    Hybrid Low-Code: The Next Step in App Development

    The promise of low-code development has long been the ability to develop business-critical applications by humans with little programming experience. In fact, over the past year or two, the lines between low-code and no-code have become increasingly blurred. Low-code platforms have incorporated more and more functional no-code features to increase the efficiency of the developer even further. Some of these platforms have become so intuitive to use, the idea that anyone can create an app has evolved into the idea of citizen developers. But is low-code really the be-all and end-all when it comes to app development? Seems the answer to that is, “It depends.”

    It has become glaringly obvious that exclusively no-code platforms can’t create complex applications. But then again, these platforms were never really designed with that kind of functionality in mind. No-code can be a highly valuable, rapid prototyping tool as well as a decent tool for very small, very specific apps. These apps would be best suited for intradepartmental use or to extend the functionality of very specific SaaS tools. No-code is not going to power your business-critical applications, and a not-quite-a-developer is not going to lighten your IT load.

    But what about low-code? Can low-code be the bridge between citizen developers and the ever-growing list of backlogged apps? Maybe. Using citizen developers comes with a whole heap of issues that need to be addressed. While this topic can be the subject of an entire blog in its own right, I can quickly highlight the major issues to consider. How much of a citizen developer’s time should be dedicated to app development? Is using citizen developers going to create backlog issues in their primary departments? Who is going to train and support citizen developers? How is IT ensuring that citizen developer-created apps are secure, scalable and extendable? As great as citizen developers sound, they still are not a definitive solution.

    A realization has dawned in the low-code industry. Low-code can’t be and do everything, but it can be a useful development tool to speed up application development. However, most low-code platforms are in their own development silos, separated from other development tools with their own IDEs. Instead, one idea is to create a quick and easy-to-use user interface, drag and drop some app functionality, and then finish complex apps in a language the low-code platform can integrate with, such as Java, or via a Visual Studio plug-in. Even the biggest and best low-code vendors admit that just using low-code isn’t going to power your business.

    Low-code can’t be everything, but it can be a major part of everything. It just needs to look different from how most low-code platforms are designed. Using a hybrid low-code approach will allow organizations to truly use low-code from start to finish in the app development process. Rather than looking at low-code as a separate tool in the development process, a hybrid low-code approach brings low-code inside an IDE where traditional coding methods are still used.

    Is hybrid low-code the future of app development? I would say hybrid low-code is a next step in the evolution of app development. Low-code development tools shouldn’t be isolated in their own IDEs. It can be frustrating to leave a low-code IDE to finish the app in another IDE, and then have to connect the different elements into one cohesive app. As you can see, efficiency is reduced every time a developer leaves one IDE for another. Hybrid low-code views low-code as a tool inside a bigger development toolbox. It is there when convenient, but a developer isn’t forced to use just low-code. They can import already created assets from other languages, hand-code complex solutions, drag-and-drop when it makes sense, and create all the necessary components of a progressive web app with a click of a button.

    While there might be a profound realization that “traditional” low-code can’t do everything it originally promised, hybrid low-code could, instead, fulfill that promise.

  • Plutora’s Bob Davis: Work From Home and Value Stream Management

    Plutora’s Bob Davis: Work From Home and Value Stream Management

    American writer Orison Swett Marden said, “Success is not measured by what you accomplish but by the opposition you have encountered and the courage with which you have maintained the struggle against overwhelming odds.” After the year that’s passed, with operations and development teams forced to scatter and work remotely, it’s a sentiment DevOps teams are currently all too familiar with.

    This demand to keep DevOps teams productive under the extraordinary circumstance of 2020 has placed an increased emphasis on effective management, including on value stream management tools, so leaders and team members can have greater visibility into delivery pipelines.

    To get a sense of the state of the value stream management market, I reached out to Bob Davis, chief marketing officer at value stream management platform provider Plutora. Below is an edited version of our conversation.

    George Hulme: Thanks for taking the time today, Bob. Could you tell us a little about Plutora?

    Bob Davis: We are a value stream management platform provider. When I first arrived here, we recognized that sales, marketing, financial and human resources teams all have their systems of record. They have Salesforce, ERP (enterprise resource management) systems, and various financial and HR platforms that enable people to practice their profession more easily. IT didn’t have anything like that at the time.

    We set out to provide that capability for the software development side of IT. Today, the market is caught up. Everybody is moving into value stream management as a platform to provide that visibility across an entire toolchain, from the idea to production. That’s where we play. We’ve been in this space since it began over two years ago. The market is just exploding with the work-from-home trend, and how the pandemic kicked digital transformation into high gear.

    Hulme: It appears that a significant percentage of the work-from-home trend is here to stay. I’m seeing surveys showing about 19% of people previously suspected that they’d be working from home in a year. That figure jumped now to near 50%.

    Davis: If you start to parse what work from home means, you’ll find it means many different things to different organizations. Some have a hybrid model with people working from home two to three days a week. I recently read a Gartner survey that said 74% of organizations were going to have some element of work from home. It’s not all or nothing.

    Some companies have decided that they are not going back to work until well into this year. All of these companies have to make sure they have governance compliance in place for this new workforce, and that they can successfully manage the complexities of software development. These challenges are at least an order of magnitude, if not more so, more difficult than typical office workers working from home.

    Hulme: Is one of the reasons behind those challenges struggling to maintain being on the same page across the organization?

    Davis: That’s a great point, George, because when we go out with our teams at many organizations, a lot of the effort helps people fast-track their processes. We are asked, “What is the best practice for automating builds? How often should I be automating builds? What KPIs do I establish to make sure that people are striving to accomplish what we need them to accomplish?”

    For example, one of the things that Lean and Agile methodologies promote are smaller work items, quicker check-ins, faster processes. They encourage cutting work down into smaller bundles to be done more quickly so that teams can iterate much more rapidly. We’ve seen that managers will often create a KPI for a performance management program to measure how often code gets checked.

    That’s horrible because now I can just check in code all the time. Yet, are people making actual progress? Are they actually delivering software, or are they just checking in small iterations of code all day?

    Organizations have to be very careful with how they manage people. They have to be cautious with what metrics they set up to keep their eye on delivering value and delivering software more quickly. This is something organizations struggle with. They want to know where to start and what metrics they need to implement. And how to make those metrics visible so people can see and understand them. That’s what provides the ability for product owners, managers, executives and other stakeholders to view the progress and status of what’s going on without disrupting people with calls and endless meetings.

    Hulme: That has to be tremendously more challenging with the work-from-home trend than years prior.

    Davis: I recently heard a great quote: “As people end up working from home, the need for human contact and human interaction, socialization, is peaking.” People are hungry for that. At the same time, the need for managers to not be in the face of the employees has never been higher. That is, the motivation and the productive nature of employees is proportional to how well they feel trusted. And it’s proportional to how well they understand where they’re headed and understand how to do their job and are left alone to do that job.

    It’s a leap of faith to leave people alone and simply trust them. You need systems that provide you the ability to collaborate; watch the progress. You need systems that will help you understand where people might be struggling, all without having to dig in and micromanage your people. Indeed, as we are learning, managers can effectively do this with Zoom, or Slack, or some other tool that provides good communication flow within a work-from-home environment. But in software, the handoffs and dependencies are so complicated that those tools are simply not enough. You need a collaboration tool that provides effective management in software development.

    Hulme: Do you believe remote development teams can communicate as collaboratively as they did in person, with modern software collaboration tools?

    Davis: Yes, I think they can. Especially when office collaboration tools, such as Zoom and Slack, and software collaboration tools work together. We can leverage Slack to communicate tasks. So we not only layer on top of the individual tools people have and integrate with them, the practitioners working within those tools can make it available to all of those stakeholders involved in that process. And when there are tasks or handoffs, the system can be configured to notify them how they prefer to work: email, Slack, instant messenger, task list on the dashboard. There’s a lot of different ways, depending on how people want to work.

    Not only that, but it can automatically alert people to what is happening and what’s needed. Fascinatingly, one of the interesting yet deceptively tricky questions to get an answer to is, “Where’s the status of a feature?” If a team is in the process of building something out, and they have a specific feature, such as check cashing in a banking app, it should be a pretty straightforward question to get answered.

    Yet, about seven or eight different teams are working on various aspects of that application. For instance, there’s a product owner who, without the right collaboration system, has to go and essentially track all of those teams down and find out where their status is.

    With a software collaboration system, you can make that query without bugging anybody. In some respects, you can collaborate more efficiently and more productively than you can when you’re all sitting in the same room. That’s because before, we would have walked over and interrupted somebody. Now you’re just looking at a dashboard, or you’ve gotten an alert on Slack, and you see what you need. Boom.

    Hulme: How important do you think it is to have useful data and that value stream knowing where things stand to keeping the system flowing and individuals knowing where they fit on deliverables?

    Davis: I think the ambiguity, unexplained delays and unforced errors are among the things that upset human beings the most. Just ask somebody that’s standing in a line that’s not moving, and it hasn’t moved in a while; how restless the crowd gets. The nature of software development is such that there are tremendous numbers of handoffs, no matter how you do your development.  It doesn’t, whether it’s an old fashioned waterfall or the most advanced development and deployment models in operations at places like Spotify — you have a lot of handoffs. And if you can’t see what you’re doing because you don’t have visibility into those parts, then you’re going to run into an incredibly frustrated team. And you are going to see a lot of finger-pointing when the question comes up, “Why didn’t this release go out?” And then there’ll be five or six different groups pointing to different reasons. You get a lot of anger, a lot of discontent.  And it’s something you have to avoid if you are going to succeed.

  • Improving Mainframe Agility With DevOps

    Improving Mainframe Agility With DevOps

    Mainframe workloads were on the rise even before the coronavirus pandemic, and transaction-processing mainframes became vital as lockdowns went into effect and every aspect of business and personal life occurred online. Mainframes are reliable, secure, highly available and affordable, and it is essential for organizations to ensure their mainframe can achieve peak agility to enhance profitability and improve customer experience.

    There are four areas of focus for DevOps teams who want to improve mainframe agility: teamwork, cloud services, KPIs and automation. Let’s look more closely at each one.

    Encourage Teamwork Between DevOps and Mainframe Ops Teams to Improve Agility

    It’s vital that mainframe ops teams work seamlessly with DevOps teams to ensure adoption of best practices in both areas, where practical, and that those best practices are adhered to. No matter how skilled your DevOps team, they must always be open to learning from mainframe professionals, operational and cybersecurity experts.

    To truly empower everyone on your team to achieve maximum mainframe agility, mainframe code must translate within the larger, multi-platform DevOps toolchain. If DevOps and mainframe code are not in sync, mainframe code could slow down software development lifecycles. Important processes, such as diagnostics, test execution and source code need to be integrated to enable DevOps teams to achieve better productivity.

    Enterprise DevOps is shifting focus away from software development exclusively to encompass surrounding processes within organizations. Successful DevOps teams must be able to work with cybersecurity experts and mainframe ops teams throughout the coding life cycle to ensure that everyone is on the same page and applications are functioning optimally.

    Decide Whether to Move Entirely to the Mainframe or Integrate Cloud Services with On-Premises Mainframes

    Scaling your organization for growth by migrating entirely to the cloud is not necessarily the right choice for everyone. In some cases, moving away from the mainframe’s core systems can be costly and unnecessary.

    Cloud-based services don’t have to be eliminated entirely, either. The cloud can and should be used for business processes that could benefit from real-time data updates, easy team collaboration and seamless integration with other software and tools. Mainframes excel at functions that require reliable, secure transactions.

    Whatever decision your organization makes, it must be communicated and agreed to at all levels. A customer-centric approach is ideal here, where the needs of the business are considered, but a seamless customer experience is prioritized.

    Establish Measurable KPIs

    Achievable and measurable key performance indicators (KPIs) are essential to monitoring your progress as an organization. KPIs for mainframe functionality usually include an availability rate of 99.999%, which roughly translates to downtime of less than 5.6 seconds per year. KPIs also generally measure time windows for batch completions. Software delivery velocity, efficiency and quality should be evaluated, but make sure you’re not prioritizing one of these metrics at the expense of another.

    There are more nuanced goals that need to be prioritized, too. Continuous improvements in software delivery are harder to quantify, but no less important. By fostering a collaborative environment where communication is key and teamwork is valued, your organization can create a better product or deliver better services for developers and customers.

    Use Automation Whenever Possible for Mainframe Agility

    Automated testing and AI-enabled processes can solve problems in real-time and free your DevOps teams to focus on larger issues. Mainframe ops teams can save their organizations money by relying on automated processes, which can also reduce personnel costs.

    Despite the benefits of automation, mainframe code is often removed from automated processes commonly applied to DevOps toolchains. Javascript, for instance, is one of the most commonly used programming languages due to its platform independence. It’s an essential tool for DevOps developers to enable the smooth configuration and installation of applications.

    But as infrastructures grow more complicated and surface areas expand to accommodate more users, operations teams can feel overwhelmed. With the continuous pressure to create new and better software on accelerated timelines, DevOps teams can unwittingly introduce vulnerabilities in Javascript coding as they speed through the software development and delivery pipeline.

    Automated mainframe diagnostics and optimization tools are vital to improving both the customer and developer experience.  Comprehensive and accurate data presented to mainframe ops teams in real-time can detect vulnerabilities and to find and fix potential issues.

    Ultimately, the mainframe is here to stay, with 93% of software experts citing the strength, reliability and scalability of the platform. Mainframes form the backbone of most monetized applications and websites, so it’s no surprise that mainframe agility has become a top focus for many IT departments. No matter how sleek and flashy your application is, if customers have a bad experience at the transactional level of the process, it could mean lost sales.

  • Report: Software Quality Issues Costing U.S. Companies $2.08 Trillion

    Report: Software Quality Issues Costing U.S. Companies $2.08 Trillion

    A report published today by the Consortium for Information & Software Quality (CISQ) estimates poor software quality collectively cost companies in the U.S. an estimated $2.08 trillion in 2020.

    The report, co-sponsored by software quality and security tools provider Synopsys, attempts to calculate, at least theoretically, the cost of known software failures. The report identifies operational software failures, estimated to be $1.56 trillion, as the single largest cost. The next-largest cost contributor is unsuccessful development projects, which totals $260 billion, an estimated 46% increase since 2018, according to the report. The project failure rate remained steady, at about 19%, for over a decade, according to the report.

    Finally, legacy systems issues contributed $520 billion to costs in 2020, a significant decrease from the $635 billion these issues cost in 2018.

    That estimate does not include technical debt, which CISQ estimates at another $1.13 trillion. Technical debt costs have been growing at a rate of 14% per year since 2018, the report noted.

    Joe Jarzombek, director for government and critical infrastructure programs for Synopsys, said it’s apparent there’s not enough focus on quality assurance within software supply chains. However, as organizations begin to realize how dependent their digital business transformation initiatives are on quality software, business executives will be forced to shift focus.

    Unfortunately, most business executives today still don’t understand or appreciate how software is constructed. Most organizations don’t even have a bill of materials describing the components that make up an application, noted Jarzombek.

    That issue becomes especially problematic in the event of a security breach, because too many organizations can’t draw a correlation between vulnerabilities and the impact on specific components of an application, added Jarzombek. At the same time, however, cybercriminals are becoming more efficient at scanning applications to discover and exploit those vulnerabilities, said Jarzombek.

    Many organizations also don’t appreciate how adept cybercriminals have become at exploiting what are perceived as low-level vulnerabilities to distribute malware laterally across an application, said Jarzombek. There is a tendency to patch only the most critical vulnerabilities within an application, while the rest are left to future updates. When fixing low-level vulnerabilities is not prioritized, these vulnerabilities may remain over multiple release cycles.

    Ultimately, Jarzombek said, rather than treating security separately from the application development process, it should be addressed as part of a comprehensive approach to software quality assurance. The immediate challenge, however, is that not enough developers have access to the tools they need to address these ongoing cybersecurity issues.

    The impact of poor software quality on individual companies will vary widely, but poor software quality is itself a universal issue. Most software development teams are not deliberately ignoring these issues; instead, the processes currently employed to build software are not especially robust, mature or, for that matter, automated, leaving organizations vulnerable.