February 2021 marks the 20th anniversary of the signing of the Agile Manifesto. Follow along as we reflect and look to the future.
“Extreme Programming turns the conventional software process sideways. Rather than planning, analyzing, and designing for the far-flung future, XP programmers do all of these activities—a little at a time—throughout development.”
– Embracing Change with Extreme Programming, Kent Beck, Oct 1999
I remember it like it was yesterday. I was searching for something related to software engineering and stumbled across a paper on Extreme Programming (XP) by Kent Beck. The year was roughly 2000 and what I read rocked my world.
Which paper it was has been lost to time, but I know Kent’s Embracing Change with Extreme Programming article was in the October 1999 edition of IEEE Computer Magazine. I was a subscriber at that point, so that’s likely where I saw it.
As I read this article, I almost jumped out of my chair! What I read was the description of a radical software process that aligned perfectly with my thoughts on how software should be built. While there were definitely some new concepts introduced in the article—like pair programming and test-driven development—the overall philosophy hit home in a big way.
This was probably because in a previous job I had the unfortunate task of building software following a very structured, documentation-heavy software process. It was as Waterfall as Waterfall could get.
I wanted to build great software and get it into the hands of customers as fast as possible, but instead I spent most of my time writing documentation that nobody read, creating features users would later tell me they didn’t really need, and sitting in review meetings discussing whether the software design we had was complete. In the end it was an unrewarding, unproductive, and inefficient way to create customer value.
While everything I read in Beck’s XP article resonated with me, there were a few specifics that really hit home.
Embracing change
Fundamentally, agile is about how to best embrace change. Traditional software development approaches try to control change, freeze change, or at least manage change—all of which we know aren’t possible. At that time, optimizing your Waterfall software process was all the rage. The thought was that by squeezing more efficiency out of each step in a Waterfall process, we could avert software disasters.
Instead, XP (and soon, the entire agile movement) believed that change needed to be embraced. It was going to happen with our without us anyway! Instead of trying to control change, agile says we need to expect and embrace change by making the cost of change as small as possible so we can afford to make changes when change happens. What a revolutionary idea.
Developer testing
XP emphasizes that developer’s must test their own code. The company I was running when I read this article on XP was a software assurance consulting company, and we always pushed for developers to do a better job unit and component testing as part of the development process. However, getting developers to test their own code was always a struggle.
While XP did not adequately define how to perform integration and system testing (other than suggesting that customers do user acceptance testing) it made logical arguments for while professional software development must include testing, and that was a game changer for the software industry in terms of building quality software.
Working code as the measure of progress
The concept that fully working code should come out of very short iteration of work was profound. No longer could teams spend eons of time generating paper deliverables and misleading themselves in thinking they were making tangible progress.
In XP the mantra is “No code, no progress!” This philosophy forces software to be built incrementally while making sure customers are on board with what is being produced. And this need to build working software rapidly also led to significant advances in automation of the software process, including the establishment of continuous integration as a core software capability.
Happy 20th Anniversary Agile!
When the Agile Manifesto was first published in 2001, I smiled. Even before looking at the authors, it was obvious how much Kent Beck and XP had influenced the agile values and principles. So many of them were tied directly to his work in Extreme Programming. Fast forward seven years and I felt strong enough about these principles to found a company that helps organizations improve their agility and delivery capabilities.
