On 14 April 2010 a small volcano erupted in Iceland, and before people could even pronounce the name Eyjafjallajökull, all air traffic in Europe was paralyzed. I was lucky. The eruption caught me while I was at home, and although my wife was happy about me being home for a week, my client was not happy about my absence. It hit friends of mine worse, some of whom were on stuck on trains from Lviv to Amsterdam for over 48 hours, or my friend, a flight attendant for Swiss Airlines, whose flight was stranded somewhere and whose pilot missed his own wedding.
I call it the Volcano principle. Time and again things happen that are beyond our control, but which still affect us. Things you need to react to us. We do not know when they will happen, we do not know what will happen. Some of us do not even want to admit that such things happen, and then are surprised by events. Others are more agile.
We value: Responding to change over following a plan
In business, as elsewhere, there are no closed systems. We never know when and where volcanoes (which we had never noticed before) will erupt. It may be that our customers have new requirements. It may be – and it is often the case – that our competitors bring something new to the market. It may be that politicians pass new laws that we have to take into account in our applications. Volcanoes lurk everywhere. Either we respond to them or we are out of the market.
Over the course of the last decade, a soft revolution has taken place in the field of software development. Experiences with projects delivering late and over budget have led people to question some of the basic tenets of software project development and management. Starting with a few provocative theses in Kent Beck’s 1999 book eXtreme Programming, the field of so-called Agile software development has grown to be a major force in the socio-economic arena of delivering quality software to people on time, on budget, and on spec. The acceleration in changing needs brought on by the rise in popularity of the Internet has helped push Agile practices far beyond their original boundaries, and possibly into domains where their application is not the optimal solution to the problems at hand.
So, where do Agile software development practices and techniques make sense, and where are they out of place? To answer that question, it is necessary to first understand how, and more importantly why, Agile practices work. In the mid 1990s, it was maintained that practices such as eXtreme Programming could not possibly work, although even then dozens of projects successfully completed had proved otherwise. Later, after sufficient empirical evidence had accumulated to irrefutably prove that Agile practices do work, the question of why they worked still remained.
How much are you prepared to throw away?
When I was working with Kent Beck back in the “early days” of the agile movement, we spent much time trying to explain to people what we were trying to do, and what the ideas behind eXtreme Programming (XP) were. Kent often used the metaphor of driving. This was always entertaining, because not only did Kent tell some horror stories from his first driving lessons with his father, but also because driving a car was well suited as a metaphor for many XP ideas, principles, and techniques. Driving as an example of test-driven development (the tests are your eyes), as an example for cost estimate is (is how far it is the goal, often answered as time and distance), or as an example of the adaptation to constantly changing conditions (driving isn’t only stubbornly pressing on the accelerator, but rather constantly adjusting, faster, slower, a bit left, right a bit, etc.). In this sense, driving also shows the problems that arise when you go strictly follow directions to your destination. As soon as you hit a site where there is a traffic jam or an accident, your plan becomes worthless. Kent’s saying “Embrace Change”, or the line in the Agile Manifesto about “Responding to change over following a plan” reminds us that, yes, we should focus on the most important goal: that we do not stubbornly follow a plan, but rather that we reach our destination safely. Agility asks us to answer the question: What do you want – the implementation of a first specification or a successful project, because the two will never be the same? The agile approach, reminds us that there will always be sites or volcanoes – so we should look at them as the norm, and not as exceptions to be processed by means of change requests. Instead, we should Embrace Change – we should expect from the outset that changes take place, and build our process accordingly.