„Wer hat das Manifest schon mal gesehen – nicht gelesen, sondern einfach nur wahrgenommen?“ Ein paar Hände heben sich hoch. Die Mehrheit der Teilnehmer der DOAG 2013 Development Konferenz sind offensichtlich nur bedingt mit dem Thema Agilität vertraut. Sie werden zwar sicherlich mit keinen Staatsgeheimnissen, aber vielleicht doch mit der einen oder anderen Erkenntnis den Saal wieder verlassen. 

Dass sie mit den Themen, die sie anspricht, das Rad nicht neuerfindet, ist ihr vollkommen klar: „Sehr häufig, wenn ich über das Thema spreche, höre ich: Ja, es ist ganz cool, aber nichts Neues.“ Mit einem gesunden Menschenverstand käme man zu den gleichen Schlussfolgerungen, ergänzt sie. Und sie stimmt dem auch zu. Die Fundamente der Agilität zu verstehen, ist in der Tat keine Kunst. Auf die Umsetzung kommt es an. Und da kann sie aufgrund ihrer Erfahrung mit Agilität in Großprojekten ansetzen und Best Practices vorstellen. 

Es gibt verschiedene Möglichkeiten, die Größe eines Projektes festzulegen. Eckstein macht sie an der Anzahl der Mitarbeiter fest. „Je nachdem, wieviele Mitarbeiter ich im Projekt habe, skalieren die anderen Messkriterien auch mit“. Ihr Spezialgebiet ist die agile Softwareentwicklung in Teams zwischen 30 und 300 Mitarbeitern. 

„Bei 100 Personen ist es fraglich, ob sie noch alle im selben Raum sitzen können.“ Und selbst wenn – dann sei die Gefahr relativ groß, dass sie nicht mitbekommen, was am anderen Ende des Raums gesagt wird.“ Bei 1000 Projektmitarbeitern wird es noch kritischer: „Da kennt man die anderen Projektbeteiligten nicht mehr“. 

Agilität ist vielmehr eine Kultur oder eine Haltung, die man einnimmt, als eine Technik. Deswegen stehen bei der agilen Software Entwicklung die Menschen im Vordergrund und nicht die Prozesse, die Dokumentation oder die Verträge. Natürlich werden trotzdem Verträge geschnürt, Dokumentationen verfasst und Prozesse aufgesetzt. Diese werden weiterhin gebraucht. Aber sie sind nur Mittel zum Zweck und kein Selbstzweck. 

In Großprojekten gibt es außerdem nicht „den Kunden“, sondern „eine Menge von Kunden“, meint Eckstein. „Und derjenige, der am lautesten schreit, bekommt, was er will“, fügt sie hinzu. Aber letztendlich kann man folgendes Motto festhalten: „Ein Projekt ist erfolgreich, wenn der Kunde erfolgreich ist“. Ändert der besagte Kunde zwischendurch seine Meinung, dann nütze es wenig zu lamentieren. 

Deswegen gibt es im Projektteam einen „Product Owner“. Er vertritt die Interessen des Kunden gegenüber dem Team. Seine Rolle ist nicht einfach: „Er sitzt zwischen den Stühlen – zwischen Kunden und Team“. Und wenn es mehrere Teams gibt, gibt es dementsprechend viele Project Owners, die sich auch in einem eigenen Meeting austauschen. 

Wer bereits auf dem DOAG 2013 IMC Summit die Keynote von Matthias Marschall erlebt hat, dürfte mit dem Thema der Silo-Denke vertraut sein. Das fasst Eckstein mit folgenden Worten zusammen: „Fast jeder hat es schon erlebt: Wenn alle an einem Strand ziehen, dann findet man immer einen Weg zum Erfolg. Wenn aber Misstrauen herrscht, dann wird es schwierig“. 

Vertrauen durch Kommunikation erzeugen – das ist eine der größten Herausforderungen überhaupt. Eine ehrliche und offene Kommunikation habe wiederum auch einen sehr starken Einfluss auf die Qualität, meint Eckstein. Für sie ist Face-to-Face-Komunikation ein Muss – auch in Großprojekten. Da wird es zwar schwieriger, aber es ist nicht unmöglich. Sie setzt auf tägliche Besprechungen und betont, dass diese Frequenz durchaus vorteilhaft ist: Wer sich täglich austauscht, kann so viel nicht zu sagen haben. Die Statusberichte in Teams dauerten demnach zirka 10 Minuten. Eine weitere, teamübergreifende Besprechung sorgt dann für die Aufrechterhaltung der Kommunikation zwischen den Teams: Jedes Team entsendet einen Repräsentanten. Das geht auch in zehn Minuten.“ 

Eckstein stellt Ihre Projektteams cross-funktional auf. So besäßen die Mitglieder eines Teams alle Rollen und Skills, die gebraucht werden, um einen Geschäftswert liefern zu können. Als Basis gilt eben die Arbeit in selbstorganisierten Teams. Hinzu kommt eine oder mehrere Architektur-Teams, die sich als Dienstleister verstehen und nach den Anforderungen der Feature-Teams arbeiten.

Wer wäre geeigneter als Marschall, den Spuren der Verschwendung nachzugehen:  Der Referent und Blogger ist seit den Anfängen von DevOps mit dabei. Zirka 2008 habe es angefangen, erzählt er. Der Belgier Patrick Debois habe den Begriff ins Leben gerufen. DevOps genoss dann ziemlich schnell eine relativ große Verbreitung. Inzwischen organisiert die Community jedes Jahr weltweit ein Dutzend Veranstaltungen zum Thema.  Wenngleich der Begriff DevOps inzwischen wohlbekannt ist, wisse man nicht immer, was dahinter steckt, bemängelt der Keynote-Speaker. „DevOps ist nichts Neues“, betont er. Man habe sich bestehende Erfolgsmodelle angeschaut, die zum Beispiel auf Scrum fußen und sich als sinnvoll erwiesen haben. Viele Unternehmen hätten einen Weg gefunden,  diese im Bereich Operations umzusetzen. „DevOps ist ein Hype, aber es steckt auch viel Substanz dahinter“, ergänzt Marschall. „Letztendlich ist es nichts Anders als ein „Change Agent“. 

Warum eine Umstellung notwendig ist? Um schneller zu wirtschaften, sagt Marschall ganz klar. Culture, Automation, Measurement und Sharing – das sind die vier Säulen der DevOps-Bewegung. „Die Kultur ist die Basis für alles“, bemerkt der Referent nachdrücklich. Es sei absolut unumgänglich, ein gegenseitiges Interesse sowie eine gemeinsame Verantwortung im Betrieb zu etablieren. Auch müssten die Abteilungen frühzeitig einbezogen werden. Transparenz ist das Schlüsselwort. 

„Einfach miteinander reden ist zu einfach“, erwidert ein Teilnehmer. "Wenn es funktionieren würde, wüssten wir es." Auf die Frage, ob Marschall Best Practices nennen könne, erzählt der Referent von seinen Erfahrungen in der eigenen Firma – von zwangslosen Treffen  beim Frühstück alle zwei Wochen, von einfachen „Drink-ups“ mit Vorträgen, Pizza und Bier. Darüber hinaus hätte das Unternehmen auch „Business Guilds“ eingeführt, um gemeinsame Interessen abteilungsübergreifend voranzutreiben – zum Beispiel zu den Themen Software Testing und SEO.  „In großen Unternehmen kennt man schon in der eigenen Abteilung nicht mehr jeden persönlich. Solche Maßnahmen helfen, mit anderen in Kontakt zu treten.“ Es sei schon alles viel einfacher, wenn man zu einem Namen ein Gesicht vor Augen hat oder ein paar Anhaltspunkte zu den Interessen vom Kollegen. 

Sitzen die Mitarbeiter allerdings geografisch getrennt, dann wird es schwieriger. Marschall vertritt die These, dass es einfacher ist, ein Wir-Gefühl zu erzeugen, wenn alle allein im Home-Office arbeiten. Dann wird auf virtuelle Kommunikationswege zurückgegriffen. Das funktioniert. Arbeiten indes verschiedene Teams an unterschiedlichen Orten, dann ist die Gefahr groß, dass Sub-Kulturen entstehen.  Ein Teilnehmer fragt, ob Marschall es geschafft hat, in seinem Unternehmen die Kultur zu ändern. Marschall bejaht und erklärt: Der Wille müsse von der Basis kommen, die Unterstützung von oben sei aber genauso entscheidend. „Wenn der C-Level sagt ‚Nee, will ich nicht‘, dann haben Sie ganz schlechte Karten. Aber von oben oktroyiert funktioniert es auch schlecht“, fügt er hinzu und verzögert das Gesicht. 

Wenn die Kultur stimmt, können durch einen höheren Automatisierungsgrad in Staging und Produktion weitere Verbesserungen erreicht werden. Ziel seien Ein-Klick-Releases, die für genug Schnelligkeit und Flexibilität sorgten. Unternehmen wie Flickr schafften es, zehn Deployments am Tag durchzuführen. Doch sich auf sein Bauchgefühl zu berufen hilft nicht viel: Es sei besonders wichtig, zahlengetrieben zu arbeiten – und zwar nicht nur bei Features, sondern auch beim Serverbetrieb.  Mit Sharing schließt sich der Kreis: "Die Probleme sind der Feind, nicht die Kollegen", heißt es. Wer sich dies regelmäßig vor Augen führt und für genug Transparenz sorgt, schafft Vertrauen. Wer versteht, wie Entscheidungen entstanden sind, ist eher bereit, diese hinzunehmen – selbst wenn sie ihm vielleicht persönlich missfallen. 

Dass es alles nichts Neues ist, weiß Marschall sehr wohl. Es handle sich nur um Spotlights, die gut funktionieren. Natürlich könne man nicht alle Probleme lösen. Aber man könne an überraschend vielen Stellen Verbesserungen erzielen. 

Trotzdem zirkulieren immer noch gewisse Erneuerungs-Killer in Unternehmen. Es sind Aussagen wie „das haben wir immer schon so gemacht“ oder Vorschriften, die aus der Historie heraus entstanden sind aber keinen Bezug mehr zur Realität haben. Es sind auch Annahmen, die auf falschen Hypothesen beruhen. 

Marschall bringt ein schönes Beispiel aus seinen eigenen Erfahrungen: Sein Team hatte in einem Projekt relativ lange Release-Zyklen. Das Team war der Meinung, dass es diese zur Qualitätssicherung brauchen. Um einem unzufriedenen Kunden entgegenzukommen, hat er Zyklen von zwei Monaten eingeführt. Nach dieser Umstellung stellte das Development-Team fest, dass es falsch gelegen hatte. Effektiv hatten sie weniger Features im Release – also auch weniger Bugs. Die Stabilisierungsphase erwies sich auch als extrem kürzer. Sie kamen zu der Erkenntnis, dass kein Unterschied zwischen Bugfixes und Einführung neuer Features besteht. Also verzichteten sie komplett auf Release-Zyklen setzten auf Continuous Deployment. 

Solche Zeit- und Nervenfresser sind in Unternehmen weit verbreitet. Auf Japanisch bezeichnet Mulda eine sinnlose Tätigkeit, eine Verschwendung, die durch Wertschöpfung ersetzt werden will. Dafür muss man aber erst in der Lage sein, die Verschwendung zu identifizieren: Marschall präsentiert sieben - dabei geht es zum Beispiel um Übergaben, bei denen viel Know-how verloren geht. Besonders ärgerlich findet Marschall auch das erneute Lernen von Sachen, die man schon mal gelernt, aber wieder vergessen hat – ganz nach dem Motto: „Das wusste ich schon mal“. 

Zu den Top-Verschwendungen gehören auch Verzögerungen – sei es das Warten auf Freigaben oder die Überlastung einer Abteilung oder eines Mitarbeiters. Mit einem Value Stream Mapping lassen sich diese Zeitverzögerungen gut aufzeigen und dann von Fall zu Fall vielleicht auch verhindern.  

Gegen die „Don’t Care“-Mentalität indes könne nur das Gefühl einer gemeinsamen Verantwortung weiterhelfen, meint Marschall. Es ist die einzige Stellenschraube, an der man in dem Fall drehen kann, , um Fehler und Bugs zu vermeiden. 

Das Inventar wird den meisten Unternehmen auch wohl bekannt sein: Es sind lose Listen, die nie abgearbeitet wurden, unfertige Features, Vergessene Sachen. Marschall und sein Team haben sich einmal die Mühe gemacht, im Projekt-Tracker „Jira“ die offenen Punkte alle zu erfassen. Sie kamen auf insgesamt 1448 Items. Der Versuch, diese nachzuvollziehen und priorisieren, um sie dann abzuarbeiten, blieb erfolglos. Es war zu viel. Bis auf 200 wurden alle gelöscht. 

Marschall verspricht keine Wunderwaffe. Er kommt allerdings mit interessanten Ideen und mit der Lust, seine Erfahrungen und Kenntnisse mit den DOAG-Teilnehmern zu teilen. Die Gespräche werden nach der Keynote draußen auf der Terrasse des Hotels weitergeführt. Die Veranstaltung – eine Zusammenlegung vom Vorabend des IMC Summits und Regionaltreffen Rhein-Mainz – hätte durchaus mehr Aufmerksamkeit verdient. 

Für Firmen, die Java auf dem Client nutzen, hat Oracle auch eine Lösung parat: Den Systemadministratoren sollen eine größere Kontrolle bei Installation und Deployment von Java in ihrem Unternehmen gewährt werden. Zum Beispiel sollen sie dann festlegen können, inwiefern Java-Applets gestartet werden dürfen. Neulich hatte Oracle angekündigt, die Nummerierung der Java-Updates zu ändern und war aus diesem Grund vom Interessenverbund der Java User Groups e.V. (iJUG) kritisiert worden. Der iJUG forderte von Oracle eine Zählweise, die allgemein verständlich ist, und schlug vor, mit der Java-Version zu beginnen, gefolgt von den Funktions- und CPU-Updates und an dritter Stelle die Security-Updates. Zum Beispiel: 7.1.3 für Java 7, erstes Funktions- und drittes Security-Update.