Rhetoric teaches us that the answer is probably yes. However I feel that we would no longer relate to the vast majority of Agile success stories.
I think that my upper management read the benefits column of an Agile process but forgot to read about the requirements or how successful Agile businesses got there.
Is it possible to be agile without use cases and tests?
Not in my opinion No. See wiki for full definition, but here is the opening:
Agile Software Development is a group of software development methodologies based on iterative and incremental development...
Does this mean you are writing unit tests with NUnit; mocking with Rhino or Moq? No, but it will certainly be more difficult to produce solid, stable applications on time (late projects will certainly hurt the budget more than time spent writing use cases and tests).
Additionally, without unit tests, it is really hard to be agile - try having a requirement modification mid-project and hunt down everywhere you have to make changes ...
Agile development, IMHO, must be incremental. Without properly defined use cases and tests, development cannot be truly agile.
I have found that agile development keeps projects focused on the requirements.
I think that my upper management read the benefits column of an Agile process but forgot to read about the requirements or how successful Agile businesses got there.
This is a very common problem with Agile...
Because Agile is so light on rigid processes, in a lot of shops it becomes an excuse for sloppy cowboy coding - a kind of methodology which looks like Agile on paper, but is really no methodology at all.
My last workplace was exactly like this. It was basically cowboy coding. The only saving grace was that they had an official Testing department and a decent bug tracking system - so at least the iterations on development of new features were relatively formalised. But in all other aspects, Agile was hardly implemented properly at all. 90% of the time you were just hacking away at some completely undocumented code.
At the end of the day, I think the biggest issue here is the good old "If you're not typing, you're not working" syndrome. A lot of non-technical managers just don't seem to get that there is more to programming than sitting at your desk banging away at code. And these are the aspects of Agile which often get neglected. eg, At my last workplace it seemed to be a bit of a taboo for programmers and BAs to sit together for a long time discussing something, as if it wasn't "real work". We'd just get a basic description of a feature, implement it, and then it wouldn't be accepted by the client. Repeat. Eventually the entire codebase becomes a hack upon a hack - not to mention that taking the time to refactor is also often not considered "real work" in that sort of environment.
Is it possible to be agile without use cases and tests?
Tests are kind of required if there is to be verification of what was built which to my mind is a typical thing. Not always done but probably 99.999% of the time there is some kind of test done. In doing that test, what is there if not some kind of use case? Even if the test is just to see that it does work as expected, isn't that still a possible scenario of execution, which is how I'd define a use case in a rather liberal way?
Wouldn't the better question be, "How useful is it to be agile without use cases and tests?" To which I'd answer, not very.
Agile is about building a system up in a set of small working iterations. You reevaluate business priorities at the end of each iteration, and figure out exactly what to build next. The use-case is the fundamental currency of agile development, in that each iteration comprises old use-cases and a small number of new use-cases.
If you are able to fully test your system at the end of each iteration, and know that you won't break any previously written code, then you don't need programmed tests. So....you don't need programmed tests....at first.
However, as the system grows, it becomes harder and harder to fully test the system, and it becomes harder and harder to remember exactly what you built a few iterations ago. At that point, you cease to be agile, because testing is too hard because it is not automated and repeatable.
IMHO, the answer is that no one knows what Agile truly is, so, basically you can't get the right answer to an abstract question about abstract thing.
MSF vs. Scrum vs. something else is like comparing apples to oranges.
And depending on the methodology, or better yet, revision of the methodology, the basic assumptions will change.
Some think that Agile is doing the same stuff, but shipping faster. Some think that Agile is really an iterative process with close interaction with customer, where every iteration sees 50%+ of code changes Some think that Agile is waterfall, but without specifications. etc.
So depending on how Agile your Agile is, the question can go either way.
