Also the words "IT Revolution" are on the front of the book, so if you don't read carefully you might end up holed up with a bunch of guns in a remote wildlife sanctuary.
The advice in this book was very successful at HP and Macy’s, two lumbering tech giants who are still relevant in this day and age, dammit.
Some organizations use Agile and DevOps to make software faster than you do. This is probably what Google, Amazon, and Facebook are doing, but Google, Amazon, and Facebook don’t produce all of the software. (yet).
Did you know that software is important? Hands up if you haven’t yet noticed that software is stupid important in every industry now. You, you, and you - with your hands up. Please leave. There is nothing for you, here.
You are bad at making software. Yes, you, large traditional organizations. You use SAP software to manage your payroll, you have 11,000 employees, and your projects always take at least 2 years and at least 5 million dollars. You know who you are. Most of your software either can’t survive without an enormous sales team or was purchased from a different company that also had an enormous sales team using an RFP process that involved no less than three separate acts of inconceivable depravity and a game of golf. Somehow you’re having trouble competing with companies that can make good software with 6 guys and a Foosball table.
Some of your employees tried agile, but the inherently poisonous and change-resistant nature of your thick bureaucratic miasma killed everything they tried. They couldn’t get buy-in from 18 different departments without a F-923 Schedule, Project Plan and Budget Breakdown that successfully navigated the 4 Goalposts of Project Innovation Success, and they gave up and went back to doing things the same way as the rest of the company. So instead of telling you how teams can be agile, we’re going to tell you how whole companies can be agile.
Using the techniques in this book, some people at HP made some bad concrete numbers go down, and also some good imaginary numbers went up - by 35%!
We found that the techniques didn’t make teams any more productive. How could it? They’re already working 8 hours a day, 5 days a week. It’s not like they weren’t working before. Instead, our whole organization has stopped communicating entirely via poorly-worded design documents and day-long-meetings, resulting in a massive decrease in miscommunication and day-long-meetings.
In Chapter 2, we will dissect The Waterfall Method - a model first introduced to the world in 1970, in a paper by Winston Royce that explained that it was a terrible idea and how to avoid it. Somehow, despite being a prominent example of failure from its very inception, it still managed to become the dominant ideology in megacorp software design, because large corporations are very, very inefficient.
Why are you doing this? Are you a trend-follower? Are you just “doing Agile”? Make this change to your organization, not because it is trendy, but because we told you that it is good and we are very trustworthy.
In Chapter 3, we’ll tell you, executives, how to lead the transformation. (If you have been handed this book by an executive, you should probably skip chapter 3, to keep the surprise alive.) You’re going to start by putting in place business objectives and a continuous development process.
Watch out, executives! While you’re doing this, some of the numbers might not go up right away! You might need to manage by something other than sheer metrics. We know it’s hard to pay attention to what’s happening in your company when there’s golf and cocaine out there, but please do, at least during this transition! Golf and cocaine can wait! It will take years of effort. Laying out what you’ll be doing in those years of effort? That’s right, Chapter 4.
HP has enough employees that if the entire city of Saskatoon decided to leave abruptly for a hockey tournament, HP could provide a replacement for each person in the town and still have enough people left over to fill a stadium. For the sake of sanity, instead let’s imagine we have 100 people.
Here are some key buzzwords for this chapter, accompanied by clip-art:
- Business objectives
- Enterprise-level Continuous Improvement
- Applying DevOps Principles at Scale
- Planning & Prioritized Backlog
Once you’ve captured business objectives and continuous development in your Pokemon collection, you’re going to need to go into the tall grass and collect some Agile and DevOps principles.
Understand that software is not the same as manufacturing wallets or whatever the fuck it is that you do. Software is different every time you make it and you usually fail at it because you are terrible. Most of the planning you do will be wasted. In Chapter 5, we’ll talk about how to do planning anyways, but way less often.
Once you do have working software, you probably have to keep it from falling over when somebody looks at it too aggressively or by sneezing in your data center. Most organizations treat these symptoms with manpower, constant panic, and by being super averse to change. We think we can do better, and we’ll talk about how in Chapters 6-11. Your employees are too stupid or unmotivated to fix this on their own, so it’s on your shoulders, suit-wearing executive stud man.
Years of working in unlit caverns and getting beaten by sacks of doorknobs will have rendered your employees sad and fearful, so the biggest change you’re going to have to make is convincing your employees that change is not to be feared, and almost nobody will be sacked.
We’ve talked a lot about changes while imparting almost zero actual knowledge of the process we plan to put in place, and we’re almost out of time in this chapter, so let’s cram it all into one paragraph:
“Developers create a stable trunk in a production-like environment as Job #1. Developers and Operation teams use common tools and environments to align them on a common objective. The entire organization agrees that the definition of done at the release branch means that the feature is signed off, defects-free, and the test automation is ready in terms of test coverage and passing rates. The organization embraces the unique characteristics of software and designs a planning process that takes advantage of software’s flexibility.”
Pow. We should have put that on the cover. We could have saved everyone a lot of time.
Anyhow, let’s start this book.