devopsy.kinsta.cloud

Tag: collaboration

Scaling Collaboration in DevOps

Those familiar with DevOps generally agree that it is equally as much about culture as it is about technology. There are certainly tools and practices involved in the effective implementation of DevOps, but the foundation of DevOps success is how well teams and individuals collaborate across the enterprise to get things done more rapidly, efficiently and effectively.

Most DevOps platforms and tools are designed with scalability in mind. DevOps environments often run in the cloud and tend to be volatile. It’s important for the software that supports DevOps to be able to scale in real time to address spikes and lulls in demand. The same thing is true for the human element as well, but scaling collaboration is a whole different story.

Collaboration across the enterprise is critical for DevOps success. Great code and development needs to make it over the finish line to production to benefit customers. The challenge organizations face is how to do that seamlessly and with as much speed and automation as possible without sacrificing quality or performance. How can businesses streamline code development and deployment, while maintaining visibility, governance and compliance?

Emerging Trends

First, I want to provide some background and share some data gathered by 451 Research on DevOps and DevOps adoption in general. Cloud, agile and DevOps capabilities are important for organizations today—both in perception and reality. 451 sees enterprise adoption of these things, as well as container technologies, growing—including increased usage in production environments.

There are a number of advantages to embracing these technologies and methodologies, such as increased flexibility and speed, reduction of costs, improvements in resilience and reliability, and fitness for new or emerging applications. According to 451 Research, organizations also face some barriers including a lack of familiarity and required skills internally, the immaturity of these emerging technologies, and cost and security concerns.

In the “Voice of the Enterprise: SDI Q4 2015 survey,” 451 Research found that more than half of the respondents (51.7 percent) consider themselves to be late adopters, or even the last adopters of new technology. The flip side of that is that almost half (48.3 percent) label themselves as first or early adopters.

Those general sentiments are reflected in the survey responses to other questions. When asked about implementation of containers, 50.3 percent stated it is not in their plans at all, while the remaining 49.7 percent are in some state of planning, pilot or active use of container technologies. Nearly two-thirds (65.1 percent) indicated that they use agile development methodologies for application development, but only 39.6 percent responded that they’ve embraced DevOps approaches. Nevertheless, while agile software development has been in the industry for years, 451 notes the impressive adoption of containers and DevOps, given they are emergent trends.

When asked what the top three IT pain points are, the leading responses were cost or budget, insufficient staff and legacy software issues. As organizations move to cloud, DevOps, and containers issues such as these will need to be addressed, along with how to scale both technologies and collaboration effectively.

The Current State

The industry—driven in large part by the DevOps revolution—is in the midst of a sea change, where software development is becoming more highly integrated across the entire business. The creation of software is less segregated and is more and more a function of collaboration and socialization.

Concepts and methodologies that were novel or niche just a few years ago have matured quickly to become the mainstream technologies and frameworks that are driving value today. Businesses rely on concepts such as agile, lean, virtualization, cloud, automation and microservices to streamline development and enable them to work more effectively and efficiently at the same time.

To adapt and evolve, enterprises need to accomplish a number of key tasks. The challenge companies face today is how to accelerate development while reducing costs. Organizations need to eliminate the barriers that exist between IT and the rest of the business, and work cooperatively toward a strategy that provides more effectiveness in a technology-driven, competitive environment.

Agile, cloud, DevOps and containers all play a role in that process, but the one thing that binds it all is effective collaboration. Each of these technologies and methodologies provides unique benefits, but the real value comes from the organization as a whole—and the tools and platforms used by the organization—being able to collaborate at scale. Successful DevOps implementations also require participation from other stakeholders beyond development and IT operations teams, including security, database, storage and line-of-business teams.

Collaboration-as-a-Platform

There are services and platforms online—such as GitHub—that facilitate and streamline collaboration. The online platform functions as a code repository, but the value extends beyond just providing a place to store code.

Such a collaboration platform helps developers and teams collaborate more effectively because it provides a community where the code and process can be shared and discussed. Managers can monitor progress and track what code is shipping next. Developers can experiment with new ideas in a safe environment before taking those experiments to a live production environment, and new ideas and experiments can be effectively communicated to the appropriate teams.

One of the keys to more agile development and DevOps is to allow developers to test things and gather relevant feedback quickly. The goal is to produce quality code and features faster, not to waste time setting up and managing infrastructure or scheduling more meetings to talk about it. The GitHub platform, for example, enables more effective and scalable collaboration because code review can occur when it is most convenient for the participants. There is no need to try and coordinate and schedule code review meetings, so the developers can continue to work uninterrupted, resulting in greater productivity and job satisfaction.

Steven Anderson of Sendachi noted that GitHub is a collaboration platform, but it’s also a place for your tools to work with you, too. This means it can help not only with collaboration and continuous integration, but also with code quality.

One of the benefits of a collaboration platform is that large teams of developers can be broken down into smaller teams that can focus more efficiently on specific components. It also allows things such as document sharing alongside code development to blur the lines between technical and non-technical contributions and enable increased collaboration and visibility.

Collaboration is Key

The importance of collaboration can’t be stressed enough. It is a key tenet of DevOps culture, and it’s vital to agile development and maintaining a competitive edge in today’s world. Executive or management support and internal evangelism are important. Organizations also need to embrace the culture shift—blending skills across functional areas toward a common goal.

With that culture established, though, effective collaboration is crucial. A collaboration platform is an essential element of collaborating at scale because it streamlines productivity and reduces redundancy and effort, and yields higher quality results at the same time.

May 16, 2016
7 Causes of Continuous Delirium

When we think of CD, we typically think of continuous deployment as a result of continuous delivery, which is a goal of DevOps.

In this article, I coin the phrase, “Continuous Delirium,” to mean unending confusion or bewilderment in development environments. There are probably several examples that could fit the bill here, but for now I offer seven real-world examples. I bet you’ve seen or heard about at least one of these.

Now that I have your attention, here are seven causes of Continuous Delirium, each with cures rooted in DevOps:

No. 1: Insufficient Configuration and Build Management

Insufficient configuration and build management in software builds leads to the same or similar software impurities rearing their ugly heads again and again. You build, test, discover the defect, fix it—or so you think—build again, retest and boom: The same coding error or software malfunction recurs.

“You can cure this malady with a rational approach to the build and configuration management process, checking software in and out with established procedures for each software module using a tracking sheet that identifies the revision of the sub-modules for the entire software product,” notes Jon M. Quigley, founder of Value Transformation, a product development consultancy and training firm based in Lexington, North Carolina.

No. 2: What’s Going On? Who’s Doing What?

When there is no reasonable understanding of the work, who is doing what work and who is responsible for what—and there is no consistent measure of what is good work or bad work—you have a breeding ground for anarchy.

“You cure this ill by establishing what constitutes the appropriate quality of work as well as by periodically reviewing the state of the objective with the receiving or depending entity,” says Quigley. Make sure everyone is on the same page with the same definition of what constitutes quality work and make sure the objectives have not changed. Also, ensure these goals are also clearly understood by all.

No. 3: Confusing Clean Daily Compiles with Testing

When you do not test the software as early as possible and throughout the development process, you can’t really say it has no bugs. Error-free compiling is not error-free software. Software compilation does not have the same investigative effect as using the software in the customer environment.

“Test throughout development using complimentary testing approaches such as testing to requirements, combinations of stimulus testing and exploratory testing, for examples,” says Quigley.

No. 4: Planning Too Far Out to Control

The further you try to plan things out into the future, the less control you have as you follow the project through to conclusion. “When we treat a plan as though we know everything associated with the project for the next 12 to 18 months, we are fooling ourselves,” says Quigley. By breaking projects into bite-sized increments, you can better assure successful completion of sub-projects and of the project as a whole.

No. 5: A Lack of Customer Involvement

Customer involvement is critical to customer satisfaction. “By getting the product or a prototype into the customers’ hands for exploration, you can retrieve feedback for developers,” says Quigley. This may expose the project to risk in the form of the potential for a great deal of change at the customers’ request, but the other side of the coin is the risk that nothing changes and the customer doesn’t use the product at all.

“Rather than try to deliver one incarnation of the product at some future date, break down the delivery into separate iterations that meet prioritized customer expectations one by one as you refine the product and add features as you go along,” says Quigley.

No. 6: Isolating Change Management from Customer Involvement

Customer involvement means there will be change. Change requires change management. There is a given—and correct—assumption that customer involvement will trigger change management at some point. You cannot isolate the one from the other.

Further, just as you can better address customer requests for changes by breaking the project into smaller subsections, so also can you manage budget through change and change management. Project subsections enable you to see the need for change a little at a time so you can create change in a more targeted and cost-effective manner.

No. 7: Forget About Collaboration—at Your Own Peril

It is necessary for DevOps team members to collaborate at all levels, except those where the work on software is so minor that it wouldn’t benefit from shared thought. To maintain development as an expedient process that benefits from all stakeholders, open communications and collaboration must reach and pull from all team members. Otherwise, the project could suffer from a lack of critical input.

April 29, 2016
Cohesion Critical in a Successful DevOps Team

In the push to adopt DevOps among enterprise IT organizations, cohesion has been one of the biggest challenges in collaborating effectively. Historically, departments within a business existed in disparate locations, or silos. Marketing, IT and operations all had their own teams and their own communication channels, which made it difficult for members of separate teams to work successfully with one another despite the fact that they were working toward a common goal.

However, with the continuing adoption of DevOps, IT admins are finding that projects are easier and more well-executed when all the parts of the development cycle—creation, coding, testing and deployment—are working in tandem. Therefore, it’s becoming ever more critical that agile product teams are on the same page when it comes to their DevOps projects.

Cohesion Matters

Why is it so important to have a development team that coheres as one entity and communicates effectively among all its members? Let’s take a look:

Quicker feedback cycles

When team members are working as one unit instead of disparate entities, testing and development cycles don’t have to be long, drawn-out affairs. One of the biggest benefits of DevOps itself is the ability to shorten time to market and deploy code more quickly, with fewer errors—so enabling teams to communicate can only enhance that benefit.

According to devopsy.kinsta.cloud contributor John Balena, facilitated collaboration allows teams to achieve continuous testing goals and streamline processes. This can lead to a continuous delivery cycle, which is the goal of DevOps in the first place.

“DevOps can best be realized when IT operates in a social, collaborative environment that ensures all groups are working with a visual model in their context with the necessary information from downstream and upstream teams, as well as in collaborating with relevant experts at the moment when clarifications are needed or issues arise,” Balena wrote.

Shared responsibility

With a collaborative DevOps culture, no one person or group of people is responsible for the entire project. It is a team effort that doesn’t rest on anyone’s shoulders unnecessarily. This makes the project more of a shared endeavor, which everyone is invested in and cares about. With silos, when something goes wrong, members of different teams may try to lay blame on one another, which lowers morale and may defeat the entire purpose of DevOps. But when teams are communicating effectively, they can share blame—but they also share success.

This mindset enhances the teamwork aspect of software development and can help get rid of the culture of fear, according to devopsy.kinsta.cloud contributor Claire Agutter. When teams work together within a blameless culture, they can more quickly see and learn from their mistakes.

Common goal

Throughout all of the steps of the software development life cycle, another important advantage of teams working together is that they share a common vision of how the company should progress. Business needs and customer satisfaction are both critical factors in the DevOps cycle, and team members should all be on the same page when it comes to these goals.

In all, it’s critical for IT managers to support a culture of collaboration and communication if their DevOps endeavors are going to succeed. You need the right tools for the job, but you also need to have the right attitude.

“Culture is like quality,” DZone contributor Jim Bird wrote. “You don’t build culture, or quality by talking about it. You build it by doing things, by acting, by making things happen and making things change, and reinforcing these actions patiently and continually over time.”

A collaborative DevOps culture can improve project success.

About the Author/Sanjay Zalavadia

As the VP of Client Service for Zephyr, Sanjay brings more than 15 years of leadership experience in IT and Technical Support Services. Throughout his career, Sanjay has successfully established and grown premier IT and Support Services teams across multiple geographies for both large and small companies. Most recently, he was Associate Vice President at Patni Computers (NYSE: PTI) responsible for the Telecoms IT Managed Services Practice where he established IT Operations teams supporting Virgin Mobile, ESPN Mobile, Disney Mobile and Carphone Warehouse. Prior to this Sanjay was responsible for Global Technical Support at Bay Networks, a leading routing and switching vendor, which was acquired by Nortel. Sanjay has also held management positions in Support Service organizations at start-up Silicon Valley Networks, a vendor of Test Management software, and SynOptics.

Connect with Sanjay:

Facebook: https://www.facebook.com/getzephyr?_rdr=p

LinkedIn: https://www.linkedin.com/in/sanjayzalavadia

Twitter: https://twitter.com/yourzephyr

Google+: https://plus.google.com/+Getzephyr/about

April 20, 2016
State of DevOps Survey – The Ultimate Feedback Loop

If there’s any consistent criticism of the larger DevOps movement, it’s that the talking heads and industry gadflies are driving the conversation, not the people in the trenches.

All the thought leadership panels and “how-to” content (including the written and AV materials on this very site) make for great watercooler discussion, but lack the input of those dev, ops and IT management pros who are actually living the DevOps experience, some critics have said.

Well, fair enough. Talking heads are paid to talk. Thought leaders are chosen to lead the debate at conferences and on webcasts. Bloggers blog. Reporters report. This is simply the way of the world. Certain voices are heard via the channels they frequent. It is, as so many people are fond of saying these days, what it is.

So what about everyone else? What of the people reading this stunning prose and listening to these talks while rolling their eyes based on the connectivity of it all to their real-world experience? How can their voices be heard?

Independent of jumping into the blogsphere or applying to speak at said industry events – which you should, btw – there’s one significant opportunity available to anyone who cares to take the time – participating in industry research.

Over the next few business days, citizens of the DevOps world will have their last chance to contribute to the industry’s most widely read and respected research project, the State of DevOps Report.

If you haven’t done so already, take the time to fill out this year’s survey, and make sure that your voice is heard when the subsequent report is published in June. Sure, it takes a little time, about 15-20 minutes; but that’s because it goes to the trouble of exploring the real-world issues that weigh most heavily on today’s practitioners.

Why is this particular project so important, or even credible? Consider that the minds behind the survey and analysis resulting in the 2016 State of DevOps Report are those authors and talking heads that actually get the most respect.

Backed by DevOps Research and Assessments (DORA), the independent think tank operated by a partnership of Jez Humble, Gene Kim, and Nicole Forsgren – perhaps the most respected voices on the landscape, along with Nigel Kersten, the project is categorically aimed at surfacing the truth about DevOps adoption today – not merely promoting the interests of vendor sponsors.

Like previous iterations of the report, the 2016 edition will focus on topics including IT performance, technical practices, culture, lean management, and organizational performance. This year’s survey also examines several new areas, including the ROI of IT performance, security and compliance, and containers.

To further entice participation, project leaders are also offering free tickets to the DevOps Enterprise Summit, along with forthcoming books from some of the industry’s leading advocates to a lucky few who take the time to get involved.

DevOps success is fundamentally based on the notion of increased collaboration and continuous feedback among the people scattered across the SDLC. Likewise, the legitimacy of this research project is utterly dependent on the input of as many real-world practitioners as possible.

If you’re one of those individuals, and you really care whether or not everyone else involved in the advancement of DevOps understands what this all means to you, do yourself a favor and participate.

Much like an application being built using DevOps practices, this quality of this project will be directly determined by the degree to which anyone with insight is willing to get involved and build toward optimal results.

Take the 2016 State of DevOps Survey… today!

April 15, 2016
Culture Change: Metrics, Tools Make a Difference
Change is in the wind.

This time of the year, as winter weather gives way to springtime renewal, this concept isn’t a cliché but rather a concrete, visceral experience. You go outside, smell the earth defrosting and know for certain that change is happening all around you. You can feel it.

Such is the case on the current DevOps landscape. Seemingly every conversation, with everyone from end users to industry analysts, reaffirms that people are making significant progress toward greater adoption. For an increasing number of organizations, DevOps is maturing from a set of budding goals into a tangible reality.

At the center of this massive shift within the software factory is the issue of cultural change; as we know in all things DevOps, culture trumps all else. So how are organizations affecting, empowering and measuring all this seismic transition, in particular the human elements?

During the recent DevOps Virtual Summit, leading practitioners representing industries ranging from banking to travel and technology shared their views on the progress of cultural reinvention.

From management tips, to tools and even metrics useful for driving transformation, here are some of their observations:
1. What’s the most critical cultural aspect of planning?
  Kazi Whitfield, director, Quality Engineering, MUFG Union Bank, N.A.: Scalability on this is the key; if you’re doing this at a new organization, you need to understand how to scale it, and starting at some smaller level helps you get there. It also helps each individual and those components that are changing to truly understand what’s changing, and why it’s changing; I think that’s a huge part of the conversation that has to happen.
1. What’s the biggest obstacle to cultural change?
  Eric Warheit, senior manager, Environment Management, Southwest Airlines: The challenges that we’re working through are organizational in nature. It goes back to the question of localization, and people maintaining a mindset that they’ve previously had, and what we do to create the conversation around what’s possible and the key impacts that we want to have. Ultimately, it’s about being productive with quality, and creating those common values.
1. How can tools enable cultural change?
  Eugene “Bear” Lehenbauer, group manager, Information Technology, Citrix: If I have to pick one that links them all, a ring to rule them all, that’s when you have an orchestration platform that can take what individual teams are already using and plug right in, or you can take what needs to be automated and automate it; that orchestration harness can now become that common thing that links them.
1. How can you ensure cross-culture collaboration?
  Warheit: Creating that concrete example, that proof case tying analytics to it, so that we have real measurable ways to make good business decisions, and being able to foster that perspective so that we can look across the organization, as opposed to in a localized way, is really critical to be able to foment that collaboration that’s needed.
1. How do you measure cultural change?
  Daniele Romano, product owner, Continuous Delivery Pipeline, ING Bank: The most important thing as an organization is to able to apply an analytical approach, meaning that for each team or department you should look at the current situation and have in mind the target situation, and then have different means to guide everyone toward that target.
1. What’s a key cultural change metric?
  Lehenbauer: We’ve a developed an agility rating scale that allows people to earn scores for something as basic as change management. Based on how those key metrics behave, and there are several of them, but they are fact-based and they’re user impact driven for the most part, they reward the right behaviors. Those types of things can draw out some of DevOps principles results, but also have hard data behind them.
1. How do you recognize advocates of cultural change?
  Whitfield: Being able to phase reward and recognition into the process is key. Organizations are doing a lot of great things and making millions of dollars, and as the individuals that are coding or testing are driving it, you have to understand how you get to those people’s hearts, to make them passionate about what they’re doing. That’s something that becomes key and it’s something that’s different per organization.
1. What’s the best way to gauge successful cultural transformation?
  Romano: There is a really only one critical human metric, which is happiness. So, if engineers are happy and they can deliver fast, at a high quality and with intense focus—that’s a very unique but important metric.
So there you have it, some of today’s most critical elements in driving the cultural transformation necessary to succeed in the DevOps world.

If you missed the DevOps Virtual Summit you can still view recordings of all the sessions including this customer panel, and stay tuned to this space for more excerpts and highlights.
March 30, 2016
Putting People Before Software

Software development teams typically are focused on a single goal: delivering new, killer features that users love. Driving revenue and usage is core to Agile and DevOps. Yet without motivated, productive people, you can forget about building good software.

Heightened competition requires companies to go the extra mile to develop and retain employees. Here are several ideas for team-building and personal development, while still pushing an awesome product out the door quickly.

Focus on high performers first

Struggling employees often receive the most attention and oversight from managers, but it’s really the top performers who should get the majority of the attention and development opportunities. While modern learning and development methods can be less costly than traditional conferences and seminars, the same philosophy rules: spend the most time and investment on those individuals with the highest potential. Don’t underestimate green developers who are eager to grow; they may not have shown their colors yet, but you can typically see early on if they will with a little push.

Ditch the annual performance review

Over the last few years, companies of all sizes are starting to move away from traditional generic performance review metrics and processes. The annual review is nearly obsolete, given the pace of change in business and the fact that employees change companies so frequently. Goals set forth a year earlier may no longer be relevant after six months. Performance review planning is also too time-consuming for busy managers these days.

Instead, consider a more organic process where the employee and manager visit quarterly, developing mutual agreements and goals for the coming months. The customized approach is more meaningful and real-time for everyone. A useful reference on modern employee retention tactics is “The Alliance,” co-authored by Reid Hoffman, a founder of LinkedIn. The book’s premise: Stop thinking of employees as family or free agents and start thinking of them as allies on a tour of duty. The “tour of duty” theme is highly relevant in software development, where tactics and objectives are constantly changing and the pressure can be intense. As long as the employer and employee are constantly seeking to get the most mutual value out of the relationship, employee retention should not be an issue.

Offer diverse experiences

Younger employees, including those of the Millennial generation, typically enjoy working in a flat organization where they can take ownership of projects and feel they’re advancing within the organization. Take advantage of that independent ambition by creating smaller teams and giving leadership roles to those who are ready. Younger employees also covet change, so rotational roles can be an excellent way to give them that diversity in experience while also monitoring their progress for long-term career growth. Mid-level employees often feel the highest level of stagnation due to the typically long process of promotion into senior management, so it’s critical to have a strategy for developing and retaining those positions as well.

Motivate and grow senior developers

Organizations often go to great lengths to bring in promising young talent and grow them into senior developers. However, the path beyond for a senior developer often provides a fork in the road, with options to either focus deeper on the technical side as an architect or on the people side as a manager. Executives should support senior developers early in this transition and identify key candidates for each role, and then help them to prepare accordingly.

Make collaboration fun

Developers today should be groomed and evaluated for their collaboration skills. There’s no right way to do this, but a good start is by making collaboration easy and even fun for those highly independent people who haven’t had to communicate much with coworkers in the past. Offer simple chat and social media tools for real-time, online collaboration or feedback tools such as TINYpulse, which can mask someone’s identity if they are too shy to share feedback otherwise. Requiring team members to demo their work in progress for colleagues can encourage collaboration and sharin, and boost product quality through timely feedback. Offer perks or bonuses for those team members who show initiative in teamwork and cross-team collaboration. Needless to say, FACs (happy hours) and other offsite opportunities for the team to unwind together also can break down barriers.

Make innovation a cultural trait

Measuring innovation isn’t straightforward, but making room for it within your organization is a powerful way to both motivate and retain employees and, ultimately, generate business value. Google grabbed headlines a few years ago when it shared its policy of giving technical employees 20 percent of their hours every month to work on independent research projects. Granting employees free time to work on new ideas is smart, but works best if developers are passionate for the business and will reinvest that time in areas that add business value.

More importantly, recognize that innovation is not a program but a cultural value that can only be communicated from the top. Senior-level support for innovation, along with free sharing of ideas, should be baked into team processes and communications. Finally, time is a finite asset. If you’re going to give your team some time off for creative brainstorming, don’t penalize them for lower output or require them to work weekends to make up for it.

Push the soft skills

This is a no-brainer. Modern development teams increasingly are linked hand in hand with business goals and customer outcomes. Therefore, developers must be able to work effectively with business counterparts and understand the language of the business. Give your developers frequent opportunities to present in front of their co-workers for practice, and whenever possible, the chance to work directly with business units on projects.

Look to the community

The days of structured career paths and employee development programs are largely over. Employees want and benefit most by self-learning and exploration with their external communities. This entails giving people leeway to attend meetups, participate in developer contests or attend half-day workshops where developers can interact with others in their field. MOOCs, online degrees and certifications are gaining favor as flexible ways to quickly gain new skills. These informal learning opportunities are much more cost-effective than formal training programs of the past and more relevant. They help employees gain general marketplace knowledge on new development trends and tools, rather than company-specific knowledge and processes.

Investing in technical skills is imperative, yet developers also to want to feel part of a team and work with someone looking out for their career potential. By paying more attention to developers’ personal goals and the needs of the team, software development organizations gain more stability to do what they do best: develop great products.

About the Author/Kevin Dunne

Kevin Dunne is VP of Strategy & Business Development at QASymphony.

March 2, 2016
Can We Stop Talking About DevOps?

I first heard the term “DevOps” from a friend in the software business when I was working at Dell HQ in Round Rock, Texas. He recommended I read “The Phoenix Project,” by Gene Kim, Kevin Behr and George Spafford. I did read it and I found it a fascinating story, but as a longtime network administrator (to oversimplify as much as possible) and having never been involved in developing software, I wasn’t quite sure how it applied to me.

It was enough to pique my interest, though, and drove me to volunteer at a DevOpsDays event in Austin. Within weeks I left Dell and joined a small software company, where I could have a better chance of getting my arms around this slippery pig called DevOps and more hands-on practice with the related tools and techniques.

So imagine my surprise when a year later, the same old friend who introduced me to DevOps suggested that the end goal of a DevOps transformation should be that we stop talking about DevOps. Uh-oh, I thought, he’s lost the plot. But he made his case by pointing out that adding testers to dev teams—a typical step in any Agile transformation—doesn’t result in new dev test or agile dev teams; they remain simply “dev teams.” Once a business/group has fully internalized the Agile or DevOps values and behaviors, he argued, “working in an Agile or DevOps way” becomes simply “working.”

This is why many DevOps promoters, myself included, have a negative reaction to seeing “DevOps” in job titles, job descriptions or department names. While it simplifies the job of identifying which job candidates have a DevOps mindset or skill set, it effectively excuses everyone else in the organization from taking responsibility for change. “Doing DevOps” becomes the job of a particular individual, team or department, instead of a philosophy internalized by the organization.

Of course, the horse is already out of the barn on that one. Each year we see an increase in the number of businesses advertising for DevOps engineers, forming DevOps departments or listing DevOps among the required skills for a position. It doesn’t matter whether we think this is a good thing or bad thing; evolution will take its course and there’s little we can do to stop it. What we can do is observe, acknowledge and adapt.

Sure, the dangers are real. A DevOps department can easily become just a third silo or the DevOps engineer might become the scapegoat for everything that goes wrong between development and operations. But if a DevOps engineer, VP of DevOps or DevOps department can form, contribute to and/or nurture an environment of increased empathy, faster feedback and continual growth, that’s awesome; put the focus there. Don’t spin your wheels arguing that they just “don’t get it” or “they’re doing it wrong.”

I’ve spent the past couple years researching, promoting and attempting to practice this thing we call DevOps. While it’s widely believed that DevOps is impossible to define, I am firmly in the camp of those who believe that empathy is, to quote Jeff Sussna, “the essence of DevOps.” Just as the sales team needs to have empathy for its customers, everyone in the value chain needs to have empathy for each other. I’m aware that many people find this term too “touchy-feely,” but the business benefit of more harmonious interaction between one’s teams and between the organization and its customers is clear: The faster and more effective one is at converting solutions into real value for customers, the more successful one will be in the market. Thus, being empathetic isn’t just being a good citizen, it’s also being a good businessperson.

Taking it a step further, someone on Twitter recently suggested that “DevOps has nothing to do with technology.” The statement seemed ridiculous on its face. After all, the term “DevOps”—literally a portmanteau formed from the words “developers” and “operations”—was coined by Patrick Dubois, a technologist intent on improving the process of building and deploying software. But as I thought about it I started to understand. As the DevOps movement has evolved, the most fundamental components its promoters have identified, from Gene Kim’s “Three Ways” (systems thinking, amplify feedback loops, culture of continual experimentation and learning), to John Willis and Damon Edwards’ CAMS (culture, automation, measurement, sharing), to Dave Zweiback’s ICE (inclusivity, complex systems, empathy), are primarily about how people work. It doesn’t matter if one is building software or running a school—DevOps principles are sound.

I recently tweeted the observation that “anyone who attempts to define DevOps in a paragraph is trying to sell you something,” adding, “not necessarily a bad thing, just buyer beware.” This wasn’t a criticism of tool providers—many tools, from build automation to log monitoring, are essential to an effective DevOps transformation. It was a reminder that the problems and solutions DevOps is concerned with are complex and nuanced. There is no prescribed tool set or checklist of actions one can take to be successful; an effective DevOps transformation requires thoughtful, committed action across the whole range of people, practices and products one uses in their work.

It might take months or years of practice, but maybe one day we can all stop talking about DevOps.

January 13, 2016
Big Room Planning: Getting Everyone on the Same Page

Many organizations—or even teams within organizations—are attempting to embrace DevOps. The operational and strategic advantages of DevOps over traditional business methodologies make it a virtual business imperative. One of the prevailing ideas about DevOps is that it’s about a culture shift more than tools and principles—and a big part of that culture shift is making sure everyone is on the same page.

Rally Software—which was acquired by CA in May of 2015—provides software and services to help customers succeed with Agile development. One of the main components of the services side is to educate customers about the importance of working in harmony and guiding customers through a process called Big Room Planning. DevOps is a natural extension of Agile development principles to the rest of the business, so Big Room Planning can be an effective tool for DevOps just as it is for Agile development planning.

I spoke with Steve Wolfe, director of Product Marketing for Rally, who explained the goal of Big Room Planning is to teach customers how to be more collaborative and help them get to a position where they’re able to respond faster to customer demand or market pressure. The idea is to foster an environment of collaborative planning that brings in the whole organization.

“At Rally we’ve learned that delivering the most value from your software usually requires multiple, coordinated development teams—often distributed—working together and with the business,” Wolfe noted in a blog post. “Building software at this level is complicated, with a lot of moving parts, dependencies and competing priorities.”

Many organizations—particularly organizations that already are familiar with Agile development—understand the value of consistent feedback and frequent iterations. Collaboration is a keystone of Agile. However, when you take that to a broader scale with DevOps, it becomes critical that all parties impacting—or affected by—the project be represented in the collaborative effort.

Wolfe noted even in companies that use Agile development effectively, problems arise when teams work in isolation. Teams create plans that they agree on in their group, but aren’t realistic or don’t align with broader business goals. Meanwhile, other teams or departments don’t feel committed to plans they had no part in creating. The result is more like the traditional business model than DevOps: You end up with a situation in which any one team can halt progress and create a bottleneck.

The Big Room Planning approach is intended to address that problem. The entire organization must be engaged, with full support from all of the affected roles and departments in the planning process. As the name implies, you need to get everyone together in a big room (or virtually via web conferencing, if necessary) and collaborate on a grander scale to make sure everyone agrees with and is committed to the plan.

Wolfe also stressed that leadership support is essential. He recommends finding someone to champion the concept—an executive to lead the Big Room Planning effort. In and of itself, this idea doesn’t seem all that revolutionary; common sense dictates that development will flow more smoothly and business will function more effectively when everyone is on the same page and working toward the same goals. The crucial part is to not take it for granted and to use a strategy such as Big Room Planning to ensure more effective cooperation and collaboration.

January 5, 2016
Carving through the hype – take the DevOps maturity assessment

As anyone who spends time with their family over the holidays can attest, the notion of maturity is a highly subjective concept.

Whether it’s sizing up the next generation’s advancement or defaulting to time-honored inter-sibling behaviors, annual get-togethers offer tangible proof of what’s new and those things that likely won’t ever change.

In the domain of DevOps – an umbrella concept that encompasses a massive array of processes and supporting capabilities – gauging the maturity of your organization’s standing is also a highly interpretive task.

Given that “DevOps” means something different to nearly every organization, based on its unique makeup, methodologies, tools, and most importantly, business goals, attempting to measure progress against any outside model may seem an effort of limited value.

That said, as an increasing number of organizations seek to embrace DevOps, and growing recognition that well-worn stories of leading-edge “unicorns” don’t relate closely to most people’s real-world expectations, many teams are left wondering where their own efforts stand, especially in comparison to their peers.

To help acquit this pursuit, and allow organizations to scope their progress, CA recently launched the second iteration of its online DevOps Assessment.

Split into three short surveys covering core limbs of the DevOps tree – “Develop and Test”, “Release and Deploy”, and “Manage and Monitor” – this free tool offers detailed insight into how your organization’s maturity stacks up to that of other practitioners.

For instance, in the domain of development, how well do your teams fare in defining and managing requirements, and then presenting them to others in a structured manner? Related to release cycles, are your teams truly meeting business-driven expectations for more frequent application deployments, shorter lead times, and higher success rates? Or, when it comes to applications monitoring, are you able to distinguish the most critical and recurrent problems and how they truly impact business services?

These are perhaps some of the most fundamental questions that one could apply to measurement of DevOps adoption in general, but further investigation attempts to take a closer look at more finite, underlying issues.

Are your development teams accurately replicating realistic conditions from production systems to create virtual services and testing scenarios? Are your application release deployments fully automated across development, test and production environments? Can your teams monitor complete business services that link user experience, transactions and applications to infrastructure to pinpoint any root cause issues?

The best thing about the survey is that it immediately provides visibility into how your answers compare to those of previous respondents. There’s no fuzzy math or editorial interpretation (though we may highlight trends in a report at some point), merely instant validation, and the option to create a customized report card charting where your efforts stand in relation to those of your peers.

If you’re wondering precisely just how to achieve your long-term DevOps goals comparative to where you stand today, it might even be worth leveraging some of the involved questions for the purpose of evolving process and methodology.

The only remaining questions are: Do you think that you’re ahead of the curve? Are you afraid to find out just how far you’re behind the crowd? And most importantly, what do you have to lose?

Take the survey today and get a real-world fix on your overall level of DevOps maturity. Guaranteed it’s a far more informative activity than debating family and friends over whose turn it is to carve the turkey, or wash the dishes.

December 3, 2015
Can We Stop Talking About DevOps?

I first heard the term DevOps from a friend in the software business when I was working at Dell HQ in Round Rock, TX. He recommended that I read The Phoenix Project, by Gene Kim, Kevin Behr and George Spafford. I did read it and I found it a fascinating story, but as a long-time network administrator (to oversimplify as much as possible) and having never been involved in developing software, I wasn’t quite sure how it applied to me. It was enough to pique my interest though and drove me to volunteer at a DevOpsDays event in Austin. Within weeks I left Dell and joined a small software company, where I could have a better chance of getting my arms around this slippery pig called DevOps and more hands-on practice with the related tools and techniques.

So imagine my surprise when a year later, the same old friend who introduced me to DevOps suggested that the end-goal of a DevOps transformation should be that we stop talking about DevOps. Uh-oh, I thought, he’s lost the plot. But he made his case by pointing out that adding testers to dev teams–a typical step in any Agile transformation–doesn’t result in new devtest or agiledev teams, they remain simply “dev teams”. Once a business/group has fully internalized the Agile or DevOps values and behaviors, he argued, ‘working in an Agile or DevOps way’ becomes simply ‘working’. This is why many DevOps promoters, myself included, have a negative reaction to seeing ‘DevOps’ in job titles, job descriptions, or department names. While it simplifies the job of identifying which job candidates have a DevOps mindset or skillset, it effectively excuses everyone else in the organization from taking responsibility for change. “Doing DevOps” becomes the job of a particular individual, team or department instead of a philosophy internalized by the organization.

Of course the horse is already out of the barn on that one. Each year we see an increase in the number of businesses advertising for DevOps Engineers, forming DevOps departments or listing DevOps among the required skills for a position. It doesn’t matter whether we think this is a good thing or bad thing, evolution will take its course and there’s little we can do to stop it. What we can do is observe, acknowledge and adapt. Sure, the dangers are real. A DevOps department can easily become just a third silo or the DevOps Engineer might become the scapegoat for everything that goes wrong between development and operations. But if a DevOps Engineer, VP of DevOps or DevOps department can form, contribute to and/or nurture an environment of increased empathy, faster feedback and continual growth, that’s awesome; put the focus there. Don’t spin your wheels arguing that they just “don’t get it” or “they’re doing it wrong”.

I’ve spent the past couple years researching, promoting and attempting to practice this thing we call DevOps. While it’s widely believed that DevOps is impossible to define, I am firmly in the camp of those who believe that empathy is, to quote Jeff Sussna, “the essence of DevOps”. Just as the sales team needs to have empathy for its customers, everyone in the value chain needs to have empathy for each other. I’m aware that many people find this term too “touchy-feely”, but the business benefit of more harmonious interaction between one’s teams and between the organization and its customers is clear. The faster and more effective one is at converting solutions into real value for customers, the more successful one will be in the market. Thus being empathetic isn’t just being a good citizen, it’s being a good businessperson.

Taking it a step further, someone on Twitter recently suggested that “DevOps has nothing to do with technology”. The statement seemed ridiculous on its face. After all, the term ‘DevOps’– literally a portmanteau formed from the words ‘developers’ and ‘operations’–was coined by Patrick Dubois, a technologist intent on improving the process of building and deploying software. But as I thought about it I started to understand. As the DevOps movement has evolved, the most fundamental components its promoters have identified, from Gene Kim’s “Three Ways” (Systems Thinking, Amplify Feedback Loops, Culture of Continual Experimentation and Learning), to John Willis and Damon Edwards’ CAMS (Culture, Automation, Measurement, Sharing), to Dave Zweiback’s ICE (Inclusivity, Complex Systems, Empathy), are primarily about how people work. It doesn’t matter if one is building software or running a school, DevOps principles are sound.

I recently tweeted the observation that “anyone who attempts to define DevOps in a paragraph is trying to sell you something”, adding “not necessarily a bad thing, just buyer beware”. This wasn’t a criticism of tool providers; many tools, from build automation to log monitoring, are essential to an effective DevOps transformation. It was a reminder that the problems and solutions DevOps is concerned with are complex and nuanced. There is no prescribed toolset or checklist of actions one can take to be successful; an effective DevOps transformation requires thoughtful, committed action across the whole range of people, practices and products one uses in their work. It might take months or years of practice, but maybe one day we can all stop talking about DevOps.

November 5, 2015