Scrum oder nicht Scrum?

veröffentlicht am : Mo, 14. 08. 2017 geändert am: Mo, 14. 08. 2017

Kategorie: Allgemeines

Schlagworte: scrum


... das ist nicht die Frage!

Denn genau das ist das Problem, viele verstehen den agilen Ansatz der Softwareentwicklung nicht wirklich. Ich würde das gerne mal ein wenig Beleuchten...

Softwareentwicklung früher

das vielleicht gute, auf jeden Fall aber alte Wasserfallmodell. Das sollte hinlänglich bekannt sein. Übertrieben formuliert teilt man ein Projekt in 2 Phasen ein - Konzeption und Implementierung. Das hat man sich von anderen Projekten so abgeguckt, wie z.B. dem Hausbau. Da gibt’s auch zuerst einen Plan und dann eben wird erst was getan.

Das hat auch seine Daseinsberechtigung in der Software: man konzeptioniert etwas komplett durch, macht einen Plan bis ins kleinste Detail, weiß schon vorher, wo alles hin muss und wie es laufen wird. Testet im Geiste alles zig mal durch und schon sind wir bei so rocksoliden Entwicklungsprozessen wie der der NASA. Deren Softwareentwicklung muss so gestrickt sein. Man kann ja nicht eben mal zum Mars fliegen und irgendwas am Marsrover austauschen, weil man bei der Konzeption etwas nicht bedacht hatte.

Agile Software Engineering

Aber eigentlich macht man doch heute dieses Agil, das ist doch der shit... da kann man die Produktivität vervierfachen, ohne dass man was tun muss. "Genau das machen wir ab jetzt..."

Und mit diesem Mindset geht man dann los und führt Agile Softwareentwicklung in der IT ein. Oder noch schlimmer, in der ganzen Firma.

Die Begeisterung für Scrum ist ja schön und gut. Aber es reicht leider nicht aus, sich für ein paar Wochen einen Coach in die Firma zu holen, ein Buch zu lesen und dann zu glauben, man kennt sich mit agilen Managementprozessen aus.

Das haut nicht hin. Und genau das habe ich jetzt schon mehrfach erlebt.

Scrum ist keine starre Vorgabe von Regeln oder Zwängen.

Scrum ist zunächst mal nur eine Menge von Methoden und Werkzeugen, die in der Praxis bei einigen Teams erfolgreich waren, d.h. deren Produktivität gesteigert haben.

Nur sollte man sich bei deren Geschichten auch mal ansehen, von wo aus die gestartet sind. Da ist eine Vervierfachung der Produktivität nicht unbedingt eine Herausforderung emoji people:smirk

Heutzutage arbeitet man in vielen Bereichen (wo sinnvoll) schon agil, ganz oft sogar, ohne es zu wissen. Für z.B. Supportabteilungen werden gerne Methoden aus der agilen Welt des Kanban herangezogen, weil das hilft, die eingehenden Anfragen bzw. deren Abarbeitung besser zu struturieren. Nur oft nennt man es weder agil noch Kanban, obwohl der gesamte Prozess in einem Support mehr oder minder agil sein muss

Also, wenn man da etwas verbessern will, sollte man sich genau ansehen, was das eigentliche Problem ist.

Das heißt auch nicht, dass das eigene Team alles davon umsetzen muss, was in den Scrum Guides und so beschrieben wird. Ich sehe es eigentlich so, dass man sich aus dem Scrum-Baukasten das raussucht, was für das eigene Team und die eigene Firma / Kultur gut funktioniert.

Das werden einige der Scrum-Nazis (so nenne ich gerne diejenigen, die Scrum buchstäblich und strikt machen) mich jetzt steinigen. Aber es ist so... Das passiert sogar bei den Erfindern. Ich habe meine PO-Zertifizierung bei Jeff Sutherland durchgeführt, nach eigenen Worten der Erfinder von Scrum.

Und in einer meiner letzten Firmen war ein Berater, der auch bei Jeff Sutherland gelernt hatte um Scrum einzuführen. Und dennoch hat er andere Werkzeuge benutzt und empfohlen, als dies Jeff getan hat. Das waren teilweise sogar widersprüchliche Aussagen (bezogen sich eben auf den konkreten Fall, unser Team in unserer Situation).

Und das ist gut so! Der Berater vor Ort kann viel besser entscheiden, was für das Team dort das richtige ist und eine entsprechende Empfehlung aussprechen. Jeff kann in solch einem Training ja nur allgemein reden und nur sehr oberflächlich auf Fragen eingehen.

Das zeigt aber, dass Scrum eben nicht immer überall gleich ist. Nichts ist in Stein gemeißelt. Pass es dir an, an dein Team, die aktuellen Umstände, die Firmenkultur. Wichtig ist, man sollte immer nur das nutzen von einer Methode, Vorgehensweise etc. bei der man sich auch wohl fühlt, die auch vom Team angenommen wird.

Was das passende ist, kommt auf unheimlich viele Faktoren an, die wichtigsten allerdings in wie weit das Management dem Team vertraut und extrem wichtig: auch umgekehrt!

Wenn das Management kein Vertrauen vom Team genießt, wird es nicht funktionieren (dann wird gar nichts funktioniere, aber Scrum insbesondere nicht).

Scrum und die Unternehmens / Teamkultur

Das Thema Vertrauen ist ein ganz wichtiges! Entgegen der früheren Methodiken wird bei Scrum die "Verantwortung" bei der Softwareentwicklung "umgedreht". D.h. es gibt kein Projektmanager mehr vor, was man wann wie zu implementieren hat, sondern es läuft umgekehrt. Das Team entscheidet, was es im nächsten Sprint machen will und wird auch daran gemessen.

Wenn allerdings die Chefetage kein Vertrauen darin hat, dass das in die richtige Richtung laufen wird, wird das zu Konflikten kommen. Und nach meiner Erfahrung endet das in einen "quasi"-Wasserfall.

Das team darf zwar vordergründig entscheiden, aber wenn die Entscheidung sich nicht mit der Der Geschäftsleitung deckt, wird so lange rumdiskutiert, bis sie das tut.

Beispiel:

im Refinement ist der CEO zugegen (eigentlich schon falsch, da sein PO das übernehmen sollte), das Team hat eine Userstory in Bearbeitung, sagen wir eine Architektonische Entscheidung ist teil der Story. Man kann sich zwischen A, B und C entscheiden. Das team entscheidet sich für A.

Der CEO kommentiert diese Entscheidung mit etwas wie "hmmm.... ja, schon gut, aber vielleicht überlegen wir noch mal weiter"

Das Team empfindet B als noch gangbaren Weg, aber C auf keinen Fall. C ist aber der Favorisierte Weg des CEO.

Was dann passiert ist, dass der CEO immer wieder sowas sagt wie "Ja, cool, aber wie wäre es wenn wir weiter überlegen"

Wenn dann irgendwer sagt "dann bleibt ja nur C übrig" springt der CEO drauf an und sagt "cool, wir machen C"

und wenn es später knallt kommt "Aber ihr wolltet doch C machen".

Klingt an den Haaren herbei gezogen? Nein, das ist so ähnlich schon passiert und ich war dabei! Klar, ist das hier überspitzt, aber im Grunde lief es genau so ab.

Wo kommt so was her? Fehlendes Vertrauen, kein Loslassen! Und zu schwache Scrum Master! Damit ist nicht die Person gemeint, sondern die Rolle im Team bzw. der Firma. Der Scrum Master durfte halt nicht das, was ein Scrum master eigentlich so machen sollte, was ihn in seiner Rolle geschwächt hat.

Das war in meinem Fall dann auch noch gepaart mit einer sehr komischen Fehlerkultur. Fehler wurden immer wieder durchgekaut und aufs Tablett gebracht, als Beispiele um Entscheidungen zu beeinflussen. Aber es wurde sehr häufig erwähnt, dass wir doch eine ach so tolle Fehlerkultur hätten und alles doch vergeben und vergessen wird - "Aber...."

Das führt dann dazu, dass das Team auch gar keine Lust mehr hat, irgendwas zu entscheiden. Die Entscheidung wird einem abgenommen - fein. Schuld ist man am Ende so oder so...

Und damit funktioniert agilität so gut wie gar nicht mehr. Damit hat man zwar von Außen das etikett "wir sind agil" aber innen drin ist es eigentlich ein Unding aus Wasserfall und... ja, was eigentlich? Monarichie?

Bei Scrum geht es um Transparenz

Viele Dinge, die man in Scrum (oder allgemeinen agilen Methoden) tut, versuchen in alle möglichen Richtungen Transparenz zu schaffen. Das soll heißen, man versucht Fehler schnell und klar sichtbar zu machen. Defizite aufzuzeigen, Verbesserungspotentiale zu erkennen. Das oben genannte Beispiel war klar, wurde oft genug in der Retro angesprochen. Aber der Scrum Master kam nicht gegen die Geschäftsleitung an, weshalb sich auch nichts geändert hat und irgendwann hat man es "akzeptiert" - in der Retro kam es nicht mehr vor.

Aber natürlich will man auch die normale Arbeit durch Transparenz und klare Kommunikationsstukturen zu verbessern. Wenn jeder weiß, wohin die Reise geht, tut er sich deutlich leichter.

Und genau da ist die Crux: viele Führungskräfte fühlen sich nicht wohl bei dem Gedanken, das Steuer loszulassen, das Team mal machen zu lassen. Das führt schnell zu Konflikten und dazu, dass das Team dem Management nicht mehr vertraut.

Auch ist Scrum und diese Transparenz nicht für jeden im engineering team das richtige. Denn wenn das Team Verantwortung übernimmt, muss es dafür auch einstehen. Und das will nicht jeder. Da ist das gute Wasserfallmodell "schöner". Dort hat man auch keine Entwickler im Einsatz, sondern Programmierer emoji people:smirk - da wird einfach nur runtergeschrieben, was im Konzept steht (im schlimmsten Fall). Ich weiß, das ist übertrieben dargestellt. Einige kommen mit der Arbeit nach Feinkonzepten einfach besser klar und das ist auch ok so.

"Helden"

Gerade in der Softwareentwicklung gibt es gerne "Leads", die zwar mit ihrem Team nach außen hin agil arbeiten (d.h. sie sitzen in allen Scrum Meetings, haben irgendwo ne WBC hängen), aber agieren nicht nach Scrum. Denn diese erfahrensten Mitarbeiter machen alles und geben wenig ab, sie sind die "Helden" die alles allein schaffen. Das führt dann zu "HiWi-Teams mit einem Head". Das frustriert die alle, da sich keiner weiterentwickeln kann und das Team nur so schnell sein kann, wie dieser Lead - Skalierung Fehlanzeige!

Auch für den Lead ist das eigentlich gar keine so tolle Situation. Da er mehr oder minder alles allein machen muss, häufen sich bei ihm die Überstunden, während die anderen in der Nase bohren. Dennoch kommt man aus diesem "Heldentum" nur schwer wieder raus, da es sich gut anfühlt, der "Held" zu sein. Denn "Ich habe Feature XY implementiert" - "ich hab den Bug bla behoben" - "Dank mir läuft wieder alles"...

Scrum sollte so was eigentlich aufzueigen, aber in solchen Situationen wird eben die Flexibilität von Scrum zum Problem: die Dinge, die dieses Ungleichgewicht aufzeigen würden (wie z.B. strukturierte Scrum Boards in denen erkannt wird, wer was tut, Tandeming etc) werden nicht eingesetzt.

Agile Vorgehensweisen helfen aber auch in so einem Fall, zumindest sollte es transparent werden. Aber dafür muss eben alles zusammenpassen....

Scrum im Rest der Firma

Agilität funktioniert sehr gut innerhalb der IT-Teams selbst, das ist eigentlich etwas, was jedem Softwareentwickler entgegen kommt, da er - wenn er ein eigenes Projekt aufsetzt - ganz genauso arbeiten würde. Man würde immer wieder Tasks abarbeiten, schauen, wie funktioniert es und sich nach und nach an eine optimale Lösung herantasten. Aber wie funktioniert die Schnittstelle zu anderen Teams?

Und das ist das Problem. Ich habe es erlebt, dass die Schnittstelle sehr gut funktioniert, obwohl der gesamte Rest der Firma nicht agil ausgerichtet ist. Das war z.B. bei einem Consultingunternehmen der Fall. Dort war es notwendig, für die Angebote und Ausschreibungen Konzepte zu liefern, die dann verfeinert wurden. Aber die Implementierung lief dann agil.

Das hat erstaunlich gut funktioniert, obwohl ein methodischer Bruch vorlag.

Natürlich geht das nicht immer so. Wenn das Management Reports nach Wasserfall erwartet, das Team aber agil arbeitet, ist es schwer das zusammenzubringen.

Das habe ich bei einer Firma erlebt, die versucht hat testweise mal ein Projekt agil durchzuführen. Mit dem Effekt, dass es überhaupt nicht funktioniert hat. Die Kommunikation lief völlig daneben, die Erwartungshaltungen waren komplett unterschiedlich und am Schluss gab es nur noch eine Menge von Lessons-Learned-Meetings und der Versuch den Gang vor Gericht zu vermeiden.

Schlimm ist es auch, wenn das Management versucht Scrum zu sein, selbst aber keine Ahnung davon hat. Das ist wirklich das schlimmste, was passieren kann.

Das Management vergewaltigt dann sehr häufig bestimmte Scrum-Zeremonien um z.B. ein Report-Meeting zu bekommen, obwohl eigentlich ein Scum-of-Scrums angesetzt war. (erkennt man meistens daran, dass weder die Zeiten eingehalten werden, noch das erwartete Ergebnis entsteht und man einen Status über alle Projekte abgeben muss).

Sowas kann nur dann funktionieren, wenn das Management Scrum wirklich verinnerlicht hat und schon viel Erfahrung damit hat und/oder der Scrummaster ein sehr erfahrener ist, mit einem Rückgrat aus Stahl und einem unerschütterlichen Selbstbewusstsein. Es schadet auch nicht, geduldig zu sein....

Das ganze endet nämlich in vielen Konflikten: der CEO der Scrum so zu 50% verstanden hat und immerhin schon 3 Monate Erfahrung sammeln konnte (weil in seiner Firma eines der Teams Scrum macht), und dem Scrum Master, der seine Felle davon schwimmen sieht, weil seine ganze Meetingstruktur kaputt geht da die Zeremonien leider misbraucht werden und er also gegen den CEO bestehen muss.

Das ist tough und ich kenne bisher keine Firma in der das auch nur Ansatzweise funktioniert. Mal abgesehen davon, dass es nicht wirklich Sinn macht.

Agile Methoden sind fein, insbesondere im Bereich der Softwareentwicklung oder wenn man eben etwas "erschaffen" will, von dem man bei Beginn noch nicht genau weiß, was es sein wird.

Ähm... wenn mein Management in der Firma so an das ganze herangeht, bekomme ich ein wenig angst. Sie wissen noch gar nicht wo es hingeht und wollen sich herantasten?

gruselige Vorstellung. Und genau deswegen sollte man sich als Fürhrungskraft auch mal mit dem Thema Agile Management beschäftigen. Das ist nämlich nicht Scrum sondern eine Sammlung von Werkzeugen, die einem Helfen in einer Agilen Welt auch im Mangement zu bestehen.

Links:

http://billschofield.net/The-Insufficiency-of-Scrum/

https://www.linkedin.com/pulse/scrum-makes-you-dumb-daniel-jones?trk=v-feed&lipi=urn%3Ali%3Apage%3Ad_flagship3_feed%3BhpLGl29RKJkQ2jmK4ZbMIg%3D%3D

erstellt Stephan Bösebeck (stephan)