Preface

This book is not a work of research. I have not done a diligent literature review. What you are about to read are my personal recollections, observations, and opinions about my 20-year involvement with Agile—nothing more, nothing less.

The writing style is conversational and colloquial. My word choices are sometimes a bit crude. And though I am not one to swear, one [slightly modified] curse word made it into these pages because I could think of no better way to convey the intended meaning.

Oh, this book isn’t a complete rave. When it struck me as necessary, I cited some references for you to follow. I checked some of my facts against those of other folks who’ve been in the Agile community as long as I have. I’ve even asked several folks to provide supplemental and disagreeing points of view in their own chapters and sections. Still, you should not think of this book as a scholarly work. It may be better to think of it as a memoir—the grumblings of a curmudgeon telling all those new-fangled Agile kids to get off his lawn.

This book is for programmers and non-programmers alike. It is not technical. There is no code. It is meant to provide an overview of the original intent of Agile software development without getting into any deep technical details of programming, testing, and managing.

This is a small book. That’s because the topic isn’t very big. Agile is a small idea about the small problem of small programming teams doing small things. Agile is not a big idea about the big problem of big programming teams doing big things. It’s somewhat ironic that this small solution to a small problem has a name. After all, the small problem in question was solved in the 1950s and ’60s, almost as soon as software was invented. Back in those days, small software teams learned to do small things rather well. However, it all got derailed in the 1970s when the small software teams doing small things got all tangled up in an ideology that thought it should be doing big things with big teams.

Aren’t we supposed to be doing big things with big teams? Heavens, no! Big things don’t get done by big teams; big things get done by the collaboration of many small teams doing many small things. This is what the programmers in the 1950s and ’60s knew instinctively. And it was this that was forgotten in the 1970s.

Why was this forgotten? I suspect it was because of a discontinuity. The number of programmers in the world began to explode in the 1970s. Prior to that, there were only a few thousand programmers in the world. After that, there were hundreds of thousands. Now that number is approaching one hundred million.

Those first programmers back in the 1950s and ’60s were not youngsters. They started programming in their 30s, 40s, and 50s. By the 1970s, just when the population of programmers was staring to explode, those oldsters were starting to retire. So the necessary training never occurred. An impossibly young cohort of 20-somethings entered the workforce just as the experienced folks were leaving, and their experience was not effectively transferred.

Some would say that this event started a kind of dark ages in programming. For 30 years, we struggled with the idea that we should be doing big things with big teams, never knowing that the secret was to do many small things with many small teams.

Then in the mid ’90s, we began to realize what we had lost. The idea of small teams began to germinate and grow. The idea spread through the community of software developers, gathering steam. In 2000, we realized we needed an industry-wide reboot. We needed to be reminded of what our forebears instinctively knew. We needed, once again, to realize that big things are done by many collaborating small teams doing small things.

To help popularize this, we gave the idea a name. We called it “Agile.”

I wrote this preface in the first days of 2019. It’s been nearly two decades since the reboot of 2000, and it seems to me that it’s time for yet another. Why? Because the simple and small message of Agile has become muddled over the intervening years. It’s been mixed with the concepts of Lean, Kanban, LeSS, SAFe, Modern, Skilled, and so many others. These other ideas are not bad, but they are not the original Agile message.

So it’s time, once again, for us to be reminded of what our forebears knew in the ’50s and ’60s, and what we relearned in 2000. It’s time to remember what Agile really is.

In this book, you will find nothing particularly new, nothing astounding or startling, nothing revolutionary that breaks the mold. What you will find is a restatement of Agile as it was told in 2000. Oh, it’s told from a different perspective, and we have learned a few things over the last 20 years that I’ll include. But overall, the message of this book is the message of 2001 and the message of 1950.

It’s an old message. It’s a true message. It’s a message that gives us the small solution to the small problem of small software teams doing small things.