Agile [Modeling, Testing, Usability, Database, Elephant Training, ...]

There are a number of discussion groups such as the ones listed above, who like to talk about how their specialty fits in with "Agile". For my sins, I hang out on those groups and try to help.

I have quite a bit of Waterfall in my history. Like me, many of the people on these lists have it as well. As such they are used to hearing and thinking things like these:

• Modeling is something that is commonly and rightly done before the programming really gets going;
• Usability is something that should get figured out in large part before we start building the system;
• The database really needs to be pretty well defined before you start coding;
• Testing is something that gets done mostly after the code is done.

Mind you, these views are not universally held, and no one holds on to them completely as far as I've noticed. But there is this "feeling" that some important parts of the specialty work need to be done "first". (Or, in the case of testing, "last".)

Furthermore, there is some very real truth in these ideas. For example:

• If a system grows too freely, it may wind up with a terrible model. Models are easier to think about and change than code, so model thinking can be more flexible.
• Some usability ideas would be difficult to impossible to retrofit, especially if the system has too much of an ad hoc architecture.
• We can't effectively store and retrieve information until we have a database. In addition, databases are hard to refactor once they contain data.
• Clearly we cannot actually test code before it exists, though we can specify our tests before the code exists if we choose to.

Suffice it to say that these disciplines and others do not fit into Agile in a completely obvious way.

The Essence of Agile

I had the privilege of being one of the people at the Snowbird meeting where we wrote the "Agile Manifesto". I'm going to reflect here on the core principles. We talked deeply about those principles. We really did mean the aspects that I propose to emphasize here.

Sofware Development in Every Iteration

We wrote the following principles addressing the need for software development:

• Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
• Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
• Working software is the primary measure of progress.

Look!! Fully three out of twelve principles call for the repeated continual production of working software. We really meant that. Let me paraphrase:

Agile Software Development has as its highest priority the early and continuous production of working software. This is Agile's primary measure of progress.

But In Our Context, Our Specialty, We Can't Do That!?!?

Specialists such as business analysts, user interface experts, testers, database experts, architects, and so on, all have the same initial reaction to this dictate. They all want to wiggle on the hook. They see, rightly, that they are not doing what these principles say, but they are sure that they are doing great work. They want their work to be blessed as "Agile", for some reason.

The upshot of this has been a number of deviations. The idea is always to fit Agile into our context.

• We can't actually have business people and developers working together every day throughout the project. Our context can't permit that. But we want to be Agile anyway. How do you do Agile Offshoring?
• We don't really produce software: we produce designs or pictures or UI prototypes. Our context won't let us produce software. But we want to be Agile anyway. How do you do Agile With UI?
• We specialize in understanding business people and telling developers what needs to be done. Our context won't allow developers to talk with the real users. But we want to be Agile anyway. How do you do Agile Business Analysis?

And so on and so on and scooby dooby dooby.

Well, understandable, understandable. Yes it's perfectly understandable. Comprehensible. Comprehensible. Not a bit reprehensible. It's so defensible!

I understand why people would want the benefits of Agile, and I sort of understand why someone not doing it would want the t-shirt anyway. And I bloody well do understand why someone like me, who can't do everything, and can't even do anything all that well, would quail and cower when he was told that he had to do all this stuff.

Yes, well. Fine. So let's grade on the curve. Let's give all the kids a gold star. Let's lower the bar so that everyone can jump it.

Sorry, No

When we wrote the manifesto, we really meant what it said. We had argued and fought and reasoned to get those four values and dozen principles settled. In particular, we really meant that to do what we were talking about, you have to deliver software all the time, beginning to end, day in and day out.

Speaking just for myself¹, I'm not willing to relax that ideal.

Does your current project sometimes fall short of that? Well, so does mine, quite often. That's why we have ideals, apparently, to fall short and try again and again to live up to.

Does your current specialty clearly have great value to projects, but not fit in nicely to Agile's definition. Well, so does mine. So let's figure out how it can fit in nicely, or figure out how best to mate it up. Let's not water down the meaning of a nice crisp idea like Agile Software Development.