Agile Theology
by Paul Hazelden
Introduction
(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.
Basic Ideas
Waterfall and Agile
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.
An Agile Approach
Pair Programming
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.
Feedback
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.
Test-driven development
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
Coding standards are not a 'given' but are negotiated
and developed by the participants. It is all about creating
a shared language.