DevOps for beginners: Where to start learning and focusing

Where to start with DevOps? Let's explore how to get going with this cross-functional way of working that breaks down walls, improves speed of delivery, and increases experimentation

Infinity lines to illustrate the concept of DevOps

If you’re beginning to learn more about DevOps, you may be confused about where to start. First, DevOps is a bit of a buzzword. Throughout the 2010's, Agile was one of tech’s biggest buzzwords: It is still often used incorrectly, to describe purely delivering software faster. Agile is, in fact, focused more around delivering business value earlier to users – and more frequently thereafter. Even though Agile is now officially grown up (it had its 18th birthday in February 2019), we still love to use the values and principles of the Agile Manifesto (created in 2001) as the basis for subsequent technology approaches and philosophies.

[ Need to explain key DevOps terms to others? Get our cheat sheet: DevOps Glossary. ]

Where DevOps came from

Before DevOps, packages of software would metaphorically be thrown over the wall from the army of developers to the army of operational staff.

One of these newer approaches, aimed at further enabling business agility, is DevOps. This term resulted from the gap that arose from software development being built and packaged up by one group of people, and then being operated and maintained by a completely different group of people. The packages of software would metaphorically be thrown over the wall from the army of developers to the army of operational staff.

This meant operations teams often had to learn about software the hard way, by investigating production incidents in the pressurized live environment. They would address bugs that were not found until production usage of the applications had started. This often meant handling new scenarios that had not been considered in business requirement planning.

To plug this gap, organizations brought together development and operations teams: They brought down the wall and formed new teams focused on the development and the operations of the technology tools, with collective responsibility.

The term “DevOps” refers to this idea that we no longer have development teams or operations teams – and to a set of DevOps practices that optimizes and improves both functions. In recent years, this has been joined by the creation of related terms such as:

DevSecOps - cross-functional teams that develop solutions, operationally support them, and ensure security compliance starting early in the development process.
BizDevOps - cross-functional teams that encompass shared understanding across the team of business value of features, development of those features, and operational support of the components containing those features.
DesOps - cross-functional teams that consider the user experience and user interaction design of proposed ideas, development of the resulting features, and operational support of the components containing those features.
BizDesDevSecOps (!) - This is what we really mean by a cross- functional product team: A group of people that, between them, can take an idea and conduct all of the research and experimentation activity, develop solutions, and operationally support them.

For the rest of this article, let’s just refer to “DevOps” but recognize that the philosophy above is what we’re trying to achieve by implementing DevOps practices.

How to begin your DevOps journey

DevOps sounds simple enough if it’s just about bringing different teams together. So why is getting true DevOps in organizations proving so difficult? And how does one start out on a DevOps journey?

A great practice to start is to map out value streams.

First, we need to identify all the gaps and bottlenecks in your organization. A great practice to start is to map out value streams. What are all the steps taken between a customer triggering a request for a product or service and the associated value being delivered to them? How long does each step take? Where is there waste and unnecessary wait times?

What about getting new releases of your software? How long does it take to get a new idea from a customer (internal or external) implemented and usable?

A pair of practices to help with all of these questions are Value Stream Mapping and Metrics Based Process Mapping: These exercises can help you think about the gaps and delays that exist between end users and business lines, between business lines and software development teams, and between software development teams and application operations teams. Plugging these gaps and shortening these delays is what DevOps helps improve.

5 factors to focus on when beginning with DevOps

Next, it’s hugely valuable to take some time to ensure you and your teams understand what DevOps is and, more importantly, what DevOps isn’t. Invest time in a DevOps enablement program where you get the opportunity to understand what DevOps is through experiential learning of continuous discovery and continuous delivery, underpinned by strong collaboration and engineering culture. There are many great educational resources to help kick-start this. (We’ve listed some community resources at the end of this article.) These resources use real-world examples to bring DevOps to life, so leaders can see metrics-based benefits. This builds motivation to make incremental changes in your own organization to move toward true DevOps culture.

When starting with the DevOps way of working, you should expect to focus on five factors. Here they are and here’s why they’re important.

1. Automation through technology

If someone or some group of people execute the same process twice, it is a candidate for automation. Engineering practices such as Continuous Integration, Continuous Delivery and Everything-as-Code employ automation at the foundation and teams should seek opportunities to automate as much of their workflow as possible.

[ For more on CI/CD basics, check out What is CI/CD? and Getting started with CI/CD: 4 success factors. ]

2. Culture and organizational change

DevOps teams break down silos by having cross-functional teams and reducing hand-offs, handovers, ticket queuing systems, and dependency mapping. In helping organizations move to the DevOps model, we’ve seen improvements in feature lead time improve by factors of over 100 when organizations simply reorganize departments to be more product focused and give the team the skills, capability, and empowerment to deliver features end-to-end.

3. Process and practices

Consider adopting the many practices in the Open Practice Library which drive continuous discovery and continuous delivery. This helps you work toward the DevOps goal of having small incremental units of value regularly delivered to (and operationally supported) in production.

4. Radiate everything

Key to learning great DevOps practices is access to information. For instance, you can use visualisation through information radiators to make practices and learnings very visible to everyone. Any stakeholder should be able to get the answer to any question they have by “walking the walls,” looking at information radiators, and having a good old fashioned conversation about what is on them.

Some examples of information radiators include: Build monitors, infrastructure health checks, automated test stats, automated security and vulnerability scan indicators, Scrum boards, burndown charts, definitions of ready and done, team sentiment charts, retrospective actions … the list goes on and on.

The most valued examples will vary among organizations: Where information is deemed useful to someone, the tool producing it and radiating it is a good one.

5. Inspect, adapt, and continuously learn

Those information radiators come in especially useful to trigger conversations, get a shared alignment and understanding about product health, and prompt motivation to continuously improve.

Using retrospectives to regularly check in on what the information is telling us about our product, our team, our people’s mood, our users, and our platform gives us the opportunity to assess what we can do to make ourselves, our products, and our organization even better.

Remember all those "lessons learned" exercises we did at the end of projects? Retrospectives work even better because we do them early, regularly, and to drive continuous learning throughout our product development.