Lesson learned Zehn Jahre agil – das wurde teuer!

Vor rund zehn Jahren führte der Berliner Softwarehersteller microTOOL GmbH mit großer Begeisterung agile Software-Entwicklung ein. Die geschäftsentscheidenden Produkte des Hauses wurden zunächst mit eXtreme Programming, später mit Scrum entwickelt. Die Erfolge bestätigten diesen Schritt, aber nach sieben Jahren stellte sich heraus, dass die Produktqualität auf diese Weise nicht zu gewährleisten war. Ursula Meseberg beschreibt, wie es microTOOL gelang, mit durchgreifenden Veränderungen, sowohl beim Entwicklungsprozess als auch beim Projektmanagement, die Vorteile agiler Software-Entwicklung mit hohen Qualitätsstandards und wirtschaftlichem Erfolg zu verbinden.

 

Download PDFDownload PDF

Lesson learned Zehn Jahre agil – das wurde teuer!

Vor rund zehn Jahren führte der Berliner Softwarehersteller microTOOL GmbH mit großer Begeisterung agile Software-Entwicklung ein. Die geschäftsentscheidenden Produkte des Hauses wurden zunächst mit eXtreme Programming, später mit Scrum entwickelt. Die Erfolge bestätigten diesen Schritt, aber nach sieben Jahren stellte sich heraus, dass die Produktqualität auf diese Weise nicht zu gewährleisten war. Ursula Meseberg beschreibt, wie es microTOOL gelang, mit durchgreifenden Veränderungen, sowohl beim Entwicklungsprozess als auch beim Projektmanagement, die Vorteile agiler Software-Entwicklung mit hohen Qualitätsstandards und wirtschaftlichem Erfolg zu verbinden.

 

Wir empfehlen zum Thema Vorgehensmodell
5 Tage
12.09.2024
1,395,-
Hybrides Projektmanagement - das Beste aus 2 Welten vereinen

Lernen Sie das Wichtigste beim Einsatz von hybridem Projektmanagement, damit auch Sie in Ihrem Unternehmen das Beste aus zwei Welten kombinieren. Mehr Infos

Vor rund zehn Jahren führten wir mit großer Begeisterung bei der microTOOL GmbH, einem Berliner Softwarehersteller, agile Software-Entwicklung ein. Wir entwickelten die neue Version eines wichtigen Produkts nicht mehr nach traditionellen Vorgehensweisen wie Wasserfall oder "Command & Control", sondern mit eXtreme Programming (XP). Später führten wir Scrum ein und die Erfolge bestätigten uns in dieser Entscheidung. Noch vor drei Jahren hätte unser Erfahrungsbericht über agile Software-Entwicklung deshalb den Titel "Sieben Jahre agil – das hat sich gerechnet" getragen.

In den letzten drei Jahren wandelte sich jedoch unsere ursprüngliche Begeisterung in eine sehr differenzierte und kritische Sichtweise. Wir mussten lernen, dass eine rein agile Vorgehensweise langfristig betrachtet erhebliche Gefahren für die Qualität des Produkts birgt. Die Konsequenz hieß für uns allerdings nicht, zu den alten Methoden zurückzukehren, sondern Scrum so zu modifizieren, dass einheitliche Qualitätsstandards gewährleistet sind. Im Folgenden schildern wir unsere Erfahrungen mit agiler Software-Entwicklung und beschreiben unsere Lösung für das Dilemma zwischen Agilität und Produktqualität.

Ausgangspunkt: die Werte unserer Unternehmenskultur

Das mittelständische Unternehmen microTOOL ist auf die Entwicklung von Software-Werkzeugen für Requirements Engineering sowie integriertes Projekt- und Anforderungsmanagement spezialisiert. Vier grundlegende Werte prägen unsere Unternehmenskultur und damit auch unsere Vorgehensweisen bei Produktentwicklung und Projektmanagement:

Vertrauen der Kunden und Anwender

Wie bei allen Softwareproduzenten ist auch für uns das Vertrauen, das Kunden und Anwender uns entgegenbringen, ein zentraler Wert. Dieses Vertrauen zahlt sich letztlich in Lizenz-, Wartungs- und Dienstleistungsumsatz aus.

Qualität von Architektur und Code

Um Vertrauen zu gewinnen und dauerhaft zu erhalten, ist eine hohe Qualität der Software-Produkte unverzichtbar. Für uns spielt bei der Qualität von Architektur und Code die Erweiterbarkeit eine besondere Rolle. Durch sie haben wir den entscheidenden Wettbewerbsvorteil, kundenspezifische Anpassungen und Erweiterungen unserer Produkte anzubieten zu können.

Wissen und Erfahrung

Um Software mit hoher Qualität zu entwickeln, braucht man das Wissen und die Erfahrung von Mitarbeitern. Da Mitarbeiter wechseln, ist es notwendig, das Wissen im Unternehmen auch personenunabhängig zu halten. Dafür verwenden wir unter anderem ein Firmenwiki und Entwickler-Blogs. Aber dokumentiertes Wissen droht immer zu veralten. In den Algorithmen zur automatisierten Softwareproduktion steckt das Knowhow über die technische Architektur unserer Produkte, dies ist das wertvollste Wissen von microTOOL.

Kultur des Miteinanders und Soft Skills

Und schließlich ist für jedes Unternehmen die Kultur des Miteinanders wichtig: Wie wird kommuniziert? Wie werden Lösungen entwickelt? Wie löst man Konflikte? Wie geht man mit Krisen um? Brainstorming, moderierte Meetings zur Problemlösung, Software-Entwurf-Sessions im Team mit Metaplantechnik, Mediation bei Konflikten – das alles ist in der Unternehmenskultur von microTOOL heute verankert.

Diese vier Werte sind eng miteinander verknüpft. Wenn nur einer ins Wanken gerät, so sind unweigerlich auch die anderen gefährdet. Diese Werte haben unseren Weg stark beeinflusst, den wir mit der agilen Software-Entwicklung gegangen sind.

Erste Begegnung mit agilen Konzepten: XP vs. V-Modell

Im Jahr 2002 starteten wir ein Projekt mit dem Ziel, eine unterstützende Software für den Einsatz des V-Modells 97 zu entwickeln. Das V-Modell ist der deutsche Entwicklungsstandard für IT-Vorhaben der öffentlichen Hand – in der Version V-Modell 97 folgt es dem traditionellen Wasserfallmodell. Das derzeit aktuelle V-Modell XT erschien 2005 und enthält auch agile Vorgehensweisen.

Für die Entwicklungsteams war der Ansatz des V-Modells plausibel, so dass eine einheitliche und standardisierte Vorgehensweise bei der Software-Entwicklung die Qualität der Entwicklungsergebnisse verbessert. Aber alle waren sich darin einig, dass für Teamgrößen von drei bis zehn Entwicklern das V-Modell 97 ungeeignet ist, da es für große Projekte mit Auftraggeber und Auftragnehmer gedacht ist.

Alle Kommentare (5)

Guest

Grundsätzlich würde ich mal formulieren: Wenn Scrum streng nach Lehrbuch implementiert worden wäre, wäre es nicht zu dieser Situation gekommen. Restrospektiven alle halbe Jahre zu machen und nicht darauf zu achten, daß der Scrum Master als Ergänzung zum Product Owner seine Aufgabe vollständig wahrnimmt, um im Sinne der Geschäftsleitung zu handeln, hätte deulich früher auffallen können. Es ist keine schlechte Idee, modellgetrieben vorzugehen und den Architekturansatz zu forcieren, aber mir fehlt da ganz klar der Ansatz dieses Wissen kontinuierlich im Team zu verankern. Da wird ein Tool als Lösung für ein Mindset-Problem gewählt. Wer hat sich in der Vergangenheit darum gekümmert, daß das Entwicklungsteam modernen Entwicklungsstandards folgt? Gab es keinen Know-How-Träger, der das fehlende Architekturwissen ins Team getragen hat? Die Argumentation, daß der Product Owner in die Autonomie des Teams eingreifen muß, zeigt, daß das Team noch immer nicht in die Lage versetzt worden ist, den "Business Value" zu leben. Damit gehen aber Effizienzpotentiale verloren. Die überschrift halte ich auch für sehr unglücklich gewählt. Hier wird suggeriert, daß Agilität im Sinne des Lehrbuchs die Kosten verursacht hätte. Das geben die Details im Text so aber nicht wieder ;-).

 

Ursula
Meseberg

Hallo Herr Eschen, danke für Ihre kritischen Anmerkungen. Aus heutiger Sicht stimme ich Ihnen zu: Wir haben sicher Fehler gemacht bei unserer Interpretation des Lehrbuchwissens über Scrum. Wir hätten uns früher und in kürzeren Abständen auf Retrospektiven einlassen sollen. Aber wir waren uns – trotz der Begeisterung im Team – unsicher, wie viel Innovation wir den Mitarbeitern zumuten konnten. Bitte beachten Sie auch den zeitlichen Scope: 2007, als wir mit Scrum begannen, gab es in Deutschland nur eine Handvoll Scrum-Trainer. Heute würden wir uns vermutlich einen erfahrenen Coach ins Team holen, der es in der Scrum-Einführungsphase begleitet. Dass die Softwarearchitektur im Team, beim Scrum Master und sogar beim Product Owner nach und nach an Wert verlor und an ihre Stelle der funktionale Zuwachs und der reine funktionale Nutzen für den Anwender traten, hat sicher auch mit dem Erfolg zu tun, den das Team damit über mehrere Jahre hatte. Wir waren damals sehr stolz auf das Team und die Geschwindigkeit, mit der es Kundenanforderungen umsetzte. Den Preis haben wir dann ja bezahlt. Mit dem Blick auf heute: Es ist nicht so, dass wir eine Tool-Lösung benutzen, um ein Mindset-Problem zu lösen. Mit der maschinell unterstützten Entwicklungstechnik, die wir heute praktizieren, hat sich bei den Entwicklern ein neues Bewusstsein für Architektur und Standards durchgesetzt. Die Entwicklung einer Komponente beginnt immer mit einem Entity-, Service- und View-Modell. Typisch sind dabei Überlegungen im Team wie diese: „Müssen wir diese Services wirklich manuell implementieren? Das Risiko uneinheitlicher Lösungen ist doch viel zu hoch. Wollen wir dafür nicht eine Modelltransformation entwickeln?“ Hier hat das Team nicht nur eine gemeinsame Verantwortung für den Code entwickelt, sondern auch für die Architektur, die Standards und die Entwicklungstechnik. So soll’s doch sein? :-)

 

Guest

Liebe Frau Meseberg, ich finde es großartig, dass Sie hier von ihren Erfahrungen berichten. Mich beeindruckt, wie sie ihre Fehler benennen und auf diese reagiert haben. Das hier mit einer "Community" (oder wie immer man das nennen mag) zu teilen, das ist für mich agil im besten Sinne. Ich denke die Anmerkungen von Herrn Eschen sind berechtigt. Ihre Antwort auf die Anmerkungen hat die "Geschichte" für mich noch besser nachvollziehbar gemacht. Als Titel hätte ich mir vielleicht etwas wie "10 jahre agil - Fehlern erkennen und zur Prozessoptimierung nutzen" gewünscht. Egal ;) Beste Grüße

 

Ursula
Meseberg

Lieber Herr Sellner, vielen Dank für Ihre netten Worte. Ich muss zugeben, dass der offene und „öffentliche“ Umgang mit unseren Fehlern mir anfangs nicht leicht fiel. Natürlich erzählt man lieber reine Erfolgsgeschichten. Aber ein echter Erfahrungsaustausch, von dem alle Beteiligten profitieren, kommt nur zustande, wenn man auch über Fehler spricht. Das durfte ich in der Zeit nach der Veröffentlichung des Artikels mehrfach erleben. Ihr „Alternativtitel“ gefällt mir, denn Prozessoptimierung ist das Ziel, das wir in den vergangenen zehn Jahren verfolgt haben – und noch immer verfolgen. So beschäftigt uns zurzeit der Zuschnitt der Rolle des Product Owners. Aber das ist ein anderes Thema ... Beste Grüße.

 

Guest

Super-Artikel. Sollte allen Leuten, welche Agil als "Silver Bullet" gegen alle Probleme sehen, als Pflichtlektüre empfohlen werden. Agile ist eine Super-Sache, aber auch hier gelten gewisse Regeln.