Agile in software development primarily means that the customer must feel that you can move immediately.
To be able to deliver results quickly, guaranteed quality is essential. You must make sure that nothing you change breaks existing functionality.
However, if you try to insure your quality by adding release regulations and code review procedures or by increasing formalities by making someone into a release manager, this defies the agility goal. A two minute fix of a bug becomes a two week ordeal.
Instead, you should ensure quality through automated testing. Continuous integration tools never get tired of running the same tests over and over again. They are always available when you need them, never make mistakes, and are fast. They are the agile quality guarantee.
There are two ways of car navigation: non-agile and agile. Non agile navigation is when you take a sheet of paper with you with instructions like this:
Drive 5km. Take a left. At the third light to the right, then before the blue building to the left. Stop when you arrive at a gas station.
Non-agile navigation works fine if there is a path to the destination that is well known, and where you can't make a mistake. If anything changes on the path, if there are roadworks, if you make any mistake along the route: there is no contingency; it will be impossible to reach the destination. Furthermore: If there is nobody around that has been to the same destination (even several times), it will be impossible to get a detailed description of the route.
Agile navigation is using road signs. To get to the San Francisco Museum of Modern Art, you first follow signs to California, then San Francisco, and when you arrive there, you follow signs for SFMOMA. The only thing you need to know is where you're going, and roughly where that is (recursively, if you want). This method of navigation is very robust: even if a street becomes a one-way street, or if the blue building is torn down, you will still be able to get to your destination. What's even better is that if, along the way, your exact goal changes, you will still be able to change your plans. On your way to San Francisco, you may still decide that you want to visit the Golden Gate instead.
Now, of course, I am not trying to teach you how to navigate a car. I just want to use this as a metaphor for the development of software.
How is software development like navigation? You normally do not exactly know what you need to develop. And only rarely can you exactly follow the tracks of somebody else. Software development is not like the known path that is suitable to non-agile navigation.
Nevertheless, a lot of software is still developed using non-agile methods. Specifications are fixed completely before the development is started. The exact steps required are written up in detail. Contracts are signed. And then road blocks occur, and the project goes over budget and falls behind schedule. And when the project is delivered, the customer is not happy with the functionality because either his ideas have changed, or he has not been able to express himself accurately enough in the specifications.
Agile software development has all of the advantages of agile navigation. You can go to unknown places. You can even change the details of your plans along the way. And it is very robust against unexpected road blocks. It is clearly the right choice.
Agile software development is not easy. But it is less prone to utter failure than the traditional method. Let's learn to navigate on the road signs!
One of the first stages in the development of a new tool (software or hardware) is a functional specification. The functional specification matures in discussions between the developers (department of R&D) and the customer representatives (often the departments of marketing and sales).
Of course a functional specification is useful: it is very hard to develop something new without an idea of how the new tool will be used and what it will be compared with. However, defining a functional specification can also be taken too far. In some organizations, the functional specifications are spelled out in the tiniest details. At the end of a long formal procedure, the book of specifications is signed like a contract between marketing and development. The development can only be started when the list of signatures is complete and will be performed in splendid isolation from the world of potential users. Why do organizations do specifications this way? It is often an attempt to separate the responsibilities of the departments, so that if anything fails the appropriate party can be blamed. If the final product does not meet the functional specifications, this can be blamed on the developers. And if the product does not succeed even though it meets all the functional specifications, this will be blamed on marketing.
I have a serious problem with this approach: using this procedure, how can one ensure that the product will be useful? After two years without interaction, development may produce exactly what marketing asked for (making all deadlines and within budget), but the market has changed and does no longer need the designed product. Or technology has changed, and better specifications would have been within reach and are offered by the competition. Or maybe marketing truly made a mistake, and asked for something the world is not waiting for. In these cases, clearly the development department can not be blamed! But if you develop an obsolete product this way, where does that leave the organization as a whole? And if this is not the best solution for the organization as a whole, will it be good for the development department? Even though everyone did exactly what was expected, people may be laid off because development costs can not be recovered.
The solution is, as often, to keep a middle road. Using e.g. Agile or LEAN development methods, developers can stay in constant communication with marketing. Iterative and modular design procedures can be used to verify that the new tool does what it should, without relying on the capacity of people to describe specifications in words beforehand. And because the communication with the market is not lost during the development process, the tool will have a significantly higher chance of actually being useful at the moment of introduction.
Image (by QuiteLucid on Flickr): "a camel is a racing horse designed by a committee".