Diese Seite setzt Cookies ein, um das Nutzerlebnis zu verbessern. Durch Klick auf "OK" erklärst Du Dich damit einverstanden. Mehr dazu gibt es unter Datenschutz.

OK

Nachlese zur Agile World 2015 – Kaizen, Messen, Optimierungen und wer braucht eigentlich Scrum Master?!

Nun auch schon wieder ein halbes Jahr her: die Agile World 2015. Hier – mit Verspätung – ein paar Dinge, die bei mir hängen geblieben sind.

Ausschnitt aus Lageplan der Agile World 2015

Ausschnitt aus Lageplan der Agile World 2015

Das waren allen voran drei Punkte:

Beim Messen mehr ausprobieren

Statistiken selbst definieren, ggf. auch als „Wegwerf-KPI“, der nur einmalig eine Sache misst und danach verworfen wird – sehr schön beschrieben im Vortrag „Inspect and adapt: Kaizen messen!“ von Sascha Storz (Xing). Seine Methodenkenntnis (d.h. hier Statistikkenntnis) habt sich wohltuend von vielen, vielen anderen Beiträgen in Blogs und Zeitschriften abgehoben. Endlich mal einer, der weiß wovon er spricht, wenn er Zahlen präsentiert.

Möglichkeiten agile Teams – auf dem Weg zur agilen Organisation(!) – in nicht agile Umfelder integrieren.

Im Vortrag „Agile Metriken – was sinnvoll und notwendig ist, um ein großes agiles Projekt zu steuern“, von Alexander Birke (Xing), ging es für mich weniger darum große Projekte per se zu steuern, sondern eher Projekte in sehr großen Unternehmen. Und das sind – okay, okay, ich geb’s ja zu – gerne mal Großprojekte. Faktisch lief es darauf hinaus, das Henne-Ei-Problem zu lösen. Nämlich wie man agile Methoden anwenden kann, bevor die Organisation die agile Transition vollzogen hat.
Denn seien wir ehrlich, in der Regel fangen Teams an agile zu arbeiten und das Management zieht nach. Dann wird gerne mal auf das Management geschimpft – ohne dass man daran gedacht hat, dass der Informationsbedarf des Managements (dafür sind Reports und Reportings eigentlich da …) berücksichtigt wurde.Um nun die Transition einfach zu machen, oder zumindest mal den Blocker aufzulösen, hat Alexander Birke gezeigt:

  • welche KPIs das Management (klassischer Weise) verwendet und wie sich diese zusammen setzen;
  • welche Größen beim agilen Arbeiten gemessen werden können und was sie aussagen;
  • welche der „agilen KPIs“ man wie transformieren kann, damit sie die Aussagen der KPIs treffen, die das Management bisher gewöhnt war;

Das war schon ziemlich cool, da es sehr pragmatisch war ohne dabei wesentliche Elemente und Gedanken agilen Arbeitens aufzugeben. So hätte ich mir das von einem Scrum Master erwartet: Blocker auflösen, Teams handlungsfähig halten und den gewonnenen Spielraum nutzen um zu coachen (hier: die agile Transition des Managements voran zu treiben).

Leider hatte ich den Eindruck, dass diese Zielsetzung nicht von allen Hörern des Vortrags in der Form erkannt wurde – was dazu geführt hat, dass Alexander Birke mit einigen Nachfragen vom Kaliber „das ist doch gar nicht agil“ zu tun hatte. Schade. Aber auch das hat er gut hinbekommen.

Ein krasses Missverständnis der Scrum Master Rolle.

In den offenen Gesprächsrunden kam immer wieder der Punkt auf, dass man Scrum Master gar nicht brauche. Insbesondere, da er ja gar nichts zu tun habe und überflüssig sei, wenn der Product Owner seine Arbeit macht.Boah. Ernsthaft?! Der Scrum Master ist doch nicht ausschließlich ein Korrektiv für einen nicht funktionierenden Product Owner.

Im Gegenteil – wenn der Scrum Master die ganze PO-Arbeit macht, dann läuft was falsch. Dann sollte man mal ein ernstes Wort mit dem PO reden (sofern er seine / sie ihre Arbeit nicht macht. Und mit dem Scrum Master, wenn er / sie sich in die Arbeit vom PO einmischt).

Zur Erinnerung: Die Scrum Master Rolle gibt es, damit es eine Position in dem Prozess gibt, die sich dediziert mit dem Vorgehen und der Arbeitsweise beschäftigt und diese verbessert:

  • Wie kommunizieren die Beteiligten?
  • Wer kommunziert mit wem?
  • Welche Konflikte enstehen?
  • Wie ist der Umgang mit Problemen, denen man bei der Arbeit begegnet?

Der Scrum Master löst ggf. Probleme indem er / sie bspw. ein Gespräch mit den Beteiligten ansetzt und moderiert / Entscheidungsbedarf sichtbar macht, Konflikte lösen hilft etc.
Im besten Fall macht er / sie das Team und alle Beteiligten fit, so dass sie selbst dazu in der Lage sind diese Punkte zu reflektieren und anzugehen.

Im besten Fall. Leider ist das in der Regel schwierig, da sich die Beteiligten – bis auf den Scrum Master – in erster Linie in operativen Tätigkeiten befinden. Und der Scrum Master ist der- / diejenige die einen Schritt zurück gehen und das Handeln als solches analysieren und Vorschläge zur Verbesserung formulieren kann.

Wer also den Scrum Master abschaffen will, der kann das schon tun, sollte sich aber vorher überlegen ob er das wirklich will.

Ausnahme: das Team besteht (ganz vereinfacht gesagt) aus drei, vier Freunden, die in der vielzitierten Garage sitzen und ihr Produkt bauen. Also sehr kleine Organisationen / Teams, in denen implizit bereits ein Prozess besteht (die Freunde haben alle die gleiche Arbeitsauffassung und ein änhliches Kommunikationsverhalten). Dann brauche ich den Scrum Master nicht, das habe ich in den Diskussionsrunden auch immer dazu gesagt. Aber in größeren Unternehmen … be my guest.

Nundenn, so viel zur Agile World 2015. Schauen wir mal, was 2016 bringt.

Verwandte Artikel

Schönen Samstag!