devopsy.kinsta.cloud

Tag: devops culture

The DevOps Culture Cocktail

As I have written in previous posts, I believe that IT has accumulated decades of cultural debt that is now due. We are a young industry that grew up in silo neighborhoods, each with it’s proprietary practices, language and population of like-skilled specialists. Left unchecked, the resulting “framework culture” contributed to IT’s cultural debt and is partially the motivation behind DevOps.

The goal of DevOps is not to undervalue or replace the frameworks that are in place. On it’s own, DevOps is not a framework – in fact, successful DevOps relies on combined effect of best practices such as Agile, Lean and ITSM. By recognizing and adapting the best of each, IT can formulate a potent recipe for enhancing performance and increasing customer satisfaction.

So let’s belly up to the bar and mix ourselves a DevOps Culture Cocktail by taking the best guidance from the top shelf of each of the frameworks and practices.

Ingredient 1: ‘Git R Done’ Scrum

Scrum is the most prominent of the Agile frameworks and with good reason: it focuses on getting work “done” in manageable increments while reducing work in progress.

Pair it with a Kanban Board

While deceptively simple, Kanban is a powerful method for visualizing workflow, identifying constraints and keeping a team focused.

Ingredient 2: Automation

There is a lot of debate around the balance of automation use in DevOps, but there is no dispute that automation and metrics play a key role in successful DevOps.

Ingredient 3: IT Service Management

ITSM is the deployment’s “ever after”. Agile and repeatable service management processes lead the way to stable continuous delivery and increased flow.

Ingredient 4: Lean

Let’s make it a skinny by creating more value for customers with fewer resources and less waste.

Ingredient 5: People

The most important ingredient. DevOps relies on the way people think, behave, interact and trust their colleagues. According to Lloyd Taylor, “You can’t directly change culture. But you can change behavior, and behavior becomes culture.”

Finally, add a splash of common vocabulary and a shot of the alcohol of your choice and you now have a DevOps Culture Cocktail! Serve it daily, share it with your neighbors or sip it while reading a good book like The Phoenix Project. It does get more potent with age.

I recently had the opportunity to present the DevOps Culture Cocktail Party at Fruition Partner’s FruDevCon Conference. One of the attendees, a hobby mixologist, formulated her vision for a signature DevOps Culture Cocktail during my presentation. We asked the hotel bartender to mix it up, passed it around and a new cocktail was born. Here goes:

The DevOps Culture Cocktail
1 part pear vodka
1 part St. Germain
1 part Chardonnay
2 parts simple syrup or 7 up

Top with a spear of pineapple and a cherry.

Improvement recommendations are of course welcome. Could this become a staple at all future DevOps events?

October 9, 2014
The Divisiveness Of The Term “DevOps Culture”

If the term DevOps has caught your ear of late and its caused you to start researching what it is and how it can benefit you, you’ve probably come across a number of dissenting pieces on the term “DevOps culture.” A recent tweet by Lori Macvittie of F5 (@lmacvittie) reiterated my thinking, “wow, this issue has some strong opinions surround it it!”

I’d be remiss if I didn’t mention that I have on numerous occasions stated my own issues with the notion of culture being an instrumental component of DevOps adoption. Having been an executive in a few startup tech companies in my past, I remember, and still smart from, the various executive team discussions about company culture. We spent hours–wasted hours???–discussing what kind of company we will be and how to build a culture that would turn us into a market leader only to have all that work undone by underhanded backstabbing and small company politics within the executive team itself.

Hence, I’m skeptical about the ability to truly foster culture anywhere. Culture is something that takes holds as a factor of the individuals involved and how they treat each other, which is a direct result of many other corporate led initiatives, such as opportunity to be recognized for their work, stability, compensation, etc. So, if it’s that difficult to foster a culture in a small startup, what is likelihood of fostering culture in a large enterprise, where so many in IT struggle everyday with great frustrations and an inability to progress through backlogs and fragility?

There’s a great Twitter discussion that includes Damon Edwards, CEO of DTO Solutions (@damonedwards), John Willis (@botchagalupe), Matt Stratton (@mattstratton) and myself on the topic in which Damon discusses how he and John Willis came up with the CAMS acronym–Culture, Automation, Measurement & Sharing–as a means of avoiding partial solutions.

In this thread, I specify that enterprises thrive on tangible, repeatable efforts. For me, attempting to explain the benefits of DevOps to the business to an IT executive needs to be rife with tangible and measurable efforts so that the IT executive can have a high threshold of confidence that if followed will lead to the expected results. In my opinion, culture does not belong in this conversation for the sole purpose that if the culture cannot be changed, the entire effort will be suspect and, thus, most likely not attempted.

In response to one of the tweets in this thread, Damon states:

Damon has been working with many large enterprises now on delivering benefits of DevOps, so I believe this statement is reinforcement of my earlier theory that culture is a big turn off for getting IT executives to invest in adopting DevOps approaches. Organizational dynamics is something that is a bullet point within the roadmap that must be dealt with and the IT executive will recognize that no transformational efforts can ever be successful without possible need to shift people and roles.

In speaking with Edwin Miller (@edwinmiller), CEO of 9Lenses, a company that provides a platform for analyzing organizational dynamics, there was agreement that culture is important, but it is very much a leadership issue. Without strong leaders that can admit fault, don’t fear not having all the answers and can incite the passion of workers any attempt at culture is a folly. The opportunity to have real transformation in IT will start with hiring IT executives that understand the changing landscape of the digital economy and realize, just like the automotive companies did in the 80’s, that middle-tier executives may have no perspective on issues where line workers have great insight into how to change things. That is, in order for things to really change in enterprise IT, it will require leaders that recognize that the aggregate knowledge of all in IT will be required to identify problems and eliminate them.

With regard to the perspective of those in favor of DevOps culture, it seems there are various perspectives on what is meant by the word culture. This blog entry by Jeff Sussna, “Empathy: The Essence of DevOps” has become a beacon for many on how to proceed by focusing on fostering change through shared experiences. This article, “DevOps Culture,” by John Willis discusses culture from the perspective of behavior modification, where behaviors are essentially how the organization responds to a given stimulus. This latter piece really is about problems caused by the overlap of people and process, which is an interesting point given that we talk about IT being about people, process and technology as if they were independent silos when what we really are talking about is the need to fix the points where these three elements overlap.

Frankly, stepping back from the fray for a moment, I find it odd that opposition to the term DevOps culture causes such fierce debate and in some cases mob-like responses in various forums. For me, I’ve presented a logical reason why the term can be seen as negative or at a minimum offer no value to entice investment or gain traction for taking action to work on the changes that are often discussed around companies practicing DevOps. Other than “it’s critical to DevOps success” messages, I’ve seen little from those pro-culture advocates as to why we should expect businesses will change something as esoteric and intangible as culture in order to succeed in fixing what we should all view as ineffective practices. Without meaningful changes in IT management to hire leaders with the aforementioned attributes, talking about culture change is akin to changing the oil filter in your car when the spark plugs are shot.

October 2, 2014
Moving Security To the Left In a DevOps World

Moving security to the left has become a coined phrase meant to describe the process of getting the security team involved earlier in a process. Most typically, the phrase is used in conjunction with IT or software development projects. One of the top suggestions for ensuring security in a DevOps world is to move security to the left in the process tool chain. But what exactly or how exactly can you move security to the left?

Grab that Open Seat

The new DevOps process pipeline created an opening for a seat at the table for security. Prior to DevOps, the development team owned the entire pipeline from plan to release. The Ops team would historically receive the release from over the wall and then be responsible for the deployment and operating the software inside the production environment. With the Ops team joining forces with Development in the process pipeline, that has opened a proverbial seat at the table. What I’ve started to witness are security teams taking advantage of the musical chairs to quickly grab the open spot.

Taking a seat at the end of the development pipeline is not enough. Too many security teams are still being relegated to positions too late in the process. While running pen tests and security code reviews after a release is better then nothing, its still not ideal. Security needs to find ways to add value to the process so they can act as a force for positive change instead of the after thought.

Threat Vector Analysis

Threat vector analysis is part science and part art and part trying to guess uncertainty. What is certain, however, is that most developers would rather be spending their time writing new functionality instead of trying to understand how an attacker could be break their code. The security team could offer a tremendous service to an organization by offering their expertise in this area.

Continuous Integration Security Testing

Continuous integration is a key component of DevOps. The security team can leverage the development chain to insert early yet important risk control tests. Those tests could be for example static or dynamic code analysis. Other tests could be simple yet known vulnerability checks in included libraries. The OWASP introduction to testing guide lists a plethora of application security tests that should be checked often and early.

Author Micro Security Services

Think about how great it would be if there was a group who specialized in authoring and delivering security related services into your application? Proponents of services models generally promote splitting the development team up into groups that are organized around business capabilities. For example, there are separate development groups for UI, middleware and DB. What’s missing in most of those models is who is responsible for security services such as authentication, authorization and audit. Security has an opportunity just waiting for them to add incredible value while also ensuring the security services used pass muster.

Summary

Where we once had Ops fighting their way to be part of the entire development process, we now have security trying to do the same. Ops managed to garner their way into the club by coming to the table with invaluable skills and resources. Now its up to security to present their creative sweet spot in order to secure their own seat at the table.

Further Reading

Andi Mann on Ensuring security and managing risk in enterprise DevOps

October 1, 2014
Collaboration in Progress: Making DevOps a Reality

Everything on your company’s DevOps checklist is accounted for. It’s got the vision and the talent. It’s identified the problems and mapped out a solution. It’s got a culture that allows the flexibility that such a plan requires. Now’s the time to put the plan into action and let the benefits begin.

The truth is that it may not be that simple. A great plan won’t mean anything unless everyone understands how to achieve it. And whatever a company’s DevOps strategy consists of, collaboration is the key to making it a reality.

Collaboration is at the heart of DevOps. It’s even conveyed in the phrase itself. No matter the size of your company, this new process of teamwork and transparency relies on combining strengths between Development and Operations to achieve goals that otherwise wouldn’t be possible.

Breaking Silos with a Full-Circle Approach

With one department responsible for writing code and another responsible for implementing it, silos can naturally form as each group focuses on its job. This kind of structure is what commonly gives rise to software deployments taking longer than they should and even little or no communication taking place between the two departments.

DevOps has come about as an antidote to these kinds of siloed situations in which inefficiencies and a lack of teamwork are the norm. Yet for DevOps to take off, both Development and Operations have to participate fully and understand that collaboration requires equal cooperation from both sides. Such collaboration has to take place not just at certain stages, but throughout the life of a project. When each team is invested in the effort by providing feedback, helping identify future problems and continually learning from day-to-day deployments, a company has a great chance of seeing benefits from these new collaborative efforts. Without complete buy-in from everyone, the process will never get off the ground.

The Evolution of Collaboration

Just as DevOps is about moving beyond the assembly line process of software development, the concept of collaboration itself is evolving. DevOps-style teamwork can consist of more than breaking down the silos between different teams. In an agile infrastructure, team members can wear different hats and swap responsibilities depending on the demands of the day. Instead of a scenario in which people work on single specialized tasks without any interaction with the larger group, you’ll have contributors who can play multiple roles within a team and understand how this boosts productivity for the entire company, rather than just a single department. It’s possible that a team member can function as a developer one day and then work on deployments another. Through DevOps, an organization can advance beyond one-dimensional departments and one-dimensional contributions.

Real-World DevOps Teamwork

For many within the IT industry, DevOps is already a working reality. Breaking silos and becoming more agile are goals for companies that know how increased collaboration can help their business. A good source that lays out some first-hand experiences of DevOps practitioners can be found in the recently published Rackspace e-book, The DevOps Mindset: Real-World Insights from Tech Leaders. It features interviews with IT experts who discuss what led them to adopt a DevOps approach and recommendations for those interested in a new agile approach to software deployment.

When discussing the importance of agile teamwork, James Kenigsberg of 2U remarks that, “To achieve true DevOps collaboration, you need your employees to really think and act as one, not just be merged together in name only.” As a provider of online university programs, 2U faces a huge demand for quick, dependable deployments and underwent a transition to increase teamwork at the company. “We had to flip the model,” Kenigsberg explains, “from the idea of personal heroics and siloed responsibilities to real, cross-functional collaboration.”

Jim Kimball of fund administrator HedgeServ reiterates this cross-departmental approach. “Repeatability and scalability are our business,” he explains. “The capabilities that DevOps gives us directly enable this by encouraging collaboration within the organization to come up with better solutions.”

Forging a Partnership Between Dev and Ops

Assembling a skilled and talented group that will be the envy of your industry is the ideal every company would like to have. If you’re able to gather a team that’s the IT equivalent of the X-Men, it’s not enough to just assemble that talent and assign them siloed roles. Without frequent teamwork, not only will company goals become difficult to achieve, but solving problems will be nearly impossible.

When Development and Operations see themselves as working in partnership with each other, the foundation for greater collaboration will be in place, and company goals, such as greater speed to market, increased productivity and an all-around agile performance, will be within reach. With the right mentality, DevOps can be an evolutionary step in company functionality and reach new levels of efficiency that otherwise wouldn’t be achievable.

September 16, 2014
The DevOps Litmus Test: Is Your Company’s Culture Ready to Get Agile?

New ideas don’t come to those who are afraid of breaking the rules. Improving something usually means you’ll have to push the status quo aside and try something that hasn’t been done before. What may be a standard operating procedure will have to make way for a brand-new approach with its own set of rules and goals.

This applies directly to DevOps, which requires changes in how departments operate, how employees interact and how problems get solved. DevOps may be an idea your company is considering, but if the culture isn’t compatible with it, DevOps will never become an active part of your day-to-day operations.

If DevOps Is the Engine, Culture Is the Fuel

Let’s say two employees who don’t normally work together wind up taking an unprecedented approach to solving a problem. To their surprise, this new way of working together is incredibly efficient and a big improvement over their usual methods. The two recommend this kind of collaboration to others in their respective departments when it comes to spotting problems, fixing them and preparing for future ones.

That’s the moment when you’ll know how receptive your company is to DevOps. This kind of cultural litmus test determines whether department silos can be broken down and new avenues of teamwork can happen. No matter the company or industry, its culture is the foundation for DevOps adoption. When that culture fits, DevOps is an ideal vehicle for improved productivity, with culture being the fuel moving it forward.

Getting the Right Cultural Fit

In order for DevOps to happen, you need the right conditions, similar to how certain plants only grow in the right ecosystem. Team members must be able to interact in ways they may not have in the past. The right culture is one that allows flexibility, spontaneity and resourcefulness to take place.

On the flip side, DevOps won’t work in a rigid environment where departments are siloed and methods can’t be questioned. DevOps has a slim chance of taking off in a company that wants to hold onto previously established rules about divisions between departments. Anyone who stands up to say, “That’s not how we do things,” will be a hindrance to progress. Greater benefits are in reach, but to make them a reality, a company and its employees have to be willing to make some changes and allow agile collaborations to flourish.

DevOps Culture in the Real World

For those who have already put DevOps in action, culture was, and continues to be, a central issue. Household names like Twitter and Netflix may be known for their DevOps practices, but many lesser-known businesses have found that their cultures identify with DevOps collaborations. The recently published e-book from Rackspace, The DevOps Mindset: Real-World Insights from Tech Leaders features interviews with a variety of DevOps practitioners. The importance of culture is a common theme throughout these discussions.

These firsthand accounts emphasize how encouraging new ways of solving problems depends on the proper culture. As James Kenigsberg of 2U explains, “You don’t have to be in Silicon Valley to embrace the DevOps culture; anyone can do it anywhere with the right people.” Bharat Krish, CIO of HBO Latin America, also emphasizes culture as an essential factor. “When I think of a DevOps culture,” Krish says, “for me it’s building a foundation where development can happen in a more agile fashion.”

Start with the Biggest DevOps Requirement

Knowing that DevOps benefits one company doesn’t necessarily mean it will automatically benefit another. Company processes, structure and communication standards all play a part in determining whether DevOps is right for your business. DevOps isn’t a product that can simply be plugged in – it requires a new way of thinking about agile software deployment.

Culture has to be at the center of a DevOps adoption, and assessing your company’s culture is a crucial first step in determining whether DevOps will be a good fit for your organization. As long as your company is flexible enough to allow some cross-departmental collaboration and silos to be broken, then prepare for DevOps to take you to new levels of productivity. You’ll find that breaking the rules isn’t such a bad thing.

August 27, 2014
Culture Debt

There has been a lot of talk lately about IT’s accumulation of “technical debt’. Technical debt describes necessary work from a prior deployment that was deferred in favor of other tasks. As technical debt grows, the ability to make future changes is hindered because of a backlog that was not addressed.

I have recently come to recognize that IT suffers from another type of debt – culture debt. IT is a young industry that grew rapidly while facing constant pressure to bring technical innovation to the market. Culture considerations were deferred in favor of building and deploying products and services. IT’s silo culture grew organically out of the need for diversifed sets of specialized experience and expertise.

While cultural debt was accumulating, IT’s complexities were increasing. The single platform mainframe vanished in favor of multi-platform servers. Production applications grew exponentially. The IT supply chain went from a single location department to a network that spans multiple geographies and organizations. Although IT’s silos were also acknowledged to be IT’s constraints, converging different processes, frameworks, vocabularies and customs was not going to be easy. And so the cultural debt grew.

Like all debts, payment is eventually due. For IT, the due date is today. Cultural debt is having a tangible impact on the bottom line by hindering IT’s ability to meet the pace of deployment that the business now requires. Every bottleneck in the workflow between Dev and Ops affects the entire system of supply and demand. The business has zero tolerance for missed deadlines, poor quality code or fragile applications. A paradigm shift is required in order to improve IT’s consistency and speed.

The good news is that an increasing number of individuals and organizations are looking to pay down cultural debt by embracing a DevOps approach. Case studies are emerging that demonstrate proof of concept – silos are breaking down and people are talking to each other. Tools are enabling automated tasks and deployments are happening faster with fewer defects. Dev and Ops are starting to embrace a common set of practices and accountabilities. Best of all, DevOps is stemming the rate of future technical and cultural debt – and that’s a win for everyone.

August 13, 2014
Five Top Tips for DevOps At Scale
Since I published my blog explaining the topic of ‘Big DevOps’ late last year, the concept of Enterprise DevOps has exploded, with commentary, experience, and advice (some good, some awful) popping up from many different quarters. Fortunately, many pundits have now come to agree that application delivery in a traditional enterprise is very different from in a typical web-scale/startup environment.

As a result, a growing body of work is filling a significant and important gap with unique insight into Enterprise DevOps, from many excellent commentators and practitioners who understand how large enterprises are different, and how to address those different challenges.

As Enterprise DevOps takes off, I seem to field questions about it on an almost daily basis, so I decided to contribute to the body of work with a webinar explaining my answers to five of the most frequent challenges I hear about DevOps at scale. It was titled ‘Big DevOps: Five Top Tips When Implementing at Scale’ and you can catch the full replay on YouTube.

The top five issues I chose to address are below:

My five ‘Big DevOps’ tips for overcoming these issues center mainly on cultural change, because DevOps is primarily a cultural and attitudinal shift. However, it is also undoubtedly true that certain technologies can play a large part in enabling that change, especially in the more complex world of larger enterprises.

With that in mind, my top five tips to address these challenges are as follows:
- Facilitate a culture of teaming and collaboration – this is at the core of devops in any environment, large or small, but especially for large organizations with bright lines between teams, this is essential to overcoming the tyranny of complex and dispersed silos
- Establish agile development as a shared discipline – agile development is brings code to market faster, but can result in just filling the clogged pipes of PMO, HR, training, security, and other departments faster. ‘Agile’ needs to be common throughout the SDLC – in dev, ops, and beyond
- Automate relentlessly to enable rapid devops response – automation allows faster execution throughout the system, enabling downstream processes to keep up with speed of DevOps. Automation also adds audit and governance, especially important to larger organizations
- Push smaller releases faster, measure and remediate impact – large organizations especially are can avoid big errors by avoiding big releases. Adopt faster, smaller cycles with closer scrutiny to achieve a DevOps approach while managing the risk of faster cycles and fewer controls
- Manage user identities to enable shared access – in smaller organizations it might be acceptable to give out root access like candy, but not for large enterprises. Identity and access management can enable a new DevOps approach that is safe, secure, auditable, and well-governed
While these tips may not be the perfect answer for every organization, I have seen how these approaches have made the journey to DevOps easier, safer, and more effective for big enterprises. I hope they help you on your journey.

If so, you will want to stay tuned to devopsy.kinsta.cloud. Since starting work on Enterprise DevOps concepts, I have collected many questions on how large organizations can best succeed in their DevOps transformation. I will be sharing these questions along with my answers here on devopsy.kinsta.cloud in a regular series, to give everyone the chance to understand how large enterprises can overcome the challenges of adopting DevOps at scale.

So keep your eyes out for my posts over the coming days, weeks, and months in the brand new occasional series, ‘Enterprise DevOps Q&A’. I hope you will keep reading, and maybe even help me out by discussing your experiences and ideas in the comments below.

Finally if you have any questions about Big DevOps, Enterprise DevOps, or anything to do with adopting a DevOps approach at scale, let me know in the comments below too. I would love to hear from you, and answer your questions if I can, or source guest opinions from the DevOps community.

Meanwhile, please stay tuned for more Enterprise DevOps Q&A. I am excited to continue the discussion on what it takes to transform application delivery at scale.
July 24, 2014
Mixed Martial DevOps vs.The Scrum Master

Royce Grace won the most tournaments in UFC history before he retired. With a record of 14 wins, 2 losses, and 2 draws, it’s understandable why he’s considered by some to be the most influential figure in the history of modern MMA. With 100% of his finishes from submissions, he’s undeniably Brazilian Jujitsu royalty. You’d be hard pressed to find anyone familiar with the fighting world that would argue against building a strong base in BJJ while learning to fight. Royce proved that BJJ was the single most effective form of fighting in the early nineties by submitting opponents much larger than him, like Dan Severn, in UFC 4. Severn had just shy of a 100 pound weight advantage on Gracie but ended up getting caught in a triangle choke. I can remember watching the video and trying to figure out how he made him tap like that. All the sudden fighting wasn’t just about kicking and punching anymore, the game had changed forever.

Fast Forward 12 years to UFC when the Master Royce Gracie is to make his return to the octagon. Matt Hughes crumpled him up like a paper napkin. Royce had continued to practice BJJ since his fight with Dan Severn as it was a successful strategy. The mistake he made was investing in a monoculture. Royce kept a razor point on his BJJ, but fighters like Matt Hughes were smart enough to put an edge on all the dull perspectives of their game. Hughes was a well decorated submission wrestler that knew he needed to work on his striking and maintaining his strength and endurance. Ronda Rousey made it clear after her last victory that she’d been working more on her striking too, which makes sense considering she’s already an Olympic medalist in judo.

At the end of the day it’s a fighter that wins a fight, not the discipline they practice. A well rounded fighter is going to be able to adapt to adversity better than someone that only has nth level experience in a particular area. The same is true for software methodology. A scrum master’s team will consistently be outperformed by a team taking a mixed approach. Not because something is inherently wrong with scrum, but that people get the work done, not the process. A team embracing a diverse approach is more likely to do what works. They will be open to more experimentation to figure out what is successful and to confirm when the current model isn’t working. Sometimes it’s the people not cooperating, but telling them there’s a problem because they’re not fully embracing the methodology is usually wrong. Often enough the methodology is being taken as gospel and is embraced too tightly.

I both like and understand kanban, but feel scrum has too much convention to adhere to specifically. I checked Google and it seems to agree with me:

Just to be fair, I checked to see how Google felt about kanban.

But Google didn’t seem to treat kanban as harshly.

If you can’t take my word for this maybe you’ll listen to someone else?

Just the other day Andrew Clay Shafer posted this on Twitter:

I did ask Andrew to offer an alternative approach if scrum wasn’t going to work, and he directed me to slide 46 of a presentation he did in Pittsburgh for a Ruby User Group (shown below). This slide advocates a mixed approach as well. I agree with everything Andrew encourages there, and can honestly admit I need to dig into XP technical practices a little deeper myself. This will not be an abandonment of current methodology and a complete shift in another direction, but an evaluation to see if I can fill some holes in my game.

July 14, 2014
The 7 skills Ops pros need to succeed with DevOps

There’s a lot of confusion about what DevOps exactly is, and what it takes for enterprises and individuals alike to succeed. Some argue it’s about successfully using collaboration toolsets. It’s not. DevOps is about collaboration between software developers and IT operations teams. DevOps grew from the need for a more agile organization, and to knock down the barriers between development and operations so that applications and IT resources could be delivered more quickly, and improved through steady iteration.

What does all of this mean, specifically, to operations professionals – and the skills they need sharp to thrive? The walls coming down are a bit of a culture clash for most large enterprise operations and development teams. And both developers and operations professionals need to ensure that they have the right skills in place to succeed in this new environment. In this post, we’re focusing on those skills ops members need in the years ahead.

The skills that are important may surprise some. Consider the findings from CA Technologies’ recently commissioned a study, What Smart Businesses Know About DevOps. “The most in-demand skill requirements for success with DevOps were actually soft skills,” says Andi Mann vice president of strategic solutions at CA Technologies. “I expected to see skills like programming or scripting; experience with specific tools for provisioning, configuration management, release automation, or shared monitoring; or even an understanding of Agile or Lean practices. In fact, those skills were much lower,” Mann says.

More on the results from the CA study below, but first we want to share the results of our informal anecdotal survey of a handful of DevOps experts and practitioners, well known here at devopsy.kinsta.cloud. Here they are:

First Up: The Soft Skills
Interestingly, it is these soft skills that are both needed and often derided. “Everyone doing DevOps, whether Dev, Ops, security, QA, project management all need [soft skills],” says David Mortman, chief security architect and distinguished engineer at Dell, Enstratius.

1. The ability to communicate clearly and concisely
“Sharing is a key tenet of DevOps and if you can’t share what you know and what you’ve learned, then having that knowledge is effectively useless. You’ve just made yourself a bottleneck,” Mortman says. The other skill Mortman cited along these lines is striving to actually understand the shoes in which your fellow enterprise collaborators stand. “I can’t emphasize enough the value of having empathy for everyone else and what they need to get done. Every role has its challenges and empathy for those challenges goes a long way to a more congenial workplace,” he says.

2. Collaboration techniques
New collaboration techniques are essential, explains Donnie Berkholz
IT industry analyst at RedMonk, and council member and Sr. developer at Gentoo Linux. “Ops will need to learn effective, distributed collaboration techniques such as those used in open-source software development. Leading-edge DevOps organizations make heavy use of online chat and shared tooling to log both communication as well as action. In some pioneers, this even involves so-called “ChatOps” where you can make changes to infrastructure through calls to an automated bot in an online chat. Typically this includes asynchronous communication in preference to phone calls, both long-form (e.g. email) and short-form (e.g. IRC), in an archived and searchable form,” he says.

This enables, Berkholz says, on-call ops during any crises or fires that arise, as well as eases the ability to identify and brainstorm infrastructure changes, where everyone can easily contribute their ideas.

3. A flexible mindset
We’re not necessarily talking about advanced forms of mental Yoga, but certainly the ability to change as knowledge and conditions change, whether those changes are technical or business driven. “The willingness to make changes and to evaluate alternate options is key to DevOps. Things are going to fail, you or a decision you’ve made are going to be the cause of that failure. Or things just won’t work as well as you’d hoped or thought. Be willing to change your mind and look for better options,” says Mortman.

4. Good enough is never enough
It’s about consistently seeking continuous improvement. “This mindset is laser focused on continuous improvement daily,” says BEHR. “It is the ability to unlearn and acquire new more relevant knowledge in light of complexity and emergent information – then disconfirm it with the scientific method and move on to application only where relevant,” says Kevin Behr chief science officer at CXO advisory and board advisory practice Assemblage Pointe, Inc.

Next up: The Technical Skills

Understanding of modern software engineering
5. “To move to a world of “infrastructure as code,” where all systems are maintained using configuration-management tools such as Puppet or Chef, including version control, unit and integration testing, agile software development, as well as continuous delivery and deployment models,” says Berkholz. “Traditional sysadmins may still live in a world of login prompts and manual edits of configuration files, so this will be perhaps the largest hurdle in terms of knowledge,” Berkholz estimates.

“The technical mindset I look for are skills which allow a team to treat servers more like cattle and less like cats,” says Andrew Storms Sr. director DevOps at CloudPassage. “To work effectively at that kind of systems mentality, DevOps engineers need programming and systems architectural skills. Whether that means Ruby or Python or whatever is needed to effectively work with orchestration tools, APIs, and automation. It’s less about needing to know a specific programing language more about understanding programing algorithms and robust systems design,” Storms says.

6. Modern software architecture
This includes cloud deployment and administration as well as distributed systems. “As we move to a cloudy world of software, ops will need to deploy, maintain, monitor, and troubleshoot production problems with this infrastructure. And yet in many cases it’s much more complex than the previous equivalent, although it brings with it significant benefits in agility and uptime if done right. Ops will need to familiarize themselves with cloud instances and services, as well as lower-level software infrastructure such as Linux distributions and databases when deployed in a cloud,” says Berkholz.

That also includes taking a step back from the trees to consistently stay aware of the forest. “Seeing the system and its boundaries rather than just the tasks and their due dates. This understanding of the interactions between the various actors in a system and [understanding] just how those interactions are making value occur is fundamental,” he says. “Without this understanding we will not know when to push harder versus be silent,” he says.

7. Understanding that security incident response are continuous efforts
Security and safety in the new DevOps environment needs to embrace new ways of addressing security and QA. “This requires continually emergent solutions rather than using ‘tried and true best practices.’ The effective team will evolve through relentless self evaluation, study, and application of more relevant and effective methods to work in complex infrastructure environments,” says Behr.

That’s all great advice, and certainly not all inclusive of the ideal skillsets. We also found it interesting that CA Technologies’ survey of 1,300 senior IT decision makers echoed the need for broader business and so-called soft communication skills when it came to DevOps success.

These included: knowledge of business priorities/strategies/metrics (47%), knowledge of current business processes (42%), communication skills (36%), and project management and people skills both scoring 30%. In fact, experience with specific tools was dead last in the survey at 12%.

June 9, 2014
Let DevOps be a business process

I just returned from an amazing time at the first Camp DevOps in Boulder, CO. It was held at University of Colorado, Boulder and in conjunction with Gluecon 2014. This is the first conference I have attended that was singularly focused on DevOps. I found the three track format at the show had something for everyone. A technical track, a business track and some great DevOps round table discussions with great panel speakers. My takeaway was that DevOps is not just a cultural thing as some claim. DevOps needs to be perceived more as a business process or it will just be a passing fancy. Some may disagree with that view but 35+ years of IT industry experience gives me a bit of a long view.

Gene Kim enlightened me on some issues in his recent response in the Wall Street Journal with some facts about what is going on within traditional legacy Fortune 500 companies. They are implementing DevOps strategies in a big way. My take is that it is not noticeable within the Fortune 500 because DevOps is viewed by the Fortune 500 as a business process, as opposed to being an implementable organizational structure. Sort of like the DevOps is not really a job title argument. If it is a business process, no one has DevOps in their title, but it doesn’t mean DevOps is not being done there.

I think most of us want to see DevOps cross the chasm and become a de facto standard. Since Patrick Debois first coined the term “DevOps” there is no question that DevOps has developed into a global movement. Of course DevOps has its cynics. Pessimists say DevOps is a new name for a Sys Admin, the flippant say DevOps is just a front for some fanatical developers trying to liberate the world from operations or DevOps is just some foolish operations people trying to make nice with Developers. That it means the extinction of QA job is another familiar mantra.

I’ve spent a lot of time trying to understand the lack of cohesiveness within the DevOps movement and everyone telling everyone else what DevOps is and what it should be. As with anything else the marketplace will decide the future and fate of Devops. During this process, I’ve begun to notice a common misconception that I think is fueling much of the reactions that some people have to DevOps ideas. Holding DevOps back is not a technology problem or a cultural problem.

In order for DevOps to happen I realized we all need to keep pushing this philosophy forward. We cannot worry ourselves with culture, commercialization or technology. Technology plays a critical role in facilitating solutions to DevOps problems. However, DevOps itself is, at its core, a business issue. The most fundamental business process in any company is getting from concept to completion with the end result of profitability.

If you remove the perspective of the business process, what is left? You’ve got a whole lot of people and groups doing their own thing. Lost is the motivation to battle inefficiency, duplication of effort, turf wars, and disparate groups. It’s a free for all.

If we don’t let DevOps take its course within the market place and embrace the business process, jobs are lost. We are able to do what we do because of the business of DevOps. If we don’t all push the commercialization of DevOps then we have nothing but a chat room to talk philosophy.

The sole purpose of DevOps is to enable, big and small alike, business to react to market forces quickly, efficiently, and reliably. Without the commercialization, there is no other reason for us to be talking about DevOps problems, much less spending any time solving them.

May 29, 2014