3 November 2007 - 17:32Agile development

A post of various thoughts that I have about Agile development.
Judging from my previous posts you may believe that I am against Agile Development. I am not, as a matter of fact I agree with a few of their ‘practices’:
I agree that you need the team members need to be constantly kept-up-to date with project developments, this way you can delegate tasks more effectively. I agree that you need to test your applications well, this makes your applications easier to change for one thing. I agree that iterations are a good way of developing a project which has a lot of uncertainty in it.
I would say that I agree with quite a few practices championed by Agile developers. What I have trouble agreeing with is the vagueness that pervades most Agile concepts. Most Agile concepts are pretty vague since Agile development aims to encompass all software development (not a small feat is you think about it) with the result that concepts can be stretched into being meaningless (just check out this Agile practitioner definition of developer). Agile practices are so easy to stretch that you would think they were constructed this way in order to avoid blame and reap glorious praise, to be honest sometimes I think this is their chief purpose.

Another problem that I have is with the total lack of structure when it comes to project management. Rather than this thick Agile soup that tries to have an answer to everything we would be a lot better off if we had some IT-management patterns, similar to the GoF design patterns, I am trying to figure out what OOP would have looked like without those design patterns and it is not a nice picture. Who knows, maybe one day some guy will write a book where you could read something along these lines: “we had this team made up of 5 people, 3 junior, 2 senior, we had this project in this environment. We had some conflicts between the 2 seniors which were resolved in this way. We determined that the best way to tackle these problems was to split the tasks in this way, etc…”. This type of book, a collection of effective and widely applicable project management patterns, would serve IT a lot better than the latest iteration of Agile practices.

If you have a homogenous team then Agile process will probably work for you. The moment you run into a team where there are big differences between members and their skill sets you will see a different set of dynamics because you will want to make the most out of each member’s skill set. Unfortunately, Agile development doesn`t have an answer to handle this.

The focus on developers going as far as to declare that you only need developers in order to put thru a successful software project is pretty ludicrous, it’s pretty ludicrous and pompous for developers to say that you only need developers for a software project, it sounds like a second-hand shoe salesman.

Small iterations and continous release sometimes run you into troubles: consider that you are exposing your application to the outside world (in REST or WS or whatever). Let’s say that you make a small change in the way the app gets exposed, like you added a method or changed a signature. The only way you can release this to prod is by creating a new version of the same service so that you don’t break the dependencies on the current service. Well, versions cannot be created very often or you run the risk of developing Versionitis, AKA version management problems. This puts a lid on the number of times you can port to prod, you will be able to port to PROD only rarely in order to avoid going into a versioning nightmare.
Continous release probably applies to projects where you have no or minimal interaction with outside parties or where you have a fair degree of control over their environments.

Agile development is mostly a mirror of various development practices occurring at various development shops which happen to have their a very skilled workforce (think ThoughtWorks and the like). It would be a mistake to believe that all of these practices apply outside of these shops. My opinion is that you should watch Agile Development from a safe distance, pick what you think works for you, try to formalize it in order to get it closer to your needs and move on.

As always I don`t have the time to finish this post, it has been gestating for a while now, so I will release it as it is.