Agile Arbeitsweisen in Projekten stellen eine eigene Kultur im Denken und Handeln von Projekten zur Entwicklung von Software- und Organisationsprozessen oder auch Produkten dar. Bessere Entwicklungsergebnisse für den Kunden oder Auftraggeber sind die Erfolge im agilen Softwareprojekt. Alle Projektbeteiligte leben die agilen Spielregeln im Sinne des gemeinsamen Ziels. Laufend werden untereinander die gerade geübten Methoden diskutiert und so direkt verbessert. Und schließlich berichten die mitwirkenden Personen von einer tollen Arbeitsatmosphäre.

Agile Spielregeln
Die nachgewiesenen Erfolge der agilen Arbeitsweise, gerade in der Entwicklung von Innovationen mit Forschungscharakter ist Motivation für diese Arbeitsweise. Wir haben für uns ein Drehbuch entwickelt, wie wir in Organisationsprojekten und der damit verbundenen Softwareentwicklung arbeiten.

Das Manifest für Agile Softwareentwicklung
Im „Manifest für Agile Softwareentwicklung”¹ aus dem Jahr 2001 legen die Autoren fest:

„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:

• Individuen und Interaktionen mehr als Prozesse und Werkzeuge
• Funktionierende Software mehr als umfassende Dokumentation
• Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlung
• Reagieren auf Veränderung mehr 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.”

Die 12 Prinzipien hinter dem Agilen Manifest
Dazu gelten die 12²  „Prinzipien hinter dem Agilen Manifest”³  

„Wir folgen diesen Prinzipien:

1. Unsere höchste Priorität ist es, den Kunden durch frühe und kontinuierliche Auslieferung wertvoller Software zufrieden zu stellen.
2. Heisse Anforderungsänderungen selbst spät in der Entwicklung willkommen. Agile Prozesse nutzen Veränderungen zum Wettbewerbsvorteil des Kunden.
3. Liefere funktionierende Software regelmäßig innerhalb weniger Wochen oder Monate und bevorzuge dabei die kürzere Zeitspanne.
4. Fachexperten und Entwickler müssen während des Projektes täglich zusammenarbeiten.
5. Errichte Projekte rund um motivierte Individuen. Gib ihnen das Umfeld und die Unterstützung, die sie benötigen und vertraue darauf, dass sie die Aufgabe erledigen.
6. Die effizienteste und effektivste Methode, Informationen an und innerhalb eines Entwicklungsteams zu übermitteln, ist im Gespräch von Angesicht zu Angesicht.
7. Funktionierende Software ist das wichtigste Fortschrittsmaß.
8. Agile Prozesse fördern nachhaltige Entwicklung. Die Auftraggeber, Entwickler und Benutzer sollten ein gleichmäßiges Tempo auf unbegrenzte Zeit halten können.
9. Ständiges Augenmerk auf technische Exzellenz und gutes Design fördert Agilität.
10. Einfachheit — die Kunst, die Menge nicht getaner Arbeit zu maximieren — ist essenziell.
11. Die besten Architekturen, Anforderungen und Entwürfe entstehen durch selbstorganisierte Teams.
12. In regelmäßigen Abständen reflektiert das Team, wie es effektiver werden kann und passt sein Verhalten entsprechend an.”

Der Scrum Guide für agile Projekte
Aus dem Manifest für Agile Softwareentwicklung und den Prinzipien wurden verschiedene Organisationswerkzeuge ursprünglich für die Softwareentwicklung entwickelt. „Scrum”⁴   ist ein weltweit bekanntes Organisationswerkzeug für Projekte, dessen Ursprünge zeitlich vor dem Manifest liegen, das das Manifest selbst beeinflusste und schließlich die Anwendung der Prinzipien hinter dem Agilen Manifest konsequent im Scrum Guide⁵ abbildeten. Eine umfassende deutschsprachige Beschreibung zum allgemeinen Einsatz von Scrum in Projekten stellt Scrum Academie⁶ bereit.

Unsere Agile Projektorganisation
Für die Umsetzung von Organisationsprojekten und damit verbundener Softwareentwicklung setzen wir immer wieder eine Projektorganisation ein, die Geist und Ziele des Agilen Manifestes, dessen Prinzipien zusammen mit Elementen von Scrum wirken lässt.

Projektziel klar festlegen
Das Projektziel wird klar, eindeutig und einem vollständigen deutschen Satz beschrieben. Es gilt das Beispiel des ägyptischen Pharao Cheops, der bei seiner Thronbesteigung dieses Projektziel ausgab: „Der Pharao wird in einem Grabmal beigesetzt, das größer ist als das seines Vaters.” Damit war der Auftrag zum Bau der Cheopspyramide klar beschrieben. Das Projektziel ist Voraussetzung, dass alle projektbeteiligten Personen und Organisationseinheiten für sich daraus ihren Beitrag zur Erreichung des Projektziels erkennen oder entwickeln können. Damit wird auch deutlich, dass die Verantwortung für das Erreichen des Projektziels im Zusammenwirken der Projektbeteiligten liegt.

Rahmenbedingungen für das Projekt identifizieren
Auf das Projekt wirken Rahmenbedingungen, die die Umsetzung und das Erreichen des Projektziels wesentlich beeinflussen oder beeinflussen können. Das möglichst vollständige Erkennen der Rahmenbedingungen ist der entscheidende Punkt für Risiken im Projekt. Bei erkannten Rahmenbedingungen fließen diese in die Projektorganisation und die Umsetzung mit ein. Nicht erkannte Rahmenbedingungen können zu spontanen Störungen, bis hin zu einem Abbruch führen. Jede auch im Rahmen der Umsetzung des Projekts erkannte neue Rahmenbedingung wird sofort in die Sammlung aufgenommen und führt gegebenenfalls zu neuen Aktivitäten.

Projektteam bereitstellen
Das Projektteam für agile Arbeitsweisen organisiert sich im Rahmen der Spielregeln selbst. Die fest besetzten Rollen in der Projektorganisation sind vorgegeben. Sie sichern die klare Steuerung hin auf das Projektziel und unterstützen alle Personen, die im Projekt mitwirken bei der Verfolgung der Arbeitsweisen im Denken und Handeln. Dieses gegenseitige Helfen stellt das genaue Gegenteil zum heute immer wieder erkannten Verhalten der Schuldzuweisung dar. Gegenseitiges Helfen ist damit das Erfolgskriterium für ein agiles Projekt.

Rahmentermine setzen
Ein Projekt, zu deutsch: Vorhaben, wird definiert durch ein Projektziel und einen Termin für Start und Ende. Dies ist auf der einen Seite ein vermeintlicher Widerspruch gerade in Entwicklungsprojekten, da zu Beginn nicht bekannt ist, oft gar nicht bekannt sein kann, wie hoch der Aufwand für die einzelnen Aktivitäten sein wird. Umso mehr greift in agilen Projekten das Time-Boxing. Für einzelne Aktivitäten, Teilziele und damit auch das Gesamtprojekt werden Rahmentermine gesetzt. Innerhalb dieser Termine wird dann jeweils festgelegt und auch nachjustiert, was erreicht werden kann.

Projektbudget bereitstellen
Die Bereitstellung eines realistischen Projektbudgets erfolgt auf Grundlage der in einzelnen Timeboxen vorgesehenen Teilzielen und anderer Zwischenstufen. Dabei werden alle erforderlichen Ressourcen ermittelt und mit ihrem Zeitbedarf und erforderlichem Finanzaufwand einbezogen. Hinzu kommen Aufwendungen für Sachmittel. Das Projektbudget wird durch die Projektleitung selbst aufgestellt. Vorgaben, die unrealistisch sind oder „hingerechnet“ werden, erreichen selten das gewünschte Ziel. Mannigfaltige Kostenexplosionen und Terminverschiebungen in Bau- und Forschungsprojekten belegen dies. Die permanente Kontrolle des Projektbudgets widerspiegelt auch einen Blick auf den Fortschritt im Projekt. Das Budget für interne und externe Ressourcen zur Umsetzung eines agilen Projektes kann aus den einzelnen Teilprojekten (Projektabschnitten, Sprints, u. ä.) und die Mitwirkenden im Projektteam sowie weiterer Quellen (temporäre Mitwirkung) ermittelt werden. Ein realistisches Projektbudget, das von der Projektleitung ermittelt wird, ist Voraussetzung für ein kontinuierliches Arbeiten. Unrealistische Vorgaben für ein Projektbudget sind immer wieder zu beobachten, führen aber in keiner Weise zu einer damit bezweckten Reduzierung des Aufwands. Mannigfaltige Beispiele in Bauprojekten, Entwicklungsprojekten und anderen Innovationen sprechen für sich.

Organisation des Projekts in Sprints
Wir organisieren agile Projekte in Sprints. Diese Sprints können als kleine Teilprojekte verstanden werden. Sie haben ein eigenes Ziel, eine fest vorgegebenen Dauer (Time-Boxing) und ein einsetzbares, funktionierendes Ergebnis. Die Planung eines Sprints erfolgt für jeden Sprint zu dessen Beginn durch das Projektteam. Dabei werden aus einem Vorrat von Anforderungen mehrere Anforderungen in den Sprint aufgenommen. Anforderungen sollen durch Einfachheit bestechen. Dies stellt eine tatsächliche Eleganz, nicht nur in Projekten, sondern auch im Projektergebnis sicher. Ingenieurinnen und Ingenieure streben elegante und somit einfache Lösungen in ihrem Arbeiten an. Aus den Anforderungen werden einzelne Aufgaben (Aktivitäten, Tasks) ermittelt. Diese werden in klare, feststellbare Pakete heruntergebrochen. Idealerweise führen sie immer zu einem Teil einer Anforderung. So sind Formulierungen in einer Aufgabe, die tatsächlich zwei Aufgaben durch ein „und“ verbinden, ein Indiz, dass es tatsächlich zwei Aufgaben sind.

Abbildung: Muster für die Organisation eines Sprints Quelle: Rösch Unternehmensberatung

Zum Abschluss eines Sprints wird das Ergebnis vorgestellt und bewertet. Die Vorstellung des Ergebnisses erfolgt durch die Anwendung der Funktionalität, nicht durch die Beschreibung des wie. Eine grundlegende Spielregel ist hierbei, dass es keine Rechtfertigung für tatsächliche oder vermeintliche Nichterfüllung von Aufgaben und / oder Anforderungen gibt. Es wird daraus gemeinsam gelernt, wie in Zukunft damit umgegangen werden kann.

Im Rückblick werden die Arbeitsweise und die Ergebnisqualität aus Sicht von jedem Teammitglied bewertet. Dies ist Ansporn und Hilfe, im nächsten Sprint diese Erfahrungen in geänderte, verbesserte Arbeitsweisen und Kommunikation einfließen zu lassen

Unser agiles Denken und Handeln in Projekten
Unser agiles Denken und Handeln in Projekten ist getragen vom Engagement der mitwirkenden Personen und dem gegenseitigen Respekt. Dieses stellt die Projektleitung durch die Zusammensetzung der mitwirkenden Personen sicher. Ganz besonders der Verzicht auf jegliche Schuldzuweisung, sondern das Grundprinzip des gemeinsamen Lernens und der gemeinsam gelebten Verbesserung in den Arbeitsweisen stellen die Projektleitung vor eine Aufgabe, die Einfühlungsvermögen und gleichzeitig Konsequenz fordert. Das in der Tradition von Projekten geübte Lauern auf Fehler anderer zum eigenen wirtschaftlichen Vorteil (Asset Management, Change Request, Nachträge) hat in einem agilen Projekt keinen Platz. Das Vertrauen in das Gesagte ist ein unumstößlicher Eckpfeiler in agilen Projekten. Die Feststellung von Zuständen erfolgt ohne Rechtfertigung. Rechtfertigungen sind der Anfang von Schuldzuweisungen oder der Rückgabe der Verantwortung.

Gemeinsame Arbeit von Kunden und Entwicklung
Agile Projekte sind nur in einer gemeinsamen Arbeit von Kunden und der entwickelnden Organisationseinheiten im Tagesgeschäft möglich. Die traditionelle Arbeitsweise mit der Festlegung von Anforderungen und Pflichten, womöglich im E-Mail-Pingpong und der seriell nachfolgenden Beurteilung des Ergebnisses widerspricht den Prinzipien. Vielmehr war diese traditionelle Form Auslöser für die Entwicklung der agilen Prinzipien.

Permanente Detaillierung und Justierung der Anforderungen
In einem Entwicklungsprojekt können nicht alle Anforderungen zu Beginn eines Entwicklungszyklus bekannt sein oder sie werden gar missverständlich beschrieben. Das Einbringen neuer Ideen aus der eigenen Erfahrung und / oder aus der gemeinsamen Arbeit ist ja genau das Ziel der agilen Arbeitsweise. Deshalb werden Anforderungen im Rahmen des Projektes permanent weiter detailliert und justiert. Es trifft nicht zu, dass eine solche Justierung zu einem Aufweichen des Projektziels führt. Am Beispiel des Projektziels Pyramide kann auch ein zylindrischer Baukörper das Projektziel „größer als” sein.

Laufende Weiterentwicklung der Lösungswege
Im Rahmen der Umsetzung des Projektes werden laufend die Lösungswege weiterentwickelt oder sogar neue Lösungswege eingebracht. Genau hier entsteht eine kreative Dynamik. Gerade die Diskussion und Abwägung unterschiedlicher, sich teilweise widersprechender Lösungsansätze führt zu kreativen, neuen Ideen. So kann eine grundlegende Änderung eines gewählten Lösungswegs tatsächlich nicht nur ein qualitativ besseres Ergebnis, sondern auch insgesamt ein schnelleres Erreichen des Projektziels bewirken. Und klar, es gehört Mut dazu, einen Lösungsweg zu verwerfen. Doch genau darin zeichnen sich die Personen in einem agilen Projekt aus.

Einfache Lösungen
Das Ziel wird mit einfachen Lösungen erreicht. Auf die berühmten „Sonderlocken” wird bewusst verzichtet. Das kann dazu führen, dass Rahmenbedingungen, die solche „Sonderlocken”, als Ausnahmen erfordern, bewusst ausgeklammert werden und / oder einer Überprüfung der tatsächlichen Notwendigkeit auch gegenüber dem Auftraggeber unterzogen werden. Ganz bewusst werden die einzelnen Ergebnisse einfach gehalten. Das ist nicht vergleichbar zu einem „Idealfall” (Sunshine Case), sondern zeigt gleichzeitig einen ideal und konsequent gestalteten Prozess auf.

Funktionierende Prozesse und Software in kurzen Abständen
Unsere Sprints führen in kurzen Abständen zu funktionierenden Ergebnissen. Die Dauer eines Sprints kann schon im Vorfeld auf zwei oder drei Wochen festgelegt werden. Bei umfassenden Projekten hat sich ein festes Raster von zwei bis drei Wochen, mit dazwischenliegenden festen Pausen, bewährt. Die laufende Bereitstellung der Ergebnisse und damit auch Übergabe an den Kunden oder Auftraggeber erzeugt Vertrauen in den Fortschritt und die Arbeitsweisen des Projektteams. Die Ergebnisse können direkt genutzt und für weitere Aktivitäten eingesetzt werden.

Qualität in Technik und Design
Die Qualität des Ergebnisses wird durch die Zielsetzung des Projektes festgelegt. Anerkannte Grundsätze fließen hier in die Definition ein, ebenso die Erwartung der Anwenderinnen und Anwender eines Prozesses.

Gegenseitige Unterstützung
Es wird aus guten und schlechten Erfahrungen im Projekt permanent gemeinsam gelernt, wie in Zukunft gearbeitet werden werden kann.

Unsere Einführung und Schulung durch Key-User
In Organisations- und Entwicklungsprojekten für Prozesse und Software bildet die Einführung in das Tagesgeschäft die tatsächliche Messlatte. Bewirkt der neue Prozess, unterstützt durch neue Software, das gesetzte Projektziel? Weitere Hinweise finden Sie unter „Key-User schaffen Akzeptanz für neue Software”.

Key-User für die Anforderungen
Bei der Ermittlung von Anforderungen wirken die Key-User mit. Ihr Schwerpunkt dabei ist das Herausarbeiten der fachlich, inhaltlich wesentlichen Prozess- oder Softwareergebnisse.

Key-User für die Gestaltung der Prozesse
Die Gestaltung der Prozesse erfordert eine Vorstellung der Durchführung im späteren Tagesgeschäfts durch oftmals eine Vielzahl von Anwenderinnen und Anwendern. Dabei spielt die Ergonomie sowohl der Prozesses als auch der Software eine entscheidende Rolle.

Key-User für die Entwicklung der Software
Wir empfehlen das Key-User-Prinzip zur Begleitung der gesamten Entwicklungs- und Einführungsphase. Key-User sind Mitarbeiterinnen und Mitarbeiter, die die mit einem Organisationsprojekt zu gestaltenden oder zu verändernden Prozesse fachlich oder inhaltlich kennen und gegebenenfalls auch selbst durchführen können. Gleichzeitig sind sie durch ihre Fähigkeiten in der Lage, in Veränderungen zu denken und damit traditionelle Arbeitsweisen zu durchbrechen. Damit sie dies leisten können, haben sie eine hohe soziale Akzeptanz innerhalb des Unternehmens oder der Organisationseinheit.

Key-User für den Aufbau und die Übernahme von Daten
In nahezu allen Organisations- und Entwicklungsprojekten, dazu zählt auch die Einführung von neuen Softwaremodulen, müssen vorhandene Daten aufbereitet und / oder übernommen werden. Dies bedingt eine strukturierte Kenntnis der bisherigen Daten, unabhängig ob diese analog oder elektronisch vorliegen und gleichzeitig das Wissen um die zukünftigen Strukturen. Die Erarbeitung eines Weges und die Umsetzung und Überwachung der Qualität kann eine sehr umfangreiche Arbeit darstellen.

Key-User für die Schulung der Anwenderinnen und Anwender
Key-User mit ihrer Kenntnis der heutigen Prozesse, der zukünftigen Prozesse und der zukünftigen Softwareunterstützung bereiten die Schulung der Anwenderinnen und Anwender vor, führen diese durch und stehen für die erste Betreuung in der Schulungs- und Einführungsphase zur Verfügung.

Endnoten

1. Manifest für Agile Softwareentwicklung https://agilemanifesto.org/iso/de/manifesto.html abgerufen am 01.03.2020
2. Die Nummerierung [01] bis [12] der Prinzipien ist hier zur Orientierung eingefügt.
3. Prinzipien hinter dem Agilen Manifest https://agilemanifesto.org/iso/de/principles.html abgerufen am 01.03.2020
4. Scrum https://de.wikipedia.org/wiki/Scrum abgerufen am 01.12.2019
5. Ken Schwaber and Jeff Sutherland. Offered for license under the Attribution Share-Alike license of Creative Commons, accessible at http://creativecommons.org/licenses/by-sa/4.0/legalcode abgerufen 01.12.2019
6. Scrum Academie, Scrum Guide https://www.agile-academy.com/de/grundlagen/scrum-guide abgerufen am 23.03.2020