Ok, here’s the situation. There are many ways to develop software. Some of them are generally recognized as being good, some of them are generally recognized as being bad. However there are no absolutes. There are no 12-step programs for successful software development. Sorry to break it to those of you who have zealously attached yourselves to this methodology or that methodology, but nothing, and I mean _nothing_ is guaranteed in software development. There are too many technical, social and political issues which differentiate every single software development effort to even be able to come close to defining the “right way” of developing software. That’s my first point.
My second point is regarding the naming of agile development. “Agile” was a good word to use when agile started, but from what I’ve seen, agile development has become considerably less agile as it has grown. Just like methodologies of yesteryear, certain processes that fall under the umbrella of “agile development” are advertised as the be all and end all of software development. These techniques and processes are apparently the only “right way” of developing software and if you believe some of the propaganda, those of us not embracing all the processes fully will soon be heading for the 6th circle of hell. Take pair programming and daily stand-ups for example. Some people claim they are great and that they always produce success. But I’ve seen software developed extraordinarily successfully without either. So they are definately not a requirement for success. In the case of daily stand-ups I’ve more often than not seen them fail to be useful at all, even though in one case they were being implemented “by the book”. They ended up just being a waste of my time. I didn’t learn or contribute anything useful or that I couldn’t have figure out or contribute in other more efficient ways. I’ve also done pair programming on a limited basis and really it was nothing to write home about. It was an okay experience which produced okay results. It was more of fun thing to do with my colleagues than anything else. In short, in my experience pair programming and daily stand-ups are neither necessary nor sufficient for success in software development. So I can only conclude that the success of these techniques in some software development situations is due to outside factors and not the techniques themselves. I’m fairly confident that this applies to any technique (agile or not) that we try to use to develop software. What it all comes down to is the people involved in the software development effort. The problem with current agile methodologies and other more traditional software development processes is that none are flexible enough to account for the differences in the humans involved in the project. Unfortunately, agile development is no longer _literally_ _agile_.
As a result of this, I’ve decided to launch pliantalliance.org and I’ve coined the phrase “Pliant Software Development” or PSD. PSD is a simple philosophy of software development which just mandates that we think, evaluate and change our processes to fit the circumstances we find ourselves in. There is no silver bullet. There is no “right way” to develop software. We should stop looking for it and start being more flexible on a day to day basis. Change when we need to change and don’t implement a process or technique just because you read a book about it. Think about how the what you’ve read about will actually impact your project/team and bend it to the situation at hand. Be Pliant.