Scrum-Projekte stellen hohe Anforderungen an die Projektmitglieder. Neben der eigentlichen Kernarbeit kommt noch die Aufgabe der Selbstorganisation dazu. Dies kann leicht zu einer Überforderung oder mindestens hohen Anhäufung an Überstunden führen.
Im Ursprungsartikel zu Scrum (The New New Product Development Game) wird explizit auf dieses Risiko hingewiesen. In den untersuchten Projekten haben Mitarbeiter in Hochphasen bis zu 100 Überstunden im Monat angesammelt und in normalen Phasen 60 Überstunden. Hier ging es nicht um Scrum in der Softwareentwicklung, sondern um Produktentwicklung. Aber ebenso wie Scrum-Techniken übertragen wurden, kommen auch die Risiken mit.
Für mich ist dies ein wichtiger Punkt. Es ist kein Gegenargument zu Scrum, sondern ein Aspekt, der bei der Einführung und Durchführung von Scrum-Projekten explizit adressiert werden muss.
Hallo Tim,
ist in der Studie belegt, dass die Überstunden wegen Scrum erfolgt sind? Das würde mich wundern. Generell kommt es in Software Projekten vor dem Liefertermin zu Überstunden. Habe ich gerade erst wieder erlebt. Dieses Projekt wurde nicht nach Scrum geführt. Durch Scrum Techniken hätten sich einige Überraschungen der letzten Wochen sicher frühzeitig vermeiden lassen.
Ich sehe eher die Herausforderung darin, in Unternehmen, die gute Arbeit an der Anzahl der Überstunden fest machen, Scrum einzuführen.
Hallo Guido, die Autoren des Artikels schränken ein, dass die Projekte, die sie untersucht haben, in Japan stattfanden. Der Kulturkreis hat sicherlich Auswirkungen auf die Ergebnisse. Und es geht nicht um Software, sondern um Geräteentwicklung.
Mich beschäftigt, dass Ken Schwaber & Co. die Scrum-Idee aus dem Artikel übernommen haben, aber ich nichts darüber finde, wie sie mit den entdeckten Risiken der Originalautoren umgegangen sind.
Meiner Erfahrung mit Scrum ist (leider?), dass das Entwickler-Team oft sehr gut vor Überstunden geschützt wird. Es wird im Planning nur zugesagt, was (fast) sicher erreicht werden kann – und zwar in den 40 Stunden – oft mit dem Verweis auf „Sustainable Pace“. Dies führt – gerade in kritischen Projektsituationen und in der Planung-/Organisationsphase – dazu, dass andere Organisationsteile (außerhalb des Dev-Temas) mit einem Mehr an Arbeit konfrontiert werden. Dort laufen dann die Überstunden an. Zu nennen ist hier besonders der ProductOwner und die Projektleiter (bei Multi-Project-Scrum). Dies erodiert letztendlich die gesamte Organisation und deren Handlungsfähigkeit. Das Dev-Team hat sich lokal optimiert, der Rest verzweifelt an dem Prozess. Zwar kann mir keiner erläutern, wie dies mit den Scrum Values zusammen passt (-> Courage/Mut sowie Committment/Selbstverpflichtung) – aber ich erlebe es immer wieder.
Da hat die Organisation dann wohl ein Impediment: Das Projekt-Team ist unterbesetzt.
Zu Felix:
Die Menschheit hat Jahrhunderte darum gerungen (und tut es noch) wer die Bibel (o.Ä.) wie interpretieren darf.
Dieses ewige Ringen in Projekten um die Methodenhoheit kommt mir schon irgendwie ähnlich vor – unabhängig übrigens von der Methodik.
ps
Wenn man statt 40 nun 41 Stunden arbeitet, ist es dann eigentlich noch Scrum?
Hallo Felix,
was passiert denn, wenn die Projektmitarbeiter außerhalb des Scrum-Teams sich auch an die 40h halten? Ist dann nicht das Maß gefunden, was das Projektteam insgesamt leisten kann? Irgendwo liegt ja definitiv die Grenze.
Tim
Keiner macht gerne Überstunden und ein Abteilungsleiter hat auch eine Fürsorgepflicht (wird gerne vergessen). Bei vielen Scrum-Implementierungen werden aber Entwickler zu SMs gemacht und diese haben ein sehr Dev-Team-zentrisches Weltbild in dem eine attraktive Entwicklerwelt geschützt/errichtet werden muss. Manchmal geht die Ignoranz leider so weit, dass man erklären muss, dass eine „Messeversion“ nicht NACH der Messe fertig werden sollte und ggfs. viele Projekte ihren Ursprung haben in einem Messeauftritt. Im Lauf der Diskussionen kommt man dann auf Lebenszyklen von Märkten und Produkten zu sprechen und oft wird auch eine unterschiedliche Qualitätsdefinition klar.
Beispiel: Technische Schuld KANN ein Problem sein – MUSS es aber nicht. Das Problem ist meist, dies im Vorfeld belastbar bewerten zu können.
Es ist interessant, dass ich ganz ähnliche Beobachtungen wie Felix mache. Durch Scrum wird das Entwicklungsteam stark abgeschottet und geschützt, da der Sprint geschützt ist. Die errechnete Kapazität und die selbst geschätzten Aufwände werden miteinander verrechnet und ergeben den Umfang dessen, was geschafft werden kann. Ales völlig nach Regelwerk. Der Kundendruck dringt kaum noch oder gar nicht mehr durch, sondern wird von der Peripherie, z.B. von einem Proxy-PO aufgefangen. Damit geht die Kopplung an den Kunden teilweise oder ganz verloren. Alles ist rechnerich und mechanisch völlig korrekt – leider fehlt der Geist, die Leidenschaft, … Scrum wird von der Triebfeder zum Schutzschild. Die Messe-Version wird nach der Messe fertig. Der Proxy-PO wird zwischen Team und Kunde langsam zermahlen. Wo bleibt da die Hyperproduktivität? Und auf welche Weise lässt sich – ganz gemäß Regelemant – der Kundendruck ins Team tragen?
Hallo zusammen,
wir haben vor ca. 6 Monaten bei uns für die Produktentwicklung unserer Standardsoftware agile Methoden auf Basis von Scrum eingeführt. Haben also scrum so angepasst wir wir denken, dass es uns am meisten bringt. Und tunen diese Modell auch immer weiter.
Ich selbst bin bei uns der Product Owner. Persönlich kann ich nicht feststellen, dass die Mitarbeiter mehr Überstunden machen – schon garnicht aufgrund der agilen Methode.
Wir / ich haben anfangs viel Zeit investiert diese neue Methode / Phylosophie zu vermitteln und den Gedanken in unser Team zu tragen – und tun dies heute noch.
Gerade die Einheiten zur Spezifikation sowie zur Retrospektive sind aus meiner Sicht ideal geeignet um Erwartungshaltungen klar zu platzieren bzw. Dinge, die nicht optimal gelaufen sind anzusprechen. Evtl. versteht ein Team unter Messeversion nicht das gleiche wie der PO. Kommunkation ist das was ankommt. Es gilt immer wieder zu hinterfragen und zu verifizieren. Das klappt face-to-face natürlich am besten. Bei uns beginnt jede Iteration mit einer 2tägigen Specs-Phase, an der das Team, der scrummaster und der PO teilnehmen. Oberstes Ziel ist Klarheit für beide Seiten zu schaffen. Zu einem inhaltlich. Zum anderen aber auch über die Zielsetzung der kommenden Iteration.
Oft bemerke ich, dass mein Entwicklerteam Dinge ganz anders versteht und interpretiert und viel Diskussion notwendig ist um auf einen Punkt zu kommen. Umgekehrt ist es nicht anders :-).
@Felix: evtl. ist bei euch eine klare Aussprache notwendig?! Nehmt den scrummaster dazu. Er hat die Aufgabe das Team dahin zu bringen optimal zu agieren. Dies bedeutet auf der einen Seite Schutz, aber auch das Einfordern von Leistung und klaren Commitments.
Vielleicht habt ihr auch schon Klartext gesprochen?! Stellt euch die Frage ob das Team eure Vision, etc. richtig verstanden hat und fähig ist diese zu leben?
Oft sehen die Leute nur die neu gewonnen Freiheit, nicht aber die Verpflichtung. Auch hier sin klare und offene Gespräche wichtig um die Grunde herauszuarbeiten und Maßnahmen / Konsequenzen ableiten zu können.
Ich hoffe ich konnte ein paar Anregungen geben.
Man kann im Grunde sagen, dass Scrum bei euch funktioniert, @felix, und ein Problem aufzeigt, diese aber nicht erkannt und nicht behoben wird. Wenn Überstunden in der Regel anfallen müssen, um ein Projektziel zu erreichen, dann sieht man ganz klar zwei Probleme, an denen nicht geschraubt wird. Und dieses Problem lässt sich auf einen Nenner bringen: Die Kapazität des DEV-Teams reicht nicht für die Projekterfüllung im gesetzten Umfang aus. Zwei Auswege, wenn man dieses Problem erkennt, wären entweder den Projektumfang zu reduzieren oder aber das Team (langsam) zu vergrößern.
Es kann ja nicht Sinn und Zweck sein den Motor immer im oberen Drehzahlbereich zu Fahren. Irgendwann wird das Teil kaputt gehen. Und verstärkend kommt hinzu, dass Menschen keine Maschinen sind. Erholung ist wichtig. Nicht nur für die Motivation sondern auch für die Produktivität. Diese Erkenntnisse aus der Organisationspsychologie werden leider zu gerne missachtet.
Das Team soll durchaus mit Scrum seine Kapazität steigern aber irgendwann setzt eine Sättigung ein, da man nicht ins Unendliche eine Verbesserung erreichen kann. Vielleicht ist bei euch diese Kapazität schon erreicht und es muss an anderen Schrauben gedreht werden: Team aufteilen und mit neuen Mitarbeitern zwei Scrum-Teams bilden.
Überstunden (und hier meine ich nicht 1h mehr, die ab und an anfällt) sind ein Zeichen dafür, dass Umfang und Kapazität nicht richtig geplant wurden. Egal ob bei Entwicklern oder in anderen Abteilungen.
@Thomas: Ich kann Dir was die Überstunden angeht nur absolut zustimmen.
Du sagst aber auch, dass Scrum funktioniert. Vielleicht ist dies Ansichtssache. Ich behaupte einfach mal, dass es nicht im eigentlichen Sinne funktioniert, da die zur Verfügung stehenden Tools anscheinend nicht greifen. Weder die Spezifikationsphase noch die Retro scheinen zu offenbaren, was die Ursachen für die festgestellten „Mängel“ sind. Und demnach werden daraus auch keine geeigneten Maßnahmen – wie von Dir vorgeschlagen abgeleitet.
Deswegen mein Gedanke auch an der Kommunikation zu arbeiten und dadurch Klarheit für alle Beteiligten zu schaffen und ein gemeinsames Commitment herzustellen. Auch um den Prozess an sich mit Leben zu füllen und gemeinsam an einem Strang zu ziehen.
Was meinst Du?
@Jan-Erik:
Aufgabe von Scrum ist es ja im Grunde nur, Probleme relativ zeitnah aufzuzeigen. Was mit dieser Erkenntnis gemacht wird, liegt in den Händen der Beteiligten. Die Grenzen, die hier durch das Unternehmen gesetzt sind, liegen doch eher darin, dass Scrum nicht richtig im Unternehmen implementiert wurde. Denn eine nach Scrum arbeitende IT bedeutet noch lange kein Scrum im Unternehmen und damit kann man das ganze dann doch wieder unter dem bekannten „Scrum, but…“ einreihen.
Wenn aus den festgestellten Mängeln keine Konsequenzen gezogen werden und der Scrum-Master mit dem PO auf taube Ohren stößt, offenbart sich ein weiteres übergeordnetes Problem. Daher: Scrum _wirklich_ zu Implementieren ist eine schwere Arbeit und geht nicht, wenn auch in den „oberen Etagen“ nicht ein Umdenken stattfindet.
Mehr, als diese Probleme auf Zeigen kann Scrum nicht. Und mehr, als diese Probleme offen anzusprechen und diese hard-Impediments nach oben zu kommunizieren kann der Scrum-Master auch nicht. Leider.
Leider wird das von dir beschriebene „Am gleichen Strang Ziehen“ oft so interpretiert, dass die IT bzw. die Entwickler durch Überstunden alles ausbaden sollen, ohne, dass ich etwas im Unternehmen grundlegend ändern wurde. Und da kann man auch mit Kommunikation oft nichts erreichen, weil eine Veränderung nicht gewünscht ist. Hier scheitert Scrum irgendwann.
Wie siehst du das?
@rdraether: Ja es stimmt. Oft werden aus Entwicklern SMs. Das ist an sich nichts schlimmes. Schlimm dabei ist eigentlich nur, dass der neue SM bei den Entwicklern und auch im Management weiterhin als „Entwickler“ gesehen wird. Das Management ist dann der Meinung er sei nicht ehrlich, weil er ja ein Entwickler ist und daher versucht seine Kollegen zu schützen. Die Entwickler verstehen nicht, dass der SM kein Entwickler mehr ist und torpedieren unbewusst seine Arbeit, weil sie meinen, dass er es als Entwickler ja besser wissen müsste.
Ein neu eingestellter SM wird vom Management gleich als solcher wahrgenommen und auch die Entwickler haben gleich eine gewisse Distanz. Das wirkt sich meiner Meinung nach durchaus positiv aus auf den Umgang miteinander – hat aber natürlich auch den Nachteil der längeren Einarbeitung.
Und es ist falsch von Scrum eine Hyperaktivität zu erwarten. Diese kommt erst recht spät, wenn man wirklich alle Probleme die zu Tage getreten sind, beseitigt. Scrum heißt nicht nur, dass das Dev-Team sich verändert sonder auch das Management. Letzteres ist ein langer Prozess.
@Thomas: Du hast vollkommen Recht. Scrum dient dazu schnell Probleme aufzudecken. Sehe ich vollkommen genauso.
Und danach gibt es genug Tools, sich dieser Probleme anzunehmen und sie aus der Welt zu schaffen.
Felix sprach ja davon, dass das Entwickler-Team geschützt wird. Es wurde auch gesagt abgeschottet werden kann. Oder das Entwickler, welche die Rolle des ScrumMaster einnehmen, nur einen Blick für die Entwickler haben und versuchen diesen ein Paradies zu bauen.
Und aus meiner Sicht setzt hier genau das Thema mangelnde Kommunikation an. Es ist ja so, dass auf allen Ebenen ein Umdenken statt finden muss. Nicht nur bei den Entwicklern. Auch beim ProductOwner und dem Management.
Ich erinnere mich gut an die Zeit, als wir mit der agilen Arbeitsweise angefangen haben. Es war und ist nach wie vor sehr, sehr intensive Kommunikation notwendig.
Jeder muss das eingesetzte agile Modell verstehen und auch dazu stehen. Ich muss mir überlegen, welche Mitarbeiter sind auch bereit für diese Arbeitsweise.
Wir haben darüber gesprochen, was sind die Ziele, welche Vorteile sehen wir. Aber auch welche Verpflichtungen gibt es und was wollen wir für jeden Einzelnen und die Organisation erreichen.
Für die Entwickler heißt es mehr Sicherheit in der Planung. Sie analysieren selber und geben ein verbindliches Commitment zum Arbeitsergebnis am Ende einer Iteration ab. Früher wurde Ihnen evtl. gesagt, mache dies bis dahin – ohne, dass sie es selbst bewerten konnte. Und am Ende stellte man fest, dass die Zeit viel zu kurz war und es wurde dann schlecht implemtiert – die Aufwände in der QA stiegen.
Ich als PO habe eine sehr hohe Planungsicherheit – behalte jedoch 100% Flexibilität, weil ich mit den Tasks spielen kann und im Stande bin auch kurzfristig Änderungen einfließen zu lassen.
Ich habe bereits ganz am Anfang die Möglichkeit entscheidend einzugreifen und auch auf die Aufwände einzuwirken. Ich entscheide am Ende des Tages wie ausgeprägt eine Funktion gebaut werden soll. Nehme ich eine einfach Variante, die meine Anforderungen abdeckt oder will ich allerlei technische Finessen haben?
Und bei den bisherigen Erzählen hier um Forum hatte ich das Gefühl, dass da wenig Klarheit herrscht. Es wird gejammert – über die anderen und wie schlecht die Welt ist – anstatt die Themen anzugehen.
Es muss zu jeder Zeit kritisch hinterfragt werden ob es die richtige Arbeitsweise ist, ob es die richtigen Leute sind.
Nicht in jeder Konstellation ist ein agiles Team erfolgreich. Es hängt sehr, sehr stark von den Leuten ab.
Und Dinge müssen jederzeit offen und ehrlich angesprochen werden. Probleme müssen konkret angegangen und beseitig werden. Hier gibt es z. B. ja gerade in der Retro wirklich viele Tools / Games um zu Lösungen zu kommen.
Da würde ich in diesem Fall einfach ansetzen. Alle an einen Tisch, kritisch hinterfragen, Konsequenzen ableiten und durchführen…
Hallo.
Wenn ein Scrum Team überfordert ist, ist das ein Indiz für den Scrum Master, dass das Team noch Nachholbedarf im Schätzen und Planen der Spronts hat.
VG
Alex.
Sorry….“Sprints“ :)