Botschaft an den CEO: Scrum und XP sind für Euch

Über die letzte paar Monate habe ich diverse Beiträge über Scrum veröffentlicht, aber noch nicht so richtig in Text-Form erklärt, was Scrum eigentlicht ist und warum man es braucht.

Mein namics-Kollege Jean-Pierre König, hat neulich einen Blog zum Thema Scrum gestartet und hat auch eine Reihe von Artikeln als Gast-Blogger über Scrum verfasste: Was ist Scrum, wie funktioniert Scrum und warum sollte man Scrum einsetzen?

Dies hat mich motiviert, wieder mehr über Scrum zu schreiben. Mit den nächsten paar Einträge möchte ich auch diese Themen aus der Perspektive vom Management beleuchten, warum Scrum und XP von strategischer Bedeutung sind.

Die Herausforderung, komplexe System zu bauen

Jeder Projektleiter wird mit dem Teufelsquadrant konfrontiert. 4 Parametern: Qualität und Funktionalität (also Umfang) sowie Termine und Preise (bzw. Aufwand). Es gilt die ersten 2 zu maximieren und die anderen zu minimieren. Je grosser das Projekt, um so mehr trägt der Projektleiter die Verantwortung, ja geht sogar persönlichen Risken ein.

Geht das Projekt schief, werden nicht nur Ressourcen vergeudet, sondern das menschliche leidet sehr stark, ja der Ruf des Projektleiters oder gar die beteiligten Firmen hängen davon ab, ob das Projekt erfolgreich wird oder nicht. Im Fall des Supergaus wollen Auftraggeber und -Nehmer gar nicht miteinander reden. Das Zwischen-Menschliche wird zum Hinderniss — als erstes muss man den Vertrauensbasis wieder herstellen.

Und troztdem, die Studien zu folge, ca 50% aller Projekten haben Probleme mit den Teufelsquadrant. Auch bei den erfolgreichen Projekte, werde 2/3. der entwickelten Funktionalität selten bis gar nicht benutzt.

Also grob geschätzt, 2/3 des investierten Aufwands hätten gesparrt werden können.

Warum wird so viel unnötige Funktionalität produziert? Das hat mehrere Grunde:

• Kunden werden regelrecht erzogen, dass Funktionalität, die man fruh im Projekt spezifiziert, günstig ist, bzw. dass Aenderungen teuer sind.
• Change happens – also Aenderung kommen, und die eingesetzen Methoden werden schwer heraugefordert, bei den Aenderungen mitzuhalten.
• Es ist schwierig herauszufinden, was die Kunden bzw. Benutzer wirklich wollen und brauchen.
• Software rapide und flexible zu entwickeln braucht entsprechende Engineering Practice und Technologie.

Ohne diese Methodik und Infrastruktur sind Aenderungen doch teuer, also doch lieber zu viel specifizieren als zu wenig. Aber das muss nicht sein.

Scrum stellt ROI im Vordergrund. Man entwickelt nur weiter, wenn es dem Geschäft tatsächlich mehr dient als es ihm kostet.

Scrum vermeidet eine über-Verplannung sowie die frühseitige Verpflichtung auf Funktionen, die evtl. gar nicht nötig sind. Man arbeitet an Sache, die von hoher Priorität sind und eindeutig sind, und wartet auf Abklärungen, Verhandlungen und Vereinfachungen von Sachen, die kompliziert oder nicht eindeutig sind.

Scrum vermeidet ein Mikro-Management der Arbeit und definiert wenige Instrumente, schreibt aber den Arbeitsablauf und Spielregeln genau vor.

Die Arbeit wird in so genannten „Sprints” oder Arbeitseinheiten von 2 – 4 Wochen aufgeteilt. Nach jedem Arbeitstakt soll eine für die Business-Einheit nützliche Funktionalität produziert werden, welche produktiv eingesetzt werden könnte.

Die Hauptvorteile dieser Methodik liegen darin, dass:

• nach einer ersten Aufbauphase ist man nie mehr als 30 Tage von einer potenziell einsetzbaren Version entfernt: ein Gesamtversagen ist fast ausgeschlossen.
• Jeder Arbeitsschritt hat einen positiven ROI: Funktionalität, welche eingesetzt werden könnte.
• Team und Auftraggeber sind bestens positioniert, um auf neue Informationen sowie ändernde Prioritäten und funktionale Änderungen zu reagieren. Probleme werden rasch erkannt und ausgeräumt.

Grundsätzlich gilt bei dieser Rythmus: Plan -> Do -> Demo -> Improve.

Die Planung erfolgt in gegenseitigem Einverständnis vom Kunden bzw Produkt-Owner und das Team. Allfällige unterschiede zwischen Wünsch und Realität werden hier beseitigt. Nachher kann man “in Ruhe” arbeiten. An den Auftrag wird nichts mehr geändert, bevor der nächsten Sprint startet. (Da der Sprint nicht zu lang ist, hat man den Auftrag auch nicht vergessen oder modifiziert). Dann wird vorgeführt.

So verbessern sich die Termin-Treue, die Spezifikationstreue und der Vertrauensbasis.

Ein besondere Eigenschaft von Scrum ist das institutionaliserte Scrum-Retrospective. Nach jedem Sprint treffen sich Team und Scrum-Leiter und fragen sich:

• was haben wir erreicht?
• was war gut?
• was war verbesserungswürdig?
• was soll unternommen werden?

Als Scrum-Leiter kann ich bestätigen, dass diese Sitzung für den Scrum-Leiter sehr unangenehm sein kann. Aber Transparenz ist wie Schönheit, schmerzhaft, aber erstrebenswert). So entwickeln sich die Prozessen, zwar inkrementell, aber konstant. Uber Monate und Jahren kann das zu erheblich positive Wirkungen auf die Produktivität führen.

Nächster Beitrag – warum funktioniert Scrum und wer setzt es ein?