"Nein, Ihr arbeitet ja nicht agil". Der Zuhörer reagiert auf eine Darstellung des Projekts. "Da fehlt doch XYZ der Methode ABC."
Die Debatte um agile Methoden verkommt leicht zu einer Prozess-Debatte, ohne das ein Blick auf das Wesentliche gelegt wird: die Kulturänderung, die agile Methoden einfordern, ermöglichen und erzwingen.
Das agile Manifest fordert einen Kulturschwenk
Die Benennung agiler Methoden beruht auf der gleichnamigen Bezeichnung im Agilen Manifest aus dem Jahr 2001. Die Autoren postulieren im Agilen Manifest einen "besseren Weg zur Software-Entwicklung" durch Wertschätzung bestimmter Werte:
| Individuen und Interaktionen | ist wichtiger als | Prozesse und Werkzeuge |
| Funktionierende Software | ist wichtiger als | eine umfassende Dokumentation |
| Zusammenarbeit mit dem Kunden | ist wichtiger als | Vertragsverhandlungen |
| Auf Änderungen reagieren | ist wichtiger als | das Befolgen eines Plans |
Sie stellen gleichzeitig fest, dass die Wertschätzung auch für rechte Seite besteht, dass die linke Seite aber wichtiger sei.
Diskussionen über agile Methoden verharren gerne im Klein-Klein über die richtige Methode. Das ist ungefähr genauso müßig wie die Frage nach der richtigen Programmiersprache... es muss halt passen... zum Team, zur Unternehmenskultur, zum Projekt, zu den Anforderungen. Auch die Frage des Scheiterns wird gerne auf dieser Ebene erklärt. Das trifft es aber nicht. Agile Methoden scheitern in einem nicht-agilen Umfeld.
Bei Einführung einer bestimmten agilen Methoden wird der Hintergrund des agilen Manifests oft nicht beleuchtet. Dies ist aber die Begründung für die einzelnen Methodenbausteine.
Was machen agile Projekte mit Ihrem Umfeld?
Was verändert der vierte Satz des Manifests: "Auf Änderungen reagieren ist wichtiger als das Befolgen eines Plans"? Entscheidungsfindung und Planverfolgung erfolgen traditionsgemäß von "Oben nach Unten" bzw. "Vom Auftraggeber zum Auftragnehmer." Agiles Entwickeln heißt, dass sowohl der Auftraggeber als auch das Entwicklungsteam Änderungsmöglichkeiten identifizieren und während des Projekts darauf reagieren, also Antworten entwickeln.
Damit ist das Entwicklungsteam nicht mehr nur Produktion oder Ausführender eines Plans, sondern gleichberechtigter Partner für dieses Thema. Das erfordert im Allgemeinen ein Umdenken in den Unternehmen. Diese Änderung positioniert die IT neu.
Denn ist nicht mehr der Plan (also Qualität, Aufwand und absolute Zeit) ist der heilige Gral, sondern die Frage, welche Features in einer bestimmten Zeit in den gegebenen Umständen durch das Entwicklungsteam erreichbar sind bzw. waren. Das ist ein Kulturschwenk. "Oben" bzw. der Auftraggeber erteilt keine Ansage, was bis wann wie zu schaffen ist, sondern alle Beteiligten einigen sich drauf, das Beste zu wollen und das zu erreichen, was unter guten Umständen möglich ist.
Agile Methoden stellen also die Frage nach Zufriedenheit in der Arbeit - und fordern eine möglichst stressfreie Arbeit (zumindest verhindern sie von "oben" bzw. vom Auftraggeber induzierten Stress im Team).
Nur das Entwicklungsteam arbeitet agil - geht das?
In einigen Unternehmen versuchen Entwicklungsteams agil zu arbeiten, während das Projektmanagement (eine Rolle, die die meisten agilen Methoden nicht vorsehen) noch klassisch kommuniziert. Dieses Vorgehen ist zum Scheitern verurteilt. Da sich die Werte der beiden Vorgehen fundamental unterscheiden, ist der Projektmanager in der Zwickmühle.
In Abständen hört man "Agil funktioniert nicht - wir haben das versucht, aber der Projektmanager, der Kunde, die Fachabteilung und / oder der Vorstand war zu doof dazu." In diesen Fällen sollte man danach sehen, wie die agile Methode vorgestellt wurde. Oft wird Agilität für Projektmanager, den Kunden, die Fachabteilung und / oder den Vorstand so erklärt: "Das ist total super, Du kannst bis zum Schluss Änderungsanforderungen einkippen."
Wenn dann aber die der Verzicht auf "Top-Down" nicht erläutert wird bzw. der Rollenwechsel des Entwicklungsteam nicht beleuchtet wird, wird der Umstieg in die Agilität scheitern.
Wenn im laufenden Prozess die genannten Projektbeteiligten in "alte" Muster verfallen und in der gegebenenen Zeit Feature-Anzahl zum kalkulierten Aufwand fordern, dann ist das die Antwort auf eine fehlende Erklärung zur Umstellung. E ist auch der Anfang für eine Debatte mit dem Management, was Qualität in der Software-Entwicklung wirklich ist. Und ob diese sich an mehr Faktoren als z.B. Feature-Anzahl messen lässt.
Es wird Zeit, dass die Debatte um agile Methoden nicht durch die Vorstellung einer Methode für ein Entwicklungsteam reduziert wird, sondern dass von der IT eine Wertedebatte für das Unternehmen bzw. das Projekt ausgeht.
- P.S. #1: Mehr zum Thema auf dem Vortrag "Agil - jetzt neu: für alle"
auf der WTC 12 - P.S. #2: Inspiriert durch "Agile Software-Entwicklung braucht auch ein agiles Projektmanagement" (Fokus liegt auf PM, nicht auf dem Gesamtunternehmen)
Dieser Blog-Post ist ein privater Beitrag von Judith Andresen.
- Nächster Artikel: jimdo-Sitemap im Layout angleichen
- Vorheriger Artikel: i-Technology | Leistungsanstieg nach 25 Monaten
- Kategorie: Leitung, Kultur
Kommentar schreiben