To transform with success and grow, collaboration is key. Collaboration not only accelerates the adoption and dissemination of new technologies, it also fosters the culture of innovation required where new, complex engineering solutions are needed to address unique problems. 

This culture-building was demonstrated at our recent Accelerate Conference where we brought together 400 of our top software engineers and Chief Information Officers for an intensive three-day collaboration in Kuala Lumpur, Malaysia for our ‘Accelerate Global Engineering Conference’. Our end goal is to leverage emerging technologies to address customer pain points; transforming the way data can be enabled enterprise-wide; and accelerating our engineering to simplify, standardize and digitize our processes to become fit for growth. 

Building on this momentum is critical in helping us become a client-focused, data-driven digital bank. Equally important is ensuring we have a diverse workforce engaged to contribute new ideas, innovation and creativity which can lead to greater productivity and business performance.

Creating a great engineering culture 

Building an engaged team should be a priority for every leader. Happy employees are productive, collaborative, and willing to work through challenges. Software engineers are no different and need the right tools, inspiration, and autonomy to deliver impact. 

First, many organizations still struggle to equip their software engineers with the right, up-to-date tools. In many instances, engineers are given the same computers as call center employees while senior managers get the latest and most powerful. At times broken processes are applied to the very cohort of experts that are charged with automating and eliminating them. Software engineers need more powerful CPUs for complex algorithm optimizations, or the additional RAM to host VMs locally, or the GPUs for machine learning, or access to production data to build models.

Upskilling and reskilling engineers should also be a priority to ensure they reap the benefits of new technologies like AI and Machine Learning with agility. At Standard Chartered, our Axess Academies help us ensure the skills of our software engineering workforce are continually upgraded and recalibrated to match the ever-changing demands of the market. For instance, we have over 130 classroom technology courses across the entire stack of technologies used in the bank, from full stack development to GenAI and Cloud Computing. New courses are added every quarter and existing ones are upgraded to reflect industry trends and changes.

Second, many organizations struggle to inspire their engineers primarily because the leaders in charge of this cohort generally do not ‘get’ software engineering. From top down as a bank, we believe that applying our technology in the right way is critical to accelerating our transformation. This enables us to standardize end-to-end, transform digitally while simplifying our business faster and permanently reducing structural costs.

Finally, autonomy is key for software engineers. Autonomy unshackles software engineering teams to ideate and deliver for the business on their terms while fostering a work culture that fulfills employee needs for meaning and personal growth. I would contend that digital disruption and Fintechs are not only about amassing more technology, or even newer technology, but about giving software engineers the space to deliver their agendas and being pivotal in delivering solutions.

With 3 trillion lines of code written every day and around 93 billion lines of code being added every year, and with things only set to increase, it is important software engineers play an instrumental role in the process of determining and shaping the development of new technologies, processes, and outcomes.

With over 10,000 software engineers, we continually build a bank that offers diverse experiences and opportunities for everyone to work on compelling and impactful projects. As our Accelerate Conference highlighted, we can do more to elevate our engineering community by increasing knowledge sharing, breaking down silos and raising the standards of technical excellence. By doing so, we empower the current, as well as the next, generation of software engineers with future-focused skills and experiences to be effective catalysts for digital transformation. 

You may also like…

Report: 7 qualities of highly effective teams

SD Times Open-Source Project of the Week: Developer Productivity and Happiness Framework

Q&A: How cognitive fatigue impacts developer productivity

The post Accelerating digital transformation means creating a great engineering culture appeared first on SD Times.

Using the 2,650 responses to its survey, it was able to narrow down seven recommendations to build a high performing team.

• Define a clear purpose and vision

Teams must have clear goals in order to ensure that team members can see how their own skillsets and tasks are contributing to the big picture. 

Dale Carnegie recommends that leaders break big picture goals down into smaller milestones to enable teams to track progress, have discussions, and make changes to improve performance. 

• Close perception gaps between productivity, satisfactions, and culture between leaders and employees 

The study cites a report from Microsoft, which claims that 87% of employees feel productive at work, while only 12% of CEOs believe this is true. 

In order to close this perception gap, the recommendation is to improve understanding on how individual employees experience the workplace. “This gap can be an issue as leaders, reflecting a more favorable view in many areas impactful to team outcomes, can overlook valuable opportunities for improvement and neglect the true needs of the team,” the report states.

• Understand what makes a team satisfied

According to the report, there are often similarities between satisfaction and high performance. Eighty-nine percent of high-performing teams are “very or extremely satisfied” with their team, while only 65% of non-high performers felt the same. 

The top drivers for team satisfaction included the ability to collaborate, group participation, and trust. The qualities that most separated higher and low performers include growth opportunities, cooperation, and the ability to share ideas.

• Facilitate effective team communication

This goes hand-in-hand with establishing a clear purpose and vision, as those ideas need to be effectively communicated across the organization. 

“A collective understanding through effective communication can help a team determine fit within the purpose and vision and provide extra motivation when heavy workloads or high-stress levels exist, ultimately supporting resiliency,” the report says. 

• Have adaptability

This enables teams to adapt to ongoing changes in the workplace. According to the report, 74% of teams that exceed their goals had good access to training and development materials. 

“A commitment to ongoing development opportunities must be a part of the organizational culture. Empowerment is key. Team members need to feel they have the necessary skill sets and permission to act and contribute in a productive way for their work product and colleagues,” the report says.

• Facilitate collaboration and cross-functionality

Dale Carnegie believes that successful teams have coworkers who share a healthy attitude towards each other and understand each other’s roles. 

The research reveals that as the frequency of interaction among teams goes down, so does its chance of being a high-performing team. Collaboration and cross-functionality will remain even more important as new flexible work models, such as fractional work, role sharing, and matrixed teams, take hold. 

• Technology can’t replace culture

As tools like generative AI, natural language processing, and VR/AR are entering the workplace, it’s important for teams to remember that “technology has a supportive role in creating and empowering high-performing teams, not a primary one.”

Dale Carnegie recommends that when exploring these new technologies and how they fit in the team, teams should also consider opportunities for improving their culture as well.

The post Report: 7 qualities of highly effective teams appeared first on SD Times.

The new division will provide consulting for companies and communities looking to improve their Diversity, Equity, and Inclusion (DEI) practices. 

According to AnitaB.org, it will provide a systematic approach customized to each company’s specific needs that will take into account business strategy, workforce profile, cultural values, and consumer markets when coming up with plans for an organization. 

The company has been working with and supporting women and non-binary technologists for the past 25 years, which gives it a unique perspective into what is needed in the industry and how to bring about change.

The new division will be led by Bo Young Lee, a human capital, DEI, and ESG executive with 23 years of experience with this sort of work. Previously, she was Uber’s first chief DEI officer and before that held roles at Marriott International, Northern Trust, John Deere, Allstate, Booz & Co., Discover, Aon, Human Rights Campaign, and McKesson.

“Bo is a respected DEI advisor, strategist, and practitioner,” said Brenda Darden Wilkerson, president and CEO of AnitaB.org. “Having her join the AnitaB.org team to head up Advisory is an honor and a privilege as we have collaborated numerous times in the past, holding insightful conversations on the state of DEI … the conversations that others steer away from. If we don’t have these conversations and bring DEI issues to light, we can’t create and implement strategy for The Way Forward. We look forward to the impact our organization will make with Bo’s experience and expertise and this new offering.”

AnitaB.org made the announcement for this consulting division at this year’s Grace Hopper Conference, which is happening September 26-29. More information is available here.

The post Company behind Grace Hopper Conference, AnitaB.org, launches DEI consulting firm appeared first on SD Times.

The upside of this challenging environment is that it creates an opportunity for companies to proactively navigate and actively manage their ADM processes. As organizations explore different ways to utilize and improve their ADM services, they should prioritize a strategic, simple, and sustainable roadmap. 

Enhance strategic decision-making: By adopting a strategic ADM approach, enterprises can reduce costs and achieve better outcomes that are aligned with their business goals and objectives. In addition, they will improve the efficiency and the effectiveness of your application development and management efforts.  Focusing on the following five key principles and practices will help your enterprise achieve desired strategic outcomes: 

Align your ADM portfolio with your business goals: Be clear on your business outcomes prior to reviewing the applications that are currently in use and the purposes they serve. Once the applications portfolio is reviewed, organizations should assess how well each application aligns with the identified business goals. This can be done by evaluating the application’s functionality, usage, and benefits to the organization.

Focus on the most important applications that drive business outcomes: Not all applications are equally critical to the organization’s success. Emphasize your ADM efforts on the applications that are most essential to achieving business goals and delivering value to stakeholders.

Foster a culture of innovation: ADM can support the development of new products and services, or the introduction of new business models by providing the tools and infrastructure needed to enable innovation.

Increase concentration on data and analytics: Data is becoming increasingly complex and diverse for which a well-designed ADM framework will process and manage this data efficiently and accurately. Collecting, processing, and analyzing data from a variety of sources is essential for effective data analysis.

Choose a partner that is aligned with your strategy: Don’t overcomplicate the setup and business KPIs. Ensure your partner is well versed in all aspects of applications and evolving technologies.

Keep the execution simple and straight forward

Once the ADM strategy is defined, implementation can begin. A popular design principle states that designs and/or systems should be simple and feasible. Complexity should be avoided whenever possible in a system, as simplicity ensures the highest degree of user acceptability and interaction. Businesses can streamline the ADM process and reduce unnecessary complications by taking the following actions: 

Adopt a flexible and agile approach: These methodologies emphasize iterative and incremental development, allowing for flexibility in adapting to changing requirements and priorities and for frequent and smaller releases, reducing the risk associated with large deployments.

Utilize low code-no code platforms: Low-code and no-code platforms provide visual interfaces and pre-built components that allow developers and even non-technical users to quickly build applications, which speeds up the application development process and reduces the reliance on traditional coding, enabling faster time to production.

Communicate clearly and regularly: Organizational Change Management (OCM) plays a vital role in implementing changes associated with ADM.  Clear and regular communication ensures alignment, manages expectations, and fosters collaboration. 

Focus on user needs and prioritize user experience:  Adopt a user-centered design approach during application development. Conduct user research, gather feedback, and understand user requirements and pain points. Incorporate user feedback into the design and development process to ensure that the application meets their needs and provides an intuitive user experience.

Increase use of automation and artificial intelligence: Strategically automation and AI tools bring numerous benefits, including improved efficiency, scalability and quality.  With technologies evolving quickly, it’s important to choose a partner that strikes a balance and identifies areas where automation and AI can bring the most value, while still maintaining human oversight and ensuring ethical considerations. Regular monitoring, evaluation, and continuous improvement are essential for successfully implementing automation and AI in ADM. 

Choose the right partner with vital experience: You can select a strategic service provider or partner that aligns with your organization’s goals, expertise requirements, and cultural fit, ultimately contributing to the success of your ADM initiatives by evaluating several factors. These factors include cultural fit, proven experience level, industry reputation and references, service offering alignment, security and compliance, innovation and future readiness, and cost and value.

Adopt a sustainable approach 

The last pillar is creating an ADM blueprint that will reduce the environmental impact with sustainable development practices. Enterprises should consider leveraging the approaches below to implement sustainable solutions and stay ahead of competition. 

Optimize code for energy efficiency: Your company or strategic partner can design and code applications with energy efficiency and sustainability in mind. These strategies, which range from optimizing the user interface to efficient data storage and processing, contribute to reduced energy consumption, lower carbon footprints, and a more environmentally friendly approach which is an essential aspect of promoting sustainability. 

Remote work: By developing applications that support remote work, organizations enhance sustainability by reducing carbon emissions, office space requirements and paper waste. These applications enable employees to work securely and efficiently from anywhere, fostering work-life balance and environmental responsibility. 

Cloud migration: Migrating applications to the cloud reduces infrastructure costs and energy consumption, optimizes resource usage, and increases scalability. It is important that the environmental practices of cloud providers assess the sustainability benefits of the migration and optimize applications for efficient resource usage. 

Providers that prioritize sustainability: Choose providers that have policies in place to reduce their environmental impact, consider their commitment to sustainability and energy-efficient practices including partners who prioritize energy-efficient infrastructure, green computing, and sustainable operations.

Leverage automation tools: Organizations enhance efficiency, optimize resource usage, and reduce energy consumption by utilizing automation tools to improve application testing, deployment, and monitoring. This approach promotes sustainability by minimizing waste, improving operational effectiveness, and reducing the environmental impact. 

Creating and maintaining a strategic, simple, and sustainable ADM environment within your enterprise opens a significant opportunity to continuously optimize your overall program. By aligning ADM efforts with business goals, simplifying processes, and adopting sustainable practices, your organization can make better use of resources, respond to changes swiftly, and achieve leaner operations. This drives continuous improvement, enhances the effectiveness of your program, and ultimately contributes to the success of your ADM endeavors.

The post How to successfully optimize application development and management appeared first on SD Times.

It’s time to shed light on the human side of automation – an aspect that goes beyond mere work efficiency gains. Yes, automation streamlines processes, accelerates software development, reduces human error, and boosts consistency in quality, but the underlying goal should not be to increase the workload or create an environment of perpetual busyness. Instead, it should serve as a catalyst for creating a harmonious balance between work and personal life. An underreported ROI of automation lies in its ability to not only free us from the burden of monotonous and time-consuming tasks but to give us back time to have a life.

The testing world has been transformed by automation. Developers can redirect the time they once spent on manual testing to more meaningful pursuits. But what about other teams? For me, the positive effects of automation have rippled throughout my organization. With a more efficient workflow, projects are being delivered faster and with higher quality. The bread and butter of my job is writing high-quality content to support sales, so AI tools like ChatGPT and Google Bard have helped me quickly come up with blog ideas, webinar titles, summarize and make sense of large amounts of data, and more.

If you’re an API developer, how time consuming is it for you to have to test your APIs manually? Is there any benefit to you performing the task that way? How many hours would it save you, your team, and your business to be able to automate that process?” 

If you’re a performance tester, what is your most time-consuming task that you do manually? Is it possible to automate even a portion of it?

Certainly, AI engineers can automate more of their tasks. For example, debugging software, predicting future issues, and filtering low-tier incidents no longer have to be manual tasks. 

The desire for work-life balance is universal among employees. Mental well-being platform Yerbo’s recent study of more than 36,000 IT professionals in 33 counties found that two in five workers are at high risk of burnout because of long hours, demanding workloads, and conflicts in work-life balance. 

As managers, it is vital to recognize the significance of this aspect and foster an environment that values the well-being of team members. By actively understanding the automation tools that teams require to effectively manage their workloads, maintain work-life balance, and embrace personal interests, managers can play a pivotal role in promoting happier, healthier, and more productive teams.

Organizations should give all their teams access to whatever automation tools they need that will enable them to do their jobs more efficiently and whatever enables others to help them do theirs – so no one burns out, quits, or feels like their job situation is forever doomed.

When developers or any team member experiences reduced stress and gains more time for personal pursuits, team morale improves. A sense of fulfillment in personal life often translates into increased creativity and enthusiasm within the workspace, leading to higher job satisfaction and better project outcomes.

Moreover, prioritizing work-life balance through automation initiatives nurtures longer-tenured and engaged teams. By empowering others with automation tools, organizations can mitigate the risk of employee turnover and create an environment where employees feel valued, supported, and equipped to thrive in their roles for the long term.

However, achieving the full potential of automation requires strategic planning and implementation. The focus should not solely be on the technical aspects of automation but also on the well-being of the those who will be utilizing these tools. Providing the right training, support, and access to automation tools tailored to the team’s needs are critical steps in ensuring the success of automation initiatives.

Automation is not just a means to improve efficiency; it is a transformative force that can lead to a more balanced and fulfilling life for all teams. The journey toward a more harmonious work-life integration begins with understanding the needs of each team, providing them with the automation tools that enable a healthier and more satisfying professional journey.

Organizations and managers hold the key to shaping a culture that values the well-being of their most valuable asset – their employees. Through a thoughtful approach to automation and a genuine commitment to work-life balance, all teams can thrive in an environment where personal growth and professional success go hand-in-hand.

Whether it’s dedicating more hours to hobbies, engaging in quality time with family and friends, or focusing on self-care, automation presents an opportunity for us all to craft a more balanced and fulfilling life. 

The post The human side of automation: Reclaiming work-life balance appeared first on SD Times.

If the Great Resignation has taught us anything, it’s that developers who are tired of workplace culture don’t stick around. Average tenure at some of the most prominent tech companies in the world is under two years, and when they leave, they often take valuable code, customer contact lists, patent applications and much more with them. For senior developers and team leaders, it’s a high price to pay when employees start sniffing around for other opportunities. 

Fortunately, you can take steps to reduce turnover, many of which aren’t complicated or time consuming. In today’s super competitive environment, one of the best ways to make your company a great place to work—and to keep developers happy—is pretty straightforward. Just back off. Trust them to do their jobs well.

This is key to building a supportive environment where developers feel comfortable voicing their ideas—particularly if those ideas are unpopular. Leaders have a responsibility to establish the kind of environment where values are reinforced, and to hire people who thrive within this framework. Even if that means they’re not always hiring the candidates who seem like an obvious fit.

Even Dumb Ideas Can Be Valuable

I know this because I have lots of dumb ideas. I’m thankful that, over the years, my colleagues have actively encouraged me to share those ideas. It taught me that I can build and foster a company culture where new ideas and new ways of thinking are valued, even if those ideas aren’t immediately well received.

Something that might seem like a dumb idea at the time, can actually evolve into something remarkable. By encouraging people to share their ideas, you can foster a sense of trust and innovation that leads to an explosion in creativity. It also makes your organization stronger by reducing employee stress—stress which ultimately leads to burnout and turnover.

Employees know they’ve long been perceived as replaceable cogs in the corporate structure, and not as unique individuals with valuable skills, and yes, shortcomings. So, fostering a culture that’s truly human and invites vulnerability has to be done with intent and deliberation.

People want to feel authenticity in where and how they work—that’s why it’s valuable to talk about new ideas (even dumb ones) to ultimately improve the company and its products. Fostering a supportive culture will likely lead to disagreements, but there are ways to offer opposing viewpoints without being a jackass. This mutual respect between developers allows your entire team to look at things through a critical lens without stepping on other people’s toes.

Here’s one example: at CodeSee, we do regular product reviews, which oftentimes lead to conversations where our developers say: “I really wish our product would do this instead.” Or “wouldn’t this be a cool feature to add?” This isn’t criticism leveled at anyone in particular, and everyone understands this. It’s a collaborative effort, with the aim of improving how our product works.

Take Steps to Sniff Out the Jerks in Your Applicant Pool

Some companies subscribe to the idea that if you’re a genius, it’s OK to treat people like garbage. We don’t. We’d rather have a decent developer who fits our culture and embodies self-reflection and humility, than a great developer who doesn’t support others. The same things we prioritize in our day-to-day operations are also reflected in hiring. There are easy-to-implement strategies to identify these qualities in potential new hires.

Two of our standard questions are simple and straightforward. We ask candidates to define three strengths and weaknesses. Three is a big enough number so that it requires introspection, and it helps us gauge if developers have already identified strategies for personal growth. The second question we like to ask is: “what will your previous managers say about you when we talk to them?”

These questions are meant to help us gauge whether or not the candidate has a pulse on self-reflection. If candidates can consider what it’s like to be one of their past managers, it shows a high level of self-awareness and empathy. And these are the people who tend to make it through our hiring process. 

Conversely, we’ve seen these questions absolutely sink some applicants. Some of them suddenly feel uncomfortable—I’ve actually been yelled at on more than one occasion. Can you imagine yelling at the person conducting your job interview? Yet it happens, and at that point, it’s game over.

Finding the Right Tools for Success

Providing the right tools is another way companies can foster a positive culture. Consider the responsibilities managed by today’s developers—especially those on teams who’ve implemented DevOps best practices. It’s not surprising that many are seeking tools to help them reduce time in tasks like project onboarding, feature planning, and code review; they’d rather focus on actual development.

Today developers spend over half of their time reading code. But what if we could cut that by just 20 percent? Or even 40 percent? If your software developers could spend 40 percent of their time doing other things, it would be truly transformative for business.

Of course, productivity tools can have drawbacks. Instead of giving more freedom and trust to developers, some organizations use technology to try to squeeze every last scrap of productivity out of them. If that’s the case, the underlying message your employees may hear is, “You’re getting a new, expensive tool because you aren’t being productive enough.” There’s no better way to push talented developers towards the exit.

Ultimately everyone needs developers, and they’ll be well compensated wherever they land. So, while some turnover is inevitable, a lot of it can be avoided if you’re intentional about crafting and maintaining a supportive work environment. And the creative energy you foster will help ignite product innovation.

The post Don’t lose developers to bad culture appeared first on SD Times.

Following are five of the misconceptions.

#1: DevOps = Dev + Ops

On some level, parsing the term seems logical. For the past 15 years or so, the software industry has been saying that Dev and Ops have to work together as a cohesive unit to deliver higher quality software faster. Interestingly, the belief that the definition of DevOps is Dev + Ops falls apart on several levels. In fact, Charles Betz, principal analyst at Forrester says this is the #1 misconception.

“There were a series of epiphanies, discussions and lessons learned coming out of a wide variety of really smart people working in very challenging environments. You have to have some familiarity with that history to begin to make sense of it,” said Betz. “We get a lot of people calling in and that’s their level of understanding. They haven’t challenged themselves to really dig into where the whole movement came from.”

RELATED CONTENT:
Creating a DevOps culture
Dynatrace replaces DevOps with NoOps
Still testing like it’s 1999?
A pragmatic view of DevOps in large enterprises

Simply parsing the term can cause issues. For example, testing is obviously missing from the term. While DevOps teams do testing, they sometimes treat it like a second-class citizen and as a result, quality is not as high as it could be.

“Without testing, you lost a vast majority of the benefits,” said Dave Messinger, CTO at talent marketplace Topcoder. “We’ve put a lot of emphasis on quality assurance and testing.”

Clearly, security isn’t included in the term either. Because quick CVE scans aren’t enough, some teams have embraced DevSecOps to ensure that security is addressed adequately throughout the lifecycle.

#2: It’s all about tooling

Many types of cultural change are confused with tool procurement. DevOps, Agile, and even digital transformation are often viewed this way. If one simply procures a tool or set of tools, then, from that time on, the organization is “doing DevOps.”

“We dive into conversations about do we do Jenkins, do we do Docker, do we do Swarm and it just becomes a tool conversation. And then we have these philosophical battles about which tools are the best,” said CTO consultant Emad Georgy. “Foundationally, they’re just not ready for the cultural changes [and] they have no idea how to communicate the business value of what they’re doing.”

Forrester’s Betz said changing practices and changing tools changes culture, although a tool may not impact culture at all, so technology has to be combined with peoples’ expectations, their priorities, how they’re measured and how they’re incentivized.

“People focus on process and tools instead of interactions and individuals and how they come together,” said Pradeep Menon, EVP at business and technology services firm Orion Business Innovation. “It’s about culture and faith.”

Consultants often say that their clients tap them for tool recommendations before thinking about the larger picture.

“A big mistake teams make is to go out and look at the entire ecosystem with hundreds of thousands of tools, trying to build the perfect solution,” said Dominic Holt, CTO of  fractional CTO company Valerian Tech. “By the time you’ve built your DevOps pipeline, you’re going to change at least 50% because the ecosystem is moving so fast.”

Some companies have spent 12 to 18 months building those pipelines only to discover they didn’t do it right the first time, so they spend more time redoing it, wasting two and a half years.

“If you haven’t done this before, talk to people who have done it,” said Holt. “It probably took me six to 12 months to become familiar enough with these tools that I realized I didn’t do anything correctly.”

#3: DevOps increases error rates 

One of the benefits of DevOps is fast feedback. However, if failure is not tolerated and the pipeline is automated, it may appear as though code quality is worse than before.

“People don’t realize that DevOps involves a lot of failing and learning,” said Georgy. “Some organizations aren’t ready for that information. They’re seeing it as ever since we adopted a DevOps culture, we’re getting more errors than we had before. What they don’t realize is the errors have always been there.”

#4: It’s about automating part of the SDLC

People often talk about the importance of automating a pipeline, but some view it as synonymous with DevOps.

“A lot of people miss the mark and say DevOps is writing automated tests, configuring continuous integration for my project, or using code to provision and configure infrastructure resources in the cloud,” said Justin Rodenbostel, VP of delivery at digital transformation agency SPR. “People confuse components or ingredients of DevOps with DevOps like somebody seeing a tree instead of a forest. For us, the most important part is the unified cross-functional aspect of working together. The communication and process aspects. We see tools as the support system.”

#5: A DevOps engineer will enable a DevOps transformation

Some organizations try to hire DevOps engineers to affect a DevOps culture. Others rebrand operations engineers as DevOps engineers and then claim to be doing DevOps. 

In a top-down transformation, the newly-hired DevOps engineer may not be empowered to spearhead a DevOps transformation. 

“You need champions because it’s very hard, especially in larger organizations to do these cultural shifts, especially when things are very much imprinted in the way things are done,” said Valerian’s Holt. “Otherwise, people will go back to what’s comfortable, their defaults.”

In a bottoms-up transformation, the person may fail for people-related reasons, either because people don’t want to change, or they resent the new role which has been charged with changing the status quo.

Topcoder has two dedicated people that manage the DevOps pipeline and processes which CTO Dave Messinger says “cascades through the entire organization.” Specifically, they help manage the infrastructure, processes, enforcements and how DevOps is done, down to individual development teams and individual sales teams. 

The post 5 DevOps myths appeared first on SD Times.

For example, talent marketplace Topcoder has had a formal DevOps practice for the past three or four years and started a DevOps-like practice in 2007. As part of its transformation, the company moved from an on-premises data center to the cloud and rebuilt its applications as cloud-native applications. More recently, it changed its tooling and updated its DevOps practice to include security and compliance. 

DevOps is ultimately a combination of a culture, processes and tools, although not everyone sees it that way. In fact, there are a lot of misconceptions about what DevOps is. 

“DevOps is a set of practices that give organizations and teams unified, cross-functional representation, shared accountability from development, operations, the business and everybody in between,” said Justin Rodenbostel, VP of delivery at digital transformation agency SPR. “People work together throughout the development process to create higher quality software solutions in shorter time frames. We like to think of it as an extension of Agile.”

RELATED CONTENT: 
Dynatrace replaces DevOps with NoOps
CI/CD pipelines are expanding
Still testing like it’s 1999?

Charles Betz, principal analyst at Forrester, said that “building a DevOps culture” is a misnomer, however.

“I think a subtle misconception is that you can somehow start with culture. This may be contrary to what you’re hearing from others because culture is important. But I believe as do a lot of other folks, that culture is a lagging indicator,” said Betz. “You do change culture by changing practices. You do change culture even by changing tools.”

Changing culture takes time because it involves changing mindsets and ways of working. While one can start using a new tool today, it may be several years before an organization believes it has achieved any kind of maturity. In fact, many of the companies interviewed for this article series have been practicing DevOps since 2015 or longer and consider themselves to be either at the beginning stage or the “awkward teenager” stage.

“You don’t build the culture, it’s more emergent, more organic,” said Forrester’s Betz. “It gradually manifests as the sum total of all the interactions people are having and how those interactions are being transformed because they now have new operational capabilities that they didn’t have before and they have permission to use those capabilities.”

Not everyone agrees with that outlook, however. In fact, some practitioners and consultants advise starting with a cultural end state in mind so it’s clearer how processes, practices, and tool sets need to evolve. That said, even with a planned transformation, pivots tend to occur along the way as organizational priorities, competitive factors, customer expectations, internal dynamics and technology all change.

“Now we’re working more closely with the business. We’re communicating better, we’re adapting to change better, and we’re delivering what the business is expecting in a timelier fashion,” said SPR’s Rodenbostel.

How roles are evolving
Forrester recently published a report entitled, “The Future of Technology Operations.” In it, Betz observes the flatter organizational structure of modern technology operations versus the traditional hierarchical structure. The flatter or matrix structure of the organizations impacts the roles of individuals and team dynamics.

“The idea that somebody can specialize is falling by the wayside,” said Betz. “You get to the T-shaped people who each have a specialty and a certain element of breath. You have more line of sight, a lot more interest, a lot more commitment to the mission outcome of a team and you have somewhat less commitment to your professional identity.” 

That can be an uncomfortable transition for people whose self-worth is tied to a particular role.

“[Traditionally,] goals and responsibilities have been based on a person. They have to be based on the success of the team,” said Rodenbostel. “When roles are being invented to align with DevOps, there is some discomfort because it’s more of an environment of shared accountability. Whereas when you operate in silos, it’s much easier to be successful as an individual.”

DevOps and CI/CD pipelines provide visibility into what’s happening throughout the development process, which has three effects. The first is providing individuals with insight into their own progress. The second is facilitating a sense of shared ownership and responsibility. The third is making people accountable for their work.

At talent marketplace Topcoder, deployment engineers became DevOps engineers. And at messaging services company Gupshup, developers have begun taking responsibility for writing deployment code. QA has moved from performing testing to maintaining automated test suites.

Dominic Holt, CTO of fractional CTO company Valerian Tech, said he first goes to the deployment files and automation scripts before writing a single line of code so he knows the code will work in whatever production environment he wants.

Teams are evolving
Like Agile, DevOps is associated with cross-functional teams. 

“One of the foundational pillars of DevOps is systems thinking,” said CTO consultant Emad Georgy. “[Instead of asking] who’s fault is it, systems thinking looks at the whole system. If something went wrong with the pipeline, no matter who owns it, let’s look at the system as a whole and understand what the actual root cause is and solve it. A lot of people don’t do that. A lot of people are not ready for that kind of thinking.”

Teams are self-organizing at business and technology services firm Orion Business Innovation. 

“It’s about empowerment. They have motive, they have purpose,” said Pradeep Menon, EVP at Orion.

Trust is a hallmark of an effective DevOps team. Specifically, members of the team trust each other. There is also a technical aspect of trust. Organizations are placing trust in that which is automated, whether it’s policies, deployments or a database’s ability to self-heal.

“I think one way to encourage behavioral change is by doing regular measurement and responding to the results of that measurement,” said SPR’s Rodenbostel. “Give the team the opportunity to improve when things aren’t going well and celebrate when things are going right.”

Another wise move is aligning financial incentives with the desired behavior, which not all organizations do. Part of the problem is that business leaders and HR don’t always understand the subtleties of IT. The disconnect can work against IT cultural transformation.

At Topcoder, everyone can see the statistics, which makes it easier to see how code changes impact revenue, for example. 

Governance is evolving
DevOps involves a lot of automation throughout the software development life cycle. With infrastructure as code and even compliance as code, governance can be integrated into the pipeline in a manner that does not add an unwieldy amount of overhead.

“If you have five product lines, all with their own product teams and release cycles, and they’re all released in their own way, [you may benefit from]  establishing one standard DevOps pipeline where everybody builds, integrates, tests, deploys and monitors the same way because everyone’s using the same pipeline,” said Georgy. “The security guys are elated because they no longer have to look at five products that all have their own custom builds; they can secure one standard pipeline.”

Forrester’s Betz said governance needs to switch from how to what.

“You need to govern the promises your team is making,” said Betz. “It takes a certain level of trust and holding teams accountable for what they said they were going to do. It’s basically elevating the concept of internal SLAs but then not really meddling beyond that, unless you need to do forensics on why something really went badly.”

Of course, that approach is at odds with auditing, which demands an explanation of exactly what happened, why it happened, when it happened, and who was involved.

“The trouble is that work is getting done in a much more collaborative, less deterministic, fuzzier way. So, when an auditor comes in and says show me your standard flow chart for how this work is supposed to happen, there is no flow chart,” said Betz. 

How to get started
If you haven’t started your DevOps journey yet, it’s wiser to start with a pilot project and learn from that instead of attempting a massive transformation effort from the start.

“If there are multiple products in the portfolio, [identify] which could immediately benefit from a DevOps transformation,” said Georgy. “Then go after quick wins.”

One thing to keep in mind is even if a pilot went well, it may not scale as-is perfectly to another product or team. The approach may have to be adapted to suit the goals of the team, the people on the team, and the business’s expectation of the team.

“It was relatively easy to implement DevOps for a specific product where it was the only way to achieve our desired outcome,” said Nirmesh Mehta, CTO at Gupshup. “It was much harder to expand it to other areas where there was no burning requirement and the possibility of a lot of disruption.”

One question is whether it’s better to have dynamic teams or static ones.

“One of the most important things that the modern manager is starting to realize is that a high-performing, cross-functional team is a very precious resource, and you don’t just throw people on or off those teams,” said Forrester’s Betz. “You don’t just take Mary off the team and replace her with Myra because Myra knows Python.”

If Mary has been a contributing member of a team and understands the business problems the team is attempting to solve, then It’s much better to teach Mary Python, assuming she can wrap her head around it, Betz said.

SPR’s Rodenbostel recommends considering the product that’s being worked on, the tools already in use, people and their skills as well as organizational constraints.

“If you take those things into consideration, the results may not be as immediate as they would be if you came in and made a drastic pivotal style change on a specific product and a bigger ecosystem, but the longer-term value, like actually changing people’s habits and making the cultural shift, is what we think is more successful,” said Rodenbostel. “It’s better to keep in mind that DevOps is a journey and not a one-size-fits-all solution.”

Vladyslav Gram, head of DevOps at digital solutions company Ciklum, stressed the fact that the people affected by the shift need to be involved from the start.

“We need to make sure everyone follows [our DevOps] process. If someone doesn’t like it, if someone thinks there are problems with this process, we need to hear them and we need to fix their problems,” said Gram. “If we don’t have this type of integrity, then we don’t have a DevOps process at all.”

How to measure success
Continuous evaluation is essential for continuous improvement. However, it may not be clear how to measure the effectiveness of a DevOps culture, since culture is intangible. However, tangible metrics can provide insight.

Number of deployments. This is measured within a specific timeframe, such as the number of deployments per day.

Release frequency is an obvious one. Many teams have embraced DevOps with the goal of increasing delivery speed. However, faster delivery should not be achieved at the expense of quality.

Idea to production velocity. Is the time from business idea to production software decreasing? While this may be reflected in faster release velocity also, this metric considers the business aspect as well as the technical aspects.

Quality improvement. Quality improvement metrics include defect rates, percentage of successful builds, and percentage of successful deployments, all of which should improve over time.

Mean time to recovery. Infrastructure as code and autonomous databases are improving mean time to recovery. However, teams still need to track their progress here.

Business impact. While technical metrics can help explain the team’s productivity, speed, or quality improvements, ultimately, the purpose of DevOps is to speed time to value delivery.

“Profitability, customer satisfaction, cost reduction and risk reduction are the big four from a CFO and CEO perspective,” said Forrester principal analyst Charles Betz. “The thing I like about DevOps is a big step towards actually getting line of sight from technical operations to those business metrics.”

The post Creating a DevOps culture appeared first on SD Times.

Andre Martin, vice president of PeopleDev at Google, spoke about how businesses can create “a culture of high performance” that doesn’t hold them back.

RELATED CONTENT: Culture fit prevents tech companies from growing

“How do you make sure that a company is as powerful as a brand?” said Martin. “And how do you ensure culture is a lever of growth and not the reason why your company doesn’t exist?”

Martin spoke about some of the top companies 20 years ago: Atari, ACE, Taxi, TiVo and Jones University. Fast forward to today, and these companies have disappeared despite being on top and having all the technology they needed to remain there, he explained.

“The reason they lost their way is because they lost the culture,” Martin explained. “They lost sight of the original principles they started their firms with … and started to treat themselves as invincible … as if no competitor could compete with them.”

“Past experience is going to be the inhibitor to future growth,” Martin added. “We use our experiences to define the moment we are sitting in and in doing so we are likely missing a lot.”

However, companies do seem to understand culture is important; they just are not tackling it, Martin explained. He cited a McKinsey and Company report that found 68% of respondents believe culture is a competitive advantage, 81% believe organizations without high-performing cultures are doomed, 76% believe they can change their culture, and 67% believe they need to change.

To get a sense of how an organization’s teams are working, Martin said to look at “the bids.” In a couples relationship study, researchers found couples bid towards, away and against. Bid towards is demonstrated through compliments, engagement and retention. Bid against is arguing, and bid away is ignoring.

The researchers found couples who bid towards each other 80% of the time were more likely to stay together than couples who only did it 33% of the time.

“The takeaway is pay attention to the bids,” said Martin. “Teams are bidding for your attention every day. What kind of bid are you giving them?”

In addition, Martin provided eight attributes he believes can erode culture quickly:

1. Keeping people busy
2. Not allowing for failure
3. Making everything a priority
4. Creating more competition
5. Being resistant to new ideas
6. Invoking history
7. Critique
8. Keeping the circle small and tight

Martin also added it’s not only important to look at your team’s culture, but also be aware of the team’s climate. Culture is the expectations that are set while climate is the environment, the felt experience of team members. Getting both aligned will result in high engagement and committed employees, said Martin.

For instance, you can’t claim to be a company all about values and collaboration and then have your teams in a dark basement and you are just barking orders at them, he explained.

In order to change culture, leaders have to be mindful of their team’s climate; as an employee or talent, they have to have a voice and speak up in order to make the company a successful brand; and as a community, we have to talk to each other and understand how to balance the work, and be open to learn and do things differently, according to Martin.

“If you find someone with creativity, innovation and talent — don’t let them go,” said Martin.

The post DOES: Culture can be a competitive advantage, or it can be an inhibitor appeared first on SD Times.

So, if every enterprise looks entirely different than the next, where do you start? First and foremost, you need to understand your business objectives because those objectives and measured outcomes drive the enterprise DevOps transformation, not vice versa. A thorough understanding of the business objectives (i.e. to free up capacity for innovation and eliminate the bottleneck to the business) enables DevOps practices to be appropriately scaled for the enterprise.

As organizations begin their DevOps journey, they will face many hurdles. Here are five common challenges you may encounter along with potential solutions to help establish a foundation for a successful DevOps journey.

1.) Changing to a DevOps Culture

Renowned American scientist, author and founding father of the quality movement, W. Edwards Deming said, “a bad system will beat a good person every time,” and this sentiment captures the main challenge when implementing a DevOps culture. The system, not the employees, is the cause of the problem, and an organization’s leadership team needs to be willing to change the system of work. To start, first define the desired actions and behaviors, then design or update the work processes to reinforce those behaviors.  

If continuous improvement and change is desired, you have to ensure the “System” is designed to support these cultural traits. If the Ops teams are measured only by mitigating risk and the Dev teams are measured only by delivering change, there is a conflict in the system that must be resolved, and the leadership team must take the initiative to fix the problem.  Only management can align the resources within the organization to drive the level of transformation that is required, and that management team needs to get on board and be willing to change the system; otherwise scaling DevOps will not be possible.

2.) System Thinking for the Enterprise

The goal of scaling DevOps in the enterprise, as highlighted in Gary Gruver’s book, “Starting and Scaling DevOps in the Enterprise,” is to document, prioritize, and optimize existing deployment pipelines and seek efficiencies to deliver better business outcomes. Every IT organization currently has a software process in place to build and deliver software – the “current” deployment pipeline. In fact, large enterprises have many deployment pipelines, and often, DevOps is first implemented at a team level that leverages DevOps practices within the context of a particular deployment pipeline. By employing system thinking within the scope of their deployment pipeline, the team can ensure that local optimization does not jeopardize the flow of the entire pipeline.

In large enterprises, to be successful, there should be another level of abstraction where system thinking is pitched above the level of individual deployment pipelines and product teams. Building a resilient enterprise requires understanding and anticipating how the whole system is designed to work vs. how it is currently working, and documenting your existing deployment pipelines could turn into a discovery session exposing the local constraints, dependencies, and waste that impact the entire system.

3.) Bridging the Old with the New

After over 40 years of investment, enterprise IT runs the world on applications that span many different development methodologies and infrastructure architectures. The future of enterprise IT depends on the ability to innovate faster while minimizing risk and to unlock the value of existing core business systems while leveraging new disruptive technologies. It’s not only about delivering legacy code faster, but also about optimizing cost and efficiency of existing infrastructures while providing the ability to automate and integrate the DevOps toolchain.

Many believe you have to be agile or implement a bimodal strategy to do DevOps; however, neither is true. Accelerating application delivery is the number one reason companies implement agile development methodologies, but agile by itself is often not sufficient. And, bimodal does not work well either as it just creates bigger silos that do not map with the value stream of the business.  Modern applications are supported across a complex, distributed and heterogeneous set of environments, and frequent changes to the systems of engagement tend to drive changes to the systems of record, requiring organizations to improve the flow of change through all systems in the value chain.   

Most organizations have been slow to realize that the same DevOps principles used for loosely-coupled architectures work for tightly-coupled architectures as well. In fact, tightly-coupled architectures provide a unique opportunity to free up capacity for innovation by automating deployment pipelines and removing waste.  At the end of the day, it is important to remember that DevOps is not about what you do on what platform, but what your outcomes are.   

4.) Prioritizing Deployment Pipeline Optimization

Once you get a view and understanding of your deployment pipelines, you need to make decisions on which pipelines should be optimized first. Decisions should be made based on the original business objectives. With fixed IT budgets, optimizations should not only reduce lead times, but reduce costs as well. Only by factoring in both cost and lead times will organizations be able to satisfy previously set objectives.  

For example, you may have a collection of loosely-coupled pipelines that support high-growth applications and drive a lot of changes. These pipelines may require more resources. You might also have several tightly-coupled pipelines that are low-growth and support your existing revenue stream.  These pipelines may have a high cost of support. In this case, where should you prioritize optimization efforts?

Many would take the tightly-coupled pipelines off the table and focus on optimizing the loosely-coupled, high growth pipelines. But, if your business objectives are to free up capacity for innovation and not be a bottleneck to the business, you can accomplish this by optimizing the tightly-coupled pipelines first, and quite frequently, these pipelines have the longest lead times, so you are satisfying both objectives.

5.) Where to Optimize

Once you have a prioritized list of deployment pipelines, you can begin drilling down into pipeline optimization. Your value stream mapping exercise should provide you with guidance on sources of waste and long lead times, which may include:

• Lack of understanding of the business requirements leading to high development rework costs and long lead times
• Too much manual effort in building, provisioning, testing, and deploying applications and environments
• Too many meetings and slow approval processes around change and release management
• Failed deployments and production incidents

Automation is often times a common place to start in order to reduce long lead times and increase efficiency. Automating your provisioning, testing and deployments will dramatically reduce manual effort, increase deployment frequency, decrease lead times, and produce fewer production incidents, enabling you to recapture capacity for innovation and redeploy it elsewhere – all at a lower cost.  As a result, teams spend less time on delivering applications and more time on doing innovative work that adds real value to the organization.   

The DevOps Journey

DevOps is a journey, not something you do, but rather a state you progress toward by implementing many different cultural and technical practices. Accelerating software delivery across deployment pipelines will enable the business to spend more time creating value by confidently delivering software innovation. And by fostering a high-trust culture, organizations will be able to establish a state of collaboration between the business, development and IT operations, ultimately contributing to better business outcomes.

The post Top 5 challenges when scaling DevOps in the enterprise appeared first on SD Times.