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.

This model is not new, but many companies are just now beginning the process of becoming service providers, according to a survey from Accenture. This report found that 68 percent of organizations wouldn’t be prepared to deliver their core processes-as-a-service until 2020, which ultimately means companies are just now entering the early phases of planning for XaaS.

Companies are also beginning to look into adopting XaaS models because the market is demanding it, said Patric Palm, CEO and co-founder of Hansoft and Favro. According to Palm, the market is demanding it because customers want to pay for what they use and they want to have customer value immediately. By definition, the XaaS model gives the customer that value, he said.

In order to be successful when adopting XaaS, companies need to be adaptable and agile, said Palm. This goes for all parts of the organization, down to the developers and the up to the business leaders. This is where Palm sees companies making mistakes. Enterprises need to not only change their business model to become flexible and agile, but they also need to continue to develop a product or service so that in each release, it’s delivering something valuable to the customer.

Another mistake he highlights is when companies move to an XaaS model and change to a subscription plan for their customers, marketing continues to drive monolithic campaigns. “They are paying for the service continuously so you need to build a relationship,” said Palm. “Product management might be more agile, but marketing is staying in their old tracks.” Palm said there is a difference between simply releasing a product and having a campaign, as compared to having continuous and ongoing relationships with the community.

Another challenge is sometimes, “management doesn’t get it,” said Palm.

“It’s common for big companies to not get it, they make long-term plans, they don’t think about consequences for the whole business,” said Palm. Essentially, it’s not the executives that need to become agile, it’s the whole business.

The three repeating challenges Chris Shinkle, director of innovation at SEP, has noticed stem from culture, design and development and operations. He said that a lot of companies think that XaaS is going to magically change everything, but they fail to realize they need to change the way they think and approach this model.

The companies that want to truly take advantage of XaaS models and its benefit need to change their mindsets, and this includes developers and even management, who need to change the way they think about budgeting and scheduling work. All of this impacts how teams go about developing products and shipping software, he said.

In some large companies, Shinkle notices that all their teams, their customer support, and their marketing teams are all disconnected from the rest of the business. For Software-as-a-Service products, for instance, these teams need to be much more integrated and overlap. When moving to an XaaS, taking care of the customers and providing a great experience is most important, said Shinkle.

“In a traditional model, where I might be selling large applications [and] spending hundreds of thousands of dollars on software, that’s very much different from a service model, which is more subscription based,” said Shinkle. “If I’m not delivering great service, they’re going to leave.”

Additionally, customer support plays a huge role in both sales and XaaS models. If there isn’t a great customer support system in place, and the company is not helping customers use the product and realize the value they are going to get through the product, then they aren’t going to renew their subscription when it comes time to sign up, said Shinkle.

“Culturally, you need to think about how that organization operates and [working] closer together is key,” said Shinkle. “Organizations think SaaS is just a technology change and it’s just software moving from a hard drive to the web or cloud, and they don’t think about managing projects, and what sort of metrics or KPIs are important.”

This is really where companies fall short and struggle, said Shinkle. Often times, the technical challenges of XaaS are not the most difficult parts to solve; it’s the people working to sell products to consumers that is a challenge. He recommends companies think about these cultural changes internally and recognize that if they get closer to their customers, they can learn from them and better provide a service or product.

“If [this] is overlooked, you are setting yourself up for failure,” said Shinkle.

The post Avoid these mistakes when transitioning to an XaaS model appeared first on SD Times.

According to an Atlassian blog post, DevOps is here to stay, but key trends revealed in the report demonstrate that companies still need to make the most of their culture, monitoring services and incident management if they want to get the full value of DevOps practices.

The research — conducted by Atlassian and xMatters, a technology company that integrates with Atlassian products — revealed that while almost half of respondents said that they were doing DevOps, over 65% reported that they see their DevOps initiatives actually producing good results.

This is good news, however; there are still respondents who said they either don’t know what DevOps is, or they weren’t sure if their companies were doing it (Atlassian notes that these companies were excluded from the rest of the survey questions).

For the companies that do practice DevOps, they said that they have established strong DevOps cultures where “boundaries are being removed, information is available, and tools are shared,” reads the report. Another good indication of cultural alignment comes from the 80% of respondents who reported that development and operations teams share at least some tools, which is the first step in establishing a DevOps culture, said Atlassian.

The survey also revealed that monitoring and tooling can’t solve all of company’s DevOps challenges. The report found that 50% of companies are still finding issues in production after the code is released, and that disconnect could be from misses in monitoring transactions and user experience, and it could be attributed to the fact that barely half of the companies surveyed that they practice automated testing.

From the research, Atlassian also found that many companies have not yet figured out how to manage incidents. According to the study, 50% of companies report having to wait for the operations center to declare an incident, and 43% still use manual process to keep customers and internal stakeholders up to date.

The post Report: DevOps companies need to make the most of culture, monitoring, and incident management appeared first on SD Times.

John Allspaw, CTO of Etsy, began QCon this morning with a keynote about incident response and trade-offs under pressure. He gave an overview of what steps engineers can take when faced with uncertain scenarios, and many of his examples resonated with the audience.

Allspaw talked about fields that often deal with incident responses, like military, space transportation, aviation and air traffic control. But despite the steps engineers can take to prevent problems, many are still left with scenarios that they hadn’t prepared for.

(Related: Putting test back into DevOps)

Because of this, Allspaw said in his keynote that “anomaly response does not happen the way we might imagine,” and that engineers need to look hard at how something actually happens. The data is there, he added; it’s just up to the team to learn how to capture it and understand it.

Variety of vendors
In addition to the panels, there were several software vendors showing off their latest technology and solutions.

IBM was demonstrating its Cloud Platform, Bluemix, and how to quickly build a variety of apps using it.

Jonathan Kaufman, developer advocate for IBM, led the demonstration on how to use Node-RED, which is open-source and helps developers visually build apps. He talked about how IBM Bluemix gives developers all they might need to build competitive applications. This is especially true for those using their Watson technology, he said, which allows developers to add such things as natural-language processing capabilities or predictive analytics.

“It’s great because as a developer, you don’t need to be an expert [in cognitive technology] to build a smart app,” said Kaufman.

He will speak more on Wednesday about how to make apps “smarter,” and what buzzwords like cognitive and smart apps actually mean. He will also be building an application from scratch, and discuss how to integrate Watson into an existing application.

For interested developers, they can sign up for Bluemix and try it out for 30 days. Since it’s a PaaS, developers also have access to boilerplate apps.

Sencha also has a booth where it discussed its Sencha Ext JS JavaScript framework for building feature-rich cross-platform web applications. The framework helps developers create their apps faster while still delivering a topflight user experience. Ext JS also integrates with the Sencha platform for comprehensive life-cycle management of web applications.

Developers can also use Sencha GXT, a UI framework for building data-rich HTML5 applications for both desktops and tablets using Java. This helps developers write applications in Java and compile their code into HTML5. Shikhir Singh, senior developer relations manager for Sencha, said that one of the main features of Sencha’s products is that they provide stability, which in turn gives users a better experience.

CloudBees was at the show to talk about how its Jenkins Platform—Private SaaS Edition is the best way to run Jenkins. Private SaaS Edition is a turnkey, elastic “Jenkins-as-a-Service” solution for enterprises to run on their private cloud infrastructure. With this, the CloudBees platform also leverages Docker containers internally with one click, so no other knowledge or administration of Docker containers are required.

Fear is an obstacle to learning
There was also a special track on how to optimize a company’s culture for learning.

Sonali Sridhar, the cofounder of the Recurse Center (RC), talked about how it provides something similar to a writer’s retreat but for computer programmers, which is free for everyone. People can apply with “cool” open-source projects, and spend six weeks to three months with other programmers.

Sridhar emphasized, “We are not a boot camp.” She said they fill an environment that was designed to be like a big container, and inside this container, programmers get to do whatever they want.

RC has been around for five years and works with about 200 programmers a year (with 35% of them being women and 10% being minorities). The organization also partners with 100 companies to make money, and they have distributed more than US$1 million in grant funding.

One of the main takeaways from her talk was that even in the working world, people are still afraid of looking stupid (and yes, she said even programmers have this fear). That’s why RC created an environment that is open and allows for brainstorming, and it allows programmers to feel comfortable saying “I don’t understand.”

The post QCon New York kicks off its first day appeared first on SD Times.