„Hoffentlich zieht dieser agile Hype über mich hinweg!“, hoffte ich, bis sich Scrum und XP wie ein Schauer über mir ergoss.
(Denjenigen, die noch nichts von agiler, Software Entwicklung, Scrum und XP gehört haben, seien folgende Links an Herz gelegt: Was ist agile Software Entwicklung? Was ist Scrum? Eine Einführung in Scrum oder das Agile Manifesto. Außerdem lohnt es sich, hier eXtreme Programming (XP) und hier zu schauen: XP A Gentile Introduction)
Gegen XP hatte ich nichts, war mir aber sicher, dass es in der Praxis keinen Bestand haben kann. Scrum hingegen war mir komplett suspekt. Wie kann ein so starres Konstrukt Agilität fördern? Kann sich ein Team das zum größten Teil aus introvertierten Nerds besteht sich ernsthaft selbst organisieren? Besteht nicht die Gefahr, dass es der Selbstüberschätzung der Entwickler, die sich (inkl. mir) gern für die Götter halten und wie Diven benehmen, Nährboden liefert, da ihnen mehr Freiräume gegeben werden? Wie kann denn die Produktivität deutlich gesteigert werden?
Unser Team hatte immer genügend Aufgaben und Leerlauf haben wir nicht. Stört der Daily Scrum möglicherweise den Workflow und erzeugt viel Overhead? Wie fließen dringende Bugs in die Sprint Planung ein? Verliert man nicht den Überblick, wenn man sich nur um die kleinen Userstories kümmert? Ist unser Team nicht eh viel zu klein für Scrum?
Zum Glück war meine Meinung nicht ausschlaggebend und die wer-weiss-was GmbH entschied sich dafür, Scrum einzuführen. Je mehr ich die Ideen verstand die Scrum ausmachen, desto klarer wurde mir, was unserem Team fehlte, um wirklich gute Arbeit zu leisten und sich weiter zu entwickeln. Das Daily Scrum löste unser wöchentliches Entwicklermeeting ab. Beim „Weekly“ vergaß so ziemlich jeder das ein oder andere, was in der Woche programmiert wurde. Das Daily Scrum ist zudem ein schöner gemeinsamer Einstieg in den Tag.
Bisher waren wir Entwickler gern genervt, dass Konzepte der großen Projekte nicht bis ins kleinste Detail ausgearbeitet waren und wir bei der Implementation immer wieder über diverse Dinge gestolpert waren. Jetzt sind wir bei jeder Projektphase (Konzeption, Planung, Ausführung, etc.) dabei und können immer unsere Ideen und Bedenken äußern. Bereits vor der Scrum-Einführung haben wir ein großes Projekt in Userstories aufgebrochen und es mit einer Runde Planning Poker durchgeschätzt. Der Vorteil war, dass wir uns über alle kleinen Teilschritte im Klaren waren und viel genauer die gesamte Projektdauer schätzen konnten. Zusätzlich ist es deutlich einfacher für andere Entwickler, die während des Projektes hinzukommen, Teile zu übernehmen und umzusetzen.
Ob wir wirklich schneller arbeiten, kann ich schlecht einschätzen. Fehlplanung fällt schneller auf und wir entfernen uns durch die ständige Kommunikation nicht so weit von den Kundenwünschen wie es bei der Wassenfall-Methode passieren kann. Die reine Entwicklungzeit verringert sich bedingt durch die verschiedenen Meetings (Daily Scrum, Review, Retrospektive, Konzeptionen, etc.), aber es bietet, gerade durch die Retrospektive, die Möglichkeit die eigene Arbeitsweise zu verbessern.
Natürlich haben wir uns zu Anfang verleiten lassen, zu viele Stories schnell abschließen zu wollen und eine tolle Velocity zu erzeugen. Damit fiel das Refactoring sehr gering aus und wir häuften einen Berg Altlasten an, den wir gerade abtragen.
Ich will hiermit nicht behaupten, dass Scrum das ultimative SuperDuperDingenskirchen ist, aber für unseren Zweck, eine sehr durchwachsene erfahrene Entwicklertruppe, die bereits lange zusammen an wer-weiss-was.de arbeitet, in die agile Software-Entwicklung einzuführen, genau das richtige. Wie sind eure Erfahrungen, welche Fragen beschäftigen euch vor und bei dem Einstieg in die agile Entwicklung?
Recent Comments