See: http://alistair.cockburn.us/7+Properties+of+Highly+Successful+Projects+from+Crystal+Clear

The key thing is that it is more important to have these kind of invariant properties of a team & environment than it is to have a solid process to make success more likely in a software development project!

On the last paragraph I agree on almost all points but the principles are written in a graduated fashion. As such I think a project could be said to ‘be Agile’ if it is following the Agile principles and using them to drive culture and work style. I also think a project that could be described as ‘being Agile’ without comprehensive automated testing would in all likelihood be working towards it as the gold standard. Though in principle its use should be contingent and corrigible.

Regarding foreman – well, there was a good idea somewhere in another discussion – a good development team needs at least one person who is passionate about the product. A good public example is Unity – once Aras Pranckevicius asked “is it normal that I review every single commit log message” – and believe me, they have quite a few of those per day:) It does not have to be a foreman – it has to be someone who brings things to attention on a constant basis and does not let your code base to rot.

“For example velocity tracking, developing in timeboxed iterations and maintaining a backlog.” Well, I don’t disagree, but I think those are at a bit higher level and less concrete. The 3 practices I list are pretty easy to check up on: is your test suite comprehensive, can anyone work on any area, are people checking in once a day without breaking things, is new code frequently shown to customers (for some definition of customer)? Things like velocity are a lot harder to measure and use; in fact velocity measurement is probably used incorrectly more often than not. I could see ten alternatives to accomplish the goal of velocity measurement (which is what, BTW?), that I cannot when it comes to building automated tests.

I stand by my statement “if you do not have comprehensive automated tests, you cannot be Agile”. It isn’t just a matter of efficiency. It is a matter of culture, work style, and principles as well. I’m not saying without automated tests you cannot good code, that you can’t release rapidly, or any number of individual things. I’m saying that without comprehensive automated tests you cannot achieve the comprehensive benefits of being Agile.

Isn’t it more “you cannot work as efficiently without comprehensive automated tests and the preference in Agile is for shorter iterations of working software so efficiency matters”.

I personally also think that development practices should also be subject to the same flexibility as project management practices. The danger for both development and project management is the misuse of flexibility and it does seem to me that your wish for rigidity is a response to flexibility being misused rather than a requirement for rigidity. In big teams with multiple sub-teams this is an issue of governance from the managers of production and technical disciplines.

Then it comes down to whether or not there is a good reason for not following certain development practices. In the case of the three you highlight the occasions where you wouldn’t want them as practices on any reasonable sized project are pretty rare.

I’m pretty sure there are some project management practices that probably shouldn’t be thrown out for the vast majority of projects as well. For example velocity tracking, developing in timeboxed iterations and maintaining a backlog.

I do think that teams should rigorously adhere to current practices in both project management or development otherwise you are going to make measuring their effectiveness pretty hard. Which in turn will make iterative improvements harder.