ww

w.O

BJE

KTs

pekt

rum

.de

Führ

ung

und

Man

agem

ent

in d

er IT

G 6

54

0F

Christian Kamm & Dr. Josef Adersberger

Agil zum Ziel: Sieben Erfolgsfaktoren für agile Großprojekte

IT-Management und Software-Engineering

€ 9,90 Österreich € 10,90 Schweiz sfr 18,20

Juli/August 2016 • Nr. 44 1 9 4 1 6 4 1 0 9 9 0 0

0 4

Führung und Management in der IT

Sonde

r-

druck

für

Agile Vorgehensmodelle sind inzwischen in den meisten Unternehmen angekommen; sie etablieren sich nach und nach als De-facto-Standard für die Durchführung von IT-Projekten [Din12]. In kleinen Projekten mit bis zu sieben Mitarbeitern haben sie sich wunderbar bewährt: Sie adressieren die wichtigsten Ursachen von gescheiterten Projekten, liefern wirksame Mittel für den Projekterfolg und sind zudem einfach ver-ständlich und gut vermittelbar. So einfach und geschmeidig agiles Vor-gehen in kleinen Projekten funktioniert [DyDi08], so schwierig und anstrengend sind die Herausforderungen in agilen Groß-projekten [FoHi01]. Besonders spannend wird es, wenn der Auftragnehmer zudem noch die Gewerksverantwortung trägt und das Projektumfeld beim Kunden noch nicht auf agil getrimmt ist.Projekte dieser Bauart haben wir in den letzten fünf Jahren durchgeführt, allesamt bei DAX-Unternehmen in Deutschland. Wir haben alle Projekte gemeinsam mit un-seren Kunden zum Erfolg geführt; die Lern-kurve war aber anfangs für beide Seiten steil und teilweise schmerzhaft. In diesem Artikel fassen wir zusammen, was wir bis-her gelernt haben.

Erfolgsfaktor 1: Mehrere Ebenen der Planung und SteuerungRichtig agil ist man nur im Sprint. Das ver-leitet viele dazu, sich geistig ausschließlich auf Sprintebene zu bewegen und nur dort zu planen und zu steuern; oder noch schlimmer: überhaupt nicht mehr zu planen, weil agil als Ausrede dient für Plan- und Ziellosigkeit. Es gibt aber drei relevante Planungsebenen oberhalb vom Sprint, die gerade in agilen Großprojekten essenziell sind für den lang-fristigen Projekterfolg (siehe Abbildung 1):n Das Projekt mit seiner Produktvision.

n Der Jahresumfang mit jährlichem Leis-tungsversprechen innerhalb der Linien- und Programmorganisation.

n Das Release mit den geplanten Features.

Produktvision kontinuierlich justierenBeständiges Justieren der Produktvision und Aushandeln von jährlichen Leistungs-versprechen mit der Projekt- und Linien-organisation sind vor allem Aufgabe des Auftraggebers; klug ist es aber, sich dabei möglichst früh vom Team des Auftrag-nehmers Input zur Machbarkeit und zum Gröbstaufwand zu holen.In jährlichen gemeinsamen Workshops die Produktvision zu feilen und die Jahres-Roadmap zu definieren, hat sich hier be-währt: Ziele und Kosten werden klarer, das gegenseitige Vertrauen wächst. Da man zu diesem Zeitpunkt in aller Regel noch nicht viel über die Details weiß, muss man grob schätzen, so gut es eben geht. Hier haben sich als Aufwandsmaß sogenannte T-Shirt-Größen mit grob hinterlegten Aufwandsin-tervallen in Bearbeitertagen bewährt.Klar ist: Je länger man im Projekt unter-wegs ist, umso treffsicherer wird man hier in der groben Aufwandsschätzung; parallel stattfindende Schätzklausuren in kleinen

Teams mit drei bis fünf Mitarbeitern haben sich bewährt. Das Ergebnis dieser gemein-samen Schätzaktion ist in jedem Fall besser als Würfeln oder ein Best-Guess-Budget, das ausschließlich durch den Auftraggeber festgelegt wird. Neben den Zahlen sind der Mehrwert: eine erste Risikoanalyse, Erken-nen von Abhängigkeiten, Offenlegen der Ziele aus Kundensicht im Gesamtteam und eine erste Validierung der Jahres-Roadmap.

Mut zur Planung für Release und SprintAuf Release-Ebene (Laufzeit drei bis vier Monate) ordnen wir den geplanten Relea-ses Features zu und pflegen einen Meilen-steinplan. Auf Sprint-Ebene (Laufzeit drei bis fünf Wochen) pflegen wir einen Team-plan. Der Teamplan beantwortet die Frage: Wer tut was wann? Granularitäten jeweils: Mitarbeiter, Komponente/Thema, Woche.Das erfordert Mut zu Planungshypothe-sen, denn Teil des agilen Spiels ist es, un-terwegs leichtgewichtig umzupriorisieren. Das macht aber nichts, denn man startet zum Releasebeginn mit der zu diesem Zeit-punkt besten Planungshypothese und passt sie unterwegs an. Das ist besser, als keinen Plan zu haben. Komponenten der Soft-warearchitektur sind dabei eine geeignete

Agil zum Ziel:Sieben Erfolgsfaktoren für

agile GroßprojekteAgile Vorgehensmodelle funktionieren weitgehend reibungslos für kleine IT-Projekte. Eine Herausforderung

stellen agile Großprojekte dar, vor allem dann, wenn der Auftragnehmer ein agiles Festpreisgewerk verantwortet und die Schnittstellenpartner im Projektumfeld noch nicht auf agil getrimmt sind. Wir beschreiben in

diesem Beitrag sieben Erfolgsfaktoren für solche Projekte.

Agil zum Ziel: Sieben Erfolgsfaktoren für agile Großprojekte

32

http://www.qaware.de/http://scaledagileframework.com/

Abb. 1: Relevante Ebenen der Planung.

Planungseinheit, um Teilteams zu bilden und Parallelisierung in der Projektarbeit zu ermöglichen.

Protektion des Teams im SprintDer Teamplan wird verbindlich und hei-lig für den Scope des aktuellen Sprints: Das Team verpflichtet sich zu einer Was-serstandslinie im Backlog. Damit herrscht die Pflicht, alle Items oberhalb der Was-serstandslinie zu realisieren. Die optimale Sprint-Dauer beträgt in Großprojekten drei bis fünf Wochen. Kürzere Sprints erzeugen unserer Erfahrung nach zu viel Overhead beim Sprint-Wechsel und reduzieren die Produktivität. Wichtig: Nicht das gesam-te Team nimmt an der Sprint-Planung teil, sondern ein Planungsteam mit den relevan-ten Experten der Teilteams.Wir schätzen keine Storypoints, sondern Be-arbeitertage auf der Basis von detaillierten Stücklisten. Der Grund dafür ist einfach: Nimmt man Bearbeitertage als Metrik für die Komplexität, kann man unmittelbar da-mit planen; bei Storypoints hat man zum ei-nen das Problem der Kalibrierung im Projekt (unkalibrierte Storypoints sind weitgehend nutzlos) und zum anderen das Problem, dass man diese Metrik irgendwie auf Aufwand abbilden muss, um damit zu planen. Neben den Standard-Rollen im agilen Vorgehen gibt es nach wie vor bewährte Rollen: den Projektleiter, den technischen Chefdesigner und den fachlichen Chefdesigner.Als übergreifendes Planungswerkzeug hat sich ein einfaches Planungs-Excel hervor-ragend bewährt, auch für Teams mit 30 Mitarbeitern. Einen Issue Tracker setzen wir ein für die Beschreibung von Epics und User Stories, ebenfalls auch für die Koor-dination von Entwickler-Tasks auf Sprint-Ebene; ein Issue Tracker ersetzt aber nicht das Planungswerkzeug, das ist aus unserer Sicht ein weit verbreiteter Irrweg.

Restaufwandsschätzung und Wasser-standslinie zum RepriorisierenZwei wichtige Elemente zur Steuerung auf den Ebenen Release und Sprint sind: Wöchentliche Restaufwandsschätzung und Justierung der Wasserstandslinie, um Repriorisierungen gemeinsam mit dem Kunden gut auszusteuern. Als Berichts-werkzeug verwenden wir auch hier ein eta-bliertes Excel, das Auskunft gibt über den aktuellen und prognostizierten Fertigstel-lungsgrad, Risiken und Handlungsbedarfe. Basis dafür ist die wöchentlich aktualisierte Restaufwandsschätzung des verantwortli-chen Teilteams.

Neuralgischer Punkt: Kontinuierliche Justierung der PläneIn Summe ist man mit diesem Ansatz ei-nerseits sehr agil, denn Änderungen sind leichtgewichtig machbar; andererseits ist man gut geplant und gesteuert: Man kennt nicht nur den aktuellen Projektstatus, son-dern ist auch prognosefähig für das Ende von Sprint, Release oder Jahr, natürlich mit abnehmender Genauigkeit. Teil des agilen Spiels ist es, die Pläne kontinuierlich zu jus-tieren. Die Anpassung der Pläne auf Ebene Release und Jahres-Roadmap erzeugt in der Regel gesunde und konstruktive Reibung zwischen Projekt- und Linienorganisation. Diese Stelle ist ein neuralgischer Punkt für jedes Unternehmen, das Mut hat zu agilen Projekten.Unsere Erfahrung dazu: Gerade die Wi-derstände an diesem neuralgischen Punkt bringen die Organisation voran, beide Seiten müssen Planungskompromisse ein-gehen und kontinuierlich um die richtige Priorisierung ringen. Das ist gut und ein wesentlicher Beitrag des agilen Vorgehens zur Verbesserung der Organisation: Man steuert kontinuierlich nach und vermeidet späte unangenehme Überraschungen im Projektverlauf!Diese Ideen sind nicht neu, sondern orientie-ren sich an den skalierenden agilen Frame-works [Heu15]. Diese erweitern agile Vor-gehensmodelle so, dass sie auch in großen und komplexen Projekten funktionieren. Bekannte Vertreter sind das Scaled Ag- ile Framework [SAFe], Large-Scale Scrum [LeSS] und Disciplined Agile 2.0 [DA]. Urva-ter der agilen Planung auf mehreren Ebenen ist aber wohl die Planning Onion [Kum11]. Die Kritik mancher Agil-Puristen an diesen Frameworks ist deutlich [Sed14], mit nüch-ternem Blick und Besinnung auf die agilen Werte [FoHi01, WiCo03] erkennt man aber den Mehrwert solcher Ansätze [Sed14].Unser Fazit zur Planung in agilen Projek-ten: Mut zur Planung auf allen Ebenen! Man kann sehr agil und dennoch gut ge-plant und gesteuert im Projekt unterwegs sein. Das ist kein Widerspruch! Was wir

bewusst nicht tun: Planning Poker im Ge-samtteam, schätzen in Story Points, hoffen auf Selbstorganisation eines großen Teams (20-30 Mitarbeiter) by magic.

Erfolgsfaktor 2: Frontrunner und Mini-SpecsDer Weg vom fachlichen Problem zur tech-nischen Lösung ist bei nichttrivialen Syste-men lang und steinig. Hundert User Stories ergeben nicht automatisch ein sinnvolles Ganzes und die Baubarkeit ist a priori nicht klar. Insofern ist für ein Feature der Schritt vom fachlichen Problemraum in den techni-schen Lösungsraum innerhalb eines Sprints in der Regel viel zu groß; das funktioniert gut in kleinen und fachlich trivialen Projek-ten; in großen Projekten riskiert man damit unnötig Projektverzug oder gar Scheitern.Unser Trick in komplexen Großprojekten: Frontrunner machen auf zwei zeitlichen Ebenen den Weg für das Entwicklerteam frei und sichern die Baubarkeit der User Stories im Sprint ab.Die erste Ebene des Frontrunning: Ein Ex-plorationsteam arbeitet immer ein Release voraus, klärt die Fachlichkeit, erarbeitet ein grobes Lösungskonzept, schließt Kontrakte mit den oft nicht agilen Schnittstellenpart-nern in der Linie und sichert die technische Machbarkeit durch Proof of Concepts (PoCs) ab. Die zweite Ebene des Frontrunning: Ein Konzeptteam arbeitet mindestens einen Sprint voraus und schreibt sogenannte Mi-ni-Specs, die die Baubarkeit der User Stories sicherstellen. Die Mini-Specs sind möglichst leichtgewichtige Konzeptionsartefakte, die beschreiben, was die fachlichen Anforde-rungen sind (Epics, User Stories) und wie die fachliche Lösung (UI Mockups, Use Ca-ses, Workflows, ER-Modelle usw.) und die technische Lösung (Datenmodelle, Schnitt-stellen, IT-Architektur, Komponentenschnitt usw.) aussehen sollen. Bewährt hat sich ein Wiki als Dokumentationswerkzeug.Wichtig ist: So wenig wie möglich, so viel wie nötig dokumentieren, und zwar genau im Hinblick auf die Baubarkeit durch das

04/2016 33

www.objektspektrum.de

4/2013

schwe rpunk t

beziehen. Test werk zeuge sind hierzu nichtin der Lage. Aus unserer Sicht ist ein voll-ständig automatisierter UAT auch in deragilen Welt nicht seriös durchführbar – aus-genommen automatisierte Smoke-Tests, diedie Vollständigkeit der Funk tio nalität ober-flächlich prüfen. Gele gentlich werden auto-matisierte GUI-Tests (Graphi cal-User-Interface) als UAT bezeichnet. Diese Testssind funktionale Tests unter Einbeziehungeiner Oberfläche und können zum Beispielim Regressionstest einen wertvollen Beitragleisten. Sie sind aber kein Er satz für dieEinbeziehung des Menschen als Tester.

Ein Fokus des UAT liegt auf der Instal -lierbarkeit der Software. Diese lässt sichleicht in Kombination mit der obenbeschriebenen automatisierten Prüfung aufVollständigkeit anwenden: Wenn dieserSmoke-Test erfolgreich war, ließ sich dieSoftware offenbar erfolgreich installieren.

Ziel des UAT ist es, die Benutzbarkeit einerSoftware zu prüfen. Aus eigener Erfahrungwissen wir, dass für einen erfolgreichen UATin allen Teststufen gewissenhaft gearbeitetwerden muss. Für Ent wickler gibt nichtsSchlimmeres als einen UAT, der von denTestern oder vom Kunden nach wenigenMinuten abgebrochen wird, weil viele offen-sichtliche Fehler in den vorherigen Teststufennicht entdeckt wurden und der Softwaremangelnde Qualität bescheinigt wird.

Last und Performance-TestsDie Teststufe Last- und Performance-Testsdient im Wesentlichen dazu, drei nicht-

Iteration knapp wird. Das führt zu einemgefährlichen Trugschluss: Wenn es akzep-tabel ist, manuelle Tests im Notfall wegzu-lassen, sind sie scheinbar nicht wichtig.

Auch in der agilen Welt ist es der Zweckvon Tests, Fehler in der Software zu finden.Wenn automatisierte Tests dazu nurbedingt in der Lage sind, gibt es lediglicheine Alternative: manuelles beziehungs-weise exploratives Testen, bei dem dieTester ihre Kreativität und Spontanität ein-setzen, um Fehler zu finden. Ein wesent-licher Nutzen manueller Tests – besondersbei neuen Features – ist die kontextbezoge-ne Perspektive auf die zu prüfendeFunktionalität. Denn im Gegensatz zuautomatisierte Tests kennt der manuelleTester deren aktuellen Kontext.

Wenn es Kunde und Budget zulassen,planen wir am Ende einer Iteration für alleEntwickler einen Tag ein, dessen Fokus aufmanueller Testdurchführung liegt. Ziel die-ses Tages ist es, die Software zerbrechen zulassen. Gelingt es, den Code durch Benut -zer eingaben oder Datenkonstellationen zuzerbrechen, wird für die Situation, die dazugeführt hat, ein automatisierter Testgeschrieben. Anschließend wird der Man -gel nach voll ziehbar behoben und mit demautomatisierten Test dafür gesorgt, dass dieso ge wonnene höhere Robustheit erhaltenbleibt.

Plädoyer für Nicht-AutomatisierungWenn die geforderte Funktionalität imple-mentiert wurde, also sämtliche automati-sierte Tests durchgeführt und um eventuellnotwendige manuelle Tests der neuenFeatures ergänzt wurden, schließt sich eineweitere manuelle Stufe an.

Der User-Acceptance-Test (UAT) dientdazu, eine Software unter realen Bedin gun -gen zu testen und zu prüfen, ob eineSoftware effizient und effektiv genutzt wer-den kann. Software, die für Endanwendergedacht ist, muss bei dieser Testart vomBenutzer selbst geprüft werden. Dazu ist esnotwendig, den fachlichen Kontext der zuprüfenden Soft ware zu kennen und einzu-

gehensweise, wenn die Erweiterung durchUmpriorisierung doch nicht stattfindet unddie Tests weiterhin manuell durchgeführtwerden müssen.

Aus unserer Erfahrung lohnt sich einesprechende, nachvollziehbare Zuordnungvon Anforderungen (User-Storys) undAkzeptanztests. Wird eine Anforderungverändert oder erweitert, fließt der Auf -wand für eine notwendige Anpassungbestehender Akzeptanztests mit in dieSchätzung ein. Gibt es außerhalb desEntwicklungsteams Interessenten für dieAkzeptanztest-Kriterien, erhalten diesewertvolles Feedback zu den Auswirkungender Änderung. Können Anforderungen undAkzeptanztests einander nicht zugeordnetwerden, kommt das böse Erwachen bei derEntwicklung: Die Änderungen dauern fünfMinuten, das Anpassen der fehlgeschlage-nen alten Akzeptanztests zwei Tage.

Manuelle TestsManuelle Tests sind auch in agilen Pro -jekten wichtig. Sie schließen die Lücke zwi-schen automatisierten Tests und aufwändigoder gar nicht automatisiert prüfbarenAnforderungen. Dabei können manuelleTests zeitaufwändig und fehleranfällig sein.Auch in der agilen Welt neigen Projekt -teams dazu, manuelle Tests zu vernachläs-sigen, wenn die Zeit am Ende einer

Tipp 4: Abnahmetests sollten immergrün sein – Zero Bug Policy.Auch wenn das Release noch ein paar Wochenentfernt sein mag, ist es sehr wichtig, Testfällenicht länger als notwendig fehlschlagen zu lassen– auch wenn man die vermutliche Ursache kennt.Ein fehlschlagender Testfall kann durchausProbleme verdecken, die erst nach Behebung deroffensichtlichen Ursache zu Tage treten. Ziel desTeams muss es sein, die Testfälle auch währendder Entwicklung grün zu halten. Grün bezieht sichhier auf die Signalfarben, die traditionell in Build-Umgebungen eingesetzt werden.

Tipp 5: Pair-Testing im UAT.User-Acceptance-Tests sollten dabei niedurch die Softwareentwickler durchge-führt werden. UAT mittels Pair-Testing hatsich dagegen bewährt. Hier führt einBenutzer den UAT durch, der Entwicklersitzt daneben und bekommt direkt wert-volles Feedback zur Benutzbarkeit seinerArbeit. Im Idealfall ist dieser Tester derKunde selbst oder ein Mitarbeiter mit tie-fem fachlichen Wissen, aber keinen weite-ren Kenntnissen über den Quellcode.

Tipp 6: Zeitnaher UAT.Während der UAT in der klassischenProjektwelt eine abgeschlossene Phasedarstellt, bietet es sich in agilen Projektenan, unmittelbar nach dem Abschluss einerFunktionalität Nutzer-Feedback einzuho-len. Will der Entwickler in Folge desFeedbacks Änderungen vornehmen, istseine Arbeit effektiver als nach einemUAT-Feedback mehreren Wochen.

OBJEKTspektrum ist eine Fachpublikation des Verlags:

SIGS DATACOM GmbH · Lindlaustraße 2c · 53842 TroisdorfTel.: 0 22 41 / 23 41-100 · Fax: 0 22 41 / 23 41-199 E-mail: info@sigs-datacom.dewww.objektspektrum.dewww.sigs.de/publications/aboservice.htm

sonderdruck_anger_eichler_OS_04_13: orange_OS_05_09.qxd 07.02.14 07:52 Seite 5

Entwicklerteam. Stellt man dies sicher, ist die Produktivität im Gesamtteam gesichert. Unterlässt man das, droht Stau oder Still-stand. Die Maschine muss ständig geölt werden, und die Frontrunner sorgen dafür.

Q-Check zur Definition of Ready (DOR)Eine User Story wird erst umgesetzt, wenn für sie eine Mini-Spec vorliegt und für diese ein sogenannter Q-Check durch den Auftraggeber stattgefunden hat. Dieser Q-Check ist leichtgewichtig, aber essenziell für den Auftraggeber: Er stellt sicher, dass das Richtige getan wird, aus fachlicher und technischer Sicht. Er dient zur Definition of Ready (DOR) für eine User Story.Abbildung 2 zeigt die typischen Ergebnis-se im Frontrunning im Problem- und Lö-sungsraum sowie aus fachlicher und tech-nischer Sicht.Ein akademisch anmutender, aber in der Praxis sehr wirkungsvoller Rat ist, im Pro-jekt ein Artefaktmodell zu etablieren, um die Erwartungshaltung an die Rollen und den Schnitt der Artefakte transparent zu machen. Ein Beispiel: Es ist sehr hilfreich für die Autoren von User Stories zu wissen, dass eine User Story zum Beispiel innerhalb eines Sprints gebaut werden soll. Das kali-briert die Granularität der User Stories und vermeidet Frust im Entwicklerteam, weil

wieder einmal ein völlig unrealistisches Wunschkonzert auf ihrem Hof landet.

Erfolgsfaktor 3: Zeitfresser und Produktivitätskiller eliminierenZeitfresser: Meetings ohne AugenmaßAgile Vorgehensmodelle sehen zahlreiche Meetings vor, viele davon mit dem gesam-ten Team: Sprint-Plannings, Sprint-Re-views, Retrospektiven, Backlog-Groomings usw. Das kostet Zeit. Kommunikation ist

wichtig, aber wenn jeder alles mit jedem be-spricht, bleibt keine Zeit mehr zum Arbei-ten. Hier sind unsere Best Practices (siehe Abbildung 3):

n Sprints dauern drei bis fünf Wochen, nur im Ausnahmefall weniger. Das re-duziert den Overhead, ohne die Agilität spürbar zu beeinträchtigen.

n Für die agilen Regelmeetings gilt der Grundsatz: So viele Teilnehmer wie nö-tig, so wenig wie möglich; die Auswahl

34

Agil zum Ziel: Sieben Erfolgsfaktoren für agile Großprojekte

Abb. 2: Vom fachlichen Problemraum zum technischen Lösungsraum in zwei Schritten.

Abb. 3: Mittel gegen zu hohen Meeting-Aufwand.

der Teilnehmer erfolgt mit Augenmaß und Blick auf Aufwand und Nutzen: Im Daily nehmen zum Beispiel alle Team-mitglieder teil, beim Sprint-Planning aber nicht.

n Bienenprinzip: Ausschwärmen, um in Kleingruppen gute Lösungen zu erar-beiten, zusammenkommen, um das Wissen im Gesamtteam zu verteilen. Unsere Erfahrung: Große Gruppen fin-den meist keine guten Lösungen, son-dern bestenfalls gute Kompromisse; und sie verbrennen dabei viel Aufwand und damit Geld.

n Hartes Timeboxing im Daily: Eine Eier-uhr hilft, 20 Minuten reichen. Auch für 30 Mitarbeiter.

Produktivitätskiller: Ungesteuerte UnterbrechungenMan weiß, dass Unterbrechungen echte Pro-duktivitätskiller sind [Ade15]: Der Kontext-Switch ist für unser Gehirn anstrengend. Software-Engineering ist aber eine sehr an-spruchsvolle Tätigkeit, die Ruhe und Kon-zentration erfordert (siehe Abbildung 4).Wenn das Entwicklerteam produktiv arbei-ten soll, sollte der Projektleiter dafür sor-gen, dass es entsprechend geschützt wird: Ad-hoc-Einsteuerungen von der Seite soll-te man vermeiden; einfache Mechanismen am Arbeitsplatz helfen zu signalisieren, ob man gerade gestört werden kann oder nicht (z. B. eine Ampel auf dem Schreibtisch oder ein Kopfhörer). Und last not least: Der

04/2016 35

www.objektspektrum.de

Sprint-Scope sollte auch aus diesem Grund geschützt werden. In diesem Kontext eben-falls wichtig: Sorge für optimale Arbeits-bedingungen des Teams, das motiviert und stellt die Produktivität sicher. Beispiele: Beamer, Leinwände, Flipcharts, Ventila-toren, Obst, Kaffeemaschine, Getränke, Räume. Das klingt alles einfach, ist aber in Konzernen nicht immer leicht zu organisie-ren. Abhilfe: Selber mitbringen.

Erfolgsfaktor 4: Softwarequalität als Gegenpol zu Feature-GierProduct Owner neigen dazu, die kom-plette Entwicklungskapazität stets in die Entwicklung von Features investieren zu wollen (das ist ihr Job); wenn man dieser Neigung ungesteuert nachgeht, entstehen Qualitätsschulden [Ade15]; sowohl das System als auch die Produktivität im Team wird dann degenerieren. Systeme benötigen Phasen, in denen vermindert neue Features entwickelt werden und das System gehärtet wird. Es braucht also einen Gegenpol zur Feature-Gier. Gute Lösungen hierfür sind:

n ein Qualitäts-Backlog mit ca. 20 Pro-zent der Sprint-Kapazität,

n Härtungs-Sprints,n einen Bug Hunting Day/Quality Day,n ein vertraglich vereinbarter Qualitäts-

kontrakt auf Basis messbarer Kennzah-len zur Produktqualität (KPIs) und

n eine umfassende Definition of Done, zu der auch der Qualitätskontrakt gehört

Abb. 4: Produktivitätskiller.

Abb. 5: Omnipräsenz der Produktqualität sicherstellen.

Die Omnipräsenz von Kennzahlen zur Produktqualität trägt maßgeblich zur Qua-lität der Software und zur Produktivität des Teams bei (siehe [Ade15] und Abbil-dung 5). Qualität zahlt sich schnell aus. Im Projekt messen und visualisieren wir die Produktqualität automatisch und kon-tinuierlich mit unserem QAradiator, der auf SonarQube (www.sonarqube.org) und Jenkins (jenkins.io) aufsetzt. Die wichti-gen Kennzahlen zur Produktqualität sind verbindlich zwischen Auftraggeber und Auftragnehmer im sogenannten Qualitäts-kontrakt vertraglich vereinbart. Damit die Kennzahlen und ihr zeitlicher Verlauf über die letzten Wochen jederzeit für das gesam-te Team sichtbar sind, zeigen wir sie auf großen Bildschirmen auf der Projektfläche an. Außerdem verwenden wir eine LED am Notebook, die direktes Feedback zum Qua-litätsstatus gibt.

stein technisch auf Herz und Nieren ge-prüft, auch auf Performanz unter Last? Ist der Nachweis der Compliance vollständig? Sind die Lizenztexte lizenzgemäß hinter-legt? Sollte auf eine aktuellere Version mi-griert werden?Beherrscht man das, bringt der Einsatz von Open-Source-Komponenten einen enormen Produktivitätsvorteil. In unseren Projekten setzen wir oft mehr als 50 Open-Source-Bibliotheken ein; die Fertigungstiefe liegt dann meist deutlich unter 10 Prozent.Software-OEM hat per se keinen Zusam-menhang mit agilen Projekten. Hier ist dieser Ansatz aber besonders nützlich, da man gerade bei agilen Projekten auf hohe Geschwindigkeit angewiesen ist.

Erfolgsfaktor 6: Absicherung der Qualität durch TestautomatisierungAnwendungen mit vielen Tausend Benut-zern müssen eine hohe Produktqualität be-sitzen. Insbesondere bei großen agilen Pro-jekten ist eine Automatisierung von Tests auf allen Ebenen (siehe Abbildung 6) über-lebenswichtig, um eine hohe Produktquali-tät sicherzustellen. Testautomatisierung ist inzwischen Standard bei Unit- und Integra-tionstests, aber noch lange nicht bei Akzep-tanz- und UI-Tests.Testautomatisierung funktioniert aber auch bei Akzeptanz- und UI-Tests hervorragend und erhöht die Qualität enorm. Der Einsatz von automatisch ausführbaren, natürlich-sprachigen Testspezifikationen auf Basis

36

Agil zum Ziel: Sieben Erfolgsfaktoren für agile Großprojekte

Erfolgsfaktor 5: Rekordgeschwindigkeit durch den Software-OEM-AnsatzFür viele gängige Programmiersprachen gibt es ein reiches und auch weitgehend reifes Open-Source-Ökosystem. Software-OEM [Ade15] bedeutet: Software mit ge-ringer Fertigungstiefe auf Basis von Open-Source-Komponenten entwickeln. Dies kann die Produktivität massiv erhöhen, erfordert allerdings spezielle Fertigkeiten in Auswahl, Integration und Pflege von Open-Source-Bausteinen.Die Kernfragen lauten: Lohnt sich der Ein-satz? Ist eine Freigabe beim Auftraggeber erforderlich? Ist die Lizenz geeignet für den Einsatz im Projekt? Welche Sicherheitspro-bleme gibt es? Wie aktiv ist die Community für den Baustein?Für die Integration ist zu entscheiden: enge Bindung oder lose Kopplung? Ist der Bau-

Abb. 6: Testebenen und Testautomatisierung.

Abb. 7: Automatisierte Akzeptanztests.

von Mini-Specs und daraus abgeleiteten Akzeptanzkriterien trägt wesentlich zur Produktqualität bei (siehe Abbildung 7). In unseren Projekten verwenden wir dafür Cucumber (cucumber.io), ein quelloffenes Werkzeug, mit dem Testfälle in natürlicher Sprache formuliert werden können.Es müssen neben funktionalen Tests auch nicht-funktionale Tests automatisiert wer-den, um die Produktqualität zuverlässig nachweisen zu können. Dies sind insbeson-dere Performanztests und Security-Tests, die mittlerweile durch Werkzeuge wie Gat-ling (gatling.io) und ZAP (github.com/zap-roxy/zaproxy) ebenfalls gut automatisiert werden können.

Erfolgsfaktor 7: One Team ApproachLast not least ein ganz entscheidender Er-folgsfaktor in unseren Projekten: Trotz kla-rer Auftragslage über ein inhaltlich verbind-liches Festpreisgewerk sind Firmengrenzen in der Teamzusammenarbeit absolut sekun-där. Was zählt, ist der gemeinsame Projekter-folg. Daran arbeiten alle, Auftragnehmer wie Auftraggeber. Reibung und Konflikte sind das nötige Salz in der Suppe, was zählt, ist die konstruktive Arbeit an der Lösung der zahlreichen Herausforderungen, die sich in einem agilen Großprojekt stellen.Dies erfordert: Mut zur offenen Reibung, Transparenz auf beiden Seiten, konstrukti-ver Umgang miteinander, politikfreie Zone im Team (Protektion des Teams durch das Management) und das Mandat zur Lö-sung für das Projektteam (klingt trivial, ist aber nicht selbstverständlich). Und auch: Eine Projektkultur, die Fehler und Lernen erlaubt (getreu dem Prinzip „inspect and adapt“); und die den Freiraum schafft, er-reichte Erfolge gemeinsam zu feiern.

FazitKlassische agile Vorgehensweisen wie Scrum liefern keine angemessene Antwort auf die Frage, wie man in Großprojekten agil sein kann. Die Kernkritik in manch agilem Ab-gesang [Ker16] dieser Tage ist, dass die klas-sischen agilen Vorgehensmodelle die Dinge über-simplifizieren, also unterhalb der für viele Projekte notwendigen Komplexität an-setzen. Ein paar Kniffe muss man sich also überlegen, um die Erfolgsrezepte von agilen Vorgehensweisen übertragen zu können auf große und komplexe Projektorganisationen:

n Mut zur Planung trotz Agilität, im Ide-alfall auf den Planungsebenen Sprint, Release, Roadmap und Produktvision.

n Frontrunning, Mini-Specs und Defini-tion of Ready (DOR), um die Baubar-keit von User Stories im Sprint sicher-zustellen.

n Effiziente Meeting-Strukturen und un-terbrechungsarmes Arbeiten, um die Produktivität im Team sicherzustellen.

n Einen Gegenpol zur Feature-Gier eta-blieren, um Qualitätsschulden zu ver-meiden.

n Open-Source-Software professionell als Software-OEM einsetzen, um schnell in der Entwicklung zu sein.

04/2016 37

www.objektspektrum.de

Literatur & Links

[Ade15] J. Adersberger, Software-Industrialisierung: Wie industrialisiert man Wissensarbeit?,

in: Marktplätze im Umbruch, Springer Vieweg, 2015

[DA] Disciplined Agile 2.0, siehe: http://www.disciplinedagiledelivery.com

[Din12] T. Dingsøyr, S. Nerur, V. Balijepally, N. B. Moe, A decade of agile methodologies:

Towards explaining agile software development, in: Journal of Systems and Software, Volume

85, Issue 6 (2012)

[DyDi08] T. Dybå, T. Dingsøyr, Empirical studies of agile software development: A systematic

review, in: Information and Software Technology, Volume 50, Issues 9–10 (2008)

[FoHi01] M. Fowler, J. Highsmith, The agile manifesto, in: Journal of Software Development,

2001

[Heu15] M. Heusser, Comparing Scaling Agile Methods, CIO.com, 21.8.2015, siehe:

http://www.cio.com/article/2974436/agile-development/comparing-scaling-agile-

frameworks.html

[Ker16] M. Kern, Agile is Dead, LinkedIn Pulse, 20.4.2016, siehe:

https://www.linkedin.com/pulse/agile-dead-matthew-kern

[Kum11] Y. Kumbar, 6 Levels of Agile Planning, siehe:

http://www.agilehelpline.com/2011/04/6-levels-of-agile-planning.html

[LeSS] Large-Scale Scrum, siehe: https://less.works

[SAFe] Scaled Agile Framework, siehe: http://scaledagileframework.com

[Sed14] T. Sedge, In defence of the Scaled Agile Framework, 15.7.2014, siehe:

http://www.ambitiousmanager.com/defence-scaled-agile-framework-safe

[WiCo03] L. Williams, A. Cockburn, Guest Editor‘s Introduction: Agile Software Develop-

ment: It‘ s about Feedback and Change, in: IEEE Computer, 2003

|| Christian Kamm (christian.kamm@qaware.de) ist Geschäftsführer bei QAware. Als Projekt- manager verantwortet er seit über zehn Jahren agile Großprojekte bei verschiedenen DAX- Unternehmen.

|| Dr. Josef Adersberger (josef.adersberger@qaware.de) ist technischer Geschäftsführer bei QAware. Agile Vorgehensmodelle und agile Praktiken für das Software-Engineering sind seine Schwer-punkte in Forschung, Lehre und Praxis.

Die Autoren

n Testautomatisierung zur Qualitätssi-cherung einsetzen, auch für Akzeptanz-tests, um Produktqualität sicherzustel-len.

n Dem Projektteam das Mandat zu Lö-sung geben und Projekterfolge feiern.

All dies sind aus unserer Sicht Erweite-rungen von agilen Vorgehensweisen, die der agilen Idee treu bleiben – genau wie wir es auch von den skalierenden agilen Frameworks [Heu15, SAFe, LeSS, DA] kennen. ||

QAware GmbH München

Aschauer Straße 32

81549 München

Tel.: +49 (0) 89 23 23 15 – 0

Fax: +49 (0) 89 23 23 15 – 129

Mail: info@qaware.de

QAware GmbH Mainz

Rheinstraße 4 D

55116 Mainz

Tel.: +49 (0) 6131 215 69 – 0

Fax: +49 (0) 6131 215 69 – 68

Mail: info@qaware.de

IT-Probleme lösen. Digitale Zukunft gestalten.

OS-Anzeige.indd 1 13.06.2016 14:51:24