The subject of DevOps is one that tends to prompt many different opinions on what it means and exactly how you do DevOps within your organization. The goals of DevOps and what it helps you achieve within your organization is also something that you will get different answers for from different people, depending on their experience, the industry they work in, and how successful those organizations have been at adopting DevOps.

For many organizations, you can define the following common goals of DevOps. These are goals that apply to most organizations:

• Deployment frequency
• Faster time to market
• Lower failure rates
• Shorter lead times
• Improved recovery time

Of course, your organization may be driven by different reasons and even for similar organizations, I would expect their goals to be slightly different. After all, while most organizations share the same challenges, how these challenges can be addresses and which of these challenges will result in the biggest gain in value will also differ, depending on the organization.

Deployment frequency

Improving the frequency at which you release or deploy software in your organization is often a key driver of the adoption of DevOps. We must start to change the way we collaborate and communicate within our organization to deliver value to our end users.

When developers and operations teams start focusing on the same shared goals, they start working together more effectively and deliver better value.

Faster time to market

Most organizations will compete with another for the services they provide. Having a faster time to market gives you a competitive edge over your competitors. With DevOps, you can work to increase value by reducing the amount of time it takes from idea inception to product release.

As a business, your value degrades the longer it takes you to release features to your product and the quicker your competition can get ahead of you. So, achieving a faster time to market is a key goal of not just DevOps but the business as well.

Lower failure rates

Every organization has failures, but with DevOps, you can, over time, expect to realize lower failure rates through teams collaborating with each other and communicating better with each other.

Tip

Cross-functional in DevOps denotes where people from different areas work together in one team.

DevOps gives teams the ability to work more closely and communicate more effectively. In mature organizations, it allows for cross-functional teams. The shared knowledge between these teams and the individuals within them and the greater understanding of each other's roles leads to lower failure rates.

Shorter lead times

Lead time is the amount of time between the initiation and completion of a specific task. In DevOps, this would be the amount of time between work starting on a user story and that story making it to release.

Tied hand in hand with faster time to market, shorter lead times is not just about your product but everything in the whole life cycle. This could be anything from planning where you capture requirements more effectively all the way to building infrastructure quicker than before.

Through slick processes, effective communication and collaboration, and high levels of automation, the lead times throughout your cycle will be quicker, leading to high performance within your team.

Improved recovery time

Of course, we all know that most organizations have Service-Level Agreements (SLAs) to measure the performance of key service-based metrics such as availability. However, how many organizations can tell you, on average, how long it takes to recover a service? Not many.

Having the level of collaboration that lets you discuss the reasons behind failures, understand them, and implement steps to prevent them from happening again is a sign of a mature organization. An organization that measures this metrics and takes steps to reduce them is an even more mature organization.

Downtime is lost revenue and reputational damage to your organization, so reducing that level of downtime is very important.

In this section, we have explored what the key goals of DevOps are and the business value behind the adoption of DevOps. Next, we'll take this further by looking at the values that make DevOps successful.

DevOps can be split into various pillars when it comes to transformation. That being said, if you wanted to take a high-level view of DevOps rather than one at a deeper level, you can talk about DevOps as four specific buckets.

These buckets are as follows:

• Culture
• People
• Process
• Technology

I firmly believe the order of these matters. While the ambition may be to work on tooling first, following the order set out here will ensure your organizations get much more value from their DevOps transformation.

Important note

Culture is one of the most important aspects of a successful DevOps transformation, even above the use of technology.

The importance of culture in DevOps cannot be overstated; getting the right culture in your organization enables you to drive in the right direction and get more value later in the transformation. You should also not underestimate the challenge of changing an organization's culture – it requires drive and executive-level support to be successful.

Next is people, the lifeblood of any business and any product. You must ensure that you have the right people to get the right culture to achieve the goals that have been set out by your organization, and those people must have the right skills to achieve this. As important as executive-level support is to DevOps, so is having the right people to execute it.

Now, we have process. The right-minded people will be the ones who can work with and drive your processes in the right direction, applying appropriate techniques to ensure your processes are fit for purpose in a DevOps world. To work together, you need to adopt some processes for continuous collaboration, such as plan, develop, release, and monitor. Finally, you need the ability to repeat those processes on demand to deliver maximum value.

Finally, technology. By this point, the work you have undertaken in your DevOps transformation should have gained incredible value for your organization, but by introducing technology, you can add yet more value. Through automation tools, your processes can now be run on demand, more frequently, and, importantly, with a level of idempotency. This means that results with the same input parameters should not change over time. This is the value automation brings over human execution.

In this section, we have looked at the values that make DevOps successful. Now that we understand what it means to implement DevOps, we will understand the challenges that DevOps will solve in our organization.

DevOps does solve many challenges in organizations. You need to be mindful that many of these challenges have existed for a significant amount of time, have become engrained in how people operate, and that it will take some time to unpick the different levels to achieve what you want to achieve.

Prior to the adoption of DevOps, organizations were ordered in functional teams and reported to line managers, siloed away from the wider business and often each other. If all the conditions were met for deployment, then code was moved through to the operations teams to deploy the application. All these teams, along with others, worked individually, in isolation, resulting in time-consuming activities that were repeated and results that were not satisfactory.

The challenges of DevOps can generally be explained by three statements, which are as follows:

• Developers are unaware of quality assurance and operations roadblocks.
• Quality assurance and operations teams are generally unaware of the business purpose and value of the product.
• As teams work individually, each team has their own set of goals, often in conflict with other teams' goals. This leads to inefficiencies.

The best example for the last point in the preceding list can be made using development and operations teams. The developer's priority is to release new features to the product quickly, while the operations team's priority is to keep the application available and performing highly. These two goals are conflicting, which leads to inefficiencies between those teams.

Addressing these challenges

These challenges are addressed in DevOps by making teams cross-functional, working in collaboration with each other and communicating about other's work and the end results. Overall, this approach increases the feedback's quality and resolves issues with existing automation.

In DevOps, most processes are continuous. With the help of feedback cycles to improve on what you already have, this gives you the ability to constantly mature and evolve your processes, thus learning from previous situations and becoming a more mature team.

Important ote

Addressing the challenges of DevOps is a time-consuming task; you should not expect instant results from a few days or weeks of effort. It will take many months to achieve the goals you have set out.

Now that we have understood the challenges associated with DevOps, it's time to look at the phases of maturity in DevOps and see how an organization will progress based on them.

Organizations should be looking to mature the more they process and adopt different DevOps best practices. This is known as maturity, and four phases are used to describe the phases of maturity in DevOps.

These phases are as follows:

• Waterfall
• Continuous integration
• Continuous delivery
• Continuous deployment

Throughout the cycle of DevOps transformation, organizations should move from waterfall toward continuous deployment, visiting each stage along the way. However, it is worth noting that waterfall is not always the starting point; some organizations start later in the phases.

During the transformation process, you will find that different teams gain maturity quicker than others. There are many factors for this, including the type of work that the team does, the processes they have to follow, and, to a degree, the level of automation and tooling they already have in place.

Waterfall

The term waterfall will be common to you if you have worked on projects in the past. Waterfall is a project delivery mechanism where tasks are completed in a sequential order to achieve a specific goal. It can also be used to explain a method of software development.

Where development teams write code over a long period of time, those teams then merge their code in order to release the latest version. In this case, so many changes have been made to the code base that integrating the new version could take months. This is because the code looks so different from the previous version.

Waterfall has been in the world of project management for a long time, and even with the adoption of Agile getting more and more popular, many projects are executed using the waterfall methodology successfully.

The advantages of using waterfall as a delivery method are as follows:

• Simple model to use and easy to understand.
• Rigidity makes it easy to manage; each phase has specific deliverables.
• In smaller projects, it works well as the requirements are well understood.
• Stages for delivery are clearly defined.
• Milestones are well understood.
• Arranging tasks with resources is simple.
• Processes and their results are well documented.

That being said, waterfall does have several disadvantages, as with all process models. Some of these disadvantages are as follows:

• No time for revision or reflection.
• High amounts of risks and uncertainty.
• Not a good model for projects that are complex and object-oriented.
• Poor model for long-term projects.
• No working software is produced until late in the project.
• Measuring success within stages is difficult.
• Integration is done at the end in a big bang, making identifying bottlenecks hard.

Agile addresses some of these challenges and together with DevOps, you can address a large number of the challenges described here.

Continuous integration

Continuous integration (CI) is the practice of quickly integrating newly developed code with the rest of the application code to be released. This saves time when the application is ready to be released. This process is usually automated and produces a build artifact at the end of the process.

The process of CI contains a number of steps, and these are critical to achieving CI, which is meaningful and efficient. Automated testing is the first step toward CI. Four main types of tests exist that can be automated as part of CI. These tests are as follows:

• Unit tests: Tests that are narrow in their scope. They usually focus on a specific part of code, such as the method of a function, and is used to test the behavior of a given set of parameters.
• Integration tests: Ensures that different components work together. This can involve several parts of your application, as well as other services.
• Acceptance tests: In many ways, this is similar to integration tests. The big difference is that acceptance tests focus on the business case.
• User interface tests: Tests that focus on how the application performs from a user's perspective.

  Important note

  One vitally important element of CI is that you integrate early and integrate often.

When you integrate early and often, you reduce the scope of changes, which, in turn, makes it easier to identify and understand conflicts when they occur. Another big advantage of this approach is that sharing knowledge is easier as the changes are more digestible than big bang sets of code changes.

Another note is that if the main branch becomes broken by a commit in code, then the number one priority is fixing it. The more changes that are made to the build while it's broken, the harder it will become to understand what has broken it.

Every new piece of work that you implement should have its own set of tests. It's important to get into this habit of writing granular tests and aiming for a level of code coverage, as this gives you a comfortable level of knowledge that you are testing the functionality of your application sufficiently.

The value of CI is realized when the team makes changes on a frequent basis. It's important to make sure that your team integrate these changes daily. Integrating often, as you may recall, is key to making sure we can easily identify what is broken.

Continuous delivery

Continuous delivery (CD) is an approach where teams release products frequently and with high quality, and with a level of predictability from source code repositories through to a production environment using automation. It builds on the work that's done in CI to take the build artifact and then deliver that build to a production environment.

CD is, in fact, a collection of best practices associated with Agile. It focuses your organizations on developing a highly streamlined and automated software release process. At the core of the process is an interactive feedback loop.

This feedback loop, sometimes referred to as continuous feedback, centers around delivering software to the end users as quickly as possible, learning from experience, and then taking that feedback and incorporating it into the next release.

CD is a separate process to CI, but they chain off each other and in mature organizations, they are used together. This means that on top of the work you have done in CI to attain levels of automated testing, you can now automatically deploy all those changes after the build stage.

With CD, you can decide on a schedule that best suits your organization, whether that's daily, weekly, or monthly – whatever your requirements may be. If you want to get the true benefits of CD, then deploy to production as soon as possible to make sure that you release small batches that are easy to solve in case of problems that may arise.

Continuous deployment

Continuous deployment is one step beyond continuous delivery. Every change that passes through all the stages of your production pipeline is released to your customers. There is no human intervention – a failed test, at this stage, will prevent new releases to production.

Continuous deployment is a great way to speed up the feedback loop and take the pressure off as there is no release day. Developers are then able to focus on building high quality software while seeing their work go live minutes after they've finished working on it. Continuous integration is part of both continuous delivery and continuous deployment. Continuous deployment is very similar to continuous delivery; the difference is that releases take place automatically:

Figure 1.1 – Showing the differences between continuous integration, delivery, and deployment

In this section, we have looked at the major phases of maturity in DevOps. Armed with this information, we can now look at how Agile plays a role in DevOps.

It is common to confuse the terms Agile and DevOps. Both are used together frequently and can be used interchangeably, but they are mutually exclusive terms. Where DevOps is the practice of bringing together development and operations teams, Agile is an iterative approach that focuses on collaboration, feedback, and small rapid releases.

While both are exclusive, you will find that, by the short comparison provided previously, the goals and values of DevOps are those of Agile as well. Agile is a key part of DevOps. While Agile focuses on constant changes and making developers and development cycles more efficient, DevOps brings in the operations teams to enable continuous integration and continuous delivery.

As a project delivery framework, Agile helps address some of the disadvantages of waterfall. It would be very difficult, if not impossible, to implement DevOps using waterfall practices due to the practices of continuous integration, continuous deployment, and continuous delivery. This is one major reason why, in organizations that practice DevOps well, teams use Agile as a delivery method.

The Agile manifesto

In 2001, 17 people met in the Wasatch Mountains in Snowbird, Utah. Their aim was to discuss the future of software development. What followed was an agreement on the frustration of the current situation of software development, even if the group could not agree on how to resolve the situation.

The group agreed that organizations were too focused on planning and documenting their software development cycles, which meant organizations lost focus and sight of what was important: customer satisfaction.

Most organizations discuss corporate values such as excellence and integrity, but these values have done nothing to foster people toward a better way of working, especially software developers. This was something that needed to change. Several members of the Snowbird 17, as they came to be known, already had ideas about how to revolutionize software development and start a new era. This trip to the mountains was the group's chance to define this new era.

What came out of this trip was the Agile manifesto. At just 68 words, this short and sweet document changed software development forever. The publication of the 12 principles defined in the manifesto has arguably led to the biggest change in software development. In the two decades that have followed, these 12 principles have been embraced by individuals, teams, and organizations around the world.

Defining culture

The Agile landscape is cluttered with ideas that seem to take Agile and transform them into real-world scenarios. This isn't anything new, though; in fact, the manifesto was born out of the need to find some common ground between Scrum, Crystal Clear, Extreme Programming, and other frameworks.

One of the biggest goals of the Snowbird 17 was to see if the representatives of these frameworks could agree – they did. The agreement ended up as a set of values that define a culture.

The Agile manifesto defines the following set of values:

• Individuals and interactions over processes and tools
• Working software over comprehensive software
• Customer collaboration over contract negotiation
• Responding to change over following a plan

You can look at the full manifesto that came out of the meeting in the mountains on the Agile Manifesto website at http://Agilemanifesto.org/.

Another product of the summit was the 12 principles (https://agilemanifesto.org/principles.html), which adhere to these values. They expand on the preceding four sentences that make up the values.

These 12 principles are as follows:

• Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
• Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
• Deliver working software frequently, from a couple of weeks to a couple of months, with a preference for a shorter timescale.
• Businesspeople and developers must work together daily, throughout the project.
• Build the project around motivated individuals. Give them the environment and support they need and trust them to get the job done.
• The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
• Working software is the primary measure of progress.
• Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
• Continuous attention to technical excellence and good design enhances agility.
• Simplicity – the art of maximizing the amount of work not done is essential.
• The best architectures, requirements, and designs emerge from self-organizing teams.
• At regular intervals, the team reflects on how to become more effective, then tune and adjust their behavior accordingly.

Even if you had very little exposure to Agile and DevOps before reading this book, in those 12 principles, I hope you can see the connection between what we have explored so far and the principles of the Agile manifesto.

Do Agile and DevOps work together?

Agile and DevOps can sound like very different concepts. In fact, most people I speak to in the early stages of transformation are very confused by the idea of both. This confusion is also compounded as both have their own jargon and slogans. It is common for people to become frustrated with the plethora of definitions for DevOps.

Most people think that when you say Agile, you mean Scrum, and that when you say DevOps, you really mean continuous delivery. This simplification then creates tension between Agile and DevOps, to the degree that you would be forgiven for not realizing that Agile and DevOps are friends.

It was back in 2008, at the Agile Conference, that a session about Agile Infrastructure by Patrick Debois and Andrew Clay Schafer was undertaken, and the connection to DevOps was born. Patrick later coined the term DevOps, and the Agile Conference continues with a DevOps track to this day.

There is more to this than history, though. Now, let's look at the practical connections between Agile and DevOps by looking deeper than Scrum and continuous delivery.

Agile is more than Scrum

At the point when the limitations of the business or the work itself request something else, a deft group will use the basic standards of Scrum, review their practices, and adjust them to turn out to be more viable. This is especially significant when Scrum is applied external to the setting of programming advancement.

Dealing with unplanned work

In the DevOps people group, those with Agile experience recognize that Scrum is helpful for following arranged work. Some work in activities can be arranged: delivering a major framework change, moving between server farms, or performing framework overhauls. In any case, a large part of crafting tasks is spontaneous: execution spikes, framework blackouts, and traded off security. These occasions request quick reaction. There's no longer an ideal opportunity to trust that the things will be organized in excess or for the following run arranging meeting. Consequently, numerous groups that have come to grasp DevOps thinking look past Scrum to Kanban. This encourages them track the two sorts of work and causes them to comprehend the interaction between them. Then again, they embrace a cross-breed approach, frequently called Scrumban or Kanplan (Kanban with an accumulation).

From various perspectives, the way into Scrum's wide appropriation might be that it endorses no specialized practices. Scrum's lightweight administration rehearses frequently have a major effect on a group. Where there was once contending needs from different experts, there is currently a solitary arrangement of needs in the overabundance. What's more, where there was once an excessive amount of work in advancement, there is currently an arrangement that's obliged by what time has demonstrated is truly conceivable. In the mix, these can take a group higher than ever in terms of efficiency. Be that as it may, the group may wind up obliged due to the absence of specialized practices, such as coding audits, computerized acknowledgment tests, and persistent joining.

Other Agile cycles such as Extreme Programming have solid feelings about how specialized practices uphold the group's capacity to keep an economical movement and give straightforwardness and perceivability to executives and partners. Some Scrum groups resort to placing specialized undertakings in this overabundance. While that fits well for the direction of Scrum, it rapidly hits the handy issue of Product Owner inclination toward highlights. Unless the Product Owner is very specialized, she or he might not have the right stuff to assess the cost/advantage of specialized practices. That gets much harder for a Product Owner as the specialized assignments stretch into tasks to help unwavering quality, execution, and security.

What is Scrum?

Scrum is a system that assists groups with cooperating. Scrum urges groups to learn through encounters, self-coordinate while dealing with an issue, and consider their successes and misfortunes to constantly improve.

While the Scrum I'm discussing is most often utilized by programming improvement groups, its standards and exercises can be applied to a wide range of cooperation. This is one reason Scrum is so well-known. Regularly considered as a coordinated venture of the board system, Scrum depicts a bunch of gatherings, apparatuses, and jobs that work together to help groups structure and deal with their work.

Applying Scrum within your organization is no easy task and you will come up against a whole new set of terminology. Here is a short list, which is by no means exhaustive:

• Sprints
• Sprint planning
• Ceremonies
• Backlog
• Retrospective
• Standups

While Scrum is probably one of the most common frameworks in Agile, many others do exist. Kanban and Kanplan, for example, as we will discuss next, are useful for organizations that are new to Agile.

Kanban

Kanban is a well-known structure that's used to execute Agile and DevOps programming advancement. It requires continuous communication of work limits and provides a clear view of work which is planned, in progress, and completed.

Kanban works by placing work on a physical or digital board. This visualization enables you limit work in progress and maximize your efficiency, sometimes referred to as the flow of your teams.

Many people use a form of Kanban board for their everyday work. In fact, I know plenty of people who use one for everyday common tasks around the home. The board is split into various columns, and these columns define the different statuses of tasks.

Your Kanban board will also define limits around work in progress items, delivery points, and commitment points.

Kanplan

You may not have heard of the term Kanplan before. It is a mixture of methodologies, but something that may be right for your team.

Important note

When it comes to picking an Agile framework for your team, there is no silver bullet. Different methodologies in the framework have pros and cons based on many different parameters. Every team will need to determine which framework will work best for them when it comes to planning, tracking, and releasing software.

Kanplan combines features from both Scrum and Kanban. It is ideal for teams who want the ability to groom their backlog, but do not have the ability to work in sprints. It provides a great mix because teams cannot always apply the whole of Scrum, including sprints, but can quite easily work with Kanplan to start getting a better handle on their work, work in progress, their backlog, and the priority of the work in that backlog.

Mixing methodologies within organizations

There is nothing wrong at all with different teams adopting different methodologies of the Agile framework, mixing them together, and making it work for them. I've not worked with any organization who can simply lift something out of an Agile textbook and implement it in their organization.

Think of operational teams who cannot work with traditional Scrum, mostly because their work contains elements of unplanned work such as incidents. For them, Kanban works well as it puts no emphasis on planning. Think of a full DevOps teams working on a product within your organization. Here, the normal approach of Scrum would work for them as everything is within their control and they have no reliance on external teams.

Finally, think of engineering teams who want to be more Agile, but work with other teams who do not practice any level of Agile. This is a tricky situation as there is a need to be more Agile to deliver better quality but no appetite in the rest of the organization to adopt Agile methodologies. In this example, Kanplan would work well for them, giving them the ability to groom a backlog of work based on priority, then work in a Kanban-style board, which enables them to visually see work, work in progress limits, and work done.

This approach is a great starting point for teams who fit this description, and it will enable them to work toward a higher quality of work, integrating some of the technical methods of DevOps without needing the rest of the organization to follow suit.

Scaling Agile teams

Through what we've learned so far, we can see how implementing Agile in our organization can provide several benefits. However, organizations are bigger than individual teams, and you may have several teams working on one product. It is at this point that we need to understand how Agile can be scaled up to many teams within one organization. As opposed to implementing Agile at an individual team level, which is relatively easy, implementing across the organization is a real challenge.

Scaling Agile at an enterprise level requires that we adopt Agile concepts, as well as Lean-Agile at a functional level. This includes finance, procurement, HR, and sales, for example. At the enterprise level, Agile is practices being implemented across many teams and lots of engineers working in a portfolio manner.

Important note

Scaling Agile in the enterprise requires you to think functionally. So far, what we have explored is at a team level. To scale Agile, you must think of it as an organization-wide effort.

Netflix coined the phrase highly aligned, loosely coupled, and you can still see this phrase on their main jobs page. It describes a highly mature organization that uses Agile development across the whole enterprise.

Two models that are highly popular when it comes to scaling Agile at the enterprise level are the Scaled Agile Framework (SAFe) (https://www.scaledagile.com/enterprise-solutions/what-is-safe/) and the Spotify model for scaling Agile in the enterprise (https://www.atlassian.com/agile/agile-at-scale/spotify). Both are very popular, so let's look at them both in more detail.

Scaled Agile Framework

Taken directly from the SAFe website, this is the definition of SAFe:

''Scaled Agile Framework (SAFe) empowers complex organizations to achieve the benefits of Lean-Agile software and systems development at scale.''

The framework defines four core values:

• Alignment
• Built-in quality
• Transparency
• Program execution

SAFe is actually pretty broad and covers four primary areas: Agile development, lean product development, systems thinking, and DevOps. However, its core places more value on the four values described in the preceding list.

Alignment is needed to ensure you keep pace with changes that are happening fast, disruptive competitive forces, and geographically dispersed teams. Alignment is key in these scenarios since Agile teams are great, but strategy and alignment does not and cannot rest with opinions from all the Agile teams. Alignment comes from enterprise-level business objectives.

The larger the system, the higher the quality. There can be no argument as to the importance of quality, especially in large systems. Built-in quality ensures that every element in the overall solution reflects the quality that's required over the entire life cycle of development. You can think of this with Agile testing, behavior-driven development (BDD), and test-driven development (TDD).

Transparency stems from the fact that it is difficult to develop solutions. As things go wrong or do not go as planned, without a high level of transparency, the facts become obscure, and any decision-making process will not be based on actual data where the best decisions are taken. Building trust takes time, however, and transparency is a source of trust, which is provided at several levels through SAFe. Above all, none of this matters if the teams are unable to perform or deliver value on an ongoing basis. SAFe places a strong focus on working systems and the business outcomes. We know that while many organizations begin transforming with individual teams, they become frustrated as these teams then struggle to deliver more value reliably and efficiently.

Spotify model for scaling Agile

With a large number of globally distributed engineers, a key part of the success of Spotify is the company's approach to ensuring work is organized in a way that enhances agility. Throughout the journey that engineering teams at Spotify have gone through, this has been documented and shared with the rest of the world.

This model, now known as the Spotify model, is a people focused approach that focuses on autonomy for scaling Agile, with a strong focus on network and culture. Over the years, this has helped Spotify and many other organizations increase their levels of innovation and productivity by focusing on autonomy, communication, collaboration, accountability, and quality, but overall, delivery.

Important note

While commonly known as the Spotify model, it's not a framework. This is simply Spotify's view of how to scale Agile from both a cultural and technical perspective. It is one example of how to organize multiple teams in a product environment.

First introduced in 2012 (https://blog.crisp.se/wp-content/uploads/2012/11/SpotifyScaling.pdf), the model has been subject to much scrutiny from experts in the field. Upon inspection, it shows the radically simple way that Spotify has approached levels of agility. Since then, it's generated a large amount of buzz and became popular.

The overarching theme is the championing of team autonomy, and it has several ways of describing the structure of your organization. It does so by using the following terms:

• Squads
• Tribes
• Chapters
• Guilds

Squads are teams that are organized into Tribes, Chapters help subject matter experts keep in touch with each other, and Guilds are there to help people keep aligned across the whole organization, where Chapters enable you to keep together within a single Tribe.

Important note

Like any other Agile model, it's important to make sure that if you implement it within your organization, you have the feedback and transparency in place to generate and sustain a culture of trust and autonomy.

Now that we understand what role Agile has to play in DevOps, we know it's central to DevOps in so many ways and that it is vitally important if we want to succeed.

That concludes this first chapter. So far, we have introduced some terminology we will be using throughout the rest of this book and ensured you have a good foundational understanding of the main concepts of DevOps, the values it brings to your organization, the challenges it can help you solve, and looked at how Agile plays a part in DevOps.

In the next chapter, we will be taking a look at how the business benefits from DevOps, as well as looking at various team topologies you can use, depending on your structure, to achieve great things, as well as highlight some of the pitfalls of DevOps and how to avoid them.