Das schicke Auto hält langsam vor dem Eingang des opulenten Hotels, die Kameras richten sich auf die Autotüren, eine Person im schicken Anzug steigt aus und öffnet die Tür. Der Star zeigt sich und das Blitzlichtgewitter fängt an. Menschen überhäufen den Star mit Fragen und halten ihm Mikrofone vor das Gesicht. Sie schauen mit glänzenden Augen zu ihm auf und wollen alles über ihn wissen. Der Star ist angekommen und fühlt sich geschmeichelt. Blöd nur, dass wir nicht auf dem roten Teppich sind, sondern in einem Büro und die Fragen wohl eher auf Projekt und Produkt abzielen, als auf die großartige Persönlichkeit der Person. Diven gibt es überall; lasst uns gemeinsam das Diven-Muster untersuchen
Scrum Master ‚Diven‚
Falls es euch schon mal passiert ist, dass der Scrum Master jede einzelne Frage beantworten kann, die er vielleicht selbst gestellt hat, die Antworten rauf und runter beten kann und sich wundert, warum niemand im Meeting mitmacht, dann hattet ihr es wahrscheinlich mit einer Diva zu tun. Der Scrum Master als Servant Leader achtet auf den Zuwachs an Wissen in seinem Scrum Team, während die Diva eher darauf aus ist, das eigene Wissen zu zeigen und abzurufen und leider an vielen Stellen nicht weiß, wo Zurückhaltung angebracht ist. Zudem neigen Scrum Master Diven dazu, sehr empfindlich zu reagieren, wenn sie in Frage gestellt werden. Scrum Master Diven dienen nicht ihrem Team, sie dienen sich selbst und ihrem Image, wie es eine klassische Diva tut. Es wird zwar nach Feedback gefragt, doch nur um sich zu versichern, dass die eigene Meinung unterstützt oder gefestigt wird. Die gesamte Konzentration zielt auf die eigene Person ab, weil man doch der Scrum Master in dem Team ist und alles über Agilität weiß. Andere Menschen, die neben der Diva stehen, werden schnell abgesägt oder klein gemacht, so dass die Diva umso mehr strahlen kann. In meinen Augen ist dies für die gesamte Organisation eine sehr bedrohliche Situation.
Product Owner ‚Diven‚
Die Product Owner Diva hat viel Ähnlichkeit mit der Scrum Master Diva. Hier ist ebenfalls deutlich zu erkennen, dass die Empfindlichkeit sehr hoch ist und die Menschen im Umfeld darauf achten müssen, dass es nichts wichtigeres und besseres gibt als das, was die Diva sagt. Versteht das Entwickler-Team die User-Story nicht, ist es deren eigene Schuld. Leistet das Team nicht genug, wird der Scrum Master in die Pflicht genommen, schreit einem das Burndownchart entgegen dass das Team zu langsam ist, weil ist Scrum als Framework schuld sei, weil man in der Wasserfallmethodik alles durch Deadlines besser kontrollieren konnte. Ebenfalls eine Illusion. Die Product Owner Diva findet immer etwas, um selbst nicht in der Verantwortung zu sein. Leider korreliert dies immer mit einer Ladung Hochmut und Unnahbarkeit, denn warum sollte eine Product Owner auch eng am Team sein? Eine Diva sitzt auch auf ihrem Thron und lässt sich bedienen. Ist dieser Thron auch noch auf Unsicherheit aufgebaut wird es extrem komplex und nicht leicht zu lösen. Darf eine Diva ein Team zu einem guten Produkt leiten? Sofern es ein Product Owner macht? Ich bezweifle es.
Entwickler ‚Diven‚
Sich einer Sache verpflichten, der Qualität, des Sprintbacklogs, des Sprintgoals. Zu wissen was zu tun ist und wann. Trotzdem herrscht unter den Diven eine Launenhaftigkeit. Selbstvergnügt und die User-Storys missachtend sitzen sie dort und klappen ihre Laptops auf. Agilität? Scrum? Gerne, aber nur um uns gegen dieses böse Management zu schützen, denn wir sind die Arbeiter oder die Diven. Scrum verkommt zum Mittel gegen einen nicht existierenden Feind. Arbeit muss getan werden, ein Produkt soll entstehen, wie kann man dies bewerkstelligen, falls die Entwickler es nicht wollen? Angeblich versteht der Product Owner die Technik nicht und deshalb sind die User-Storys falsch. Die Diva will verstanden werden, doch dass der Product Owner diese Rolle nicht ausfüllt, wird ignoriert. Der Scrum Master erfüllt nicht alle Maßnahmen aus der Retrospektive, dass das Team selbstorganisiert an den Maßnahmen arbeiten soll, wird vergessen. Die Diven wollen in ihrer Komfortzone bleiben und das tun was sie wollen, egal, was für das Produkt das Beste ist. Fortlaufend werden massive Qualitätsschwankungen entstehen, die wiederum auf das Team zurückfallen. Alles in allem können Diven nicht das erfüllen, was ein agiler Developer erfüllen soll.
Stakeholder ‚Diven‚
Die einzigen Diven, die immer verfügbar sein sollten und bedient werden müssen. Stakeholder haben Wünsche, manche sind Diven und sehr streng, aber diese Diven sind gern gesehen, denn alles was sie wünschen, macht das Produkt in der Regel besser.
Was dagegen tun?
Wir setzen oft die gleichen Mittel ein. Transparenz, um Probleme sichtbar zu machen. Hinter jedem Problem, das in den Vordergrund rückt, steht eine Person mit Bedürfnissen und Konflikten im Hintergrund. Warum ist der Product Owner empfindlich? Findet es heraus. Wieso stellt sich der Scrum Master ständig in den Vordergrund und nimmt dem Team die Möglichkeit, sich zu entfalten? Wie kommt das Development Team auf die Idee, dass sie sich hinter den agilen Werten verstecken können? Welche Gefahren und Konflikte werden damit beiseite geschoben? Scrum ist Empirie. Subjektive Erfahrungen fließen in die tägliche Arbeit mit ein. Pragmatismus und völlige Illusionslosigkeit bei der Arbeit. Wir alle mögen Magie und diese passiert, wenn der Kunde auf das Produkt reagiert. Diven lassen sich schlecht in dieses Konzept einzwängen, weil sie Platz für sich und ihr Ego brauchen. In einem gruppenbasierten Framework wie Scrum ist es aber sehr schwierig, so etwas zu tolerieren. Fällt euch so ewas auf, sprecht es an! Nutzt Scrum dafür, denn Scrum bietet genug Feedbackschleifen!
Fazit
Jeder kennt sie, manche benötigen sie, aber nur in begrenzter Dosis und außerhalb des Frameworks. Diven sind vorhanden, oft mehr als genug. Redet mit den Leuten und löst dieses Verhalten entweder auf oder versucht, mit den Diven zu arbeiten. Es ist gesund für das gesamte Umfeld und bringt neue Erkenntnisse. Viel Erfolg dabei!