Donnerstag, 10. März 2016

The wrong way to do Agile: Team Structure



Atlassian schafft es mit seiner Video-Reihe um Chet Rong (The (W)Rong way to do Agile), auf unterhaltsame Art und Weise den Zuschauern agile Prinzipien näher zu bringen.
Das Video "Team Structure" zeigt auf, wie wichtig die folgenden Punkte sind:
  • Product Owner und Scrum Master dürfen nicht die gleiche Person sein
  • Die Einbindung eines Vorgesetzten in das Entwicklungsteam kann kontraproduktiv sein
  • Ohne Qualitätssicherung geht es nicht


Product Owner und Scrum Master nicht dieselbe Person


Viele Punkte sprechen dagegen, beide Rollen von einer Person ausüben zu lassen. Beide haben einen anderen Schwerpunkt und andere Aufgaben. Während der Product Owner entscheiden muss, was entwickelt werden soll, hilft der Scrum Master dem Team, diese Ziele zu erreichen.
Hinzu kommt, dass beide Rollen so viel Aufmerksamkeit benötigen, dass bei einer Vermischung der Aufgaben mindestens einer der Rollen vernachlässigt werden würde.
Auch die Ziele, die PO und SM jeweils verfolgen, sind unterschiedlich. Während es in der Natur des Product Owners liegt, mit jedem Sprint mehr entwickeln zu lassen, versucht der Scrum Master das Team vor zu viel Arbeit zu schützen. Bei einer Vermischung dieser Rollen würden direkt Zielkonflikte auftreten.

Vorgesetzte im Team integriert


Für das Entwicklungsteam ist es schwierig, wenn eine der Rollen durch einen Vorgesetzten besetzt ist. Vor allem die Rolle des Scrum Masters sollte unabhängig von anderen Aufgaben sein, um Interessenkonflikten vorzubeugen.
Wenn der Scrum Master in der Vergangenheit eine Führungsposition besetzt hatte besteht die Gefahr, dass alte Muster wieder in die Entwicklung mit einfließen. Das Entwicklungsteam muss vor äußerem Druck geschützt werden, um kreativen Prozessen freien Lauf lassen zu können.
Vor allem in kleineren Unternehmen ist es nicht unüblich, dass Vorgesetzte die Entwicklung direkt beeinflussen wollen - vor allem wenn Mechaniken wie Scrum disziplinäre Hierachien explizit ausschließen. Der Scrum Master muss das Team vor einer solchen Einflussnahme abschotten können.
Eine oft gewählte Lösung in vielen Unternehmen ist die Besetzung eines Vorgesetzten für die Rolle des Product Owners. Manager oder Teamleiter besitzen in den meisten Fällen über ausreichend Kenntnisse über das Produkt, um dem Team die Vision und die Aufgaben zu präsentieren und fungiert als Schnittstelle zu den Stakeholdern.
In den meisten Fällen besteht bereits ein guter Kundenkontakt über diese Person, weswegen eine Umstellung zu Scrum für diese Rollenbesetzung am sinnvollsten ist. Damit keine alten Muster und Vorgehensweisen wieder aufgegriffen werden, ist auch hier der Scrum Master gefragt.

Qualitätssicherung in agiler Umgebung


Ein großer Irrtum ist es oft, dass die Qualitätssicherung als nicht wichtig erachtet wird. Wenn ein Produkt nur wenige Fehler beinhaltet, wird diese Position oft als überflüssig angesehen, "da es ja nichts zu testen gibt".
Unternehmen mit einer klassischen Hierarchie unterschätzen in viele Fällen die Wichtigkeit einer guten QA. Ob es sich dabei um ein mittelständisches Unternehmen oder einem Konzern handelt, ist davon unabhängig.
Die Mitarbeiterzahl der Firma ist unwichtig, doch die Qualitätssicherung ist in den meisten Fällen immer zu dünn besetzt. So können nur die wichtigsten Punkte abgearbeitet und getestet werden.
Selbst wenn ein Stück Software stabil läuft und wenige Fehler beinhaltet, kann ein großer Schnitzer die Zukunft des Unternehmens beeinflussen, der durch den Einsatz einer ausreichend besetzten QA-Abteilung möglicherweise hätte verhindert werden können.
In agilen Umgebungen tritt die Wichtigkeit von QA weiter in den Vordergrund, Testprozeduren sind explizit vorgesehen. Jede Änderung muss einem Test unterliegen.
Prinzipiell ist es möglich, dass ein Test vom gesamten Entwicklungsteam abgewickelt werden kann. Effektiver ist es aber, eine oder mehrere Personen im Team aufweisen zu können, die unabhängig von der Entwicklung die Änderung testen.

Fazit


Generell sollte ein agiles Team so aufgestellt sein, dass alle anfallenden Aufgaben ohne externe Auslagerung vom Team erledigt werden können. Das Team muss autark arbeiten können, auch ohne Beeinflussung von außen.
Sind diese Voraussetzungen geschafft, ist ein großer Schritt Richtung agiler Entwicklung bereits gemacht worden.

Keine Kommentare:

Kommentar posten