Missverständnisse beim Umstieg vom traditionellen zum agilen PM - Qualitätssicherung in der Softwareentwicklung und im Softwaretest

Viele Firmen haben sich in den letzten Jahren dazu entschlossen, sich vom traditionellen Projektmanagement zu verabschieden und sich den agilen Methoden zu widmen. Immer öfters ist der Umstieg schwerer gefallen als es sich die Firmen vorgestellt haben.

Folgende Missverständnisse scheinen meistens die Gründe für auftretenden Probleme zu sein.

1. Anforderungen? Davon hab ich gehört ...
In der agilen Softwareentwicklung müssen Anforderungen allgemein zugänglich und verständlich sein. Es muss jedem klar sein, warum und wie etwas umgesetzt wird. Ebenfalls muss bedacht werden, dass sich Anforderungen zu jeder Zeit wieder ändern können und der Entwickler dementsprechend seinen Code strukturieren muss.
2. Dokumentation? Brauchen wir nicht.
Im agilen PM verwendet man nur Dokumentation, die man für nützlich hält und die aktuell gehalten werden kann. Ist man von anderen Projekten mit traditionellem PM umgeben, kann dies zu Problemen führen. Hier ist man gezwungen zu Kompromissen zu greifen. Komplett ohne Dokumentation zu arbeiten ist keinesfalls agil.
3. Wo ist der Projektmanager hin?
Im agilen Ansatz ist das Team für die Aufgaben des Projektmanagers verantwortlich und keines Wegs z.B der Scrum Master. Das Team plant selbst, priorisiert Anforderungen, diskutiert Lösungen und setzt eigenverantwortlich um. Dies muss vor allem vom Management akzeptiert werden. Viele Köpfe können mehr erfassen als nur einer und wer hinter seiner Arbeit steht, arbeitet engagierter und ist zufriedener.
4. Wie? Wo? ich soll verantwortlich sein?
Manchen Mitarbeitern im Team ist die Vorstellung Verantwortung übernehmen zu müssen nicht geheuer. Man ist das alte Schema gewohnt, dass man eine feste Rolle begleitet, Aufgaben vorgesetzt bekommt und diese in einem festen Zeitrahmen lösen muss. Mitarbeiter die auf dieser Arbeitsweise beharren riskieren aber den Projekterfolg, wenn sie nicht am Wissensaustausch mitarbeiten, Risiken ignorieren und Probleme unter den Teppich kehren.
5. Wir schaffen das!
In traditionellen Projekten besteht oft ein gewisser Druck von oben, bestimmte Aufgaben in einem sehr engen Zeitrahmen zu erledigen.
Zu Beginn eines agilen Projektes nehmen viele Teammitglieder diese Mentalität mit und muten sich zu viel zu. Die Folge ist, dass die Mitarbeiter überarbeitet und für Rückfragen anderen Mitarbeiter nicht erreichbar sind. Kurz vor der Kundenpräsentation sind viele Features unvollendet und bei allen Beteiligten macht sich Ernüchterung breit. Die eigene Arbeit soll aber Spaß machen!
6. Testen, ja schon ...
Im bekannten Wasserfallmodell findet das Testen nach dem Ende der Entwicklung statt. In der agilen Softwareentwicklung findet das Testen parallel zur Entwicklung und gegebenenfalls sogar komplett parallel zum eigentlichen Entwicklungsprojekt statt. Das Testteam ist trotz allem ein Teil des Entwicklerteams und nutzt die kurzen Kommunikationswege aus. Bei Bedarf werden Entwickler gegen Ende als Tester eingesetzt oder umgekehrt.
Die Testautomatisierung ist im Gegensatz zum traditionellen PM fast unverzichtbar.
7. Wir können doch nicht alles diskutieren ...
Für viele Manager ist es zu anfangs schwierig "loszulassen". Man ist gewohnt, dass es lange Meetings gibt auf denen der Plan präsentiert wird. Anschließend wird widerspruchslos umgesetzt. In einer agilen Umgebung sind jedoch alle Teammitglieder an der Planung beteiligt. Es werden kurze und zielführende Meetings geplant, kurze Kommunikationswege genutzt, Anforderungen immer wieder und wieder diskutiert, Termine gemeinsam beschlossen und Aufgaben einvernehmlich verteilt.
8. Woher sollen wir das wissen?
Im agilen PM ist es besonders wichtig schnell die richtigen Entscheidungen treffen zu können. Um dies zu erreichen, müssen die richtigen Metriken gefunden werden, die klare Aussagen über die Zielerreichung und den Projektfortschritt machen können. Die bisherigen gewohnten Metriken, die mehr aus Sammelwut und durch Managementvorgabe erfasst wurden, sind nicht mehr brauchbar. Es herrscht Transparenz nach allen Seiten, für das Management genauso wie für das Team. Wird festgestellt, dass ein Ziel oder eine Anforderung nicht wie geplant umgesetzt werden kann, dann wird flexibel neu geplant und nach praktikablen Lösungen gesucht. Schnelles Handeln ist ein besonderer Vorteil der agilen Entwicklung.