Agilität ganzheitlich denken, statt nur „PS auf die Straße zu bringen“

Warum es mehr als Scrum in einem Team braucht 

In acht Jahren klassischem Wasserfall-Projektmanagement hörte ich den Spruch „jetzt die PS auf die Straße bringen“ etliche Male. Für einen ehemaligen Schumi-Fan klang das gut. Doch es fühlte sich zu einfach an, um wahr zu sein – und das war es auch. Im Folgenden beschreibe ich, warum es mehr als Scrum in einem Team braucht, damit die Geschwindigkeit bei den Kund:innen ankommt. 

Agilität, die bei den Kund:innen ankommt

Denken wir die Formel 1-Metapher weiter: Angenommen ein Logistik-Unternehmen möchte Express-Dienstleistungen anbieten und schafft sich ein Formel 1-Auto mit 950 PS an. Dieses erreicht Geschwindigkeiten von über 300 km/h. Die erfahrenste Fahrerin wird ausgewählt, den Auftrag auszuführen. Und da es gerade nicht regnet, zieht das Unternehmen die härtesten Reifen auf.  

Aus zeitlichen Gründen hielt das Unternehmen Parkplatz und Ausfahrt allerdings nicht ausreichend instand. Diese gleichen eher einer Schotterpiste als einer Rennstrecke. Wenn die Fahrerin unter diesen Bedingungen das Gaspedal ordentlich durchdrückt, wirbelt viel Staub auf. Fortschritt erzeugt sie jedoch nicht.  

Erfahrungswerte 

Als Scrum Master erlebte ich bei einem Kunden, dass ein Team eine Webanwendung vorbildlich nach Scrum Guide entwickelte. Alle Scrum-Zeremonien erfüllten sie pflichtbewusst. An den Wänden im Büro hingen Flipcharts, beispielsweise mit einer unterschriebenen *Definition of Done.  

Das Problem: Obwohl dieses Team der Fachabteilung neue Funktionen oder Veränderungen am Ende jeden Sprints vorführte, kamen Änderungen nur drei Mal im Jahr bei den Kund:innen an. Das Team war auf die Releasezyklen der Gesamtorganisation angewiesen – und das verzögerte den Prozess enorm. Zusätzlich schnitten sie die *User Stories aus einem umfangreichen Fachkonzept heraus. Dadurch war es sehr herausfordernd, kleine *Inkremente abzuleiten. Mit viel Mühe und enger Zusammenarbeit mit dem Fachbereich konnten wir größere Inkremente schneiden und mit anderen Services aus der übrigen Organisation zusammen releasen.  
Hinzu kam, dass es zu diesem Zeitpunkt noch keine umfassenden Integrationstests gab. Oberflächenfunktionen testeten die Fachabteilungen manuell. So folgten nach einer harten Integrationsphase zwei Sprints, deren Ziel die Fehlerbehebungen war. Denn: Manche Irrtümer kamen erst im Produktivsystem zum Vorschein. Wir sind heute dabei den Kunden darin zu unterstützen, automatisierte Tests zu schreiben und Voraussetzungen für automatisierte Auslieferung zu schaffen. 

Resümee

Mit der Formel 1-Metapher und dem Kundenbeispiel möchte ich verdeutlichen, was wir für echte Agilität benötigen. Beim Rennsport braucht es mehr als viel Leistung im Motor. Nämlich die passenden Reifen für die aktuelle Wetterlage und eine gute Rennstrecke als Untergrund. Darüber hinaus sind eine geschulte Fahrerin sowie ein eingespieltes Boxenstop-Team, das seine Handgriffe beherrscht, entscheidend. 

Das bedeutet in Bezug auf Agilität: Es braucht mehr als ein Entwickler:innenteam, das nach Scrum Guide arbeitet. Es bedarf genau formulierter fachlicher Anforderungen, die den Kund:innenwert deutlich machen. Weiterhin ist es notwendig, dass das Management dem Team vertraut. Konstruktives Feedback von Kund:innen und technisches Know-How sind relevant, damit fertiggestellte Software-Inkremente schneller und regelmäßiger ausgeliefert werden können. Auch die Fehlerkultur ist maßgeblich: Die Bereitschaft, aus Fehlern zu lernen, ist unverzichtbar. 

Ganzheitliche Beratung 

In Unternehmen muss das tägliche Geschäft weiterlaufen. Es kann nicht alles gleichzeitig auf agil “umgekrempelt” werden. Daher braucht es in all diesen Themenfeldern viel Erfahrung und Fingerspitzengefühl: Wir als Expert:innen-Team schauen mit einem Rundumblick darauf, was es wirklich braucht. Davon profitieren unsere Kund:innen, auch wenn sie nur einen einzelnen Experten oder eine Expertin von Conciso für ein spezifisches Problem beauftragen. 

Bei Conciso verstehen wir Agilität ganzheitlich. Uns ist wichtig: 

• Anforderungen aus drei Dimensionen (Kund:in, Unternehmen, Produkt) nach enbl.it Methode zu beschreiben 
• Architekturen zu liefern, die den Anforderungen der Kund:innen und Organisationen gerecht werden 
• sauberen, lesbaren Code zur Verfügung zu stellen, damit dieser langfristig wartbar bleibt 
• automatisierte Tests, um die Qualität des Produkts sicherzustellen  
• Wertschätzung für die geleistete Arbeit und konstruktives, lösungsorientiertes Feedback zu geben 
• gemeinsam zu lernen und die Arbeitsweise zu verbessern  
• Produkte in kleinen Schritten zu entwickeln, um zeitnah Mehrwert und Kund:innenfeedback zu ermöglichen 

Dies sind die Kernpunkte unserer agilen Arbeitsweise und die unseres Beratungskonzepts.  

Vereinbare gerne ein unverbindliches Beratungsgespräch mit uns, wenn auch Du mehr Agilität in eurer Produktentwicklung erleben möchtest.  

Glossar:

*Definition of Done: 
Die Definition of Done: DoD ist eine Vereinbarung zwischen dem Entwicklungsteam und dem Product Owner oder der Product Ownerin. Sie beschreibt die Erfüllungskriterien für alle umzusetzenden Anforderungen. Ziel ist es, eine gleichbleibende Qualität der Ergebnisse sicherzustellen. 

*Inkrement: 
Ein Softwareinkrement ist eine funktionierende Anwendung, die nur einen Teil der Anforderungen umsetzt. Mit jedem Inkrement kommen neue Funktionen hinzu oder es werden bestehende Funktionen erweitert. Das ermöglicht es Kund:innen schon frühzeitig die Anwendung im realen Einsatz zu verproben und bestenfalls sogar schon wirtschaftlichen Mehrwert zu generieren – noch bevor alle Anforderungen fertiggestellt sind. 

*User Story: 
Eine User Story ist eine Anforderung an die Anwendung. Sie beschreibt aus Kund:innensicht den gewünschten Mehrwert.