We're Agile... Right?

"We don't do much requirements analysis because its too much overhead. "
"We really need to hit our deadline in a few months, so we will make the most with the resources we have."
"Testing is a luxury, we just don't have time for that."
"Our developers have really been letting us down and dogging the project"

These are all reasons I have heard that a team is developing with an Agile philosophy, however none of the projects were Agile at all.

Where do you draw the line between agile and chaos? All too often a project is managed under the assumption it is agile when it reality it is simply chaotic. In the wrong hands, the tenets of agile development can create an incredibly dysfunctional environment. Agile development requires more discipline to do the right things than a highly structured waterfall approach. Here is a list of questions I used to try to clear up the confusion.

1) Are you managing for VALUE? Are the management decisions (features/timeliness/resources) being made to enhance value, or are they serving another purpose. If the timeline is ultimately hard, then focus on providing the highest value items to the customers in allotted time and deliver a high-value working product. Do not feel you can just squeeze out some extra productivity out of the staff and expect everything to work out. It’s a mistake that's been made over and over again. Once the team is set, and the deadlines are made, then you can only manage an extra 10% or so out of the team.

2) Is the end goal Speed or Efficiency?
Most people confuse these two concepts. Getting a project done faster does not correlate well to the efficiency of the project. Some projects appear to move too slowly, but the lack of defects greatly reduces the cost of a project since most defects costs many more times than developing correctly the first time. The best analogy is driving to work. Do you want to be efficient or get home as fast as possible? You could choose to drive as fast as humanly possible, but you end up paying more for gas/speeding tickets/ etc and take on more risks, such as crashing head on into oncoming traffic. I choose efficiency.

3) Are the customers engaged?
Are your customers an integral part of the process? If not, how can you be sure you are developing the highest value items at any given time?

4) Do you have defined iterations?
I think have predefined iterations (Of a suitable length) are extremely important. Without any defined iterations, it’s too easy to drift into complacency or drift into chaos where the feature list is constantly updated and the development team has nothing to focus on.

5) Do you always have a working, production ready piece of software?
If you are managing the project in such a way that you are adding many partially tested features at one time you are not Agile. Every iteration needs a fully tested piece of software associated with it. If you are adding features that 'We'll clean up later' you are doing a great disservice to the project by introducing inefficiencies and uncertainty.

There are some more, but those covers most of the things that help me draw the distinction between chaos and Agile software development. If you can strongly say yes to all the above items, you need to address this issues ASAP. Being chaotic and explaining it as agility only hurts the agile software development community's credibility.