Der folgende Inhalt stammt aus dem beliebten Whitepaper "Agiles Projektmanagement: Worum geht es?". geschrieben von Jerry Manas. Es ist so gut, dass wir es unseren Lesern kostenlos zur Verfügung stellen und es auf unserem Blog zu Ihrem Vergnügen weiterleben lassen wollten.
Seit den Anfängen der Agile-Bewegung sind die Verfechter der traditionellen Methoden skeptisch. Einige ihrer Bedenken sind berechtigt, während andere auf Unkenntnis der echten agilen Methoden beruhen.
Zehn häufige Ängste des Managements sind:
- Für große, komplexe Projekte wird das nicht funktionieren.
- Es ist zu offen. Wir können die Kosten nicht vorhersagen. Das ist eine "sanktionierte Ausweitung des Geltungsbereichs".
- Das klingt nach einem Entwurf und einer Planung auf der Rückseite der Serviette.
- Es ist zu sehr auf "Technik" ausgerichtet.
- Softwareentwickler sprechen nicht die gleiche Sprache wie Kunden.
- Die Kunden haben keine Zeit, sich in die Planung einzumischen.
- Wir wollen nicht, dass unsere Kunden unsere schmutzige Wäsche sehen.
- Dieser "Teamwork"-Ansatz klingt nicht gerade praktisch.
- Tägliche Treffen? Unsere Mitarbeiter werden das Gefühl haben, dass sie unter einem Mikroskop stehen.
- Sie ist zu starr und hemmt die individuelle Kreativität.
Die Wahrheit ist, dass Agile mehr Planung erfordert, als ihnen bewusst ist- und zwar bei jeder Iteration. Außerdem sind Kunden und Unternehmen stärker involviert, und die Kommunikation ist ausgeprägter, so dass der Fokus nicht ausschließlich auf der Technologie liegt. Aber andere Sorgen sind durchaus berechtigt.
Insgesamt können die folgenden zehn Strategien typische Bedenken ausräumen:
- Passen Sie die Strategie an die Situation an - verwenden Sie die richtige Methode für die richtige Aufgabe; Agile eignet sich am besten für ein zusammenhängendes Team, das an Wissensarbeit mit einem gewissen Maß an Unsicherheit arbeitet.
- Verringern Sie das Risiko, indem Sie sich auf geschäftliche Symptome statt auf Lösungen konzentrieren - verlieren Sie das zu lösende Geschäftsproblem nicht aus den Augen.
- Überzeugen Sie sich selbst und bewerten Sie das Nutzererlebnis - vorher und nachher.
- Fördern Sie einen systemorientierten Ansatz - denken Sie nicht nur an die Software, sondern auch an Prozesse, vor- und nachgelagerte Systeme, Auswirkungen auf die Stakeholder usw.
- Engagieren Sie einen Business-Analysten, um sicherzustellen, dass keine Details übersehen werden - Entwicklern fehlt oft das Verständnis für geschäftliche Details.
- Überbrücken Sie die kulturelle Kluft zwischen Technikern und Kunden - dies kann durch Schulungen für Entwickler zur Interaktion mit dem Kunden geschehen oder indem Sie andere als Dolmetscher und Übersetzer engagieren, um die Kluft zwischen Entwicklern und Kunden zu überbrücken.
- Nehmen Sie Veränderungen an, aber verwalten Sie sie - gehen Sie davon aus, dass sich die Funktionen auf der Grundlage der gewonnenen Erkenntnisse ändern werden, aber führen Sie Diskussionen über den Gesamtumfang und verwalten und protokollieren Sie Änderungen des Umfangs.
- Konzentrieren Sie sich auf die Produktentwicklung, nicht auf die Projektentwicklung; verwalten Sie nach priorisierten Funktionen und Releases; haben Sie Release-Ziele - die meisten Sprints führen nicht zu einer Lieferung an den Kunden, sondern liefern ein gewisses Maß an Wert; Releases führen zu Kundenlieferungen; stellen Sie außerdem sicher, dass Sie Funktionen priorisieren und Meilensteine für Releases festlegen.
- Gewinnen Sie die Bereitschaft des Managements, an Retrospektiven und offenen Demos teilzunehmen - ohne die Beteiligung des Managements und der Kunden verliert die agile Methodik ihre Wirkung; die Gewinnung von Engagement ist der Schlüssel.
- Konzentrieren Sie sich auf die Ergebnisse und den Wert, nicht auf Aktivitäten oder Stunden - geben Sie Ihren Mitarbeitern nicht das Gefühl, unter einem Mikroskop zu stehen - konzentrieren Sie sich auf das, was benötigt wird, und nicht auf die Art und Weise, wie es erreicht werden soll; lassen Sie Flexibilität und individuelle Kreativität zu und konzentrieren Sie sich nur auf die vereinbarten Ergebnisse und den Wert für jeden Sprint - Freiheit bei den Stunden und der Kreativität kann die starke Konzentration auf das Erreichte ausgleichen, und eine Einigung auf das Erreichbare kann den Druck verringern.
Eine weitere Möglichkeit, andere Unzulänglichkeiten von Agile zu verringern, besteht darin, einen integrierten Ansatz zu wählen, um das zu betonen, was im Allgemeinen außerhalb der Agile-Methodik liegt. Verwenden Sie dazu einen vierstufigen Ansatz, der zusätzlich zu Ihrer derzeitigen Methodik eingesetzt werden kann. Das Akronym lautet UP-IT:
- Understand - bauen Sie das notwendige Wissen auf, um bei dem Projekt erfolgreich zu sein; recherchieren Sie; untersuchen Sie die aktuelle und die gewünschte Benutzererfahrung.
- Prepare - sich die Fähigkeiten aneignen, um das Projekt erfolgreich durchzuführen, wie z.B. Schulungen, die richtigen Tools, das Engagement der Stakeholder, etc.
- Iterate - planen Sie Iterationen/Sprints und führen Sie sie aus, um durch geplante Veröffentlichungen einen Mehrwert zu schaffen.
- Transform - konzentrieren Sie sich auf den laufenden Support und die Selbstständigkeit des Kunden; stellen Sie sicher, dass Sie das Team über die gelernten Lektionen unterrichten, damit diese in zukünftigen Versionen angewendet werden können.
Und schließlich gibt es einige Situationen, in denen Agile wahrscheinlich NICHT der beste Ansatz ist.
Hier sind acht Beispiele dafür, wo Sie agile Methoden vermeiden sollten:
- Große Unternehmensinitiativen, bei denen die Anforderungen im Voraus definiert werden müssen und die im Allgemeinen eine umfangreiche Dokumentation erfordern
- Wenn formale Spezifikationen für die Nachvollziehbarkeit, Sicherheit oder Genauigkeit erforderlich sind
- Wenn der Umfang und die Anforderungen bekannt sind, definiert werden können und sich wahrscheinlich nicht wesentlich ändern werden
- Wenn viele Genehmigungen von mehreren Parteien erforderlich sind
- Wenn die Organisations- oder Teamkultur mit einem agilen Ansatz unvereinbar ist
- Wenn Kunden/Nutzer nicht allgemein verfügbar sind, um teilzunehmen
- Wenn es dem Team an zwischenmenschlichen Fähigkeiten oder umfangreichen technischen Kenntnissen mangelt (d.h. sie können nicht befähigt werden)
- Wenn das Team zu groß ist, um effektiv miteinander zu kommunizieren (d.h. mehr als 100 Personen, wobei diese Zahl je nach Kultur und Technologie variieren kann)
Virtuelle Teams und Agile
Laut Gartner werden bis 2015 drei Viertel der wissensbasierten Projektarbeit in der Welt 2000 von verteilten virtuellen Teams erledigt werden. Dies stellt neue Herausforderungen an die Zusammenarbeit, die ein zentraler Grundsatz von Agile ist. Vor diesem Hintergrund wird ein Verständnis der neuen Medien und der Tools für die Online-Zusammenarbeit immer wichtiger werden.
Agile Teams müssen Methoden einsetzen, um regelmäßig miteinander zu kommunizieren, sei es über Telefonkonferenzen, Webinare, Twitter-ähnliche Tools wie Yammer, Websites zur Zusammenarbeit oder andere Medien. Einige Unternehmen nutzen sogar Wikis, um Wissen zu erfassen, zu organisieren und zu teilen.
Dies gilt auch für Unternehmen, die derzeit nicht in der Lage oder nicht willens sind, ihre Entwicklungsteams an einem gemeinsamen Standort unterzubringen. Die meisten Agile-Experten sind sich einig, dass ein gemeinsamer Standort am besten ist, aber mit der richtigen Technologie und den richtigen Prinzipien können auch verteilte Teams effektiv sein.
Finden Sie heraus, ob die agile Methode das Richtige für Sie und Ihr Unternehmen ist. Registrieren Sie sich noch heute für eine kostenlose Demo! Weitere Informationen finden Sie unter https://www.planview.com/lean-agile-delivery/. Wir hoffen, dass Ihnen diese Serie gefallen hat und dass Sie viele wichtige Erkenntnisse gewonnen haben. Bleiben Sie auf dem Planview-Blog für weitere Lean- und Agile-Inhalte dran.
