Agile Complexities

I spent all of last year attending local (Johannesburg, South Africa) seminars, public lectures and summits on agile work for the South African professionals. A lot is happening in the agile world in our country today. In fact so many practitioners are crossing the chasm at an exciting rate. Towards the end of last year (2008) I presented a lecture on a brief overview on agile development to development managers at a Microsoft developers breakfast. The organizers were rather prescriptive of what was to be presented. The majority of the delegates were quite impressed by what agile has matured into and the level of interest in South Africa. To those who had already bought into agile and were looking for more graphic hints on the adoption processes and experiences my presentation might have been disappointing. If you are interested in the real stuff that is happening in agile South Africa then attend the Agile Forum details can be found from www.jcse.org.za. What I found interesting from the other presenters is the extent to Microsoft has adopted agile development into their MSF. I learnt about some very useful tools that they have developed for agile development.

Agile Confusion

I have noticed over the years that no matter how much agile development people are involved in they still get entangled into arguments about the following issues:

• Which agile method is better than others
• Everyone seems to be doing the same thing but calling it different names

After more than six years of serious research in agile software development I can authoritatively say that agile methodologies did not start out as a group. They started through isolated simultaneous efforts of innovation by practitioners who were frustrated by the heavy linear process of the 70s to the early 90s. It was mostly practitioners who were in love with coding but did not like the processes they were forced to follow. So they came up with what was practically possible for them to do. Hence when they met to form the Agile Alliance it was based on what all present (at that time and place) had come to value as the best way to practice software development. You see now, the similarities among the various agile methodologies are what gave birth to the Agile Manifesto. They have to be similar; it is a virtue in the agile world.

The good thing though, is that similar as they are they are based on different models of reality. What I mean is that Lean Software Development for example looks at software development from the eyes of a production factory and simulates software development using the world’s best manufacturing process (Lean Manufacturing). Scrum on the other hand views software development from a Control Engineering perspective i.e. the concept of empirical processes. Without even going into the details of all the agile methodologies you can see that the real-life metaphor is different but the goals are similar, hence the similarities. The names are different but the work is similar, it is this similarity that led to an agreement to put these methods under a single group.

Why do I believe there is no complexity in practicing agile development despite the similar values, principles and practices? Well, once again based on detailed research, it has been found that these methodologies are complimentary and not conflicting. So you can use them in combination to get the best results. For example most people who use Scrum combine it with XP etc.