3 Produktivitäts-Killer für jedes agile Team

Agile Methoden wie Scrum oder Kanban zu verstehen ist einfach, sie aber gut umzusetzen hingegen weniger.
Mit diesen drei Killern, die ich im Alltag oft zu spüren bekommen habe, wird die Produktivität von jedem Team nachhaltig gebremst:

3. Das Team arbeitet dezentral

Es lässt sich oftmals nicht vermeiden, dass Teams an verschiedenen Orten zusammenarbeiten müssen. Welche Konsequenzen dies jedoch auf die Produktivität und Kosten hat, wird dabei oft übersehen.
Schauen wir uns einmal an, womit verteilt arbeitende Teams zu kämpfen haben:

  • Menschen nehmen Dinge besser auf, wenn sie sich sehen können. Die Mimik und Gestik, die z.B. von den Teilnehmern im Daily Standup vermittelt wird, sagt viel darüber aus, wie wohl sich die Team-Mitglieder mit dem Sprint fühlen. Dies ist ein Indikator für den Stand des Projekts. Fehlt diese wichtige Information, können Risiken nicht gesehen oder falsch eingeschätzt werden.
  • Wie lassen sich Gespräche, die „zufällig“ in der Kaffeeküche stattfinden, ersetzen? Mehr Teams erfordern mehr Kommunikation, damit sie nicht den Draht zueinander verlieren.
  • Video- und Telefonie-Technik muss für jedes Meeting absolut verlässlich arbeiten und daher gut vorbereitet werden. Das kostet Zeit. Gleichzeitig miteinander zu sprechen ist über Skype & Co nicht so einfach wie wenn man zusammensteht.
  • Team-Mitglieder, die am gleichen Standort arbeiten, entwickeln durch das tägliche Miteinander einen eigenen Spirit und kennen ihre Stärken und Schwächen. So können sie sich besser fachlich ausgleichen. Durch einen vereinfachten Wissenstransfer entstehen damit weniger Wissensinseln. Dadurch ist das z.B. bei Krankheitsfälle besser aufgestellt.
  • Auch wenn es im Team mal nicht ganz rund läuft, kann der Scrum-Master die Besetzung des Teams einfacher ändern, wenn das Team an einem Ort arbeitet. Spannungen und Disharmonien lassen sich erst wahrzunehmen, wenn man persönlich mit Leuten arbeitet.
  • Product Backlog, Impediment Log, Release Map, Story Maps… alle Dokumente sind nicht physisch greifbar, sondern zwischen elektronischen Tools (wie JIRA, Confluence) verteilt.
  • Arbeiten Teams in unterschiedlichen Zeitzonen, ist es mit bis zu doppelt so viel Zeit für die Synchronisation der Teams einzukalkulieren, jenachdem wie groß der Zeit-Versatz zwischen den Zeitzonen ist.
  • Der ProductOwner soll „mal eben“ etwas am Whiteboard skizzieren. Hoppla, dazu muss man ihn erst einmal telefonisch erreichen oder sogar einen Termin vereinbaren, statt am Nachbarbüro anzuklopfen. Und dann muss er seine Skizze auch digital anfertigen anstelle mit Stift und Papier, wenn er nicht parallel seinen Entwurf filmen möchte. Schade!
    Effektiv ist der ProductOwner in dem Moment für das Team nicht wirklich ansprechbar, denn allein die Hürde, um ihn anzurufen, ist zu hoch.

2 .Es wird an Hardware oder Lizenzen gespart

Wenn ich auf Baustellen bin, haben die Handwerker dort meistens Maschinen von Makita. Sogar das wetterfeste Radio. Die Dinger sehen oftmals abgenudelt aus, aber es ist schließlich DAS Werkzeug, mit dem der Handwerker jeden Tag seine Werk verrichtet.

In der IT scheint Geiz aber geil zu sein:
Auch in der IT werden Werkzeuge benötigt, die täglich und teils ohne Pausen zum Einsatz kommen. Diese Werkzeuge sind dann aber schlecht ausgestattet oder aber Marke Baumarkt für Hobby-Handwerker.
Beispiele:

  • Ich bin letztes Jahr, also 2015, in ein Büro eines Teams gekommen: Interne Mitarbeiter hatten schicke MacBooks, externe Mitarbeiter klapprige Windows-Rechner, per VGA an einen Monitor angeschlossen. Was für eine gewollte Zwei-Klassen-Gesellschaft!
  • Weil die Windows-Lizenzen ja schon teuer genug sind, werden einige Entwickler dazu gedrängt Eclipse zu verwenden, obwohl sie IntelliJ-Profis sind (das Beispiel ist nur exemplarisch zu sehen). Mitarbeiter sollten sich das Werkzeug, mit dem sie am besten arbeiten können, aussuchen dürfen – ohne Wenn und Aber.
  • Die Rechner sind lahm,  weil SSDs zu teuer sind. Und heute, da SSDs günstiger sind, werden winzige SSDs verbaut, weil größere ja zu teuer sind. Plötzlich geht gar nichts mehr: „No space left on device„! Ich glaube ich habe die Meldung zuletzt vor 20 Jahren gesehen. Aber nein, das war vorgestern, wir schreiben das Jahr 2016… Nicht zu fassen.
    Rechner müssen so ausgestattet sein, dass effiziente Arbeit damit möglich ist.
  • Ein Mitarbeiter möchte einen Zweit-Monitor oder sogar ein Retina-Display? Das geht wirklich nicht. Wenn er es wirklich will, muss er ein Beschaffungsformular gemäß den IT-Beschaffungsrichtlinien einreichen. Und Geduld haben. Viel Geduld für Bürokratie!
    Ich habe es erlebt, die Bestellung einer externen Festplatte hat 4 Monate gedauert, weil die Beschaffungsrichtlinie genau einen Händler vorsieht, der das Teil erst nicht vorrätig und dann falsch geliefert hatte. Geliefert hat am Ende übrigens Amazon.
    Für Bürokratie ist an einem wissens-intensiven Arbeitsplatz kein Platz.
  • Der Build-Server ist stets an seinen Grenzen, das Bauen von Artefakten dauert 30 Minuten? Das kann vorkommen, wenn man ihn sich mit anderen Teams teilt. Den Server mit RAM oder Speicher aufzurüsten würde das Problem schnell lösen. Aber verdammt, RAM ist so verdammt teuer geworden…
    Wenn Teams durch Wartezeit bedingt durch Hardware ausgebremst werden, kostet das Zeit und bremst damit den Fortschritt.

(Wenn ich so etwas erlebe, mache ich im Kopf eine Überschlagsrechnung:
Nehmen wir an, eine vernünftige SSD koste 400€ netto und ein Mitarbeiter werde intern mit 80€/Std. verrechnet. Nehmen wir ferner  großzügig an, der Einbau der SSD koste nochmal 2h intern, also 160€. Effektiv hat sie 400€+160€=560€ gekostet.
Das bedeutet, schon nach 7h Zeit-Ersparnis ist dieser Mitarbeiter produktiver und glücklicher.)

Geiz ist nicht geil. Zum Glück hat sich das schon etwas herumgesprochen. Dass ein Mitarbeiter aber glücklicher ist, weil er nach seinem Verständnis von Effizienz arbeiten kann, dadurch motivierter ist und produktivere Beiträge leistet… das lässt sich doch kaum in Geld aufwiegen!

1. Der Product Owner sind zwei Personen

Schizophrenie? Mehrere Personen als Product Owner zu haben ist ein Anti-Pattern, was es aber nicht besser macht ;-).
Warum ist dies ein Anti-Pattern und warum ist es überhaupt ein Muster?
Ein Erklärungsansatz: Es gibt mehrere Produkte oder Produkt-Sorten im Unternehmen, für die es jeweils einen Ansprechpartner gibt. Nun wird ein Scrum-Team gebildet, aber da es um alle Produkte oder -Sorten geht, sollen auch alle Produkt-Verantwortlichen gleichermaßen einbezogen werden.
Klingt nach Gleichberechtigung, birgt aber zahlreiche Probleme:

  • Ein Product Owner ist verantwortlich für den Produkt-Erfolg. Die Verantwortung wird bei mehreren Personen aber verteilt. Verantwortung ist jedoch nicht teilbar. Die Konsequenz von Verantwortung, die versucht wird auf mehrere Schultern zu verteilen: Niemand hat den Hut auf. Stattdessen wird Verantwortung verschoben.
  • Die Entscheidungsfindung wird verlangsamt und erschwert. Denn es dauert, bis sich mehrere Personen einigen. Wenn sie sich denn einigen können. Auch Rückfragen vom Team können nicht spontan geklärt werden, was die Entwicklungsgeschwindigkeit dramatisch reduziert.
  • Die Entscheidungen, die von mehreren Product Ownern getroffen werden, stellen lediglich Kompromisse dar. Denn wenn sich mehrere Personen in einer Sache nicht ganz einig sind und keinen gemeinsamen Nenner finden, hilft nur noch noch, ein gemeinsames Vielfaches als Lösung vorzustellen. Was nicht die beste Lösung ist.
  • Wen fragt das Team bei Rückfragen? Genau einen zentralen Ansprechpartner gibt es nicht. Soll es nur einen fragen oder beide? Wessen Meinung ist die bessere, wenn die beiden Product Owner gegensätzliche Antworten liefern. Nein, das funktioniert nicht.

 

Dies sind bloß drei Punkte, aber drei richtige Killer.
Welche Erfahrungen habt ihr im Projekt-Alltag gemacht? Ich bin auf eure Kommentare gespannt!