www.bigmachines.de | zurück zu BigMachines

In der späteren Entwicklungsphase im Sommer 2008 gab es für mich als VP of Product Development bei BigMachines mehrere Gründe zur Besorgnis:

• Wir mussten für die neue Version mehrere komplexe Funktionen entwickeln
• Auch zu dieser späten Phase des Veröffentlichungszyklus hatte ich noch nicht viel davon gesehen, wie das Produkt aussehen würde
• Wir verwandten für die neue Version neuere Technologien, die eine Lernkurve bedeuteten
• Die Entwickler hatten mehrere wichtige Termine verpasst und für viele im Team waren die verschiedenen Entwicklungskomponenten noch unklar
• Die Qualitätssicherung war unsicher. Wann würde die Testphase beginnen, die schon mehrmals verschoben wurde?
• In den letzten Entwicklungsphasen hat das Team viele Nachtschichten eingelegt

Kurz, es gab zu viel Stress und nicht genug Ergebnisse – kein guter Ausgangspunkt!

Zu diesem Zeitpunkt wandte das Produktentwicklungsteam von BigMachines das Wasserfallmodell des Software Development Life Cycle (SDLC) an. Beim Wasserfallmodell wird jede Entwicklungsphase aufeinanderfolgend abgeschlossen. Der Hintergrund dieses Modells ist, dass die am Anfang des Produktionszyklus aufgewandte Zeit zu größerer Ökonomie in späteren Phasen führen kann – wenn zum Beispiel klar definierte und umgesetzte Anforderungen zu einer schnelleren Implementierung und besserer Produktqualität führen. Entsprechend dem Wasserfallmodell soll deshalb erst zu einer späteren Phase übergangen werden, wenn die vorangegangene Phase abgeschlossen und perfektioniert wurde.

Wir hatten also neben wenigen Ergebnissen viele Meetings. Am Ende eines jeden Meetings schien mir immer jemand zu versichern, dass ich unbesorgt  sein soll, weil die Wasserfall-Kurve noch gegen Ende des Zyklus anziehen werde. Dieser Vorstoß sollte zur Fertigstellung einer großartigen Produktversion führen.

Am Ende hatten sie damit teils Recht, teils Unrecht. Wir haben etwa 2-3 Monate später als geplant eine großartige neue Produktversion abgeliefert. Dies hat mir die Augen geöffnet und ich entschied mich dafür, unseren Prozess noch einmal dahingehend zu überprüfen, dass jeder Mitarbeiter im Team den Fortschritt einer neuen Version nachvollziehen kann und Erfolge beim Entwicklungsprozess verzeichnen kann.

Nachdem ich mich mit unseren Teams im Engineering und der Qualitätssicherung abgesprochen, viel gelesen und mein Netzwerk zu Rate gezogen hatte, entschieden wir uns, es mit Agile zu versuchen. Bei der agilen Softwareentwicklung evolvieren Anforderungen und Lösungen durch die Zusammenarbeit funktionsübergreifender Teams. Agile motiviert zu häufigen Kontrollen, Teamarbeit und Verantwortung und dazu, die Entwicklung an den Kundenbedürfnissen und Unternehmenszielen auszurichten. Letzteres hatten wir bereits durch den Einsatz unserer  My BigIdea-Plattform, die Customer Success Foren und die jährlichen BigIdeas-Benutzerkonferenzen, bei denen wir unsere Produktplanung bekanntgeben und Kunden über neue Funktionen abstimmen, umgesetzt. Obwohl unser Team und die Komplexität unseres Produkts nicht gänzlich zur Scrum*-Anordnung von Agile passten, verleitete uns der versprochene Nutzen von Agile dazu, es damit zu probieren. BigMachines führte BigMachines Agile Methodology (BAM) Anfang 2009 ein.

BAM  hat uns dabei geholfen, die BigMachines 10-Versionen erfolgreich zu liefern. Zu den Vorteilen von BAM, die uns zu einem glatteren Entwicklungsprozess verhalfen, gehören:

• Konsistente Entwicklungsgeschwindigkeit über den ganzen Entwicklungszeitraum
• Alles geschieht in Sprints**, einschließlich des Entwurf, der Programmierung und Qualitätssicherung
• Hochinteraktiver Entwurfsprozess, der zu qualitativ hochwertigeren Entwürfen und transparenterer Entwicklung führt
• Flexible Umfangsplanung aufgrund messbarer Meilensteine
• Früheres Feedback, Vertriebsdemos und BETA-Versionen für interessierte Kunden
• Offener Prozess unter früherem Einbezug der Hauptbeteiligten am Entwicklungsprozess einschließlich Marketing, Kundensupport und Kundenservice
• Nicht zuletzt natürlich höhere Produktqualität, einer Begleiterscheinung des Scrum-Systems, von dem wir auch profitiert haben

Heute, etwa 2 Jahre nach Einführung dieses neuen Prozesses, ist es an der Zeit, ihn als Erfolg zu bezeichnen!

* Scrum ist ein Rugby-Begriff, der beschreibt, wie das Entwicklungsteam als Einheit zusammenarbeitet
** Sprint bezeichnet den Zeitrahmen der Softwareentwicklungsaktivität mit messbaren Zielen