Agile Journey: Häufigste Missverständnisse

Bei meiner täglichen Arbeit mit Softwareentwicklungsunternehmen höre ich Geschäftsleute stolz sagen, dass "wir agil sind". Da stellt sich mir die Frage: "Ist Agilität selbst eine Leistung?" Für mich lautet die Antwort: Nein. Agilität ist vieles, aber keine Leistung per se. 

Wenn ich mit verschiedenen Leuten über die beste Art und Weise spreche, ein Projekt zu leiten, denken sie, dass agil sein bedeutet, "ein wöchentliches Ziel zu haben" oder "so schnell wie möglich zu entwickeln". Das ist der Moment, in dem ich sie frage, 

Im agilen Manifest aus dem Jahr 2001 heisst es dazu:  

• Menschen und Interaktionen haben Vorrang vor Prozessen und Werkzeugen, 

• Eine funktionierende Software hat Vorrang vor einer umfassenden Dokumentation, 

• Die Zusammenarbeit mit dem Kunden ist wertvoller als Vertragsverhandlungen, 

• Auf Veränderungen zu reagieren ist wertvoller als dem Plan zu folgen. 

Diese Denkweise, die in den 12 Grundsätzen des agilen Manifests verdeutlicht wird, ist das, was in einer Organisation, die ihre Arbeitsweise verbessern will, wirklich eine Veränderung bewirkt. Diese Grundsätze sind: 

1. Unsere höchste Priorität ist die Kundenzufriedenheit durch die frühzeitige und kontinuierliche Bereitstellung wertvoller Software. 
   
   
2. Wir akzeptieren, dass sich die Anforderungen ändern, auch noch in späten Phasen der Entwicklung. Agile Prozesse nutzen den Wandel, um dem Kunden einen Wettbewerbsvorteil zu verschaffen.
   
   
3. Wir liefern funktionale Software in regelmässigen Abständen, zwischen zwei Wochen und zwei Monaten, wobei wir die kürzestmögliche Zeit bevorzugen. 
   
   
4. Geschäftsleiter und Entwickler arbeiteten während des gesamten Projekts täglich zusammen. 
   
   
5. Projekte werden um motivierte Menschen herum entwickelt. Geben Sie ihnen das Umfeld und die Unterstützung, die sie brauchen, und vertrauen Sie ihnen, dass sie ihre Aufgabe erfüllen. 
   
   
6. Ein Gespräch von Angesicht zu Angesicht ist die effizienteste und effektivste Methode, um Informationen an das Entwicklungsteam und untereinander zu übermitteln. 
   
   
7. Arbeitssoftware ist dem wichtigen Mass für den Fortschritt.
   
   
8. Agile Prozesse fördern eine nachhaltige Entwicklung. Projektträger, Entwickler und Nutzer müssen in der Lage sein, einen konstanten Rhythmus auf unbestimmte Zeit beizubehalten. 
   
   
9. Kontinuierliche Aufmerksamkeit für technische Exzellenz und gutes Design verbessert die Agilität. 
   
   
10. Einfachheit ist das A und O, oder die Kunst, die Menge der nicht erledigten Arbeit zu maximieren.
    
    
11. Die besten Architekturen, Anforderungen und Entwürfe entstehen in selbstorganisierten Teams. 
    
    
12. In regelmässigen Abständen denkt das Team darüber nach, wie es effektiver arbeiten kann, und passt sein Verhalten entsprechend an und verfeinert es. 

Im Gegensatz dazu finde ich Unternehmen, die sich selbst als agil bezeichnen und in denen Situationen wie die folgende auftreten: 

• Manager sehen jede Änderung der Softwareanforderungen als etwas Schreckliches an, das niemals passieren darf. 
  ➔ Was ist mit dem Grundsatz 2 passiert? 

• Die Unternehmer vermeiden den Kontakt zwischen den Personen, die die Tätigkeiten ausführen, und den Endkunden so weit wie möglich, es sei denn, es ist notwendig. 
  ➔ Wo ist Grundsatz 4? 

• Manager, die den Fortschritt anhand der Anzahl der geleisteten Arbeitsstunden oder der prozentualen Fertigstellung der PBI durch die Entwickler messen möchten. 
  ➔ Und wo ist Grundsatz 7? 

• Unternehmen verlangen von ihren Mitarbeitern ständig lange Nächte, was sie oft erschöpft. 
  ➔ Wo sind Grundsätze 5 und 8? 

Abschliessend möchte ich darauf hinweisen, dass die agile Arbeitsweise nicht unbedingt für alle Projekte von Vorteil ist. 

Einige Kriterien für die Entscheidung, ob es sich lohnt, auf diese Weise zu arbeiten, sind: 

1. Ist mein Entwicklungsteam "ausgereift"? 
   1. Wenn ja, könnten Sie von der Selbstorganisation profitieren. 
   2. Wenn nein, könnte der Versuch, diese Techniken anzuwenden, dem Unternehmen schaden.
      
      
2. Hat das Projekt, das ich entwickeln möchte, von Anfang bis Ende genaue Anforderungen und werden sie sich nicht wesentlich verändern?
   1. Wenn ja, ist es sinnvoll, in kleinen Blöcken zu planen, anstatt das gesamte Projekt auf einmal zu planen 
   2. Wenn nein, wäre es sehr vorteilhaft, in kleinen Arbeitsblöcken zu planen und für jede Lieferung ein Feedback zu erhalten.
      
      
3. Enthält das Projekt ein technisches Element, mit dem wir noch keine Erfahrung haben?
   1. Wenn ja, kann der agile Ansatz wahrscheinlich besser mit dieser Unsicherheit umgehen. 
   2. Wenn nein, könnte das Projekt von Anfang an vollständig geplant werden (wenn die Anforderungen präzise sind). 
      
      
4. Könnten die Begünstigten des Projekts mit Teillieferungen des Systems einen Gewinn oder eine Investitionsrendite erzielen? 
   1. Wenn ja, lohnt es sich, konsequent kleine Arbeitsblöcke zu liefern, um den kurzfristigen Wert für die Kunden zu maximieren. 
   2. Wenn nein, kann die Arbeit in kleinen Blöcken zu einer höheren Arbeitsbelastung führen und die endgültige Fertigstellung des Projekts verzögern, verglichen mit der Durchführung der Entwicklung in einem einzigen Arbeitsblock. 

Ich hoffe, dass dies eine kleine Einführung in Agility ist. Lassen Sie uns wissen, wenn wir Ihnen bei irgendetwas helfen können.