Ich war vor kurzem bei einem Kurs und bin so mal wieder mit der „Aussenwelt“ in Kontakt gekommen. Man unterhielt sich und plauderte auch über die eigene Arbeit, das Unternehmen und später sogar darüber was einen störte.  Ich war überrascht in was für Umgebungen so mancher meiner „neuen Kollegen“ arbeitet und wie Unternehmen mit ihren Mitarbeitern und Teams umgehen. Hier einige Beispiele:

  • Vor /während/ nach jedem Projekt werden die Mitarbeiter in neue Teams verschoben, weil dort „Not am Mann“ ist.
  • Während eines Projekts müssen sie sich prozentual aufteilen (20% hier, 10% dort, 30% ganz woanders), da das Wissen sonst nicht vorhanden ist.
  • Sie werden in Technologiekatekorien unterteilt, da jemand der Meinung ist so das Beste aus dem Team herauszuholen.

Schon 1965 beschrieb Bruce Tuckman die verschiedenen Phasen der Teambildung. Zu allererst wird das Team gebildet. Dabei versucht jeder keinem anderen auf die Füsse zu treten, sich anzupassen und akzeptiert zu werden (Forming). Nach einiger Zeit gibt es die ersten Reibereien und jeder versucht seine Ideen/Perspektiven den anderen näher zu bringen (Storming). Sollte das Team es schaffen in die nächste Phase überzugehen, steht das gemeinsame Ziel an oberster Stelle (Norming) und die eigenen Ziel treten in den Hintergrund. Einige der Teams schaffen es noch eine Stufe weiter: Performing – das Team funktioniert als eine Einheit und erledigt die Aufgaben reibungslos.

Somit sollte auch klar sein, das es nicht möglich ist Teams auf dem Papier zu erschaffen und zu hoffen, das daraus „High-Performance-Teams“ werden.

  • Jeder Mensch braucht Zeit um sich in Gruppen/Teams zurecht zu finden
  • Jeder einzelne in einem Team sollte zu 100% in diesem arbeiten.
  • Das Team sollte eine Technologie beherrschen, nicht nur Einzelne im Team.

Aber auch jedes „gestandene“ Team ist nicht vor diesen Veränderungen gefeit. Ein neues Teammitglied, ein neuer Vorgesetzter oder andere Umstrukturierungen innerhalb des Unternehmens können dazu führen, das ein Team alle Phasen erneut durchleben muss. Aus diesen Gründen sollten man allen Teams auch Zeit geben, um sich zu finden und die Chance zu erhalten ein „High-Performance-Team“ zu werden.

Scrum, als agile Vorgehensweise, kennt einen eingebauten kontinuierlichen Verbesserungsprozess. Dies ist einer der elementaren Vorteile des Rahmenwerks, vorausgesetzt natürlich, man führt Retrospektiven tatsächlich durch und handelt anschliessend aufgrund der dort aufgebrachten Probleme.

thinkingoutofbox

Ein nützliches Werkzeug Retrospektiven inhaltsvoller und auch zielgerichteter zu gestalten, stellen die in Rolf Smith’s Buch „The 7 Levels of Change: Different Thinking for Different Results“ (3rd Edition, Tapestry Press 2007) beschriebenen Ebenen des Nachdenkens dar. Sie helfen Probleme aus verschiedenen Blickwinkeln zu betrachten. Dadurch kann man mehr alternative Ansätze zur Lösung eines Problems generieren.

Die 7 Ebenden des Nachdenkens sind: Effektivität, Effizienz, Verbesserung, Reduktion, Nachahmung, Originalität und Unmögliches.

Wir wollen uns im Folgenden einen Überblick schaffen, wie wir sie in der Praxis verwenden können. Wir können die 7 Ebenen wie Kategorien von Fragen betrachten, die wir uns im Team stellen und beantworten sollten.

Ebene 1: Effektivität

Ziel: Die richtigen Dinge tun

Fragen, die wir uns stellen können:

  • Was hat Priorität?
  • Was ist dem Kunden wichtig?

Ebene 2: Effizienz

Ziel: Die Dinge richtig tun

Fragen, die wir uns stellen können:

  • Wie schreiben wir gute Tests?
  • Wie können wir eine gemeinsame Sprache mit dem Kunden finden?

Ebene 3: Verbesserung

Ziel: Die Dinge besser tun

Fragen, die wir uns stellen können:

  • Wie optimieren wir die Laufzeit unserer Tests?
  • Wie können wir die Kommunikation zum Kunden verbessern?

Ebene 4: Reduktion

Ziel: Dinge nicht mehr tun

Fragen, die wir uns stellen können:

  • Auf welche Dokumente können wir gefahrlos verzichten?
  • Welche Features können weggelassen werden?

Ebene 5: Nachahmung

Ziel: Dinge tun, die andere tun

Fragen, die wir uns stellen können:

  • Können wir den Testansatz des anderen Teams übernehmen?
  • Wie können wir dieses bewährte Design Pattern bei unserem Problem anwenden?

Ebene 6: Originalität

Ziel: Dinge tun, die sonst niemand tut

Fragen, die wir uns stellen können:

  • Können wir Behavior-Driven Design ausprobieren?
  • Können wir unser Projekt-Portfolio mit Kanban verwalten?

Ebene 7: Unmögliches

Ziel: Dinge tun, die unmöglich scheinen

Fragen, die wir uns stellen können:

  • Kann der Direktor der Behörde, die unser Kunde ist, unser agile Vorgehensweise für uns verkaufen?
  • Wie schaffen wir es, ein grosses Softwaresystem 26-mal im Jahr an 10 Kunden gleichzeitig in Produktion auszuliefern, ohne dass sie je einen Betriebsausfall haben?
  • Wie überzeugt man nichtagile Unternehmen zusammen mit uns agil vorzugehen?

Auf Seite 138ff meines Buches „Agile Prozesse: Fallstricke erkennen und vermeiden“ gehe ich mehr ins Detail, wie
dieses Tool in der Praxis angewendet werden kann.

Der Product Owner ist der Herr des Product Backlogs in Scrum. Er trägt die Verantwortung, dass der Kunde das bekommt, was er auch tatsächlich benötigt (nicht unbedingt, was das, was er möchte! – aber das ist eine andere Geschichte).

Die Rolle des Product Owners kann sich je nach Projekt und Firma in andere Richtungen bewegen, als sie ursprünglich gedacht war. Hier einige mögliche Entwicklungen (die sich meist negativ auf das Projekt auswirken).

PO maximiert Geschäftswert

Product Owner als Projektleiter

Der Product Owner kann unter Umständen sehr leicht in die Falle tappen, sich „nur“ als Projekleiter oder Koordinator zu sehen. Dies manifestiert sich darin, dass er an allen Meetings (auch Team-internen, oder sonstigen Leitungs-Meetings) teilnimmt.

Dabei kommen seine Kernaufgaben (die Pflege und Priorisierung des Backlogs, die Überwachung der finanziellen Mittel, die enge Zusammenarbeit mit dem Kunden) zu kurz. Häufig zieht ein Product Owner in solchen Momenten weitere Personen zur Hilfe heran, z.B. Business Analysten, um ihm zu helfen seine Kernaufgaben zu lösen.

Product Owner als Business Analyst

Der Product Owner kümmert sich in dieser Konstellation vor allem um Details der Anforderungen/User Stories und vergisst dabei gerne das Planen und Priorisieren gemäss den Wünschen des/der Kunden. Das Festhalten von Anforderungen fällt ihm auch deshalb einfacher, weil es bei dieser Arbeit weniger Konflikte mit dem Kunden gibt.

Dem Kunden andererseits zu entlocken, dass er eventuell auf gewisse Anforderungen verzichten sollte oder ihm klarzumachen, dass er Prioritäten setzen sollten, obwohl er den ganzen Funktionsumfang haben möchte, ist hingegen der Ort wo in der Regel die meisten Schwierigkeiten für den Product Owner liegen.

Product Owner als Administrator

Ich beobachte immer wieder, dass Product Owner (wie übrigens auch schlechte Projektleiter) zu reinen Administratoren verkommen können. Sie sind fern des Kunden, fern des Teams und organisieren lediglich Meetings oder koordinieren Leute. Dies ist ein Hinweis darauf, dass nicht nur mit dem Product Owner etwas nicht stimmt, sondern mit dem ganzen Projekt und den daran Beteiligten.

Product Owner als ScrumMaster

In Scrum gibt es eine bewusste Gewaltenteilung zwischen Product Owner und ScrumMaster. Letzterer ist verantwortlich für das bestmögliche Funktionieren des Prozesses und nicht der Product Owner. Übernimmt der Product Owner auch diese Rolle, kann dies verschiedene Ursachen haben. Zwei der häufigsten sind: Entweder der Product Owner ist sehr dominant oder der ScrumMaster nimmt seine Aufgabe nicht war.

Dies waren nur einige wenige Anti-Patterns, die mir bisher begegnet sind. In einem spätern Post mehr zu diesem Thema.

Zum vierten Mal jährt sich die, von der Fachgruppe „Lean Agile Scrum“ der Swiss ICT organisierte, Konferenz mit Fokus auf der Anwendung von modernen Entwicklungsvorgehensweisen. Dabei stehen einerseits die Erfahrungen von Anwendern von agilen Methoden im Vordergrund. Andererseits kommen Experten zum Wort, die über aktuelle Praktiken, die sich bewährt haben hinausschauen und neue Ansätze und Werkzeuge entdecken und vorstellen.

Als einer der Gründer der REDpill GmbH, darf ich in meiner Rolle als langjähriger Entwicklungsleiter der Löwenfels Partner AG, aus meiner Erfahrung plaudern, die sich doch nun schon über einen Zeitraum von 8 Jahren angesammelt hat.

Die LAS-Konferenz verspricht eine Plattform für den Austausch von Erfahrungen mit agilem Vorgehen, aus dem deutschschweizer Raum zu sein.

Ein Besuch lohnt sich. Zur Konferenz: http://www.lean-agile-scrum.ch/

Mein Vortrag: http://www.lean-agile-scrum.ch/sessions/in-8-jahren-und-128-releases-vom-grossprojekt-zum-produkt/