I often have occasion to describe some very effective ways of doing things. Let me list a few:

  • Building software incrementally, in two-week cycles, with each increment showing real working features, is a really good way of managing a project.
  • Creating acceptance tests (or checks), which amount to automated examples of what is wanted, is a really good way of ensuring that requirements are understood, and that the software does what’s required.
  • Creating developer tests (or checks) incrementally as software is developed, before writing the next few lines of code, is a really good way to produce software that is low in defects, and in which new defects are easily discovered.
  • Continuous refactoring can keep code clean without requiring long delays while design is figured out.

None of these things is easy to do: they all require a bit of skill. However, that skill is within the reach of any competent development team.

There are many items that could be on the list above. Essentially they are the elements of good Agile software development practice. There are hundreds of teams, thousands of programmers, who have the skill to do these things, and who do them every day.

Commonly, when I’m teaching a Scrum course or a developer course, or even just chatting with some team, people will raise objections. They couldn’t do this or that, for some reason that they have stuck in their mind.

As it happens, I’ve personally written just about every kind of software that has ever been written, and I’ve worked with teams who have done the rest. There is no kind of software that does not yield to the techniques in Agile, and I’m no more than two degrees of separation from someone who knows exactly how to do it, in the event that I do not.

This means that I am not easily convinced that the objections being raised are valid. I know something that the objecting party does not: I know how to do these things, and they have not yet learned them.

Sooner or later in these discussions, someone will say something to the effect that these ideas are all very well and good, but in the “real world”, they just don’t apply.

You can imagine how impressed I am by this argument, since I have over a half-century of experience creating software by just about every method known, and because I have helped hundreds of people learn how to do these things, and it wasn’t even that hard.

I generally reply to the effect that our job is to create the “real world” and not to imagine that our present situation is the only situation there is. I try to do that respectfully. Sometimes I find that very hard.

So listen up. Agilists like me live in the same real world you do. We’ve done the things you’re doing, we’ve encountered the problems you’re having. We’ve suffered just as you have. And we know some techniques that you probably do not know, and we have found those techniques to be very strong.

You’re free to dismiss these ideas. You might not be wise to do so. But you are free.

Also, get off my lawn.