Vor kurzem wurde ich gefragt, ob es bis zu fünf Elemente in Scrum sowie gegebenenfalls bei der Rolle des Scrum-Masters gibt, die mich bei meiner täglichen Arbeit stören. Mich interessiert hierzu auch die Meinung der Teamprove Community und vor allem, wie Ihr mit bestehenden störenden, aber notwendigen Scrum-Master Aufgaben bei Eurer täglichen Arbeit umgeht.
3 Antworten
Hi,
ich bin gespannt ob es mir jetzt leicht fällt 5 Punkte zu finden, bzw. ob ich mich auf 5 Punkte beschränken muss. Ich schreibe das jetzt einfach mal so aus der Situation heraus runter :)
- Teammitglieder, die mich als Vorgesetzten (Teamleiter oder Projektleiter) sehen. Das äussert sich durch die Erwartungshaltung, dass ich zu allem immer die richtige Antwort haben soll, im Zweifel entscheide was jetzt gemacht wird oder "MIR" im Daily den Fortschritt berichtet und nicht mit dem ganzen Team in Austausch tritt.
- Meine Vorgesetzten/Auftraggeber, die mich als Überbringer ihrer Prozessveränderungen ins Team verstehen oder "missbrauchen". Hier wünsche ich mir eine direktere Interaktion mit dem Team so dass die verschiedenen Sichtweisen bei einer gewünschten Veränderung einbezogen werden können.
- Meine Vorgesetzten/Auftraggeber, die Optimierungen an der Zusammenarbeit und Prozessen nicht mit mir besprechen und mir somit keine Möglichkeit geben, meine Expertise einzubringen. -> Wertschätzung fühlt sich anders an
- Dogmatische Scrum Verfechter, die in jeder Situation direkt mit dem Scrum Guide unter dem Arm um die Ecke kommen und dabei übersehen, dass Scrum von Inspect & Adapt lebt und damit der Scrum Guide niemals fertig sein kann und darüber hinaus, die Zusammenarbeit und Interaktion eben wichtiger ist als Prozesse und Tools sind. (Hab ich mal irgendwo, ich glaube im Agilen Manifest gelesen :))
- Beteiligte, die mich als Super-Helden sehen, der niemals schwach sein darf und keinen Bedarf hat mal andere zu fragen. (Wenn ich in dieser Situation bin, habe ich aber zum Glück meine Kollegen und diese diese Fragen- und Antwortplattform :) )
Jetzt sind es genau 5 geworden. Wahrscheinlich hätte ich bei längerem Nachdenken auch noch weitere gefunden. Ich bin jetzt gespannt, ob meine Perspektive durch andere Antworten bestätigt, erweitert oder revidiert wird.
Zunächst erst mal 100% agreed mit Matthias Antwort. Das sind ganz wichtige Dinge, die mir auch oft im Wege stehen bzw. die die eigene Arbeit sehr behindern. Gleichzeitig bin ich mir bewusst, dass eben diese Phänomene die Nachwirkungen traditioneller Arbeitsweise und Kultur sind. Die eigentliche agile Transformation, die notwendig ist, findet genau auf dieser Ebene statt. Z.B. durch viel Aufklärung und Ent-Lernen alter Gewohnheiten.
Passend zum Ent-Lernen fallen mir noch diese Punkte ein:
1. Epics/User Stories/JIRA-Items werden wie bisher verwendet (also detailliert vorbeschrieben) und verkommen damit auch nur zu einem Dokument. Über Dokumente kann kein gemeinsames Verständnis hergestellt werden, sondern nur durch gemeinsame Diskussionen und Visualisierung aller individueller Gedankengänge. Wie Jeff Patton es so schön sagt: If you end conversations you have stopped to use stories! User stories are not a different way to write requirements, they are a different way to work!
2. Aus der Forderung nach gemeinsamen Diskussionen ergibt sich daraus oft ein Widerstand, weil die Organisation glaubt, wenn viel geredet wird, wird nicht gearbeitet. Das ist schlicht falsch. Softwareentwicklung besteht im Wesentlichen aus Kommunikation. Working Code ist ein Nebeneffekt davon. Und nicht andersherum.
3. Lokale Optimierung wird oft von der Organisation wichtiger bewertet, als globale Optimierung. Es kommt aber nicht darauf an, dass jeder 100% ausgelastet ist, sondern dass effektiv am Ende des Sprints etwas geliefert werden kann. Das Loslassen von der alten Maxime 'Effizienz über alles' fällt insbesondere Führungskräften schwer. Das Festhalten an der Effizienzmaxime führt interessanterweise dazu, dass sich die Organisation so sehr mit sich selbst beschäftigt, um alle auszulasten, dass negative Effekte auf die Gesamtleistung schlicht nicht wahrgenommen werden. Die Mitarbeiter sind dann eben zu 100% beschäftigt mit allerlei Bürokratie und Prozess-Overhead, der Anteil an werthaltiger Arbeit für den Kunden liegt aber erschreckend niedrig. 'If you want busy people, you will get... busy people'.
4. Unpassende Strukturen, keine echte Cross-Funktionalität und viele Abhängigkeiten, die notwendige Entscheidungen oder Zulieferungen lange hinauszögern und somit ein Team schlicht lieferunfähig machen. Cross-funktionale Arbeit bedeutet nicht am Ende eines langen Vorprozesses, wo Product Owner und andere Beteiligte aus den Fachbereichen Epics und User Stories auf Halde in einem übervollen Backlog erzeugen, das dann von einem quasi-cross-funktionalem Team (Architekt, Entwickler, Tester) abgearbeitet werden soll. Genauso wenig wie dass Teams Sprint um Sprint neue Funktionen für eine Integrationsumgebung zur Verfügung stellen, die vierteljährlich dann in einer großen SIT-Phase durchgetestet werden.
Cross-Funktionalität bedeutet: Fachbereich, Product Owner, Developer, Tester, Release-Management, ... all diese Rollen gehören zum Scrum-Team dazu und erarbeiten gemeinsam das Backlog und Arbeiten dieses gemeinsam ab. So, wie es im namensgebenden Dokument 'The new new product development game' von Hirotaka Takeuchi und Ikujiro Nonaka erwähnt wurde: 'Like the Scrum moves down the field as a whole...' Es bedeutet eben nicht, dass jemand etwas vor-denkt und andere etwas nach-liefern!
5. Und zu guter letzt: Überflüssig gewordene Rollen, team-außenstehende Entscheider, die die Autonomie und Verantwortung des Scrum-Teams verletzen. Entweder man ist Teil eines Teams und damit auch voll verantwortlich für das Liefern oder man ist es eben nicht! Super-Heroes (so genannte 'freie Radikale'), wie sie traditionelle Strukturen oft hervorgebracht haben, sind schädlich für die Teammotivation und darüberhinaus ein Bottleneck-Risiko für die Organisation. Das ist nicht die Schuld der Super-Heroes, sondern eine Folge des Systems. Denn Menschen werden passend zu den gegebenen Arbeitsstrukturen über die Zeit - ob wir wollen oder nicht - entsprechend konditioniert. Und so fällt es manchem Hero schwer, sich wieder einzugliedern in ein Team und die über die Zeit aufgebaute Macht, die insbesondere durch das hohe Wissen legitimiert ist, wieder loszulassen. Ich rate meinen Kunden im Zweifelsfalle dazu, diese Wissensträger gehen zu lassen. Unter dem Strich wird die Organisation davon profitieren. Agilität ist leider nicht für jeden gemacht. Das lässt sich nicht ignorieren.
Weil ich es aktuell wieder erlebe: Man kommt als Scrum-Master zu einem neuen Projekt hinzu und möchte die agilen Prinzipien zum Leben erwecken. Blöd nur, wenn das Kind schon lange in den Brunnen gefallen ist. Z.B. man entscheidet sich dafür, eine neue Webapplikation zu entwickeln. Also benötigt man dazu ein Scrum-Team und Entwickler und auch einen Scrum-Master. Und dann stellt man im Kickoff-Meeting fest, dass bereits Monate zuvor im stillen Kämmerlein an Web-Designs und Funktionalitäten gearbeitet wurde und der Auftrag nun lautet: 'Bitte baut das genau so!' Das ist nicht Agilität, auch wenn dann iterativ das Design abgearbeitet wird. Der Unterschied zum Wasserfall ist marginal. Und von Agiltität wertgetriebenen Denken kann das Projekt bereits nicht mehr profitieren. Schlimmer noch, wenn die Entwickler jetzt das vorgefertigte Design challengen und eigene Ideen dazu haben. Nicht selten entstehen daraus Konflikte und werden dann so gelöst: 'Aber das sind die Anforderungen!'. Leider gibt es in komplexen Projekten keine wirklichen Anforderungen, da diese genau genommen alles Hypothesen sind, die noch nicht bewiesen sind, ob sie tatsächlich die Kundenprobleme und -nöte lösen. Anforderungen hingegen beinhalten die implizite Aussage: 'Shut up!'.