Kategorien
Scrum löst eure Probleme nicht.
Starke Worte für einen der größten Verfechter der agilen Herangehensweise. Scrum löst die meisten Probleme die ein Unternehmen hat nicht, aber es zeigt sie auf. Nehmen wir das klassische Beispiel der Priorisierung. In den meisten Software-Unternehmen werden Task-Tracking-Tools eingesetzt, betrachtet man dort die Art nach der Priorisiert wird, so existiert dort meist eine Handvoll Einstufungsmöglichkeiten. Blocker, sehr wichtig, wichtig, muss irgendwann mal gemacht werden usw.. Was passiert in solchen Unternehmen mit der Priorität? Natürlich ist alles erst mal sehr wichtig. Es könnte ja das nächste große Ding dabei sein und wenn wir das nicht alles sofort umsetzen, haben wir ein Problem. Wenn aber alles eine sehr hohe Einstufung bekommt, dann haben wir im Endeffekt gar keine Bewertung vorgenommen. Was ist denn jetzt wichtiger? Feature A oder Feature B? Meist weiß es der Produktverantwortliche selbst nicht. Dieses Vorgehen ist nicht optimal, aber verstößt auch gegen keine Regel des Wasserfallmodels oder anderen veralteten Standards.
Bei Scrum ist es anders. Es wird vom Product Owner verlangt alle Features in eine Reihenfolge zu setzen. Es ist eine einfache Liste mit Wünschen und wie bei allen Listen gibt es keine Einträge, die auf derselben Position verharren. Das Team, welches das Projekt technisch betreut weiß also immer genau, was als nächstes ansteht und was zum jetzigen Zeitpunkt das Potential hat bald umgesetzt zu werden.
Wo war aber das eigentliche Problem? Im ersten Beispiel war es der Produktverantwortliche, der sich nicht entscheiden konnte, was denn momentan das wichtigste ist und wie die verschiedenen Features untereinander gewichtet werden sollen. Hilft uns Scrum dabei dieses Problem zu lösen? Ein klares Nein. Das gute an Scrum ist aber, dass es uns als Rahmenwerk dazu zwingt unser Projekt besser zu verstehen. Es zwingt uns eine klare Reihenfolge zu definieren. Der Product Owner muss sich hinsetzen und Gedanken darüber machen in welcher Reihenfolge die Punkte abgearbeitet werden sollen. Er reflektiert sein Produkt immer und immer wieder, redet mit anderen Stakeholdern und stimmt sich mit ihnen ab.
Oft ist einem gar nicht klar, was dies eigentlich bedeutet und wird als pure Schikane empfunden. Dem ist aber nicht so. Die Entwickler haben auf einmal nicht mehr den riesen unsortierten Berg an Arbeit vor sich liegen und können uns strukturierter beginnen anzufangen. Wünsche, die ganz hinten auf der Liste stehen müssen erst mal gar nicht mehr in Betracht gezogen werden und es wird nur das entwickelt, was gerade relevant ist. Auch wird den Verantwortlichen klar, was es vielleicht nicht in das nächste Release schaffen wird und man kann sich frühzeitig darauf einstellen. Es handelt sich also keinesfalls um Schikane.
Nehmen wir ein zweites Beispiel. Bei Scrum gibt es täglich ein aktuelles Sprint-Burndown-Chart, das dazu verwendet wird den Fortschritt im aktuellen Sprint zu visualisieren.
Die optische Aufbereitung hilft den Entwicklern zu erkennen, wann sie mit ihrer Arbeit hintendran sind und wann sie nahe an der erhofften Geschwindigkeit liegen. Man könnte jetzt meinen, das Burndown-Chart löst das Problem des faulen Entwicklers und es ist dazu da ihn immer wieder drauf hinzuweisen, dass er härter arbeiten soll. Viele Arbeitgeber sehen dies genauso. Zum Glück ist dies aber falsch.
Das Burndown-Chart ist ein Werkzeug um Probleme aufzuzeigen. Sobald etwas Unerwartetes im Diagramm zu sehen ist, heißt es, dass man nachforschen muss, um herauszubekommen, was der Grund dafür ist. In den allermeisten Fällen ist es nicht das faule Team, sondern Rahmenbedingungen, die nicht stimmen. Häufig sind es Rahmenbedingungen wie unaufgelöste Abhängigkeiten, ungenaue Schätzung durch zu viele unbekannte technische Voraussetzungen oder zu ungenaue Beschreibung der eigentlichen Features.
Scrum gibt auch in diesen Fällen nicht vor, wie die Probleme zu lösen sind, es hilft einem aber zeitnah festzustellen, dass dort Probleme existieren. Wie diese zu lösen sind, muss das Team entscheiden.
Probleme in Unternehmen sind zwar häufig ähnlich, aber doch immer wieder ein wenig anders. Ein Projektmanagement-Framework zu schaffen, welches alle möglichen Probleme löst ist also fast unmöglich zu konzipieren, ohne dass das Regelwerk die Umfang einer Enzyklopädie annimmt. Scrum geht also den richtigen Weg indem es einem die Werkzeuge an die Hand gibt Probleme aufzudecken und sich bei der Lösung im groben erst einmal heraushält.
Das funktioniert trotzdem alles nur dann, wenn die Firma nicht alle 2 Wochen ihre Berechnungsstandards ändert, die Teams durcheinanderwürfelt oder aus Prinzip meint, alles auf den Entwickler abwälzen zu müssen.
Nach dem Motto: der Entwickler sei ja selbstständig. Also macht er Anforderungsanalyse, Projektmanagement, Risikobewertung, Entwicklung, Test, Deployment. Egal ob er dafür qualifiziert und ausgebildet ist, oder nicht. Obendrein kippen wir noch fleißig Störungen von außen ein. Das muss er abkönnen. Und wenn irgendwas schief läuft: ist immer der Entwickler schuld. Er hat sich „commited“ auf das Ziel, dann soll er auch zusehen, wie er damit fertig wird. Und wenn nicht: ist er offensichtlich inkompetent und wir müssen mal wieder zum zweiten Mal in 4 Wochen die Berechnungsmetriken ändern und die Teamstruktur umwerfen. Denn es müssen schließlich Ergebnisse her: Kohle, Kohle, Kohle. Der „kontinuierliche Verbesserungsprozess“ hat in manchen Firmen eben auch grundsätzlich einen Abgabetermin: und der ist IMMER „gestern“.
Es gibt Firmen, die sind nicht zu retten. Nicht mit Scrum oder irgendwas. Es gibt nur einen Ausweg, wenn man das Problem auch wahr haben will.
Guter Beitrag.
Hallo,
interessanter Artikel! Ich stimme diesem weitgehend zu, muss allerdings meinem Vorredner in den Kommentaren recht geben.
Kein Modell, egal wie abstrahiert oder wie weit entwickelt es ist, kann mit dynamischen Variablen wie „Achso, das hatte ich nicht erwähnt?“ und „Na das müssen wir dann halt vorziehen!“ klar kommen.
Diese uns allen bekannten Schwellengrenzen unserer Firmen sind nur durch gutes Management zu vermeiden und nicht durch unerfahrene Pseudomanager, die sich entweder mehr als Consultant sehen oder versuchen das gerade auf einem Seminar gelernte Wissen sofort umzusetzen.
Ich kann mich noch an meinen Ausbilder erinnern, der einmal zu mir sagte: „Scheisse fällt nach unten.“ – und er hatte damit recht. Aller Analysen und neuer Modelle zum Trotz müssen die Modelle zu den Menschen passen.
@Tom: Eine wichtige Regel in Scrum ist, dass der Sprint heilig ist und nur unter bestimmten Umständen von außen beeinträchtigt werden darf. Damit versucht man das Chaos vom Team fernzuhalten. Es wird trotzdem vorkommen, aber dadurch, dass der Sprint dann abgebrochen wird, die Reviews abgesagt und ein neues Planning einberufen wird, schafft man wieder Transparenz.
@Manuel: Scrum muss bei den Anforderungen nicht mit „Achso, hatte ich das nicht erwähnt?“ klar kommen, es ist dafür gemacht. Mit dem ProductOwner werden die Akzeptanzkriterien zu Beginn des Sprints festgelegt, ändern sich diese, kann das normalerweise nur im nächsten Sprint behoben werden, oder der ProductOwner bricht den aktuellen Sprint ab. In beiden Fällen ist es nicht die „Schuld“ der Entwickler, da der ProductOwner die Akzeptanzkriterien vorgegeben bzw. genehmigt hat. Änderungen und ein damit evt. verbundenes „nicht erreichen“ des Sprintziels liegen in diesem Fall in seiner Verantwortung.
Schwierigkeiten sehe ich eher bei Scrum in großen Organisationen, in denen lediglich ein Teil der Entwicklung nach Scrum arbeitet. Hier ist es wichtig, Schnittstellen zur „Nicht-Scrum-Welt“ zu etablieren, damit sich nicht ein Riss zwischen Nicht-Scrum- und Scrum-Welt bildet. Wenn dann die Organisation nicht flexibel genug ist, darauf schnell zu reagieren kann das ganz schnell zu einem oder mehreren ernsthaften Problemen führen.
Ein weiteres Problem sehe ich in der Skalierung in sehr großen Projekten mit sehr vielen unterschiedlichen Komponenten, bei denen nicht in jedem betroffenen Team ein Vertreter aller betroffener Komponenten vertreten ist.
@Tom bzw. @ständige Teamwechsel
Das Scrum Framework empfiehlt, dass sich das Scrum Team nicht immer neu
zusammen setzt. Denn zum einen kann man dann keine vernüftige Aussage über die Velocity des Teams treffen. Auch wenn das nur „Richtwert“ dafür ist ein Gefühl dafür zu bekommen was ein Team schaffen kann. Zum anderen muss sich jedes neue Team erst wieder finden.
Judith Andresen hat zu dem Thema ständig wechselnder Teams einen sehr guten Vortrag auf dem letzten PHPSummit 2012 gehalten.
Slides sind hier zu finden: http://www.judithandresen.com/2012/03/20/php-summit-2012-soll-performant-ist-schwierig/
@Tom & Manuel: was ihr da beschreibt nennt man unter Entwicklern Waterscrum oder auch Waterfail. Das hat alles nichts mit Scrum zu tun. Scrum hat nur 3 Rollen und 3 Meetings definiert – der Rest ist eigentlich aus den Prinzipien des Lean Development übernommen. Wenn ein Manager von diesem „Scrum“ gehört hat und von 300% mehr Entwicklungsgeschwindigkeit, aber kein Interesse an einer anderen Unternehmenskultur, dann wird sich wenig bis garnichts ändern und mittelfristig auch voll vor die Wand fahren und zurück rudern zum vorherigen Entwicklungsprozess.
„Scrum“ höre ich heute zum ersten Mal.
Heisst auf deutsch wohl „Gedränge“.
… eo Leute immer Begriffe hernehmen ;(
@Thorsten „Scrum“ bedeutet tatsächlich „Gedränge“ und wurde als Name für die Methode der Bezeichnung des Gedränges aus dem Rugby entliehen.
Scrum ist neudeutsch für Akkordarbeit…
Stimmt, das artet nach meiner leidvollen Erfahrung in übelste Akkordarbeit mit Mikromanagement aus. Aber die Scrum-Jünger werden jetzt gleich sagen „ich weiß nicht, was ihr da macht, aber es ist nicht Scrum“. Das sagen die immer, wenn jemand die negativen Seiten von Scrum aufzeigt. Das ist so wie im Mittelalter. Wenn die Pest kommt, dann hat man nicht den rechten Glauben oder man hat nicht richtig oder nicht genug gebetet. Scrum ist so ähnlich wie eine Sekte, die oben verdienen mit Training und Consulting einen Haufen Geld und die unten müssen den Scheiß ausbaden.
Moin,
@Jochen, wie kommst Du zu diesem Statement ? Jetzt Ihr bei euch Scrum oder ähnliches ein ?
VIele Grüße
@Jochen: Ich glaube, Ihr habt da ganz andere Probleme in Eurem Team, doch dazu später mehr.
Jetzt möchte ich noch kurz auf das eingehen, was ich vorher angedeutet hatte:
Das (Entwickler-) Team comitted sich bei Scrum (und nicht bei Srumbut) auf den Inhalt des Sprints, wenn hier regelmäßig zu viel von den Teammitgliedern angenommen wird, oder man sich innerhalb des Teams unter Druck setzt, so liegt das Problem innerhalb des Teams und nicht bei der Methode! Vielleicht sollte man das in der Retrospektive ansprechen oder zumindest andeuten! Der ProductOwner hat zwar ein Mitspracherecht bei der Reihenfolge – er legt schließlich die Priorität fest – aber nicht an der Menge. Eigentlich sollte der ScrumMaster ja Druck vom Team fernhalten – natürlich muss er da abwägen, was dem Team hilft und was nicht. An dieser Stelle kommt es natürlich auch darauf an, zu sehen, welches Selbstverständnis der ScrumMaster hat – wenn er ein verkappter Projektleiter ist, hat er seine Rolle leider falsch verstanden… Vielleicht solltet Ihr mal einen Coach kommen lassen, der sich Eure Situation einmal ansieht und analysiert, wo die Probleme liegen! Alternativ ist natürlich das Gespräch mit allen Beteiligten zu empfehlen, aber das scheidet ja meist wegen der Vorgeschichte aus und es ist leichter unter dem Vorwand der Methodenoptimierung einen Coach zu akzeptieren.