DevOps Overture

What You Need to Know When Starting a DevOps Journey

Shawn D Doyle

• Publisher: ReleaseTEAM Press
• Year: 2020
• eBook ISBN: 9780578625812
• Topic: Computer Science
• Subtopic: Computer Science General
• Index: Computer Science

The new culture of software development, explained by a 30-year industry veteran.

Over the last decade, more and more companies have adopted a new approach to software development called DevOps. But few people seem to understand what DevOps is—or how they might fit into a DevOps environment.

DevOps Overture answers these questions. It begins with an overview of what software development methodologies came before DevOps and of the problems associated with those systems. It then explains what DevOps is and how it works to address these problems. Finally, it offers advice to anyone who wants to position themselves for a career in DevOps and warns of common pitfalls to avoid.

Maybe your company has adopted DevOps, and you need to adjust to an Agile culture. Or perhaps your company hasn’t adopted DevOps, and you want to either advocate for the change or to position yourself to switch to a company that has. Or maybe you want to become conversant in DevOps practices. Either way, DevOps Overture is for you.

Shawn D. Doyle is a founder and CEO of ReleaseTEAM, Inc., a DevOps Consulting Firm, established in 1999. After serving in the US Army and Desert Storm, he has amassed nearly 30 years of software delivery experience, having worked with companies from midsized to Fortune 100 to solve their business-critical challenges. Shawn lives with his wife and three dogs in Colorado.

Software is everywhere. DevOps makes better software. Here is where you start.

1

CHAPTER

Before DevOps

“If you don’t have a competitive advantage, don’t compete.”

–Jack Welch

In This Chapter:

•The Waterfall Model

•Problems with the Waterfall Model

•Responses to the Waterfall Model

All organizations need some type of competitive advantage to survive. Often, the source of competitive advantage is quick time to market. Sometimes it’s an ability to innovate or to learn and to act on that learning. Or maybe it’s teamwork—like how a good pit crew provides a competitive advantage in an automobile race. Or it could be a positive organizational culture. And so on.

Oddly, few companies exploit these sources of competitive advantage. If anything, they do the opposite. They’re slow to market. They don’t innovate, or learn, or act on their learning. They impede teamwork. They create a toxic organizational culture. You get the idea.

Why do companies do this? Well, there are lots of reasons. But one of them is that most companies are mired in old, outdated ways of working.

This chapter explores the most prevalent old-school approach to working, called waterfall, and the problems inherent in this model. This chapter also covers various work models that attempted to address waterfall’s problems: the Toyota Production System (TPS), total quality management (TQM), incremental and iterative development, Lean, and Agile. Aspects of these models formed the basis of DevOps, so it’s good to know a little bit about them.

The Waterfall Model

For decades, countless organizations, including software companies, have employed a workflow model called waterfall. This process-intensive model breaks development activities into a series of phases that are completed one at a time and sequentially. Each one of these phases cascades into the next (hence the name).

For software development, the phases of the waterfall model are roughly as follows.

1.REQUIREMENTS: The product team documents in broad terms what the software product or feature will do.

2.DESIGN: Adhering to the requirements set forth by the product team, the design team designs the product or feature and indicates which tools and technologies to use to build it.

3.DEVELOPMENT: Using the tools and technologies specified by the design team, the development team builds the product or feature.

4.TESTING: The development team passes the product or feature to the quality assurance (QA) and information security (infosec) teams for testing. This phase often reveals bugs and security flaws that require additional design and development to correct—time permitting.

5.DEPLOYMENT: When the development team deems the product or feature ready for release, the operations team deploys it to a live environment.

6.MAINTENANCE: After the product or feature is deployed, the operations team maintains it. That can mean, for example, patching it to address bugs or security flaws or updating it to include new features.

NOTE

The phases listed here may deviate depending on the project or organization, but in general, they apply.

Problems with the Waterfall Model

Although widely used, the waterfall model presents serious problems for software development—problems that rob companies of their competitive advantage.

Here are just a few problems associated with using the waterfall model for software development, which are discussed further in the following sections.

•The development cycle takes too long.

•There’s a lack of timely feedback and learning.

•Teams become siloed.

•It creates a toxic organizational culture.

•It stifles innovation.

NOTE

Did you notice how this list of problems is basically the opposite of the sources of competitive advantage described in the first paragraph of this chapter?

When Waterfall Works

Waterfall is not all bad. It offers considerable control over the development cycle and can result in a more predictable product outcome. In some scenarios, it works very well. For example, suppose you just won a ten-year government contract to build a spacecraft. You need to be absolutely certain you deliver exactly what the contract calls for, and you have zero market pressure to account for. In this case, waterfall might be the right model for you! But when a large project calls for agility in the face of market pressure, an Agile approach will likely work better. To borrow from economist Robert S. Ellinger, waterfall worked to get us to the moon, but it took Agile to build the airline industry.

Long Development Cycle

Because the waterfall model requires software teams to complete one phase of a project before advancing to the next one, the design team can’t start work until the product team wraps things up; the development team can’t start until the design team is done; and so on. This approach results in delays. Lots of them.

Frequent handoffs from one team to another compound these delays. Handoffs often result in work queues, which inevitably add time to the process. Short queues might be somewhat manageable, but long queues? Not so much. When a work queue becomes too long, a bottleneck forms. (A bottleneck is any point in the system that stems the flow.) This bottleneck slows the flow of work, adding more delays.

NOTE

Think of an automobile assembly line. If the station in charge of welding the frame falls behind, a bottleneck forms that starves every station after it of work. The same thing happens with software development.

Because of these delays, development cycles and lead times in the waterfall model tend to be very long—months or perhaps even years. These long development cycles have critical consequences:

•MISSED MARKET OPPORTUNITIES: By the time a product steps through each phase of the waterfall process and is released to market, the market may already have moved on.

•LACK OF AGILITY: Long development cycles make it impossible to react quickly to new market information.

•ADDED RISK: Organizations that operate on a long development cycle must invest hefty sums up front that they might not recoup—for example, if the bottom of the market for the product drops out two years into a four-year development cycle.

•DEATHMARCH DEPLOYMENTS: In the waterfall model, because deployments happen all at once at the tail end of a long development cycle, they tend to be complex, cumbersome, and error-prone, and last for hours or even days. Also, they often occur during off hours—nights and weekends—to minimize their impact on users. This places a significant burden on the operations teams who perform these deployments (not to mention their families).

Lack of Timely Feedback

Because the waterfall development cycle takes so long, it might be months before a designer or developer receives feedback on their product or feature from the QA and infosec teams downstream. Customer feedback takes even longer.

There are serious ramifications to this lack of timely feedback—especially when the feedback is negative. One is that designers and developers don’t really learn from it. Think about it: Do you remember the thought process behind every decision you made six months ago? Neither do designers or developers. So, when they find out that some product or feature they worked on way back when doesn’t operate as planned, odds are they’ll have little to no idea why, or how best to fix it. (Of course, all this assumes the designer or developer still works for your company. Given how quickly people jump from job to job, this might not be the case!)

More importantly, a lack of timely feedback—specifically, customer feedback—reduces the chances that the software or feature will succeed in the marketplace. Here’s why: Research indicates that between 60 and 90 percent of ideas for software products, features, or anything else are awful. Even ideas that seem amazing often deliver zero or negative value....

Table of contents

• Cover
• Title Page
• Copyright Page
• Dedication
• Acknowledgments
• About the Author
• Table of Contents
• Introduction
• Chapter 1: Before DevOps
• Chapter 2: DevOps to the Rescue
• Chapter 3: Maximizing Flow
• Chapter 4: Obtaining Fast Feedback
• Chapter 5: Fostering a Positive Learning Culture
• Chapter 6: DevOps Roles
• Chapter 7: Positioning Yourself for a Career in DevOps
• Chapter 8: Steering Clear of Common Pitfalls
• Conclusion
• Appendix A: DevOps Resources
• Appendix B: Tools for DevOps Success
• Appendix C: Glossary
• Index