Afterword

By Eric Crichlow, April 5, 2019

I can easily recall the first job I had where they decided to transition to Agile. That was in 2008 at a company that had been acquired by a larger corporation. It was undergoing significant changes to its policies, procedures, and personnel. I can also remember a couple of other jobs where an emphasis was placed on Agile practices. The rituals were followed religiously: sprint planning, demo, sprint review… At one of them, every developer in the company was put through two days of Agile training with a certified Scrum Master. As a mobile developer, they had me write a mobile app for playing Agile Poker.

But in the 11 years since my first exposure to Agile, I have also been at several companies where I honestly can’t remember whether they used Agile practices. Maybe that’s because Agile has become so ubiquitous that it’s easy to take it for granted and not even think about it. Or maybe it’s because there are still a significant number of organizations that haven’t adopted it.

At the time I was introduced to Agile, I wasn’t particularly enthusiastic about it. Waterfall may have its problems, but I was in an organization that didn’t spend a significant amount of time writing design documents. My life as a developer generally consisted of being verbally given a set of features expected in the next release, being given a date when the next release was due, and being turned loose to make the magic happen. While this could certainly lead to the dreaded death march, it also gave me the freedom to structure my activities the way I wanted to. It also kept me free of the frequent scrutiny and accountability of a daily standup meeting where I would have to explain what I had worked on yesterday and what I would be working on today. If I decided to spend a week reinventing the wheel, I was free to do so without having that choice judged by anyone because they were blissfully unaware that I was doing it.

A former Director of Development under whom I worked used to refer to us as “code slingers.” We just loved blasting away at our keyboards in the Wild West of software development. He was right. And to an extent, Agile practices represented the new sheriff in town that reigned in our maverick tendencies.

Agile had some work to do in winning me over.

It would be presumptuous to believe that Agile is the de-facto standard in software development houses or that all developers embrace it as something positive. Conversely, it would be naive to deny the significance of Agile in the world of software development. But what does that even mean? What, exactly, is its significance?

Ask the developers in an “Agile organization” what Agile is, and you’ll likely get a very different answer than if you ask anyone beyond the level of a software development manager. Perhaps that is where this book has been the most enlightening.

Developers understand Agile to be a methodology for streamlining the development process and for making software development more predictable, more practicable, and more manageable. It’s reasonable that we look at it from this perspective because it’s the perspective that most directly affects us.

Speaking from personal experience, many developers are blissfully unaware of management’s use of the metrics provided by the implementation of Agile practices and the data it produces. In some organizations, the entire development team participates in the meetings where these metrics are discussed; but in many others, the developers have no idea that these discussions even take place. Moreover, perhaps in some, those discussions don’t actually happen.

While I have long been aware of this aspect of Agile, I still found it enlightening to understand the original intent and thought processes of the founders of this methodology that this book provides. It was also good to see those founders humanized. They weren’t some set of ultra-elite software architects, ordained by the Software Engineering Masters or elected by the software programmer masses to hand down canon. They were a set of experienced developers with ideas about how to make their jobs, and their lives, easier and less stressful. They were tired of working in environments destined for failure and wanted to foster environments that allowed for success.

This sounds like most developers at every company where I’ve ever worked.

Had the Snowbird meeting taken place 15 years later, I could see it having been a number of developers with whom I have personally worked and myself, who convened that meeting and put those ideas to digital paper. But being just another group of seasoned developers, this group was prone to flights of fancy that might not play well in the real world of corporate software development. Maybe it all works as designed in the world of highend consultants with the authority to make demands and hold organizations and management to their commitments, but most of us are grunts, cogs in the machinery of software factories. We are replaceable, and we have very little leverage. So when it comes to things like The Bill of Rights, we understand that this is an ideal, but one that is not realized for the majority of us.

With the social media communities of today, I am heartened to see many new developers extending themselves beyond the boundaries of a CS degree and 9-to-5 development job, connecting with other developers around the world, learning in any number of different ways, and putting their own knowledge and experiences out there to teach and inspire other fledgling developers. I fully expect the next sea change in methodology to emerge from a digital gathering of these young up-and-comers.

So while we await the Next Big Thing that the next generation will reveal to us, let’s take a minute to reassess where we are and what we have to work with at present.

Now that you’ve read this book, contemplate it for a minute. Consider the aspects of Agile you may have known about but to which you hadn’t given much thought. Think about it from the perspective of the business analyst, project manager, or anything-other-than-dev manager responsible for planning releases or creating product roadmaps. Consider what value the input from developers into the Agile processes brings to them. Understand how your input into the process affects more than just your workload for the next two weeks. Then go back and skim the book again. If you approach it with this broader perspective in mind, I believe you will glean even more useful insights.

Once you’ve done that, encourage another developer in your organization to read it and undergo the same introspection. Maybe even hand the book to someone who, wait for it… isn’t a developer. Give it to someone on the “business” side of the company. I would almost guarantee you that The Bill of Rights is something they have never given much thought to. Your life stands to be much more pleasant if you get them to understand that these rights are just as integral to Agile as the metrics that they pull out of it.

You might say that Agile has become something akin to a religion in the realm of software development. Many of us have accepted it as a best practice. Why? For many, it’s because they’ve been told so. It has become tradition; it’s just how things are done. For a new generation of corporate developers, it just is. They, and even many of us old-timers don’t really know where it all came from, nor what the original goals, purposes, and practices were all about. Say what you will about religion, but the best adherents to it are those who make the effort to understand what they believe, beyond just believing what they are told. And as with religion, there isn’t one universally accepted, one-size-fits-all version.

Imagine the significance of having a view into the origins of your religion, an understanding of the events and thoughts that shaped what would become canon for you. When it comes to your professional life, that’s exactly what you have here. Use it for all it’s worth, evangelize it to the others in your sphere of influence, and reclaim the original goal, the goal you and practically everyone you’ve ever worked with have longed for, talked about, and probably given up on. Make successful software development achievable. Make organizational goals attainable. Make the process of making things better.