Warning Signs that Agile Is Declining

You can get away with a lot of informality and doing things on-the-fly for small projects, when everyone involved can get around the same table in a meeting room and a single expert from the customer side can make all significant decisions. When your project team is made from 200 people divided among geographically and temporally diverse teams and the customer for your business management software is a 100,000 employee global corporation trying to co-ordinate the activities of six divisions in five key areas? Not so much.

http://www.satisfice.com/blog/archives/27

Sorry, just one of my pet peeves, and describing agile as == best practice doesn't help anyone.

And probably a growing number of people are going to be put off by their experiences with "agile", if they are anything like mine have been.

Managers love the idea of releasing more often and understand that. And that part can be an improvement.

However, quite a few people seem to think that means you can fit that many more features in, which is false.

This is the big challenge for agile in my opinion: automated testing or even testing at all, is hard for many development teams for a number of reasons. Not to say that the actual skills or knowledge are particularly difficult to acquire. But practically speaking, putting into place a good testing and release system are challenging for many teams.

And doing "agile" (read: code and release more features faster) without solid automated testing or at least one real QA analyst who is busy, will guarantee that you have a ton of regressions and broken deployments. Now, since you are releasing much more often, you will still gain from getting much more feedback from customers, but there will be loud drone of bug fixing conflicting with the "agile" manager's push to release more features.

If your implementation of "agile" actually includes frequent refactoring and you don't have unit or at least integration tests, you are definitely going to be sorry.

Test-driven development requires a little bit more discipline, sometimes more up-front design, and sometimes investment in developer training. If TDD or the like is off the table or only partially implemented but you are still going ahead with "agile", then you still might survive, if you have a real QA analyst and solid process. My perception and experience is that most managers will decide that hiring an additional person "just for testing" is "not in the budget" and if they do bring someone onto the project for QA they will think they can use just any person rather than hiring a single QA professional.

That has been my experience with agile. Several years in, I am still working on trying to discipline myself and with my latest project I am having a bit of success with vows-bdd integration tests. But TDD/BDD etc. is a skillset that takes time to develop and a discipline that I believe young developers will greatly benefit from if it is part of their early training and experience.

I didn't have anything specific in mind; I'm going by my own experience, discussions with past colleagues, and conferences over the years more than anything. That said, it's not hard to turn up examples with a few minutes looking through my bookshelf and Google Scholar.

For automated testing, just stick search terms like "automated software testing" into Scholar and set the latest year to, say, 2000. You'll turn up dozens of papers going back decades that talk about techniques similar to what we would call unit testing today.

Continuous integration is another obvious one. The likes of Grady Booch were writing about the advantages of frequent integration builds by the early '90s. The term "continuous integration" appears in Object-Oriented Analysis and Design with Applications (1993), for example.

The prior existence of refactoring techniques is kind of obvious, as people had been discussing simple transformations like moving functions and data up and down a class hierarchy since the dawn of OOP. If you want a specific citation, Design Patterns (1995) mentions the specific term "refactoring" a few times, in turn citing academic papers on the subject cowritten by one of the authors as early as 1990, around a decade before Fowler's book and several years before Beck coined the term according to some Agile advocacy.

That's all I've got time for now, but I'm sure you could find eqally authoritative sources for the other things I talked about if you genuinely want to know.