Angeberwissen zu Scrum - Teil 3 von 3

Zum Abschluss der kleinen Reihe noch der dritte Teil mit zwei Angeberweisheiten:

Scrum hat alles nur geklaut!

Fast richtig. Wenn man mal die bunten Prospekte der vielen Scrum-Trainer und –Experten zur Seite legt und sich auf die guten, alten Projektmanagement-Traditionen besinnt: da findet sich doch vieles, was in Scrum auch wieder hochkommt. Beispiele? Also:

Autonomes Team

Fast religiös ist die Diskussion der echten und selbsternannten Gurus darum, was das Team alles entscheiden darf – und was die anderen, in Unternehmen gelegentlich anzutreffenden unwichtigen Leute wie Chefs und Manager auf keinen Fall dürfen. Abgesehen von der Schwierigkeit, die Vielfalt real existierender Unternehmen auf eine einzige Methode mit dem immer gleichen Mantra zu reduzieren: gab es schon als „Empowerment“. 

Wann genau das aufkam, kann ich nicht rekonstruieren, meinem Gedächtnis nach Ende der 80er und Anfang der 90er. Der Trick: Übernahme von Verantwortung durch den, der die Arbeit wirklich macht. Das übliche Toyota-Beispiel ist ja: jeder darf das Band anhalten, wenn die Qualität gefährdet ist – auch eine Form von Empowerment, früher hätte man Meldung machen müssen. 

Neu ist: ein Team wird „empowered“ – nicht einzelne. Das  Team muss in der Gruppe entscheiden und handeln. Das ist bekanntermaßen schwierig, kann aber erlernt werden. Ziel: die Herde entscheidet besser als ein einzelner Ochse...

Stetige Verbesserung – Kaizen 

Scrum versucht durch regelmäßige Reviews und Retrospektiven Hindernisse und Fehlentwicklungen aufzudecken. Insbesondere wird dabei auch beleuchtet, wie denn der Prozess selbst angepasst ist. Das ist mitunter anstrengend, vor allem nach den ersten Monaten, alles ist eingeschwungen und läuft, und jetzt schon wieder Bauchnabelschau?

Der stetige Wandel zum Besseren wurde vor allem in der Industrie von Toyota nach dem Krieg vorangetrieben – bis es zum Allgemeinplatz wurde. Ich persönlich halte eine stetige Optimierung von Prozessen für schwer vorstellbar, irgendwann ist die Zitrone ausgequetscht, oft versumpft das „Lessons Learned“ dann zu einem Pflichttermin. Vorteilhafter scheint mir eine „stetige Anpassung“ – weil sich Anforderungen und Technologien ändern, weil Mitarbeiter und Strukturen sich ändern. Vielleicht war das sogar mit Kaizen gemeint? Auf jeden Fall ist die effektivste und beste Optimierung die Evolution: nicht der „fitteste“ gewinnt (das ist ein Übersetzungsfehler!) – sondern der am Besten angepasste! Byebye T-Rex – Welcome Säugetier!

Kurze Sprints

Häufige Überprüfung des Erreichten geht einher mit Verbesserung. Ich selbst kam Anfang des Jahrtausends mit dem Rational UnifiedProcess® (RUP), heute ein Warenzeichen der IBM, in Kontakt. Ein Kernpunkt ist die iterative Herangehensweise: beherrschbare und überprüfbare Abschnitte, statt jahrelanger Arbeit im Verborgenen. Der RUP hatte noch viele Elemente von traditionellen Kommandostrukturen in Projekten – aber das iterative und inkrementelle Vorgehen erwies sich in meinen Projekten als wertvolle und risikomindernde Taktung. Scrum geht da weiter: statt Iterationen von sechs oder acht Wochen reduziert man die Planung auf zwei bis vier. Und zwar aus dem gleichen Grund: Transparenz und Steuerbarkeit – lieber den Aufwand von vier Wochen mit zehn Personen wegwerfen (ca. 200 PT) als den Aufwand von zwei Monaten (ca. 400 PT).

Seit Anfang des Jahrtausends – glaube ich – sind auch Änderungshektik und Erwartung schneller Ergebnisse deutlich gestiegen. Und welcher Fachbereich hält sich heute schon noch gerne mit wochenlangen Spezifikationen auf?

Scrum rettet mein Projekt!

Kommen wir mal auf den Blog-Titel zurück: Wird Scrum Ihr in Schieflage befindliches Projekt retten? Möglicherweise!

Die wichtigsten Punkte einer Rettung sind:

• Ziele bestimmen – sind die Anforderungen klar beschrieben, bekannt und abgeschätzt?
• Standort bestimmen – was wurde wirklich schon erreicht?
• Einen Weg suchen – kann Ihr Team die Ziele noch erreichen? Was waren denn die Gründe, warum es bisher nicht geklappt hat? Können Sie diese Hindernisse aus dem Weg räumen?
• Anpassen – Ziel und Weg sind ja voneinander abhängig. Wenn Sie die Ziele gar nicht erreichen können – welchen Teil davon können Sie denn erreichen, lohnt sich das? Wichtig ist, dass Sie realistische Ziele beim Neustart haben. Alles andere bringt keine Verbesserung.
• Neustart – Klarer Start, klare Ziele, klarer Weg.
• Häufige Überprüfung des Erreichten – ist ein Nutzen zu erkennen? Passt Ihr Plan zur Realität? Manchmal muss man wieder vorne starten.
• Häufige Überprüfung des Prozesses – tut Ihr Team eigentlich das Richtige? Oder erzeugt es seitenlange Dokumente, „weil man das hier so macht“?
• Motivation und Einbindung – fragen Sie die Experten für Teamarbeit – Ihr Team. Menschen, die selbst über ihre Arbeitsweise entscheiden, identifizieren sich viel mehr mit den Ergebnissen und Zielen. Dafür müssen Sie als Projektverantwortlicher manchmal auch loslassen können!

Schön und gut – aber war das jetzt Scrum? Noch nicht – aber weit sind Sie nicht mehr davon entfernt... 

Angeberwissen zu Scrum - Teil 2

Für große Projekte taugt Scrum nicht!

Wird gerne auch abgewandelt zu: in traditionellen Unternehmen geht Scrum nicht! Stimmt’s? Tja – kommt darauf an, wie Sie denn bisher Ihre großen Projekte gemanaged haben. Die agile Fraktion kümmert sich herzlich wenig um Budgets und Zuständigkeiten – man setzt einfach voraus, dass sich das Management bereits darum kümmert. Wie das Management das macht, liegt außerhalb der Kernmethodik von Scrum. Der Witz an der Sache ist: genau genommen ändert sich an den Projektvorbereitungen nicht so viel, wenn Sie dann auf „Agile“ umsteigen! Oder wird Ihnen irgendjemand in Ihrem Konzern mal eben so 1-2 Millionen Euro genehmigen, wenn Sie weder Umfang noch Termin benennen können?

Die Frage ist ja eher, wie Sie zu einer Aussage dazu kommen: 

Aussage zu...	Traditionell	Agil
Budget	Sie investieren sehr viel Zeit in Anforderungen mit Lasten- und Pflichtenheft Schätzung von Aufwand in PT – am besten bereits mit den Entwicklern Projektplanung – mit allen Beteiligten Risiko-Planung für Puffer („known unknowns“) Planung für Management-Puffer („unknown unknowns“) Da Sie den Budget-Rahmen meist vorher kennen, machen Sie alle Klimmzüge, um irgendwie im Bereich zu bleiben.	Sie investieren viel Zeit in Erstellung des Product Backlog mit bekannten Anforderungsblöcken und Verfeinerungen für die zunächst anstehenden Anforderungen Schätzung der Einträge mit Story Points durch das Team Risiko-Analyse mit dem Team Puffer-Bestimmung (alle „unknowns“) Budget-Bestimmung durch Teamgröße über Zeit Wenn Sie über den Rahmen hinauskommen, sprechen Sie mit den Anforderungsgebern und streichen Anforderungen durch Priorisierung.
Termine	Ihre Planung (s.o.) führt in MS Project oder einem anderen Tool zu einer Zeitaussage. Ihre Vorlagen erinnern Sie daran, Zeit (und Aufwand) für Test und Bugfixing sowie Stabilisierung und Wartung nach Go-Live zu reservieren. Spätestens jetzt sprechen Sie mit den Stakeholdern, um Inhalte herauszunehmen, damit es noch passt.	Sie erstellen eine sehr grobe Release-Planung auf Basis der bisherigen Team-Geschwindigkeit und fügen Release-Sprints ein. Termine werden sich ändern - machen Sie das doch einfach transparent durch Zeitpuffer!
Umfang	Anforderungen haben Sie bereits aufgelistet – für die gesamte Laufzeit, alles andere wird durch ein rationales Change Request Verfahren abgewickelt: damit kann Ihnen keiner mehr etwas vorwerfen.	Der Umfang wird sich ändern. Schon morgen. Sie passen sich von Sprint zu Sprint an – und nutzen das Budget für den wirklich gewünschten Nutzen.
Zuständigkeiten	Sie haben rechtzeitig den Projekt-Sponsor ausgemacht und binden ihn ein. Im Zweifel hat er mehr zu sagen als die Benutzer des Systems.	Die Anwender – vertreten durch den Product Owner – reden mit. Kein „Wünsch Dir Was“, sondern direktes Feedback in beide Richtungen: „Das Feature wird sehr teuer!“ vs. „Die Umsetzung erleichtert meine Arbeit nicht!“

Sehr wichtige Elemente für die erfolgreiche Verwendung von agilen Methoden sind Transparenz und Vertrauen. Mussten Sie gerade lachen, weil Transparenz durch die vielfältigen Reporting-Ebenen sowieso verlorengeht? Wie wäre es, wenn sich das ändern würde? 

Scrum never fails!

Gerne auch mit einem Augenzwinkern kolportiert. 

Ich meine: vertrauen Sie keiner Methode! Nur Menschen lösen Probleme, nicht Methoden. Schon gar nicht Methoden, die man auf Papier kauft und ins Regal stellt...

Vereinfacht gesagt, können Sie mit Wissen, Methoden und Maschinen sehr gut vorhersagbare Aufgabenstellungen bearbeiten, während Sie hingegen für komplexe Problemstellungen Ideen und Können benötigen. 

Zur vertiefenden Lektüre empfehle ich das „Institut für Institut für dynamikrobuste Höchstleistung“ und die kompakten „Denkzettel“, insbesondere Nummer 16. 

In einem Scrum-Team kann sich keiner mehr verstecken!

Ein Management-Traum! Endlich wird deutlich, wer reinhaut und wer nur CO2 produziert! Dann schmeißen wir jedes Jahr die schlechtesten 10% raus?

In jedem Team werden Sie gruppendynamische Effekte aller Arten beobachten, bis hin zu „den / die ziehen wir doch mit“ und auch „mit dem Bart passt der nicht bei uns ins Team“.

Bei Scrum ist es zunächst Aufgabe des Managements, das Team zusammenzustellen. Der ScrumMaster soll für die Team-Findung sorgen, also Storming – Norming – Performing usw. Das Team kann natürlich sich über seine Zusammensetzung Gedanken machen. Aber möchten Sie wirklich ein Team aus lauter Superhelden haben? Die Kunst ist doch, aus dem, was man vorfindet, das Beste zu machen.
Wie in der Bundesliga: natürlich kann man sich verstärken oder mal jemanden auf die Bank setzen. Und eine Mannschaft aus lauter Superstürmern gewinnt keinen Pokal. 

Angeberwissen zu Scrum

Scrum ist ein agiles Prozess-Framework zur Abwicklung von Projekten. Klar, das haben Sie gewusst! Natürlich haben Sie viel gelesen und gehört zu

• Team-Verantwortung statt Projektleiter-Verantwortung
• Kurzen Sprints statt langen Projektphasen
• Mehr Software für den Euro
• ...

Aber: wie fühlt sich das wirklich an? Können Sie auf den Szene-Partys mitreden beim Thema Scrum? Oder müssen Sie das Feld anderen überlassen?

Damit SIE mal im Mittelpunkt stehen können – hier das wichtigste Angeberwissen zum Thema Scrum! Am besten streuen Sie es beiläufig in Ihre Projektgeschichten ein...

Die machen, was sie wollen – jahrelanges Management war umsonst!

Stimmt nicht: Die Rolle des Managements ist eine andere. Ich habe tatsächlich Manager und Projektleiter kennengelernt, die glaubten, dass man Software-Entwickler antreiben müsste, weil die alle faul seien! Und dass man am Besten unangemeldete Kontrollen macht. Wenn jemand jahrelang sich mit etwas derart komplexem wie Programmiersprachen, Datenbanken, Application Servern und Entwicklungsumgebungen auseinandergesetzt hat – freiwillig und mit Freude – warum sollte der nicht genau das tun wollen? Fragen Sie sich mal, was denjenigen denn daran hindert, richtig effektiv zu arbeiten – und fragen Sie ihn das mal. Sie werden staunen.

Ein fähiger Produkt Owner ist extrem wichtig und schwer zu finden

Stimmt – meistens. Sie sollten nie erwarten, immer nur perfekte Supermänner und –frauen zu bekommen. Sehen Sie es mal wie beim A-Team oder McGuyver: machen Sie das Beste aus dem, was Sie haben! Das geht – mit Analyse und Ideen: ist der Product Owner unerfahren oder noch neu im Thema? Kann das Team ihm helfen – und wie? Wer kann – mit Hilfe des Teams – die Rolle zeitweise übernehmen? Natürlich reduziert das die gefühlte Entwicklungsgeschwindigkeit, aber der Gewinn durch Vermeidung größerer Katastrophen und peinlicher Fehler wiegt meist die Kosten auf. 

Schätzungen in Story Points sind am Anfang immer schwer für ein Team

Stimmt. Die Schätzung in konkretem Aufwand in PT oder Stunden fällt den Entwicklern leichter. Haben Sie denn damit gute Erfahrungen gemacht? Auch dann noch, wenn Sie die Kosten für die Stunden-Schätzungen mal gegenrechnen? Wie viel davon ist dann doch nicht realisiert worden, hatte einen deutlich höheren Aufwand – trotz aller Schätzklausuren? Story Points bilden ein „gefühltes“ Komplexitätsmaß. Das ist schwer zu schlucken, wenn man eher Algorithmiker ist. Deswegen sind auch Function Points in der Vergangenheit so zu Tode definiert worden, dass man auch gleich in Stunden schätzen konnte. Wie oft haben Sie in Ihrem Function Point Spreadsheet so lange rumprobiert, bis es zu Ihrem Gefühl passte?

Der Trick ist: Mit der Zeit bildet sich ein Gruppengefühl, was wie einzuschätzen ist. Und Planning Poker ist immer noch viel schneller als die Erstellung einer detaillierten Schätzung.

Testen kommt bei Scrum immer zu kurz

Stimmt meistens. Scrum ist ein Management-Framework – kein konkreter Prozess zur Software-Entwicklung. Sie können mit Scrum auch die Organisation Ihrer Hochzeit umsetzen (der Grund dafür wäre wohl sehr interessant). Wie testen Sie Ihre Hochzeitsvorbereitungen? Das steht nicht im Scrum Guide! Tja. Sie haben aber schon Software entwickelt – also nutzen Sie das, was sie schon können und bauen Sie es ein. Man unterscheidet meist zwischen

• Entwicklertest: Dauernd, durch automatisierte Modultests und manuelle Tests der „Bitschubser“.
• Integrations- oder Inkrementtest: regelmäßig im Sprint, durch jemanden, der die fachlichen Zusammenhänge durchblickt – also meist der Product Owner
• Release-Test: wenn Sie was ausliefern – Sie wollen ja keine Rückrufaktionen verursachen! Durch Hardcore-Tester oder Product Owner und am besten auch durch Endbenutzer...

Wichtig: die Test-Aufgaben müssen im Sprint Backlog stehen – sonst macht sie keiner. Lassen Sie Ihre Leute doch mal überlegen, wie sie „zero defects“ erreichen können; das nervt anfangs aber zahlt sich später aus. Meist braucht man für ernsthafte Anwendungen auch ernsthaftes Test-Wissen - wie früher.

To be continued...