iX | Gezielte Wahl (Teil 2)

Gezielte Wahl, Teil 1 | Dieser Artikel ist erstmals in der iX im Heise-Verlag, Ausgabe März 2013, erschienen.

iX-Tract
  • Wenn Projekte nicht funktionieren, fordern viele einen Wechsel der Methode. Aktueller Favorit ist der agile Ansatz.
  • In jedem Fall – klassisch oder agil – ist sicherzustellen, dass die Grundfragen des Projektes methodisch beantwortet sind.
  • Es empfiehlt sich ein evolutionärer Wandel der Methode. So fällt der Wechsel allen Beteiligten leichter und die neue Arbeitsweise kann sich dauerhaft etablieren.

Eigene Projektmethoden reformieren

Vor der Wahl der Bausteine sollten Softwareteams darüber nachdenken, ob sie eher in der klassischen oder besser in der agilen Projektwelt aufgehoben sind. Und diese Frage ist sowohl für die Gruppe als solche als auch für die Zusammenarbeit mit allen anderen Beteiligten zu stellen.

 

Ist die Unternehmenskultur klassisch-hierarchisch geprägt, sollte das Team nach außen Kommunikationsformen wählen, die in diesem System angemessen sind. Ohne umfassende Maßnahmen kann man hier nicht ein komplettes agiles Vorgehen einführen. Es ist fraglich, ob eine Mannschaft alleine die notwendigen Veränderungen initialisieren und durchsetzen kann.

 

Ein Umbruch der Methode bedeutet einen Verhaltenswandel für eine Gruppe. Diese Entwicklungen – für jeden Einzelnen genauso wie für Teams – brauchen ihre Zeit. Insofern empfiehlt es sich, den aktuell genutzten Ansatz Schritt für Schritt umzugestalten. Dabei sind Bausteine,

  • die man bisher implizit nutzt, zu explizieren beziehungsweise
  • solche, die ineffizient im Projektumfeld sind, durch andere zu ersetzen. 

Passende Methodenbausteine finden

Wenn man einen Methodenbaustein als ineffizient erkannt hat, ist es die Aufgabe aller Mitarbeiter, einen neuen zu definieren. Um eine passende Wahl zu ermöglichen, sollten die Beteiligten ausarbeiten, warum der Baustein im eigenen Projekt nicht funktioniert hat. Sobald die Gründe feststehen, kann das Team Veränderungen konzipieren, die den Projektverlauf verbessern sollen. Zum Beispiel könnten die Schritte wie folgt aussehen:

 

Im klassischen Projektmanagement, genauer dem Kostenmanagement, ist die Restaufwandsschätzung oft fehlerhaft. Diese sollte einen wichtigen Hinweis für den Projekterfolg und das Änderungsmanagement bieten – insofern ist allen Be- teiligten daran gelegen, eine korrekte Zahl zu ermitteln. Häufig erfolgt die Restaufwandsschätzung durch einen einfachen Dreisatz: Nach Kontrolle der bisher aufgelaufenen Aufwände ermittelt man den Restaufwand durch Vergleich mit der Ursprungsschätzung. Durch dieses Verfahren erkennt man erst beim Überschreiten der Ausgangswerte, dass eine Fehlschätzung vorliegt. Um dem entgegenzuwirken, könnte das Team als wöchentliche Maßnahme eine aktive Restaufwandsschätzung (wahlweise gestützt oder ungestützt gegen Verbrauch und Ursprungszahlen) der aktiv bearbeiteten Aufgaben vereinbaren.

 

Aber auch mit agilen Methoden kann Veränderungsbedarf bestehen: Die Planung einzelner Sprints erfolgt bei Scrum durch Sprint Planning I und II. Während im Sprint Planning I der Project Owner Anforderungen und Prioritäten für die einzelnen Anforderungen definiert, bewertet das Entwicklungsteam unter Leitung des Scrum Master im Sprint Planning II die technische Komplexität und plant den Sprint im Detail. In vielen Gruppen entstehen in dieser Phase des Sprints zeitraubende Abstimmungsschleifen. Ursachen hierfür können sein:

  • Fachliche Anforderungen erweisen sich als zu wenig konkret.
  • Diskutierte technische Umsetzungen haben Einfluss auf die Fachlichkeit.

Wenn man diese Unstimmigkeiten als Ursachen für die Abstimmungsschleifen erkannt hat, könnte eine Änderung darin bestehen, die fachlichen Anforderungen und die resultierende technische Bewertung in einer gemeinsamen Sitzung unter Beteiligung von Project Owner, Scrum Master und Team vorzunehmen.

 

Beim Korrigieren einer Methode sollten die einzelnen Änderungen jeweils für sich nicht zu groß sein. Auch sollte man nicht zu viele Modifikationen auf einmal vornehmen. Gerade in Krisen fallen alle Beteiligten in altes Verhalten zurück, wenn eine Großzahl von Veränderungen zu beachten ist. Das können viele Mitarbeiter nicht schaffen.

 

Durch regelmäßige Kontrolle der Zusammenarbeit kann man die Effizienz der Veränderungen überprüfen. Das Team kann so nach und nach die eigene Metho- de optimieren.

Tabelle 1: Ermitteln der aktuellen Methodenbausteine

  Zurück Im Hier und Jetzt Voraus
Wie? Kommunikations-management Terminmanagement, Personalmanagement, Kommunikations-management Integrations-management, Qualitätsmanagement, Beschaffungs-management
Was? Qualitätsmanagement, Kostenmanagement Änderungsmanagement Anforderungs-management, Risikomanagement

Leitfragen zum Identifizieren von Methodenbausteinen

Damit ein Projekt erfolgreich verläuft, sind die vier Leitfragen „Wohin?“, „Warum?“, „Was?“ und „Wie?“ zu beantworten. Während in vielen Unternehmen das übergeordnete Management die strategische Verortung eines Projekts vornimmt und an die Gruppen vermittelt, kann die Frage „Warum?“ bereits in den Teams liegen. Je stärker ein Unternehmen hierarchisch organisiert ist, desto eher befasst sich auch das höhergestellte Management mit der Frage, worin Erfolg und Misserfolg bestimmter Maßnahmen begründet sind. Je agiler ein Unternehmen aufgestellt ist, desto stärker beantwortet diese Frage das Team im Rahmen einer positiven Fehlerkultur. Die Leitfragen für das Projektmanagement lauten „Was?“ und „Wie?“

  • Was: Welche Aufgaben liegen an? Was genau muss das Team, was die anderen Projektbeteiligten leisten? 
  • Wie: Wie genau geht das Team vor? Welche Rituale führt es ein? Wie gestaltet sich die tägliche Zusammenarbeit? Wie berichtet die Gruppe? Woran misst das Team Erfolg?

Eine Alternative zum schrittweisen Vorgehen ist der komplette Schwenk auf eine neue Methode. Die meisten Ansätze konzentrieren sich auf bestimmte Elemente. Durch Überprüfen der zehn Wissensbereiche des Projektmanagements sowie der zwei Leitfragen kann das Team sicherstellen, alle wesentlichen Fragen geklärt zu haben. Zum Testen empfiehlt es sich, hier ebenfalls die Tabelle 2 auszufüllen. Die Gruppe sollte gleichzeitig bei allen vorgestellten Bausteinen hinterfragen, warum man diese in eben jener Form vorgeschlagen hat – und im eigenen Umfeld evaluieren, ob der Einsatz zielführend sein kann.

Tabelle 2: Bausteine und schriftliche Artefakte

  Zurück Im Hier und Jetzt Voraus
Wie?

Retrospektive des Sprints, Sprint-Review, Projekt-Review 


Statusbericht, Zeitplan, Daily Standup an der Wandzeitung, zweiwöchrige Sprints, Montag: Teamfrühstück 

Pair Programming, Zeitplan für Zulieferer, API-Definition über Workshop, zweiwöchentlich: Telefonkonferenz mit Datenbank-Anbieter 

Was?

Steuerungsmeeting mit Auftraggeber, Qualitätsmanagement über QA-Abteilung, wöchentliche Aufwandskontrolle, Change-Request-Puffer von 20 Prozent im Projektbudget 

„Definition of Done“ für alle Projektbeteiligten 


Kick-off-Workshop zur Ziel- definition, Workshop zur Erstellung von User-Stories, Risikotabelle im Intranet, wöchentliche Restaufwands- schätzung, Sprint-Planung mit Auftraggeber und Team 

Ein Ändern aller Bausteine führt da- zu, dass keiner der Bausteine wirklich eingeübt ist. Gerade in kritischen Situationen und unter Zeitdruck fallen Beteiligte auf ein älteres – das bisherige – Verhalten zurück. Im Team löst das meist große Unruhe und Unsicherheit aus. Anstelle eines neuen Ansatzes liegt so eine ungeklärte Sammlung von alten und neuen Bausteinen vor. Um dieses Chaos zu vermeiden, ist ein schrittweiser Wandel vorzuziehen.

 

Viele Methoden sehen eine Sitzung („Review“ bzw. „Lessons learned“) am Ende des Projekts mit allen Beteiligten vor. So will man erfolgreiche und optimierungsbedürftige Verfahren ermitteln. Die Ergebnisse dienen dem Wissensaufbau in der Organisation – und sollen als Grundlage zum Verbessern nachfolgender Projekte dienen. Eine solches Vorgehen bedingt, dass alle vorurteilsfrei und ohne Nachteile für die Beteiligten über den Verlauf sprechen können. Ist eine positive Fehlerkultur nicht in einem Unternehmen – insbesondere beim Auftraggeber – verankert, sollte man eine andere Form finden, wie man das Vorgehen im Nachhinein bewerten kann.

Evaluieren und Verbessern der Projekte

Agile Methoden sehen ein stetiges Verbessern des Projekts vor, indem Teams regelmäßig im Verlauf Retrospektiven vornehmen. Durch kleine Änderungen können die Beteiligten so auf Fehlannahmen und geänderte Anforderungen direkt reagieren. Eine Retrospektive ist ein Baustein, der das „Wie“ beantwortet.

Die Leitfragen „Was?“ und „Wie?“ des Managements sind in drei zeitlichen Dimensionen zu beantworten: Im Rückblick auf abgelaufene Projekte beziehungsweise bereits bearbeitete Schritte, im Hier und Jetzt sowie im Ausblick auf kommende Aktionen.


Es ist empfehlenswert, für jede der Fragestellungen ein Ritual einzuführen, das die Antworten auf die Leitfragen gibt. Rituale vermitteln den Beteiligten Sicherheit im täglichen Geschehen. Gleichzeitig ist es schwerer, über wiederkehrende Handlungen hinwegzugehen. Hat man ein bestimmtes Vorgehen nicht ritualisiert, vergisst man die betreffende Fragestellung in Krisenzeiten oder unter großem zeitlichem Druck.

 

Hauptakteurevon Ritualen können Einzelne (z.B. aus dem Projektmanagement), andere Beteiligte oder alle Mitglieder sein. Je agiler sich eine Mannschaft versteht, desto stärker beteiligt sich das gesamte Team am Beantworten. Die klassischen Wissensbereiche des Projektmanagements ordnen sich in diese Fragestellungen ein. Tabelle 1 verdeutlicht diese Zuordnung.

 

Das Team kann diese Tabelle auch zum Ermitteln der aktuelle genutzten Bausteine heranziehen. Beim Ausfüllen fallen Mitarbeitern häufig Kommunikationsrituale auf und ein, die man bisher nicht als projektrelevant erachtet hat. Treffen sich Mitarbeiter wöchentlich zum Mittagessen, kann das ein wichtiges Element der Frage nach dem „Wie“ im „Hier und Jetzt“ sein. Dieses Element sollte man zusätzlich in der Beschreibung der Bausteine aufführen.


So kann das Team genutzte, aber bis- her nicht explizit benannte Bausteine erfassen. Fehlende Bausteine kann man durch Vergleich mit den zehn Wissensbereichen des Projektmanagements ermitteln. Durch das systematische Annähern können Teams, die bisher SWBLM gefolgt sind, ihre Methode vervollständigen.


Ein solches Zusammenstellen von Bausteinen kann sowohl klassische als auch agile Elemente enthalten.


In Tabelle 2 kann man Bausteine und schriftliche Artefakte eintragen. Bei Letzteren sollte sich das Team einig sein, auf welchem Weg (d.h. „Wie“) das schriftliche Artefakt entsteht. So ist das Erstellen eines wöchentlichen Statusberichts in einigen Teams allein Aufgabe des Projektmanagers, in anderen entwickelt und formuliert ihn eine Teamsitzung. 

Fazit

Durch das Erfassen und Definieren aller Bausteine sorgt das Team für Transparenz im weiteren Verlauf. Es empfiehlt sich, beim Einführen einer gesamten Methode die Bausteine anhand der zehn Wissensbereiche des Projektmanagements und der Leitfragen „Was?“ und „Wie?“ zu prüfen. So stellt man sicher, dass man alle notwendigen Bausteine für den Projekterfolg beisammen hat. (fo) 


Gezielte Wahl, Teil 1 | Dieser Artikel ist erstmals in der iX im Heise-Verlag, Ausgabe März 2013, erschienen. Der Text ist abweichend von den anderen Blog-Einträgen in der Sie-Form und nicht geschlechtsneutral formuliert.


Kommentar schreiben

Kommentare: 0