Impediments
 |
| Bild: Flickr / WSDOT - CC BY-NC-ND 2.0 |
Fragt man einen beliebigen Scrum Master aus welchen Tätigkeiten sein Beruf eigentlich besteht wird mit Sicherheit eine dabei sein: das Beseitigen von Impediments. Nachfragen was mit diesem Begriff gemeint ist führen dann aber erstaunlich häufig zu dem Punkt an dem nicht mehr näher erläutert werden kann was er bedeutet, nur dass er irgendwie alles umfasst was irgendwie problematisch ist wird meistens genannt. Dabei ist es eigentlich gar nicht so kompliziert.
Als erstes ist es wichtig zu verstehen, dass dieser Begriff oft deshalb mystifiziert wird, weil er ein eher selten vorkommendes Fremdwort ist. Englische Muttersprachler tun sich da leichter, weil es für sie ein ganz normales Wort ist - Impediment bedeutet übsetzt Hindernis oder Behinderung, und genau das ist in Scrum damit auch gemeint: irgendein Hindernis, das dazu führt, dass das von ihm betroffene Team in seiner Arbeit verlangsamt oder blockiert wird.
Auch das ist natürlich noch unkonkret, es lässt sich aber konkretisieren. Man muss sich nur fragen welche verschiedenen Kategorien von Behinderungen es geben kann von denen Teams üblicherweise betroffen sind. Aus denen ergeben sich dann auch unmittelbar die notwendigen Gegenmassnahmen, mit deren Durchführung oder Veranlassung der jeweilige Scrum Master dann (unter anderem) beschäftigt ist. Hier ist eine (sicherlich unvollständige) Übersicht:
Fehlende Personalkapazität
Einer der grossen Klassiker. Entweder sind zu wenige Leute im Team um in der gewünschten Geschwindigkeit voranzukommen oder die Teammitglieder sind nur in Teilzeit verfügbar und zum Teil an anderer Stelle verplant. In solchen Situationen ist es hilfreich den Personalverantwortlichen mit Hilfe valider Statistiken (Velocity, Lead Times, Durchschnittszeit in Meetings, etc) aufzeigen zu können, dass ohne mehr Kapazität die angestrebten Ziele nicht rechtzeitig erreicht werden können.
Fehlende Skills
Kann in verschiedenen Ausprägungen vorkommen. Entweder müssen bestimmte Tätigkeiten extern vergeben werden oder sie dauern bei interner Ausführung länger als möglich. Auch hier lässt sich das Problem mit Hilfe von Statistiken aufzeigen, sei es in Form der Wartezeiten auf externe Zulieferungen oder in Form hoher Aufwände für Analyse und Bugfixing. Beides ist normalerweise auf Dauer teurer als eine Weiterbildung oder eine Vergrösserung des Teams um Experten sein würden.
Fehlende Ressourcen
Ressourcen sind hier nicht als menschliche Mitarbeiter verstanden sondern als sonstige benötigte Mittel. Von der Entwicklungs- und Test-Umgebung über leistungsfähige Rechner, angemessene Arbeitsplätze, ausreichend vorhandene Meetingräume und Büromaterialien bis hin zu banalen aber notwendigen Dingen wie Klopapier in den Toiletten - ohne all das sind die Effektivität und Effizienz eines Teams stark eingeschränkt, was sich den Budget-Verantwortlichen in der Regel auch einfach erklären lässt.
Fehlende Genehmigungen
Von der fehlenden Genehmigung mit Kunden zu sprechen bis zur fehlenden Genehmigung auf Produktion zu deployen ist hier vieles möglich, und in der Regel wird es nicht aus bösem Willen verweigert sondern aus Angst vor Kontrollverlust. Hier sollte nicht nur aufgezeigt werden, dass Genehmigungs-Bürokratie diesen Kontrollverlust erst recht herbeiführt, sondern auch, dass Scrum mit seiner Transparenz und seiner kurzfristigem Umsteuerbarkeit sogar für mehr Kontrolle sorgen kann - wenn man die Teams machen lässt.
Falsche Priorisierungen
Selbst wenn falsch und richtig bei Backlog-Priorisierungen schwierige Begriffe sind - wenn Refactoring, Bugfixing, Testautomatisierung und Ähnliches immer wieder zugunsten neuer Features wegpriorisiert werden wird es unvermeidbar zu Problemen kommen. Die Aufgabe an dieser Stelle muss sein, dem (vermutlich technikfernen) Product Owner begreiflich zu machen, dass er bei diesem Vorgehen nicht schneller zu neuen Features kommt sondern langsamer, da alles umständlicher und fragiler wird.
Externe Störungen
Die in der Regel am schwersten zu beseitigende Art von Impediment, da diejenigen die versuchen in laufende Sprints oder am Product Owner vorbei Aufgaben an die Entwickler zu geben oder Priorisierungen zu ändern in der Regel Stakeholder und Manager mit Einfluss, Budget- und Personalverantwortung sind. Im Besten Fall lassen sie sich davon überzeugen, dass sie so nicht helfen sondern stören, im schlimmsten Fall bedarf es einer Eskalation zu ihren Vorgesetzen.
Interne Störungen
Die Art von Impediment mit der sich viele Scrum Master am schwersten tun, selbst wenn sie hier den grössten Handlungsspielraum haben. Vom narzisstischen Entwickler der Code Ownership will bis zu den Teammitgliedern die sich über Nichtigkeiten zerstritten haben - die möglichen Ursachen für zwischenmenschliche Probleme sind zahllos. Hier darf jeder Scrum Master sich als Konflikt-Moderator, Vermittler und Mediator beweisen um die beteiligten Egos wieder zusammenzubringen.
Wie oben gesagt, diese Aufzählung ist mit Sicherheit unvollständig, sie gibt aber eine Idee davon was gemeint ist wenn von der Beseitigung von Impediments die Rede ist. Sie zeigt durch ihre grosste thematische Breite auch auf was den Job des Scrum Masters so anspruchsvoll macht, denn in allen diesen Themen muss er in der Lage sein mitzureden. Dass das oft nicht der Fall ist, ist übrigens auch einer der Gründe dafür, dass sich viele so schwer damit tun zu beschreiben was Impediments sind.
