Die Haustür ist noch abgeschlossen. Ich bin scheinbar der erste, der unser Wohnhaus in Berlin verläßt. Vor dem Haus wartet ein Taxi auf mich, das mich nach Tegel zum Flughafen bringen soll. Von da aus soll es dann mit Lufthansa weiter nach München gehen, zum ersten deutschen Scrum Day gehen. Es regnet leicht.
Scheinbar kommen auch die agilen Vorgehensweisen nicht ohne ihre Konferenzen und Treffen aus. Wohl wieder eine Gemeinsamkeit mit den klassischen Vorgehensweisen. Da sich Scrum immer weiter in der IT-Branche als leichtgewichtiges Vorgehensmodell oder besser gesagt Framework etabliert und es in vielen Punkten mit dem von mir früher selbst praktizierten und auch bevorzugten Praktiken in Projekten deckt, habe ich beschlossen dabei zu sein. Die Keynote wird von Ken Schwaber, dem Vater von Scrum gehalten, der praktischer Weise gleich noch vor dem Scrum Day Zertifizierungen zum Scrum Master anbietet. Und da Vorgehensmodell von einigen Vertretern unserer Zunft wie Religionen gelebt werden, will ich auch einmal einen echten Gott sehen. Da lohnt sich die Anreise doch gleich doppelt.
Da ich selten in München bin, bin ich bei der Suche nach einem Taxi-Stand auf Hilfe angewiesen, die mich aber glatt zu einem Taxi-Stand für Abflüge schickt. Die Taxen halten hier nur kurz, so daß ich kein freies finde und mir ein wartender Chauffeur eines freudlicher Weise ruft. Gut, S-Klasse als Taxi hatte ich auch noch nicht, hinterläßt aber auch keinen besonderen Eindruck.
Götter müssen gut verkaufen können
Der Scrum Day beginnt mit der Keynote von Ken Schwaber. Leider komme ich etwas zu spät, so daß mir nur noch ein Stehplatz am Ende des Raumes bleibt. Ken Schwaber ist ein kleiner und drahtiger Mann wohl Ende vierzig, der in seiner Keynote „Scrum, But…“ mit den Problemen von Scrum in der Praxis auseinandersetzt. Und das kann er gut. Ken Schwaber ist ein gekonnter Verkäufer, wohl auch einer der Gründe für den Erfolg von Scrum. Er ist überzeugend, auch wenn etwas manipulativ.
Um die Schwächen von Command&Control zu demonstrieren, läßt er die Zuhörer seiner Keynote aufstehen und Paare bilden. Einer aus dem Paar konnte dem anderen die Befehle links, recht, vor und zurück geben und es schaffen, daß dieser in vorgebener Zeit 60 Schritte schafft, ganz nach dem Grundmuster von Command&Control. Natürlich schafften das die wenigsten. Aber auch kein Wunder, schließlich war der Raum voll. Anschließend durfte jeder Teilnehmer seinen Weg selber suchen, was zu einem wesentlich besseren Ergebnis führte. Worüber dieser Test etwas aussagt weiß ich nicht. Vielleicht darüber, daß, wenn günstige Voraussetzungen geschaffen werden, man alles zeigen kann was man will. Übrigens, die einfachste Lösung der Aufgabe auf kleinstem Raum ist sechzigmal links zu sagen.
Aus Schwabers Vortrag ist mir vor allem die Aussage im Gedächtnis geblieben, daß nur 25% aller Entwickler in der Lage sind, innerhalb von Sprints auslieferbaren Code zu liefern, da ihnen wesentliche Techniken fehlen. Grund dafür seien mangelnde Anwendung von TDD, fehlende Standards zu Coding-Styles und Reviews und letztendlich eine schlechte Werkzeugunterstützung. Wahrscheinlich stimmt das leider auch. Gute Arbeit kann man nur in einer gutem Umgebung leisten.
Butter bei die Fisch
Die anschließenden Vorträge teilten sich in zwei Stränge auf, womit ich vor dem üblichen Problem stand, daß man nur einen von zwei Vorträgen hören kann. So stand ich vor der Wahl zu „Retrospektiven als Grundlage agilen Projektmanagements oder: Gelebte Streitkultur“ oder „Vom Businessneed zum hochwertigen Produktbacklog“ zu gehen. Ich entschied mich für letzteres. Die beiden Referenten, Dr. Martin Wrangel und Sebastian Neus, beschrieben in ihrem Einführungsvortrag wie sie in einem größeren Projekt Anforderungen in Product-Backlog-Items umgesetzt haben.
Ausgehend davon, daß Anforderungen für jeden Sprint hinreichend präzise sei müssen, um sie verläßlich in einem Sprint umzusetzen.
Beide gehen davon aus, daß Backlog-Items so präzise sein müssen, daß das Team sein Commitment abgeben kann. Wer bereits Projekte geleitet hat, weiß wie schwierig das sein kann, da sich viele Aufgaben bei der Umsetzung als komplexer erweisen, als anfangs angenommen und eine Menge Erfahrung dafür notwendig ist, dies miteinkalkulieren zu können.
Konzeption und Schätzung von Aufgaben gehören für die beiden auch in einen Sprint und können bis zu drei Tagen in Anspruch nehmen, da das Planning Meeting sich bei ihnen nicht als zeitlich ausreichend erwiesen hat. Um alle wirklich existierenden Anforderungen an das Produkt zu erfassen, wurde in dem behandelten Beispielprojekt ein Product-Owner-Team unter Führung eines Chef-Product-Owners gebildet. Wer oder welcher Bereich in dem Product-Owner-Team vertreten sein mußte, wurde über eine Stakeholder-Analyse ermittelt.
Nach den Erfahrungen der aus diesem Projekt kommen einige Entwickler nicht mit der für Scrum notwendigen Eigenverantwort klar und wünschen sich eine klarere Vorgabe was wie zu tun ist. Auch war es für das Team wichtig, zusammen zu einer gemeinsamen Definition von Fertig zu kommen.
Insgesamt war dieser Vortrag von meinen gehörten Vorträgen, inklusive der sich nach jedem Vortrag anschließenden Diskussion, einer der besten, da er inhaltlich überzeugend war und praktische Lösungsmöglichkeiten gut aufgezeigt hat.
Als nächsten Vortrag habe ich mir dann Boris Gloger und Oliver Zeil von ImmobilienScout24 ausgesucht. Wahrscheinlich, weil ich Boris Gloger nach der Lektüre seines Scrum-Buchs einmal selber erleben wollte. Hierzu muß ich sagen, daß das Buch nicht schlecht ist, viele Beispiele in dem Buch die Gloger benutzt schlichtweg falsch sind und er geradezu in der Einführung polemisiert. Alles Punkte die mich etwas abgestoßen haben. Vielleicht war ich voreingenommen, aber der Vortrag hinterließ auch keinen besonderen positiven Eindruck. Viele Punkte waren mir zu vereinfachend. Teilweise war es mir zu prinzipiell. Warum ein Planing Meeting genau 90 Minuten sein müssen, ist mir nicht klar geworden. Zwar sollten Timeboxen eingehalten werden, wenn sie aber generell zu kurz für ein Team sind, müssen sie auch angepaßt werden dürfen. Mit dieser Art der Orthodoxie kann ich immer wenig anfangen.
Im dritten meiner besuchten Vorträge haben Jan Ebert und Reines Vicups sich mit Anforderungsmanagement innerhalb von Scrum beschäftigt. Dementsprechend hieß der Vortrag auch „Scrum und professionelles Anforderungsmanagement – ein Widerspruch oder nur eine Frage der Vorgehensweise?“ Beide vertraten die Ansicht, daß Anforderungsmanagement grundlegend für erfolgreiche Projekte ist, aber in Scrum nur unzureichend behandelt wird. Zwar wird dem Product-Owner die Verantwortung übertragen die Anforderungen des Kunden an das Produkt zu erfassen und gegenüber dem Team zu priorisieren, doch liefert Scrum hierfür keine Hilfsmittel. Diese Lücke zwischen „ja, aber nur wie?“ kann professionelles Anforderungsmanagent lösen. Inhaltlich ein sehr fundierter Vortrag, dessen behandelte Techniken sehr gut durch Literatur zum RE behandelt werden. Beide haben auch die notwendige Fähigkeit des Product Owners betont, gute Anforderungen bereitzustellen. Hierfür muß er sich zum einen mit den Methoden es Requirement-Engineerings auskennen und zum anderen auch über Domain-Wissen verfügen. Ich denke, daß dies in vielen Nicht-IT-Firmen schwierig sein dürfte, diese beiden Fähigkeiten in einer Person vereint zu finden.
Interessant war die anschließende Diskussion, in der Oliver Zeiler von ImmobilienScout24 einwandte, daß er sich in seinem Bereich diesen Aufwand nicht in der Form leisten könne, worauf ich bat doch Beispielprojekte zu nennen, in denen die beiden RE in der von ihnen beschriebenden Tiefe durchgeführt haben. Erwartungsgemäß war es größere Projekte mit einem längeren Fokus, entweder in regulierten Einsatzgebieten wie Medizintechnik oder auch Produktlinienentwicklungen. Das solche Projekte ein anderes Umfeld mit anderen Anforderungen haben als ein Internetportal dürfte klar sein.
Als letzten Vortrag habe ich mich dann für „Was (noch) klassische Projekte von Scrum&Co lernen können – eine empirische Studie“ von Markus Wittwer, oose Innovative Informatik, entschieden. Die oose hat um die Jahreswende 2008/2009 eine Online-Umfrage zum Projektmanagement durchgeführt, deren Ergebnisse von Wittwer vorgestellt wurden. Nach den Umfrageergebnissen sind agile Projekte häufiger erfolgreich als klassische Projekte, wobei der regelmäßige Kundenkontakt ein maßgeblicher Faktor ist. Erfahrene Projektleiter kombinieren jedoch eher agile und klassische Techniken. Dazu paßt auch, daß ein Vorgehensmodell keine Aussagen zu eingesetzten Techniken und umgekehrt zuläßt. Vorgehensmodelle sind wohl eher doch Leitkulturen oder -ideen, die letztendlich durch Menschen gelebt werden müssen. Im schlimmsten Fall sind sie aber auch nur ein Mäntelchen, welches sich man umhängt. Ich es ist wie mit dem Kochen. Jeder paßt sein Rezept dem eigenen Geschmack an und nimmt die Zutaten welche die eigene Küche hergibt.
Neben dem ersten erscheint mir der Praxisvortrag von Mathias Patzak „ScrumHell – Wann sind Sie ‚Done‘“ über die Scrum-Einführung bei AutoScout24 einer der besten gewesen zu sein. Nicht nur, wegen seines sehr lebendigen Vortragsstils, sondern auch wegen des wichtigen Hinweises darauf, daß es wichtig ist eine Kultur zu etablieren. Und die in einem Unternehmen gelebte (nein, nicht die nach außen kommunizierte) Kultur entscheidet über Erfolg von agilen Techniken. Fragwürdig erscheint es mir aber, die Spezifikation in den Sprint zu verlegen.
Was am Ende bleibt
Spät kehre ich wieder nach Berlin zurück. Das eine Konferenz in München stattfindet heißt nicht, daß man als Teilnehmer auch in München landet. Es kann auch Aschheim-Dornach sein und macht sich in einem dreistelligen Betrag für Taxifahrten bemerkbar. Abgesehen davon konnte ich an einigen interessanten Vorträgen teilnehmen und interessante Gespräche führen. Gewünscht hätte ich mir aber auch eine stärkere Diskussion von Scrum und Lean Management Methoden ansich. Das Organisationsniveau des Scrum Days war gut bis sehr gut. Das man sich so gut um das leibliche Wohl der Gäste gekümmert hat, habe ich nicht so oft erlebt. Getränke und kleine Imbisse waren über die ganze Zeit verfügbar. Lediglich hätte mich mir in manchen Räumen mehr Stühle gewünscht und nicht über das Kabel des Projektors steigen zu müssen. Bei einer Eintagesveranstaltung dieser Preisklasse stelle ich diesen Anspruch schon. Fachlich hat es sich auf jeden Fall gelohnt, da der Scrum Day nicht nur gute Einblick in die Umsetzung von Scrum gebracht hat, sondern auch gezeigt hat, daß Scrum als kleines Framework bei jedem anders sein kann. Eine gute Voraussetzung, um langfristig erfolgreich zu sein.
P.S.: Einige weitere Gedanken zum Scrum Day von Markus Wittwer kann man im oose-Blog (Gedanken zum Scrum-Day in München (Teil 1), Gedanken zum Scrum-Day in München (Teil 2)) finden.
sein wie wir selber. Die gute Entwicklungsumgebung muß uns bei allen Änderungen unterstützen, uns einladen neues auszuprobieren und flexibel zu bleiben. Sobald wir eine Änderung, einen Test oder Idee verwerfen, nur weil sie nicht mit angemessenem Aufwand mit unserer Entwicklungslandschaft umzusetzen ist, ist es Zeit über sie nachzudenken.
