Agile Manifesto - Part 2

Note that this is a second installment of a 4-part discussion of the Agile Manifesto.  I recommend that you read Part 1 before reading this post.

This post will focus on the second value of Agile:  "Working software over comprehensive documentation".  In traditional software development, the team will first produce a set of requirements.  Once this is done, the analysts will put together comprehensive functional and technical design documentation.  In larger projects, this exercise can equate to thousands of pages of text, charts, wireframes, and flow diagrams - all this before one line of code is written.

It is not that forethought and design aren't important, but in today's fast-paced business world, by the time you get the documentation complete, oftentimes the business drivers and requirements have changes.  It can then be a vicious cycle of change requests and document revisions, just to keep the supporting designs current to the needs of the organization.  Another issue with this approach is that it starts with the assumption that business sponsors and users can fully anticipate their needs through an abstract documentation exercise.  Many times, people need to work through real time prototypes in order to fully grasp what will meet their needs.

Agile addresses this problem by demanding that only the most fundamental and minimal documentation be created.  Rather than taking months or even years to develop all requirements and design documentation, Agile takes the approach of segmenting the work into very small deliverables that can be completed in 2-4 weeks rather than 2-4 years.  Each development period, called a "sprint", will result in a small piece of working software.  Since there are no detailed design documents, the customer's product expert is embedded with the development team, and together, they design, build, test, and refactor the software.  The results are something that not only meets the organization's immediate needs but also can provide an immediate payback to the company.

So how does this value apply in the process of doing theology?  To answer this, I want to bring in a couple of concepts from traditional theology.  First, is Luther's concept of theology from below.  Luther argued that it a futile exercise to formulate a theology as if one could view existence through God's eyes (a theology from above).  Humanity is incapable of such an insight, and any theology that starts with this premise is doomed from the start.  Instead, he advocates what he called theology from below (meaning a theology grounded on what is within human perception and comprehension).  Thus, he proposed that everything that a person needs to understand God is evident and accessible in the human person of Jesus of Nazareth.  In essence, Luther would define divinity not as Jesus is who God is, but instead as God is who Jesus is.

The second concept I would like to touch upon is Rudolf Bultmann's process of demythologization.  There are many misunderstandings around this process, and a full discussion of the topic is far beyond the scope of this piece.  In a nutshell, his process begins with the understanding that the biblical record was written in an historical context that assumed a world view that we no longer share.  Science was non-existent.  Illness was thought to be caused by demons.  In fact most every aspect of life was believed to be related to a supernatural cause beyond human understanding.

In order to communicate the message of Jesus within this context, the writers of the gospels who also shared this world view communicated their message in a way consistent with their understanding of the universe.  In literary terms, Jesus' life and his divinity was only able to be communicated through the symbols available within this world view.  Thus Jesus was borne from a virgin, walked on water, healed the sick, and made food appear from simple loaves and fish, etc.  It was, to be blunt, a literary device that in the context of first-century people, was accepted and expected.

Today, many people of faith feel the need to somehow be twenty-first century people while still clinging to a first-century world view.  Easy (and extreme) examples of this thinking are groups such as the creationists or faith-healers, who garner headlines by rejecting fundamental science in favor of a primitive, pre-scientific understanding of the universe.  Of course, nobody in this generation can truly achieve the perspective of a first-century person.  Instead, these people are conflicted hybrids, holding onto old perspectives for fear that they will otherwise somehow be torn away from God's salvation.

Bultmann promoted the understanding that people of the modern era must separate the myth from that which it is intended to convey.  This is not (as many detractors believe) an invitation to rewrite a Bible free of all supernatural imagery.  Bultmann is clearly on record against this.  Instead, he stated that myth and the meaning behind the myth (he called this kerygma) must be taken together.  The myth is the vehicle that communicates the meaning.  Without it, you have a dry prose devoid of the depth of meaning contained in Scripture.  So if you treat myth as literal fact, you substitute myth for meaning.  If you remove the myth altogether, you lose that which communicates the meaning.

After this long digression, let me tie this together into the second Agile value "working software over comprehensive documentation".  In the exercise of doing theology, it is important to focus on what works in our world and in human relationships.  Scripture is a critical piece of it, but we do not use its world view to recast modernity into first-century Palestine.  Instead we use the kerygma to develop theological understandings that work in our world and in our time.  We cannot hope to, nor should we try to, develop a theology for all time.  Instead, we should focus on creating short "sprints" of working theology for our context and our time.   We can trust that as things changes, as challenges arise, and as knowledge increases, we will need to adjust our theological understandings.  No problem.  This change and evolution is a core principle of a Refactoring Theology -  one that adapts yet retains the most simple and clear expression of the kerygma we value.