Scrum Rollen in anderen Galaxien!

 

 

….da wagte ein junger Berater-Schüler, das gut geplante, doch ungewöhnlich umgesetzte Scrum-Framework einer Organisation zu hinterfragen.

 

 

Wie konnte er nur?

 

Es entstanden kuriose Diskussionen über die Aufgaben einzelner Rollen. Ich rede hier nicht von den klassischen Rollen, die wir kennen, NEIN, es waren die Rollen, die hinzugedichtet wurden und als unabdingbar galten. Man müsse eben  auch als Berater von aussen verstehen, dass gewisse Elemente einer Branche nicht vor Scrum Halt machen könnten…und so öffnete der junge Berater-Schüler wohl unbewusst die Luken zum Todesstern und liess einige bis dato unerwartete Scrum-Rollen aus der Kiste…..Alle diese Rollen hatten eines gemeinsam, sie versprachen einem Keksen und faselten etwas von einer dunklen Seite….

 

 

Der junge Berater dachte sich wie die Leser seines Blogs, dass er davon ausgehen konnte, dass die meisten bereits mit den typischen Rollen vertraut sind, wenn es um Scrum geht (ihr wisst schon, das Scrum Team, der Scrum Master, der Scrum Product Owner).

Er war sich auch sehr sicher, dass alle wussten, welche Aufgaben jeder von ihnen erfüllen sollte und wie sie interagieren und zusammenarbeiten sollten, um ein Projekt erfolgreich abschliessen zu können.

 

Aus diesem Grund wollte er auch aufhören, über traditionelle und bekannte Scrum-Rollen zu sprechen, um sich mit einigen anderen ungewöhnlichen jedoch einflussreichen Rollen vertraut zu machen, die es auch in deinem agilen Team geben könnte.  

 

Sei also auf der Hut!

 

Um seinen Standpunkt besser zu erklären, schrieb er uns eine (nicht umfassende, aber hoffentlich ziemlich relevante) Liste von Rollen auf um diese Erfahrungen uns zur Verfügung stellen.

 

Mal sehen, ob wir auch diese Rollen in unserem Team erkennen 😉

 

—

 

Die wortreichen „Gäste“ des Meetings

 

Obwohl sie nicht wirklich eine besondere Meinung über etwas haben, werden sie vorgeben, eine zu haben, nur um Zeit zu verschwenden, indem sie ihren Sprechautomat benutzen um andere Leute zu verwirren. Sei es bewusst, oder unbewusst…

Mehr noch; selbst wenn sie sich dazu bekennen mit jemandem über etwas übereinzustimmen, müssen sie mindestens eine halbe Stunde damit verbringen, ihre Zustimmung zu betonen; ganz zu schweigen davon, wenn sie vorgeben, nicht übereinzustimmen…

 

 

 

Die engstirnigen Untergebenen

 

Sie tun nur, was ihr Chef ihnen sagt.

Auch wenn jemand der Meinung ist, dass diese Art von Arbeitern leicht zu managen sind da sie ihrem Chef immer zunicken, macht die Tatsache, dass sie normalerweise nicht in der Lage sind eine persönliche Meinung zu einem relevanten Thema zu haben, sie in einer agilen Umgebung praktisch nutzlos.

Merkwürdigerweise entscheiden sie sich im entfernten Fall, ihre “Meinung” mit dem Rest des Teams zu teilen, denn ihre Meinung stimmt immer genau mit der überein, was ihr Boss bereits gesagt hat.

 

 

Die irreführenden Programmierer

 

Wenn ein Tester den Entwickler nach etwas Merkwürdigem fragt, von dem er glaubt, es in der Anwendung gefunden zu haben, versucht dieser lieber schnell diese Veränderung vorzunehmen, wobei er sich auf etwas anderes konzentriert (etwas Ähnliches natürlich, aber völlig unabhängig von dem speziellen Bereich, der von dem merkwürdigen Gefühl des Testers betroffen ist), nur um sicherzugehen, dass der Tester durch eine gut funktionierende Funktionalität abgelenkt werden kann.

Übrigens, was diese Programmierer wahrscheinlich tun in der Hoffnung den Tester dazu zu bringen sich mit dieser lästigen Gewohnheit abzufinden und einfach zu einer anderen Aufgabe/Funktion zu springen, könnte den gegenteiligen Effekt haben da der Tester normalerweise anfängt, diese seltsame Sache zu untersuchen die ihre Aufmerksamkeit noch tiefer in sich gefangen hat…

 

 

Die verblendeten Testdesigner

 

Für diese Art von Leuten ist es egal ob eine Anforderung überhaupt Sinn ergibt oder eben nicht. Anstatt eine Überprüfung der Anforderungen vorzuschlagen, fangen sie einfach atemlos an zu arbeiten, um so schnell wie möglich einen Testfall zu haben um dann auch noch den Unsinn zu überprüfen.

 

Wenn der Testfall also fertig ist und ein aufgeschlossener Tester erkennt, dass sowohl die Anforderung als auch der Testfall keinen Sinn ergeben, gibt es für das Team trotzdem oder gerade deswegen noch eine Menge Arbeit zu tun: eine Anforderung muss aktualisiert werden, eine Implementierung muss überprüft werden, ein Testfall muss wahrscheinlich gelöscht werden, ein neuer Testfall muss entworfen werden…

Und selbst wenn es wahr ist, dass einige dieser Dinge sowieso hätten getan werden müssen, in einer weniger engstirnigen und agileren Umgebung hätten einige von diesen Tests früher erledigt werden können während andere vielleicht gar nicht erstellt worden wären.

 

 

 

Die boykottierenden Entwickler

 

Auch wenn sie normalerweise stolz darauf sind, dass sie einige Fehler in der Anwendung eingebaut und belassen haben, nur der Kontinuität des Projekts zuliebe, würde ich nicht darauf wetten, dass sie in der Lage sind, all diese Fehler zu beheben. Ausserdem ist ihr Code normalerweise so schlecht, dass niemand sonst in der Lage ist diese Veränderungen zu ändern, geschweige denn zu refaktorisieren.

Es muss nicht erwähnt werden, dass diese Art von altmodischem und unethischem Verhalten besonders bei kritischen Projekten riskant sein kann.

 

 

Die grosszügigen Inkompetenten

 

Sie sind normalerweise in fast allem inkompetent was kein ernstes Problem darstellen würde, wenn sie nicht bei allem helfen wollten, in dem sie unfähig sind.

Mit anderen Worten das Problem ist je schlechter sie etwas tun, desto mehr wollen sie helfen etwas zu tun.

 

Seltsamerweise lehnen sie normalerweise die Hilfe anderer ab, vielleicht nur, um sicherzustellen, dass sie die einzigen sind, denen es erlaubt ist zu “helfen”…

 

 

Die laaaaaangsamen Typen

 

Nicht zuletzt passen Menschen die aus offensichtlichen Gründen [PAUSE] denken und [PAUSE] langsam [PAUSE], sehr [PAUSE] langsam [PAUSE] handeln, nicht sehr gut in eine agile Umgebung. Ausserdem, da sie sich normalerweise nie unter Druck fühlen, gibt es keine Möglichkeit, sie schneller zu machen: sie werden einfach in ihrem gemächlichen Tempo weitermachen.

 

Auch wenn sie für Projekte, die auf andere Art und Weise funktionieren, sicherlich nützlich sein könnten, scheinen sie sich nicht für eine Umgebung zu eignen, in der sie kontinuierliche Leistungen erbringen und in der man stattdessen besser die Verwendung von pro-aktiven und schnelleren Typen nutzen sollte.

—

 

Nun, wenn du bis hierher gelesen hast, liegt es wahrscheinlich daran, dass du einige dieser unerwarteten Rollen in deinem Scrum-Team erkannt hast. Ausserdem scheinen einige Leute eine Gabe zu haben, mehr als eine dieser Eigenschaften gleichzeitig zu haben.

 

 

Wenn dem so ist, solltest du ernsthaft in Betracht ziehen, dass sie, wenn du sie nicht loswirst, deine zerbrechliche Umgebung sprengen könnten, da sie (unbewusst oder nicht) wirklich darauf erpicht sind dein (nur scheinbar) agiles Team zu zerstören, zumindest bis sie an Bord der Fähre des Imperators sind…

 

In diesem Sinne, „Do or do not there is no try“, lasst und nicht gleichzeitig eine Aufgabe erledigen indem wir sie nicht erledigen. Wenn du etwas tust, dann verpflichte dich. Engagiere dich, oder tue es überhaupt nicht. Ich bin gespannt auf weitere, ungeahnte Rollen im Scrum Universum…

 

 -Euer Sven