Agil wollen wir irgendwie alle sein – zumindest der Wortbedeutung nach.
Wir verbinden mit Agilität so erhabene Tiere wie den Gepard, der sich schnell und wendig bewegt und so sein Überleben sichert. Wir wollen nicht auf der Stelle treten. Denn wir wissen ja: Stillstand bedeutet Tod.
Deshalb klang „agil werden“ für alle Beteiligten auch nach einem guten Plan: etwas verändern, besser werden.
Aber ausgerechnet Scrum?
Traum oder Albtraum: endlich mehr Kontrolle oder gefangen in einem Rollenkonflikt?
Du bist ein Projektleiter.
Als du von Scrum hörtest, fragst du dich zunächst, ob du nun überflüssig bist. Du hast nämlich gehört, dass es in Scrum keinen Projektleiter gibt. Du siehst in Scrum also eine direkte Gefahr für deinen Arbeitsplatz.
Vielleicht gehörst du aber auch zu den Leuten, die Scrum haben wollten und sich davon Vorteile versprachen.
Du erinnerst dich, wie schlecht es bisher für dich lief. Schließlich schien es wie pures Glück, ob irgendein Plan mal jemals der Realität standhielt. Alle tanzten immer aus der Reihe: der Kunde, die Lieferanten und sogar deine Mitarbeiter. Mit den Jahren und wachsender Erfahrung wuchs auch deine Resignation. Du hast irgendwann festgestellt, dass du eigentlich nie so über den Projektfortschritt informiert bist wie nötig. Wie solltest du du da deiner Aufgabe gerecht werden? Du wolltest ja schon immer die Verantwortung in die eigenen Hände nehmen, aber so wirkte es eher wie eine Bürde auf dich.
Vielleicht dachtest du, dass eine Methode wie Scrum dir endlich bringt, was du brauchst: regelmäßige Status-Updates durch die Entwickler, einen an die Realität angepassten Plan und rechtzeitige, schnelle Lieferungen.
Möglicherweise wurde dir die Rolle des Scrum Masters angeboten.
Vielleicht dachtest du, dass das genau dein Ding sei. Du sahst darin eine Chance, endlich zum Mitspieler im Team zu werden. Besser als der Außenseiter, als der du dir manchmal vorkamst, wenn du etwa auf die Einhaltung der Deadlines pochen musstest. Etwas, das dir selten Gegenliebe – aber häufig Spott in Form von XKCD-Comics einbrachte. Du freutest dich folglich, als dein Chef dich zu einer Schulung schickte und warst nach diesen drei Tagen total enthusiastisch, aber die Dinge entwickeln sich nicht wie erhofft.
Statt dem Team zu bessere Produktivität zu verhelfen – ohne ihnen den Spaß an der Arbeit zu vermiesen – findest du dich in einem Rollenkonflikt wieder. Aus Sicht deines Chefs hat sich eigentlich nichts an deinen Aufgaben geändert. Nach wie vor sieht er in dir den Wächter über das magische Dreieck, dessen Gleichschenklichkeit du bewahren sollst.
Zeit, Kosten und Umfang immer in perfekter Balance.
Obwohl du dich selbst nicht einfach als einen Projektleiter mit einem anderen tollen Namen sondern als Servant Leader mit einer gänzlich anderen Verantwortung siehst, wird genau das von dir erwartet – nur mit höherem Tempo.
Darum bist du hin und hergerissen: ist Scrum nun Traum oder Albtraum?
Vom Regen in den Überwachungsstaat: wie du als Entwickler sicher nicht arbeiten möchtest
Als Entwickler hast du die schlimmsten Horror Storys über Scrum gehört.
Von allen Dächern wurde gepfiffen, dass alles schlimmer als vorher wird. Im Internet konntest du lesen, dass mit Scrum der Druck für dich und deine Kollegen steigt – und schließlich lügt das Internet ja nicht, oder?
Als ob ihr nicht vorher immer schon dafür verantwortlich gemacht worden seid, dachtest du als man dir erklärte, dass ihr jetzt Scrum macht. Obwohl es ja eigentlich fast immer daran lag, dass die Zeitschätzungen den tatsächlichen Aufwand nicht wirklich widerspiegelten und ihr manchmal Abkürzungen nehmen musstet.
Für die falschen Aufwandsschätzungen sollt ihr auch verantwortlich sein. Dabei müsste jeder klar denkender Mensch verstehen, dass es gar nicht möglich ist, einen Aufwand akkurat zu schätzen. Euer Projektleiter hat trotzdem immer versucht, aus euren Schätzungen mit ein paar fixen Puffern einen Zeitplan abzuleiten – welch absurde Versprechungen auf dieser Basis den Kunden gemacht worden.
Aber wer fragt euch schon?
Mit Scrum müsst ihr plötzlich jeden Tag Rechenschaft ablegen und steht noch mehr unter Zeitdruck. Ihr hetzt förmlich von einem Sprint zum nächsten, immer mit dem Druck im Nacken, etwas Lauffähiges abliefern zu müssen. Noch viel mehr als früher seid ihr gezwungen, komplexe Bauwerke auf Sand zu bauen, denn für ausgeklügelte Architektur oder das Vermeiden von technischen Schulden ist bei so einem Vorgehen keine Zeit.
Von den vielen Meetings hattest du ja vorher schon gehört. Jeden Tag im Standup-Meeting, am Ende eines jeden Sprints ein ewig langes Review-Meeting und als ob das nicht genug wäre, ein ebenso langes Meeting direkt im Anschluss. Bei all diesen Meetings geht es im Grunde nur darum, Eure Ergebnisse infrage zu stellen, euer Vorgehen zu rechtfertigen und mögliche Fehler aufzudecken.
Dabei hieß es, der Projektleiter sei tot, nun gäbe es einen Scrum Master und dieser solle dem Team dienen. In Wirklichkeit ist der Scrum Master nur eine weitere Person, die auf euch rumhackt.
Wenn diese Orwellsche Vision von einem Unternehmen Scrum ist – dann möchtest du den Wasserfall zurück.
Projekte auf der Überholspur – oder große Zeitverschwendung?
Als Chef überzeugte dich vor allem das Argument mit der Schnelligkeit.
Bisher habt ihr ja immer ein bisschen zu spät geliefert und so dauerte es, bis ihr Geld verdienen konntet. Der externe Berater sagte, dass mit Scrum die „Time to Market“ drastisch sinkt – und du bekamst Dollarzeichen in den Augen. Folgerichtig hast du deinen Projektleiter zur ScrumMaster-Schulung entsandt – der ist schließlich in der richtigen Position, um die neuen Methoden umzusetzen.
Wahrscheinlich bist du auch gar nicht so kühl, dass du alles nur von der geschäftlichen Seite betrachtest.
Du hörtest, dass deine Entwickler mit Scrum gleichzeitig produktiver und glücklicher sein könnten. Dir schien das logisch – ständig verspätet und oft auch noch fehlerhaft zu liefern, das musste auch die Experten frustrieren. Und es klang schlüssig, dass zwischen guten Arbeitsbedingungen und der Produktivität ein Zusammenhang besteht. Also wolltest du das Experiment wagen.
Aber im Unternehmen etwas ändern?
Dazu sahst du keine Veranlassung. Schließlich ist Scrum doch eine Projektmanagementmethode und ansonsten eigentlich alles ganz in Ordnung, solange ihr noch im Geschäft seid. Sollte es nicht reichen, hier und da lokale Anpassungen vorzunehmen? Den Projektleiter zur Schulung schicken und mit einer neuen Aufgabe betrauen, ihn gleichzeitig als Scrum Master und Product Owner einsetzen: das muss doch funktionieren – falls die Methode wirklich etwas taugt.
Wenn nicht, kann man ja ohne Weiteres zu den bisherigen Ansätzen zurückkehren.
Manches, was man dir über Scrum erzählte, bereitete dir aber auch Sorgen: etwa die vielen Meetings. Eines dieser Meetings wurde dir sogar sein bisschen wie eine Bauchpinselrunde für die Entwickler beschrieben, eine Spaß-Veranstaltung mit dem nebulösen Ziel der kontinuierlichen Verbesserung, das regelmäßig viel Zeit frisst – und dann darfst du noch nicht mal daran teilnehmen!
Der externe Berater sagte, das Meeting sei wichtig und dürfe nicht weggelassen werden.
Am Anfang hast du die Zeit dafür zähneknirschend eingeräumt. Doch es sind raue Zeiten im Geschäft: so viel zu tun und so wenig Zeit eben. Du denkst, dass die Sicht des Beraters eben die Theorie ist und die Praxis ganz anders aussieht. Dein Projektleiter ist erleichtert, denn die Retrospektiven fressen Zeit und so ganz sieht er darin auch keinen Sinn. Auch die Entwickler sind alles in Allem ganz froh, denn eigentlich gibt es ja schon genug Meetings in denen sie rumhängen müssen.
Also lasst ihr die Retrospektiven erst seltener stattfinden, kürzt die zur Verfügung stehende Zeit drastisch ein und schafft das aus eurer Sicht völlig unproduktive Meeting ganz ab.
Mit der Zeit stellt ihr fest, dass Scrum offenbar nicht so recht hält, was es verspricht.
Zurück auf Anfang …
Ihr liefert nicht wirklich schneller und die Qualität hat sich auch nicht verbessert.
Noch dazu sind eure Mitarbeiter unglücklich – vielleicht sogar unglücklicher als zuvor. Einer eurer Entwickler ist nicht mal mehr da, um ihn zu befragen, ob seine Befürchtungen eingetreten sind – er sah nicht ein, wieso er sich mit seinen Fähigkeiten und seiner Erfahrung dermaßen unter Druck setzen lassen sollte und kündigte. Der Entwickler merkte schnell, dass die Anforderungen an ihn gestiegen waren, während sich an den Bedingungen rein gar nichts änderte.
„Alles bloß kein Scrum!“, sagt ihr einstimmig und stellt das Experiment ein.
Und nun?
Vielleicht kommt euch die ein oder andere der zuvor beschriebene Position bekannt vor.
Es handelt es sich um Übertreibungen von Aussagen, die man im Internet finden oder aus den Flurgesprächen und Erfahrungsberichten bei Konferenzen raushören kann. Manchmal ist der Tenor dabei, dass die Methode schuld sei. Nicht nur, wenn es um Scrum geht – die Kritik am Wasserfallmodell ist vielleicht das beste Beispiel.
Die Frage ist nur: bringt uns Methodenkritik auch weiter?
Natürlich ist es gerechtfertigt eine Methode zu kritisieren, wenn sie nicht hilft, was sie verspricht. Mit Sicherheit ist Scrum in vielen Fällen nicht die richtige Lösung für ein wie auch immer geartetes Problem und manchmal kann es auch nur nicht die alleinige Lösung sondern Teil einer Lösung sein, bei der Scrum von anderen Maßnahmen flankiert wird.
Aber sollten wir nicht auch die Herangehensweise kritisieren, mit einer Methode all unsere Probleme lösen zu wollen?
Wenn es im Unternehmen knirscht, wenn die Jobzufriedenheit der Mitarbeiter und die Stimmung im Unternehmen nah am Gefrierpunkt stagniert, wenn die Unternehmen nicht die gewünschten Ziele in der gewünschten Zeit erreichen, die Statistiken zur Auslastung und Produktivität unserer Mitarbeiter hinter den Erwartungen zurückbleiben und der Shareholder-Value sowieso … sollten wir uns dann nicht auch mit anderen Themen beschäftigen?
Stellen wir uns zum Beispiel auch die Frage, ob die Ziele, denen wir da hinterherhecheln auch die Richtigen sind? Und ob das auch jeder im Unternehmen so sieht?
Ob die Mitarbeiter im Unternehmen alles haben, was sie für ihre Arbeit brauchen? Ob es ihnen gut geht, sie einen Sinn in ihrer Tätigkeit sehen und nicht das Gefühl haben mit kaum zu bewältigenden Anforderungen jonglieren zu müssen, während „die da oben“ immer größere Ziele ausrufen? Gibt es Probleme, zu deren Lösung wir beitragen könnten oder erwarten wir von manchen Problemen sogar, am Werkstor abgegeben zu werden?
Fragen wir uns auch schon mal, ob wir wirklich jeden Auftrag annehmen müssen und ob die Art, wie die Zusammenarbeit zwischen Vertrieb und dem restlichen Unternehmen gestaltet ist – für welche Ziele wir Anreize setzen – auch Sinn macht? Ob unsere Leute zu viel Zeit in Meetings verbringen und die Meetings eventuell ineffektiv sind?
Und ob unsere heiligen Statistiken und Kennzahlen wie der Shareholder-Value vielleicht ein total lächerlicher Indikator für Erfolg sind oder zumindest als Gängelung wahrgenommen werden können? Tragen sie wirklich zur Entwicklung der Leute im Unternehmen bei?
Und last but not least: lassen wir die Leute, die die Arbeit machen auch bei der Wahl der Mittel mitentscheiden oder drücken wir ihnen vermeintliche „Best Practices“ auf?
Kann man schon so machen …
Natürlich kann man sich auch einfach nur mit Methoden beschäftigen, sie von oben verordnen und eine nach der anderen ausprobieren. Aber wenn man sich nicht gleichzeitig auch mit diesen Fragen auseinander setzt und einem trotzdem nichts weiter außer „Alles bloß kein Scrum“ einfällt – tja, dann gibt es da eigentlich nicht mehr viel zu sagen.
Nur so viel: Kann man schon so machen, …
FACK! Die Führungskräfte etablieren SCRUM nicht, damit die Mitarbeiter zufriedener sind. Im Zentrum steht Kontrolle (Daily-Standups) und die Verminderung von Abhängigkeiten zu einzelnen Entwicklern. Denn im Scrum-Team übernimmt das Team Verantwortung über fast alles. Der Scrum-Master gleicht eher einen Erfüllungsgehilfen der Führungsriege, wobei die Retrospektive einer Team-Beichte entspricht. Bislang habe ich Scrum ausschließlich in dieser negativen Variante erlebt. Bei Scrum wird Empowerment des Teams als positive Eigenschaft verkauft. Meine Erfahrung ist, dass Probleme nun einfach ins Backlog entsorgt werden.
Passende Seite :
http://programming-motherfucker.com/