© Excellent backgrounds/Shutterstock.com
Fünf Thesen zu Scrum

Fluch oder Segen?


Scrum hielt als Vorgehensmodell für das Projektmanagement in den letzten Jahren in vielen Unternehmen Einzug. Ganz so toll, wie von vielen propagiert, läuft es aber nicht immer damit. Das motivierte mich dazu, fünf Thesen zu formulieren, die in Folge von fünf Scrum-Experten auf Herz und Nieren geprüft werden.

Video: How and why to design your Teams for modern Software Systems

Als Consultant und Trainer bin ich ein bisschen in der IT-Welt herumgekommen. Interessanterweise lernte ich dabei im letzten Jahrzehnt kaum mehr ein Unternehmen kennen, das in Sachen Projektmanagement auf ein klassisches Vorgehensmodell wie Unified Process setzt. Die meisten Firmen nutzten ein agiles Verfahren, vorrangig Scrum. Groß geworden bin ich dagegen mit den klassischen Vorgehensmodellen und konnte damit viele Projekte erfolgreich umsetzen, obwohl die meisten Kunden anfangs nicht wussten, was sie softwaremäßig eigentlich haben wollen. Die Bedeutung des Zitats „Walking on water and developing software from a specification are easy – if both are frozen“ lernte ich also von der Pike auf kennen.

Ich würde mich selbst als pragmatischen Programmierer bezeichnen, der mit den meisten Punkten aus „Clean Code“ (und ähnlichen Büchern) übereinstimmt, manches darin aber für übertrieben hält. Wichtig ist mir bei der Softwareentwicklung, dass das Rad nicht ein zweites Mal erfunden wird, sondern die bereitstehenden Technologien maximal ausgenutzt werden. Weiterhin halte ich die Softwareentwicklung für eine Ingenieursdisziplin, der man, vereinfacht gesprochen, gemäß der Devise „Spezifizieren – implementieren – testen“ nachgehen sollte. Leider stellte ich in den letzten Jahren aber fest, dass ich mit meinen Ansichten eher zu einer aussterbenden Art zu gehören scheine. Das Softwarebasteln ist unter dem Deckmantel, dass gemäß ­Scrum-Modell entwickelt wird, wieder stark in die Mode gekommen. Auch neue Technologien werden heute vielerorts ohne Evaluierung eingesetzt. Dazu halten sich gewisse Vorurteile beständig, z. B. „Java Enterprise ist umständlich“.

Wurde es früher teilweise mit der Dokumentation vollkommen übertrieben, findet man heute manchmal keinerlei Dokumentation mehr vor oder darf sich durch Wiki-Friedhöfe wühlen, um abschließend festzustellen, dass hier kaum mehr eine Seite up to date ist. Wie passend, wenn in einem solchen Moment auch noch der Song „Es lebe der Zentralfriedhof“ im Radio läuft ;-)

Bitte verstehen Sie mich nicht falsch! Scrum ist meiner Meinung nach ein sehr durchdachtes, ausgereiftes und sinnvolles Vorgehensmodell für das Projektmanagement und eignet sich bei korrektem Einsatz bestens zur Umsetzung von Projekten auf ingenieursmäßige Weise. Ich kritisiere vielmehr, wie Scrum in vielen Unternehmen implementiert und genutzt wird. Das brachte mich dazu, die folgenden fünf Thesen zu formulieren. Zwecks Überprüfung dieser Behauptungen habe ich fünf Scrum-Experten um ihre Stellungnahmen dazu gebeten.

Die Scrum-Experten

diener_konstantin_sw.tif_fmt1.jpgKonstantin Diener ist CTO bei cosee. Er arbeitet seit etwa zehn Jahren mit agilen Vorgehens­modellen wie Scrum und Kanban. Bei cosee beschäftigt er sich mit der Anwendung agiler Prinzipien auf Unternehmensebene.

Mail Web Twitter

duesterbeck_frank_sw.tif_fmt1.jpgFrank Düsterbeck ist bei der HEC GmbH tätig. Kern seiner Arbeit ist die Qualifizierung und Beratung von Menschen in den Bereichen Organisation, Projekt-, Test- und Anforderungsmanagement mit dem Fokus auf den Einsatz agiler IT-Verfahren und -Methoden. Weiterhin ist er Trainer der HEC Software-Akademie, Sprecher auf unterschiedlichen Konferenzen und Veranstaltungen und doziert an Hochschulen im Bremer Umland.

Mail Web Twitter

kraeft_oliver_sw.tif_fmt1.jpgOliver Kraeft ist Senior-Softwareentwickler im Bereich Java Enterprise bei der PIXEL GmbH in Gräfelfing bei München und Professional Scrum Master (PSM I). Nebenbei betreibt er die Website http://runnr.de.

Mail Web

much_thomas_sw.tif_fmt1.jpgThomas Much ist Agile Developer Coach und XP Coder aus Hamburg. Als Freiberufler unterstützt er zahlreiche Teams bei der Bewältigung der alltäglichen Projektherausforderungen, sowohl methodisch als auch technisch – und oft auch an der Reibefläche dazwischen.

Mail Web Twitter

schaffler_michael_sw.tif_fmt1.jpgMichael Schaffler ist Gründer und Inhaber der CIIT GmbH, die für große österreichische und deutsche Unternehmen Individualsoftware entwickelt und als Oracle-Partner Java- und JavaScript-Schulungen anbietet. Nach vielen Jahren in der IT in unterschiedlichen Positionen ist nach wie vor das Programmieren seine große Leidenschaft.

Mail Web

These 1

Die meisten Unternehmen machen nicht Scrum, sondern verwenden lediglich einen Scrum-ähnlichen Prozess. So werden beispielsweise immer wieder die Daily Stand-ups oder die Retrospektiven nicht gemacht. Dadurch geht aber manch großer Vorteil verloren, dessen sich die Unternehmen aber gar nicht bewusst sind.

Konstantin Diener: Auf jeden Fall! Ich unterscheide gerne zwischen Unternehmen, die „agil machen“ und denen, die „agil sind“. Damit ein Team oder eine Organisation wirklich die Erträge agiler Entwicklung bekommt, muss man die zugrunde liegenden Konzepte verstehen. Zum Verständnis ist es nützlich, sich am Anfang an die Elemente des Scrum-Frameworks zu halten und nichts wegzulassen. Wenn die Konzepte und Beweggründe in Fleisch und Blut übergegangen sind, ist es vollkommen in Ordnung zu experimentieren, z. B. „Wir machen eine kurze Retro bei jedem Produktionsfehler, dafür aber nicht mehr unbedingt nach jedem Sprint“.

Frank Düsterbeck: Diese These unterstütze ich. Die Sätze „Das Beste aus beiden Welten“ oder „Wir haben Scrum auf unsere Belange zugeschnitten“ höre ich relativ häufig. Ursache hierfür ist nicht selten die Angst, mit allen Konsequenzen von Scrum umgehen zu müssen – angefangen bei den Rollen bis zum potenziell auslieferbaren Produkt. Scrum ist ein Problemsensor, und als solcher zeigt es alle Hindernisse sehr schnell auf: in der Organisation, bei den Menschen und deren Interaktionen, bei den Prozessen und Praktiken und in den Technologien. Das muss man aushalten können und an die Ursachen ran. Die konsequente Abarbeitung der Hindernisse zur Optimierung des Wertstroms schaffen aber nur die wenigsten. Den Sensor beispielsweise durch das Weglassen der Retros zu verlieren, ist manchmal viel einfacher, bedeutet aber nichts anderes als die Ursachen zu ignorieren und das wirkliche Potenzial von Scrum nicht zu n...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang