Are we forgetting our history?

Ok, before anyone panics, this is not a political post. We get enough of those already. I want to talk about where we are in the Agile world in general, and software development in particular. I have been watching many organizations over the past few years, and I can honestly say that I am concerned about the directions we are headed.

As I'm sure you were all expecting from the title, lets start with the de rigueur quote from George Santayana: "Those who cannot remember the past are condemned to repeat it" (The Life

of Reason, 1905-1906). Depending on how you choose to calculate it, the Agile movement is around 20 years old. Some would say older, since the proto-Agile movement just didn't have a name, some would say younger since the manifesto wasn't published till 2001, but lets just go with "around" twenty years. Disclaimer: I am going to provide a summary of my recollection of "our history". Like most oral histories, its based on my memory, so it might be flawed, and it surely doesn't cover all of the details.

So, lets get in our Way Back Machines and look at where we came from. Somehow, in the early days of the current era of software development, we were in a tough spot. When I say current era, I am specifically

referring to the early nineties to present. This was an expansive era when software started to become truly ubiquitous, and the software we were writing became widely available, and subject to the whims of a larger consumer audience. These were heady times, but also risky. Software was going out that was bug-laden and the conventional wisdom was that much of what we did was haphazard. Hence came terms like "cowboy coding". So, what did we do? We decided that this wasn't cool and that were were Software Engineers. We introduced a bunch of processes in order to "Assure Quality" by testing everything after it was written.

But guess what? We still were putting out less than awesome software. But at least now we hade project management processes that would ensure we had a plan. And estimates that would tell us when everything would be done. And project managers to ensure that the programmers...sorry, Engineers... worked their collective butts off to stick to the plan. So now, not only were we delivering buggy software, but we were delivering it "late". "Late", of course is defined as after the imaginary time that people optimistically decided something should be done, based solely on the evidence of a guess as to how long each of the parts would take. This wasn't cool. Something needed to be done. People started arguing about what ceremonies and processes should be added to make quality better. Or maybe what we needed was a more rigorous application of phases and timelines. If we had complex branching structures, and delivery playbooks, and Gantt charts to help us see how far behind we would be. Then add some more meetings and motivational posters about hard work, we could do this. And...things got worse.

Meanwhile, a few folks said "wait, that still doesn't work". They decided to try something different. We've found certain practices that work, even within those high ceremony, low flexibility environments. What if we do those, and remove all that ceremony, leaving time for developers to make software. We will weave testing throughout the development, not at the end. We will make changes often and without a lot of ceremony. This requires us to make better and more flexible software, but that is what we want to do anyway. But mostly, lets not do anything that gets in the way of making working software. Only write documents that support the working software. Stop all of the ceremonies that don't

specifically help make working software. And focus on enabling the team through empowerment rather than exhortation and fiat. Funny thing happened: It worked! People were enjoying work. I had programmers thank me for helping to make programming fun again. Products might not have been coming out faster(I haven't done any research to confirm or deny if Agile speeds up actual delivery) but they were coming out better. People who were trying it were successful and happy. So they wanted to share. Books were written, conferences convened, and...yes...certifications created. An entire industry was created of consultants helping others learn what we had learned.

Then something strange happened. People started asking for specific rules and structures on how to "do agile". If you weren't doing x/y/z, you were Doing It Wrong. This was followed up with an ever growing list of ceremonies we should have. One of the early, major focuses of Agile was that teams ought to be small. So someone said "we are An Enterprise, we need Big". So Big Frameworks were created, with even more ceremonies, and official ways to "do estimates" and timelines based on these estimates.....

And so here we are, back where we started. Now what? The optimistic side of the Santayana quote can be inferred that if we *do* remember our history, we can avoid the mistakes. I personally think the best response to the project management overload that is trying to take over is the

Modern Agile movement. Mostly, we just need to get back to remembering what made Agile work in the first place. It wasn't a set of practices, although there are some good ones out there. It wasn't A Framework. It was a simple set of four values and twelve principals, that when applied creatively help create a happier, safer workplace, and awesome software. Lets commit ourselves to remembering that, and focus our energies in that direction. Who knows, maybe we can make programming fun again?