(This is not an article, but a quick sketch to remind me of an article I plan to write at some point.)
In the realm of software development, one of the most interesting developments in recent years has been the rise of new approaches, such as 'extreme programming' and 'agile programming'.
It seems to me that many of the ideas embodied in these new approaches could usefully be taken up by theologians. I would like to explore this possibility, and see if it goes anywhere.
Traditional theology follows the 'waterfall' approach, in which you constantly build upon the given and unquestioned output from a previous stage. Generally, this would be implicitly your own previous studies, and explicitly the works of theological giants such as Calvin, Luther and Aquinas, and selected parts of more recent theologians.
Agile theology means that you question and re-work previous studies, questioning the assumptions and asking if there are now better or different ideas and tools to use. Nothing is sacred, apart from the sacred.
Agile values are sometimes identified as communication, feedback, courage and simplicity; Agile tools include pair programming, refactoring, simple design, test-driven development, continuous integration, coding standards, open workspace, collective ownership and sustainable pace.
Traditional theology is about ideas: are they right? Agile theology recognisess that theology is an activity that involves people, and which affects people. Yes, it has to be right, but the way you get to an answer does not have to involve sitting in a room all on your own for weeks or years at a time. Theology should be done in a social context because we are social beings, and because the theology we produce will change the lives of the people who hear it.
The importance of feedback goes beyond the simple rejection of 'waterfall' approaches to theology: it means that we are constantly asking what people understand by the theology they have already accepted: people, ideas, values and priorities all change, and the words used by one generation will not have the same meaning or impact on the next - or even on the same people ten years later.
In programming terms, test-driven development means that you are not content with writing writing new code, or even testing it: the job is not done until you have created a test of set of tests that can demonstrate that the code does what you intended.
Similarly, in theology, the aim is not to create works of theology: papers, essays, books and the like: the aim of theology is to enable God's people to understand God's truth so that they can live God's way. The test of theology is how it affects the way we live.
We may imagine that some piece of teaching is sound theology, but if the effect is to produce lazy, fearful, insensitive or pleasure-seeking believers, then something has gone wrong and we know the job is not yet done.
Of course, to say 'I like the effects of this doctrine' is not the same as 'this doctrine is true' - even with software, the code may be wrong but produce the right output by acident. On the other hand, if the output is wrong, we know that the code must be wrong. If God is love, then God's truth must produce love.
Coding standards are not a 'given' but are negotiated and developed by the participants. It is all about creating a shared language.
