Ich habe das Glück, dass ich mich bei vielen tollen Unternehmen in unterschiedlichsten Softwareentwicklungsprojekten austoben konnte. Dank geht raus an Navigate, ITML (heute NTT DATA Business Solutions), Micromata und POLYAS.

Ich bin nicht per se gegen „Tradition“ im kirchlichen Kontext. Aber als ein Art Beharrung und Konservierung endet sie oft in einer Institutionalisierung. Ich meine mit Blick auf die Geschichte von „Gottes Volk“: Wenn es schon eine Tradition gibt, dann ist es eine „Tradition der Bewegung“. Ich bin fasziniert von dem Gedanken, dass sich Kirche beweglich, anpassungs- und wandlungsfähig zeigen sollte. Und darum soll es in diesem und weiteren Beiträgen gehen.

In der Softwareentwicklung beschreibt man das als Agilität. Anfangs ging es „nur“ um Projektmethoden wie Scrum oder Kanban. Heute fragt man sich aber auch, wie sich Teams und ganze Unternehmen als agile Organisation aufstellen. Und das nicht nur im IT-Kontext, sondern branchenübergreifend.

Wenn du über die Entwicklung der „klassischen“ zur „agilen“ Softwareentwicklung informiert bist, kannst du die folgenden zwei Absätze getrost überspringen. Aber lass dich noch einmal beim „Agilen Manifest“ abholen, denn da beginne ich mit meinem Versuch, was das ganze eventuell mit Kirche zu tun haben könnte.

„Klassische“ Softwareentwicklung

Um ein besseres Gefühl für die Trendwende zu bekommen, schauen wir noch einmal zurück: Seit den frühen 2000ern bin ich in der Softwareentwicklung unterwegs. Ich kann mich noch gut an große Projekte erinnern, bei denen die Kundenseite ein monströses Lastenheft ausstellte, auf deren Basis wir als Dienstleister ein Pflichtenheft verfassen sollten. Die Phase der Pflichtenhefterstellung hat viele Projekttage verschlungen und somit einiges an Kosten verursacht. Das Pflichtenheft wiederum galt als Vorgabe für die zu entwickelnde Software. Erst mit Fertigstellung und Freigabe des Pflichtenhefts wurde mit der Entwicklung begonnen. Und natürlich streng nach Vorgabe eines Projektplans, bei dem die Gewerke in starker Abhängigkeit zueinander entwickelt wurden. Dieser sah als Meilenstein zumeist auch eine Fertigstellung und Zwischenpräsentation eines Prototyps vor. Dieser Termin war meistens sehr enttäuschend. Je umfangreicher Lastenheft und Pflichtenheft gestaltet waren, desto wahrscheinlicher war eine Enttäuschung bei der Projektleitung auf Kundenseite. Denn meistens hatte sie etwas komplett anderes erwartet als das, was nun vorgestellt wurde. Trotz bester (und kostenintensiver) Vorbereitung auf beiden Seiten hatte man sich wohl deutlich missverstanden. Das war dann oft der Auftakt zu nervenaufreibenden Change Management-Verhandlungen. Mit Ach und Krach hat man dann solche Projekte über die Ziellinie gebracht. Häufig mit einem ernüchternden Ergebnis und einer gravierenden Budgetüberschreitung.

Agile Softwareentwicklung

Und genau aus diesen enttäuschenden Gründen hat die agile Softwareentwicklung in den letzten 20 Jahren einen enormen Aufschub erhalten. Man kann zurecht von einer agilen Transformation in diesem Kontext sprechen. Um es mal kurz herunterzubrechen:

Bei der agilen Softwareentwicklung geht es darum, möglichst unbürokratisch vorzugehen und in kurzen Iterationen aktuelle Softwarestände auszuliefern. Das hat den großen Vorteil, sich ein schnelles Feedback einzuholen und dieses ggf. für die nächste Iteration zu berücksichtigen. Durch diese Transparenzerhöhung wird das Risiko der Fehlentwicklung minimiert und letztlich eine schnellere Projektgeschwindigkeit erreicht. Und schlussendlich haben wir auf beiden Seiten zufriedenere Menschen.

Agiles Manifest

Nun gibt es einige agile Vorgehensmodelle (wie beispielsweise Scrum, XP, Kanban). Deren kleinster gemeinsamer Nenner ist das agile Manifest, das bereits 2001 verfasst wurde. Es beschreibt Verhaltensregeln und Werte agiler Teams und besteht aus vier Leitsätze. Zur Verdeutlichung wird eine Gegenüberstellung verwendet:

Wir erschließen bessere Wege, Software zu entwickeln, indem wir es selbst tun und anderen dabei helfen. Durch diese Tätigkeit haben wir diese Werte zu schätzen gelernt:

  1. Individuen und Interaktionen sind wichtiger als Prozesse und Werkzeuge.
  2. Funktionierende Software ist wichtiger als eine umfassende Dokumentation.
  3. Zusammenarbeit mit dem Kunden ist wichtiger als Vertragsverhandlung.
  4. Reagieren auf Veränderung ist wichtiger als das Befolgen eines Plans.

Das heißt, obwohl wir die Werte auf der rechten Seite wichtig finden, schätzen wir die Werte auf der linken Seite höher ein.

Meines Erachtens kann das agile Manifest als Referenz auch für die Zusammenarbeit von Teams in anderen Kontexten herangezogen werden. Und ich meine auch für ein mögliches Kirchen-Startup, denn auch dort begegnet uns eine nicht zu unterschätzende Komplexität, die bewältigt werden muss. Zudem müssen wir uns ständig neuen Herausforderungen und Dynamiken stellen. Dazu bedarf es vieler unterschiedlicher Kompetenzen. Deshalb versuche ich nun einmal die vier Leitsätze des agilen Manifests auf eine Kirchengemeinde zu abstrahieren.

„Individuen und Interaktionen sind wichtiger als Prozesse und Werkzeuge“

Der Mensch steht im Fokus. Kirchensatzungen, -visionen, -programme, Glaubensbekenntnisse und was man sonst so als Kirche dokumentieren kann sind schön und gut, ersetzen aber nicht die Beziehungen. Wir reden miteinander und suchen im direkten Austausch nach Lösungen. Dabei denken und urteilen wir nicht kleinkariert, sondern wollen ein weites Herz haben.

„Funktionierende Software ist wichtiger als umfassende Dokumentation“

Einfach mal machen“ bringt es gut auf den Punkt. Wir wollen nicht nur träumen, sondern auch anpacken. Wir machen uns gegenseitig Mut, neue Wege zu gehen und Experimente zu wagen, statt uns ausschließlich in tollen Powerpoints, Instagram-Stories und Dokumenten über unsere Zukunftsabsichten zu verkünsteln. Dabei gestehen wir uns Fehlversuche ein und warten nicht darauf, bis wir den perfekten Plan haben.

„Zusammenarbeit mit dem Kunden ist wichtiger als Vertragsverhandlung“

Hier muss ich zugeben, dass ich mich mit dem Transferieren des Begriffs „Kunde“ schwertue. Denn wer ist in einem Kirchen-Kontext „Kunde“? Wir wollen doch als Kirche nichts verkaufen. Bei seinem Vortrag „Agile Church: Survival Skills for Christian Organizations in the 21st Century“ bezieht der Business Agility Coach und Baptist Bernd Winkelsträter „Kunden“ auf den Personenkreis, der außerhalb der Kirche steht, quasi als Zielgruppe, die die Kirche zu erreichen hat. Das möchte ich nicht ausschließen. Ich denke noch ein wenig anders darüber nach: Wir sehen uns als Kirche nicht als Mittelpunkt in unserem Kontext. Wir lassen externe Faktoren miteinfließen. „Suchet der Stadt Bestes […] und betet für sie zum HERRN; denn wenn’s ihr wohlgeht, so geht’s euch auch wohl.“ Jeremia 29,7. Aber ich sehe dabei auch noch die Personen, die bereits in der Kirche sind. Hier gehen wir mit unseren Strukturen, Programmen und Angeboten auf ihre Wirklichkeit ein. Und die kann sich ändern. Bei allem wollen wir mit der Zeit gehen. So oder so gilt: Eine persönliche „Auseinandersetzung“ mit den Menschen ist wichtiger als eine wasserdichte Amtshandlung. Der direkte Austausch steht über Formalien.

„Reagieren auf Veränderung ist wichtiger als das Befolgen eines Plans“

Das habe ich eben schon anklingen lassen: Wir gehen mit der Zeit. Wir erhalten uns Flexibilität. Auch gut durchdachte Konzepte, in die wir viel Herzblut hineingesteckt haben, sind wir bereit zu opfern. Wir sind adaptiv und verlangen uns selbst eine hohe Anpassungsfähigkeit ab. Das heißt nicht, dass wir sprunghaft, reaktionär oder chaotisch vorgehen. Wir haben ein Ziel im Auge, weichen aber auch gerne vom eigentlichen Plan ab, wenn es für uns sinnvoll ist, sich die Zeichen der Zeit geändert haben und es Aussicht auf einen höheren Wertbeitrag gibt.

Zum Abschluss

Soweit erstmal ein paar Gedanken zum Thema „Agile Kirche“. Demnächst mehr dazu.

Habt ihr euch schon mit dem Thema beschäftigt? Kennt ihr andere, die dazu schon etwas geforscht und experimentiert haben?

Ähnliche Beiträge

Ein Kommentar

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.