BERATUNG JUDITH ANDRESEN
  • Change gestalten
  • Coachen + Begleiten
  • Besser führen
  • Im Team arbeiten
  • Über uns
  • Blog
  • Termine
17. Juni 2012

Agilität ist eine Kulturfrage

"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.

Mood: Wegweiser
Bild: morgueFile

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
tagPlaceholderTags: Leitung, Kultur

Kommentar schreiben

Kommentare: 0
ÜBER UNS
BLOG
KONTAKT
TERMINE
RÄUMLICHKEITEN

LinkedIn
Newsletter
Shop
Veröffentlichungen
Volltextsuche

1 Gilt für Lieferungen in folgendes Land: Deutschland. Lieferzeiten für andere Länder und Informationen zur Berechnung des Liefertermins siehe hier: Liefer- und Zahlungsbedingungen
2 inkl. MwSt.
Cookie-Richtlinie
Sitemap | Kontakt | Impressum | Datenschutz | AGB | Widerrufsbelehrung und -formular | Liefer-und Zahlungsbedingungen
Anmelden Abmelden | Bearbeiten
  • Change gestalten
  • Coachen + Begleiten
    • Agile Coach-Ausbildung
    • Agile Coach-Kompaktausbildung
    • Agile Organisations-Entwicklung Zusatzausbildung
    • Executive Coach Training
    • Weitere Angebote
    • Downloads für Coaches
  • Besser führen
    • Führungskräfte-Coaching + Supervision
    • Ausbildung Agile Führung (organisationsintern)
    • Projekte führen in (teils) agilen Systemen
  • Im Team arbeiten
    • Individuelle Teambegleitung
    • Begleiten von Konflikten + Mediation
    • Agiles Basistraining
    • Retrospektiven moderieren
    • Feedback-Training
    • Übungsgruppe "Feedback"
    • Projektcoaching
    • Visualisieren am FlipChart
  • Über uns
    • Veröffentlichungen
    • Kontakt
    • Newsletter
    • Räumlichkeiten
  • Blog
    • Agiles Coaching
    • Agile Teamentwicklung
    • Agile Organisationsentwicklung
    • Agile Führung
    • BERATUNG JUDITH ANDRESEN
    • Podcast
    • Videocast
    • Workshops (Archiv)
  • Termine
  • Nach oben scrollen
zuklappen