Schlagwortarchiv für: Agile

Reduzieren von Technical Debt in SAFe®

Technische Schulden sind der Fluch eines jeden modernen (und nicht so modernen) IT-Produkts. Wie bei einem faulen Kredit hat man Mühe, die Zinsen zurückzuzahlen, geschweige denn die Schulden zu tilgen. 

Technical Debt nimmt viele heimtückische Formen an, wie z. B. fehlende Testautomatisierung, veraltete Dokumentation, ineffizienter Code, veraltete Architektur und Sicherheitsschwachstellen aus alten Technologien. Und es interessiert die Stakeholder meistens erst dann, wenn sie beginnen die schlechte Leistung oder die lange Entwicklungsdauer und damit steigende Kosten neuer Funktionen zu hinterfragen.  Oft erreicht man den Punkt, an dem die Kosten für den Austausch des systemkritischen Produkts geringer sind als das Risiko, weitere Änderungen vorzunehmen. Muss das so sein?

Ist das auch für Agile Coaches relevant? Aus meiner Sicht absolut, da wir alle Rahmenbedingungen berücksichtigen müssen, um einen effektiven Agile Release Train oder auch ein einzelnes Team zu coachen. Oft müssen erst die technischen Hausaufgaben erledigt und die technischen Rahmenbedingungen geschaffen werden, bevor man tatsächlich iterativ inkrementell entwickeln kann. Im schlimmsten Fall beschleunigt man sonst sogar den Aufbau von technical Debt. 

Technischer Schuld vorbeugen

Wenn wir heute in klassischen Organisationen damit beginnen in kurzen Zyklen zu arbeiten — sei es ein einzelnes Scrum – oder mehrere agile Teams, die mit SAFe® arbeiten —so wird eine Kernkompetenz des Scaled Agile Framework oftmals unterschätzt: „Team and Technical Agility“.

Bereits in Scrum spricht man am Ende eines Sprints von einem „Potentially Releasable Increment“. Das heißt, dass die Teams nach 2-4 Wochen ein Stück Software bereitstellen, das so gute Qualität hat, dass man es potentiell releasen kann ohne dafür noch einen „Hardening“-Sprint (Antipattern) oder Release-Phasen von 6 Wochen zu benötigen.

In SAFe existiert hierfür die System Demo, die alle zwei Wochen eine über alle Teams integrierte Lösung bereitstellt. Das erhöht natürlich die Qualitätsanforderungen nochmals. Der Spruch „you can’t scale crappy code“ trifft es ziemlich genau.

Nur wenn wir dem Konzept von Built-In-Quality rigide folgen, können wir in so einer Geschwindigkeit liefern, sonst erhöhen sich die technischen Schulden noch viel rascher als in einem klassischen Vorgehen.

Quelle: Scaled Agile

Konkret benötigt jedes agile Team heutzutage folgende Skills, für die das Scaled Agile Framework auch jeweils aussagekräftige  tiefgehende Artikel zur Verfügung stellt:

  • Agile Architecture, die Software-Architektur muss zulassen, dass Systeme über die Zeit wachsen und sich verändern
  • Agile Testing, ein test-first Ansatz, der weit darüber hinaus geht, nur über „Unit Tests“ zu sprechen.
  • Behaviour-Driven Development (BDD): Ein weiterer Aspekt des agilen Testens, bei dem es darum geht System-Verhalten zu beschreiben und automatisiert zu testen.
  • Test-Driven Development: Test schreiben, alle Tests laufen lassen, danach nur so viel Code schreiben, dass der Test grün wird und erst danach Refactoring anwenden, wenn benötigt.
  • Refactoring: Der Quellcode und das System werden kontinuierlich auf Basis der neuen Anforderungen angepasst und erweitert. Auch dies erfordert, dass das System diese Veränderung zulässt und wir eine ausreichende Testabdeckung vorliegen haben, um sicherzustellen, dass man nichts durch dieses Refactoring zerstört hat.
  • Spikes: Oft versucht man eine Story fertig zu machen, auch wenn noch zu viele technische Risiken dahinterliegen. SAFe® bietet hierfür das Konzept der „Enabler“, die künftige Story Umsetzung ermöglichen („enablen“) sollen. Ein Spike ist eine konkrete Ausformulierung eines Enablers um vorab wichtige Experimenten durchzuführen, sodass das Risiko mitigiert wird.

All diese Kompetenzen werden heute von „Software Engineers“ erwartet, die mehr sind als nur „Coder“. Wenn wir agil arbeiten und zum Beispiel ein Stream Aligned Team aufsetzen möchten, dann benötigen wir hochqualifizierte Engineers, die genau diese Praktiken verstehen und umsetzen. 

Von Agile Coaches und Scrum Mastern erwarten wir heutzutage umfangreiches Wissen über diese Praktiken, sonst fehlt ein wesentlicher Teil des Coachings.

Nur so vermeiden wir technische Schuld und vor allem auch den raschen Aufbau technischer Schuld über agile Vorgehensweisen.

Strategie für bestehende Technische Schuld 

Gratulation, Sie haben technische Schulden? Ab jetzt haben Sie die Wahl zwischen einer teuren Lösung um neue Funktionalität hinzuzufügen oder einer günstigen „Augen zu und durch“ Variante. Zweite Lösung wird leider oft präferiert und führt nur zu noch mehr technischen Schulden.

Was sind die meisten Gründe für technische Schulden?

In einem Artikel von DZone wird eine Studie des Software Engineering Institute erwähnt, die 1319 Entwickler gefragt hat, was aus Ihrer Sicht die Gründe dafür sind:

Quelle: DZone

Deckt sich diese Beobachtung mit ihrer Wahrnehmung? Was sind bei Ihnen die Gründe? Schlecht qualifizierte Entwickler, die von sich aus den Shortcut über der guten Lösung wählen? Markt-Druck? Druck vom Fachbereich, der mehr Features will und kein Verständnis für refactoring hat? Falsche Architektur?

Erster Schritt: Technical Debt transparent und quantifizierbar machen

Ein Technical Debt Backlog kann dabei helfen konkret quantifizierbar und messbar zu machen, wie viel Aufwand bereits in die Beseitigung von technischen Schulden geht.

Capacity Allocation

Planen Sie in jedem Fall eine gewisse Kapazität Ihres Backlogs dafür ein, „Enabler“ Stories ohne Diskussion machen zu können.

So vermeiden Sie unnötige Diskussionen mit dem Fachbereich oder den Business Stakeholdern warum gewisse technische Dinge getan werden müssen. 

Wenn die benötigte Kapazität zu hoch wird kann man dann auch darüber diskutieren, warum das geschieht. Also auch hier gilt es, transparent zu sein und ständig zu beobachten ob zum Beispiel Bugs und die Behebung von technischen Schulden verhältnismäßig die Überhand übernimmt gegenüber Neuentwicklungen.

Just do your Job as an Engineer

Eine sehr persönliche Meinung von mir als Agile Coach und ehemaliger Software Engineer ist, dass es in der Verantwortung jedes Entwicklers und Team-Mitglieds liegt gute Qualität zu liefern und nicht zu viele Kompromisse einzugehen. Jeder Entwickler ist der Experte für seinen Job. Das Team an sich benötigt ein gut abgestimmtes Qualitäts-Verständnis und ist in der Verantwortung dies auch durchzusetzen. Leider lassen die Teams oft zu schnell zu, dass man Kompromisse und Shortcuts in der Qualität eingeht. 

Conclusio

Technical Agility ist ein Kernkonzept in SAFe. Mit einem Test-First Mindset, verhindert SAFe den Aufbau von mehr Technical Debt und unterstützt proaktiv den Abbau von Technical Debt.

Gleichzeitig fördert SAFe über die Kombination von IT- und den für Business verantwortlichen Rollen auf allen Ebenen den ständigen Dialog auf Augenhöhe. IT ist nicht der “Lieferant” für Business. Wir sitzen alle im gleichen Boot. Stellen wir sicher, dass es gut schwimmt. 😉

Nur unsere Newsletter Abonnenten bekommen alle Artikel!

Bleiben Sie Up2Date mit unseren Interviews und Artikeln zu Agile Transformation. Für Agile Experts, Change Leader, Digital Transformation Experts.

Solution Focus: Fragen Sie nach der erwünschten Zukunft und nicht nach den Problemen

Als Agile Coach bin ich öfter mit Rahmenbedingungen konfrontiert, die Personen oder ganze Teams daran hindern, konstruktiv und zielgerichtet zusammenzuarbeiten. Dadurch verursachte Irritationen sind nicht nur im Team selbst spürbar. Auch die Führungspersonen bemerken, dass in Ihrem Bereich etwas nicht rund läuft.  

Die Probleme können in unterschiedlichsten Bereichen angesiedelt sein. Hier nur einige Beispiele: 

  • Fehlende, unklare oder widersprüchliche Zielvorgaben für Teams 
  • Missverständnisse bei der operativen Zusammenarbeit  
  • Äußere Abhängigkeiten, die schwer adressiert werden können

Die betroffenen Teams oder auch einzelne Personen beschäftigen sich häufig sehr intensiv mit diesen Problemen. Sie versuchen, sie bis ins letzte Detail zu analysieren und zu verstehen, damit sie dann endlich eine Lösung dafür finden können. Diese Problemanalyse nimmt viel Zeit in Anspruch.

Mit Solution Focus stellen Sie die Lösung in den Mittelpunkt!

Typisch für lösungsfokussiertes Arbeiten ist ein starker Fokus auf die erwünschte Zukunft. Dafür werden alle bereits existierenden Ressourcen genutzt. Es werden positive Unterschiede betrachtet und analysiert, was genau funktioniert unter welchen Bedingungen bereits gut. Mit kleinen, schnell greifbaren Veränderungen wird ein konkret formuliertes Ziel angesteuert.  

Dem Problemfokus und damit  auch der Problemanalyse wird keine Aufmerksamkeit geschenkt.  „Der Lösung ist egal, wie das Problem entstanden ist“ (Insoo Kim Berg). Gemäss dieser Denkweise nutzt man im Solution Focus das simple und zugleich unheimlich kraftvolle Werkzeug der „Fragen und sprachlichen Interventionen“.

Die große Palette an Methoden und Tools im Solution Focus basiert fast ausschließlich auf Fragetechniken und sprachlichen Interventionen. Als Führungsperson können Sie damit u.a. folgende Veränderungen unterstützen:

  1. die Teambildung positiv beeinflussen  und die Zusammenarbeit stärken
  2. die Definition von gemeinsamen Zielen (sowie damit verbundene erkennbare Kriterien für die Zielerreichung) fördern
  3. die Veränderungsprozesse in der Organisation (Change Prozesse) sinnvoll begleiten und gestalten
  4. die rasche Überwindung von Krisen begünstigen.

Hier einige wirkungsvolle Anregungen für die Formulierung Ihrer Fragen im Business Kontext:

  • Offene Fragen laden Ihre Gesprächspartner ein, ihre Gedanken mit Ihnen zu teilen. Versuchen Sie statt „Denkt ihr, wir bekommen das hin?“ oder gar „Denkt ihr, ihr bekommt das hin?“ einfach mal „Wie können wir das gemeinsam hinbekommen?“. Oder statt „Können wir den Zeitplan halten?“ die Frage „Wie können wir den Zeitplan halten?“ 
  • Setzen Sie gerichtete und ungerichtete Fragen bewusst ein.
    • Verwenden Sie gerichtete Fragen, um möglichst konkrete und auch verbindlichere Antworten zu erhalten. Zum Beispiel statt einem „Was müsste man besser machen?“ ein „Was könnt ihr zur Verbesserung beitragen?“. Oder statt „Kann der Zeitplan gehalten werden?“ die Frage „In welchem Zeitraum könnt ihr es schaffen?“ 
    • Verwenden Sie ungerichtete Fragen, um eine Vielzahl an Ideen zusammenzutragen und die Anzahl an Antworten zu erhöhen. Ungerichtete Fragen fördern die Kreativität, und erst in einem zweiten Schritt wird aus den möglichen Optionen gewählt, was am wirkungsvollsten in der jeweiligen Situation erscheint. Statt „Wie könnt ihr das lösen?“ ein „Wie könnte man das lösen?“. Oder statt „Wieso ist die Performance so schlecht?“ die Frage „Wie könnte man die Performance verbessern?“ 
    • Fragen Sie nach Ausnahmen. Kein Problem tritt ohne Unterbrechungen auf, fragen Sie nach positiven Unterschieden. In den positiven Unterschieden sind oft erste Lösungsmöglichkeiten begründet. Hören Sie zum Beispiel „Nie schaffen wir das, was wir uns vorgenommen haben.“, dann fragen Sie „Wirklich nie? Wann ist es euch doch einmal gelungen? Und was war da anders?“. Sagt man zu Ihnen „Immer kommt X zu spät.“ dann fragen Sie „Wirklich immer? Wann ist X mal pünktlich gewesen? Wie ist es dazu gekommen, dass X da pünktlich sein konnte?“ 

Mit diesem Beitrag leiten wir eine Blog Post Serie ein, die Führungspersonen, Agile Coaches und Scrum Mastern nützliche Ideen für die tägliche Arbeit liefern soll.

Von „Doing Agile“ zu „Being Agile“

Bleiben Sie Up2Date mit unseren Interviews und Artikeln zu Agile Transformation. Für Agile Experts, Change Leader, Digital Transformation Experts.

SAFe in Österreich: Eurofunk Kappacher

Bei diesem Meetup berichtete Martin Jörg von Eurofunk Kappacher von der SAFe Transformation, die mit einem Release Train gestartet hat und mittlerweile bei drei Release Trains angekommen ist. Organisiert wurde das Meetup von Susanne Bauer (Kegon AT) und mir.

Dabei hat Martin Jörg folgende Themen behandelt:

  • Warum haben wir uns für SAFe entschieden? 
  • Was waren die Probleme, was haben wir uns davon versprochen?
  • Wie hat SAFe in die Organisation skaliert?
  • Wo hat Eurofunk jetzt noch Verbesserungspotential?

Eurofunk Kappacher ist Marktführer für Leitstellentechnik im deutschsprachigen Raum und wächst stetig. Hier wurde auf das Scaled Agile Framework gesetzt.

Ausgewählte Highlights aus der Diskussion:

  • Das Framework hat uns geholfen, viele Dinge auch nicht diskutieren zu müssen, weil viele Prozesse und Rollen dokumentiert sind. Das hat den Start vereinfacht.
  • Das schwierigste war die Cross funktionalen Teams zu bilden, um von Silo Teams wegzukommen.
  • Durch das Framework verbessern sich laufend unsere Prozesse. Die Dokumentation der Prozesse hat uns die ISO 9001 erleichtert.
  • Wir haben es geschafft, kürzere Feedbackzyklen aufzubauen, was einen positiven Impact auf unsere Produkte hat.

Mit unserem Leading SAFe® 5.1 Training können Sie von erfahrenen Experten lernen wie Sie Fähigkeiten zur Unterstützung und Durchführung von PI Planning Events, Koordinierung mehrerer Agile Release Trains (ARTs), Anwenden der Prinzipien aus den Bereichen Lean, Systemdenken, agile Entwicklung und vieles mehr.


Lassen Sie uns weitersprechen!

Sie wollen mehr zum Thema Leading SAFe erfahren? Sie wollen in Ihrem Unternehmen ein Umfeld entwickeln, um die Arbeit nach agilen Methoden zu ermöglichen?

Kontaktieren Sie mich:

Richard Brenner
Agile Coach bei TechTalk
richard.brenner@techtalk.at


Business Agility Dialogue mit Erste Bank CEO Peter Bosek (Teil 2/2)

Im TechTalk Business Agility Dialogue durchleuchten wir kritisch die Themen Agilität und Transformation in großen Organisationen mit deren hochkarätigen Vertretern. Wir werfen einen Blick auf die wichtigsten Stolpersteine und Learnings mit Agile Change Leadern.

Im ersten Teil des Interviews haben wir mit Peter Bosek (CEO Erste Bank and Chief Retail Officer Erste Group) über die Kernelemente des Erfolges von George, die Herausforderungen ein innovatives Produkt wie George zu entwickeln und dieses letztendlich in bestehende Strukturen zu integrieren, gesprochen.

Im zweiten Teil dieses Business Agility Dialogues sprechen Richard Brenner, Agile Coach bei TechTalk und Erste Bank CEO Peter Bosek über die Zukunft der Agilität.

Wir befinden uns in einer Krise die einiges verändert hat. Diese Krise triggert ein Verhalten, welches wir oft bei Agile Methoden auch hervorrufen möchten. Teams beginnen cross-functional zu arbeiten, um mit einem klaren Ziel aus dieser Krise zu kommen. Ist das ein Treiber für erfolgreiche Initiativen? 

Nur unsere Newsletter Abonnenten bekommen alle Artikel!

Bleiben Sie Up2Date mit unseren Interviews und Artikeln zu Agile Transformation. Für Agile Experts, Change Leader, Digital Transformation Experts.

Selbstorganisation und Verantwortung in der agilen Welt – Müssen jetzt alle Häuptlinge sein?

Im Rahmen des agilen Arbeitens erhält Selbstorganisation einen sehr hohen Stellenwert und damit auch die Rolle der Verantwortung. Man möchte weg von einer HiPPO-Entscheidung (Highest Paid Persons Opinion) oder dem LVD (loudest voice dominates) hin zu einer Entscheidung, die dort getroffen wird, wo die Information liegt, die notwendig ist, die beste Entscheidung zu treffen (siehe auch Intent-Based Leadership). 

Bei agilen Transformationen und bei neu aufgestellten Agilen Teams kommt es bei dieser Neuverteilung der Entscheidungskompetenz manchmal zu Widerständen. Es gibt Ängste für Fehlentscheidungen verantwortlich gemacht zu werden und eine Unsicherheit aufgrund der neuen „Last“, die die neue Verantwortung mit sich bringt.  

Es stellt sich die Frage – „Inwiefern müssen alle Menschen selbstbestimmt sein und Verantwortung übernehmen?“. Diese Frage stellte Markus Knopp im Rahmen einer Open Space Session der Freiräume Unkonferenz, die Mitte November stattfand. Aus dieser Session möchte ich zwei Erkenntnisse teilen.  

Räume aufmachen und Räume schließen 

Es ist wichtig, v.a. in der Rolle als Scrum Master, Agile Coach oder Führungskraft, zu reflektieren welche Freiräume offen sind und wo es hilft einzelnen Personen und dem Team diese auch wieder zu schließen. Beispiele für das „Schließen“ von Freiräumen sind z.B. das detailliertere Vorgeben von Regeln und Rahmenbedingungen oder Entscheidungen für das Team (vorläufig) treffen. Das Schließen von Räumen kann helfen den Fokus auf ein Thema zu lenken und dem Team oder Einzelnen auch Schutz und Sicherheit zu geben, um voran zu kommen. 

Ein Beispiel aus der Praxis: Es kann den Mitarbeitern helfen einen Fokus in der Weiterbildung zu treffen, wenn eine strategische Technologieentscheidung im Unternehmen klar getroffen und kommuniziert wird.  

Für die Gestaltung und Diskussion dieser Freiräume, z.B. in Bezug auf ein Team, gibt es auch methodische Möglichkeiten zum Beispiel mit dem Delegation Poker, um Verantwortlichkeiten zu diskutieren, sichtbar zu machen und zu vereinbaren.  

Das Team als wichtiges Element in der Selbstorganisation 

Ein weiterer wichtiger Kernpunkt in der Diskussion war auch, dass die Verantwortlichkeit und Selbstorganisation nicht auf individueller Ebene betrachtet und gefordert werden soll, sondern dass dies auf Teamebene betrachtet wird.  

 „The best architecturesrequirements, and designs emerge from self-organizing teams.“ (Agile principle) 

Dabei ist es sinnvoll, das Team als eine Einheit zu betrachten – die einzelnen Individuen in diesem Team sind dann mehr oder weniger selbstorganisiert, sind diverse Persönlichkeiten und ergänzen sich im Idealfall gut. In einem Teamgefüge ist es sogar wünschenswert, dass nicht alle Personen Häuptlinge sind.  

Die Conclusio für uns zur Selbstorganisation und Verantwortung war: Das Team ist selbstorganisiert und verantwortlich, und nicht das Individuum. Das Team trägt das Individuum mit. 

„Für eine wirklich gelungene Veranstaltung braucht man sowohl Bühnenmenschen als auch Publikum.“ (Zitat Teilnehmerin im Open Space) 

Und manchmal muss die Selbstorganisation auch über eine Teamgrenze hinaus betrachtet werden, vor allem, wenn Teams zusammenarbeiten bzw. Abhängigkeiten haben. Dies ist z.B. in Scrum of Scrums oder SAFe relevant. Hier spielt dann wieder das Öffnen und Schließen von Räumen eine Rolle, denn es kann nicht jedes Team völlig unabhängig von anderen Teams selbstorganisiert Entscheidungen treffen, sondern es müssen klare Verantwortlichkeiten und Entscheidungsrahmen vorhanden sein. 

Von „Doing Agile“ zu „Being Agile“

Bleiben Sie Up2Date mit unseren Interviews und Artikeln zu Agile Transformation. Für Agile Experts, Change Leader, Digital Transformation Experts.

Für einen tiefergehenden Austausch stehen meine Coach-Kollegen gerne zur Verfügung. Mehr zur Stärkung der Verantwortung im Team durch eine neue Art des Leadership gibt es auch im Rahmen des Intent-Based Leadership Trainings von Jenni Jespen. 

Weiterführende Literatur:  

4 Mythen über agile Software Wartung, denen Sie keinen Glauben schenken sollten

„Wir können nicht agil arbeiten, wir machen nur Wartung!“ – Kommt Ihnen diese Aussage bekannt vor?

Finden Sie heraus, wie Sie mit den dahinterstehenden Annahmen aufräumen können und wie Sie mit einer agilen Arbeitsweise in der Wartung Ihre Geschäftsziele leichter erreichen.

Mythos 1: die ideale User Story

Das Team sagt: „Wir können nicht mit User Stories arbeiten, weil wir Issues zur Bearbeitung bekommen und kaum Features entwickeln.“ 

Egal, ob Sie in Ihrem Team von Issues, Fehlermeldung oder Bugs reden: Dieses Argument ist auf eine Idealvorstellung einer User Story zurückzuführen, die in den Schulungen vermittelt wird. Tatsächlich ist es auch bei laufender Software sinnvoll, Anforderungen nach den INVEST Kriterien zu formulieren, um sicherzustellen, dass sie effizient und effektiv umgesetzt werden können. 

Was sind die Besonderheiten der INVEST Kriterien in der Softwarewartung?

  • Independent: Die meisten Issues zu laufender Software sind unabhängig, da sie sich auf einen einzelnen Aspekt beziehen, der nicht oder nicht mehr wunschgemäß funktioniert. Wenn der Issue komplexer ist, spricht alles dafür, ihn in unabhängige Backlog Items aufzuteilen, damit die Umsetzung planbar wird.

  • Negotiable: Das Ergebnis einer User Story muss verhandelbar sein. Auch für Issues in laufender Software gibt es meistens mehr als eine mögliche Lösung. Auch in der Softwarewartung ist es sinnvoll, über die Lösung zu verhandeln, die die Anforderungen zu den geringstmöglichen Kosten erfüllt. 

  • Valuable: Eine User Story muss einen klar herausgearbeiteten Business Value haben. In der Wartung spielt es sogar eine noch größere Rolle, dass der Wert der Lösungen klar ist. Denn die Bereitschaft zu investieren, sinkt mit zunehmender Lebensdauer der Anwendung. Der Wert ist die Voraussetzung für eine Priorisierung, bei der jeweils der Issue umgesetzt wird, der aktuell den höchsten Business Value bringt. 

  • Estimable: User Stories müssen schätzbar sein, damit das Umsetzungsteam sich zu einem Umsetzungsplan verpflichten kann. Es spielt dabei keine Rolle, ob es sich um eine Neuentwicklung oder eine Änderung einer Software handelt. 

  • Small: User Stories müssen klein genug sein, dass sie innerhalb des Planungszeitraums, zum Beispiel eines Sprints, einen Business Value liefern. Die Diskussion darüber wird im Team hauptsächlich geführt, damit die Erwartungen auf den Tisch kommen. Dies gilt für Neuentwicklungen und Weiterentwicklungen, sowie Fehlerbehebungen gleichermaßen. 

  • Testable: Um nachweisen zu können, dass der vereinbarte Business Value geliefert wurde, muss jedes Backlog Item testbar sein. In der Wartung ist der Nachweis der Funktionsfähigkeit, abhängig vom Release-Zyklus, oft noch wichtiger als im Verlauf der Neuentwicklung.

Fazit: Es ist nicht unbedingt notwendig, dass jede Anforderung sich in eine idealtypische Story verpacken lässt. Die Orientierung an den INVEST Kriterien ist auch bei Altanwendungen sinnvoll und möglich.

Mythos 2: Scope Management ist unnötig

Der Produktmanager sagt: „Wir brauchen kein Backlog, wir machen ohnehin nur mehr Dinge, die wir unbedingt machen müssen.“

Diese Meinung drückt die Erwartung aus, dass die Benutzer nur absolut notwendige Arbeiten in Auftrag geben, da die Anwendung ihr Einsatzende fast erreicht hat. Diese Anwendungen wurden meistens nach dem Wasserfall-Modell entwickelt, das heißt alle Funktionalitäten wurden vorab spezifiziert und – häufig Jahre später – umgesetzt ohne noch einmal nach dem Nutzen zu fragen. Im Wasserfall-Modell geht man davon aus, dass alles umgesetzt werden muss, was spezifiziert wurde.

Gerade bei Altanwendungen am Ende ihres Lebenszyklus hilft ein agiles Vorgehen, weil es die Optimierung des Business Value in den Mittelpunkt stellt. Durch eindeutige Priorisierung und Umsetzung mit dem Business Value im Fokus kann die Entwicklung jederzeit beendet werden, sobald der zusätzliche Nutzen geringer ist als die zusätzlichen Kosten. Die Praxis zeigt, dass Benutzer und Umsetzer am besten gemeinsam über die optimale Nutzung des bereitgestellten Budgets entscheiden können. 

Fazit: Aktives Scope Management ist die Voraussetzung dafür, dass nicht nur das Budget im Rahmen bleibt, sondern auch das Ergebnis optimiert wird. Das gilt in der Wartung genauso wie bei der Neuentwicklung.

Mythos 3: Störungen haben Vorrang

Das Team sagt: „Wir können nicht mit der Bearbeitung dringender Fehlermeldungen warten, bis der Sprint vorbei ist. Wir müssen uns sofort darum kümmern.“ 

Dieser Mythos ist auf die herrschende Meinung zurückzuführen, dass nur eine sofortige Reaktion auf alle Inputs von Kunden oder Benutzerinnen als kundenfreundlich gilt. Nach dem Push-Prinzip werden alle Anforderungen, die vom Kunden dokumentiert wurden, sofort in Bearbeitung genommen. Viele werden aber lange nicht fertig, zum Beispiel weil es offene Fragen gibt oder weil das bemängelte Verhalten auf dem Testsystem nicht reproduzierbar ist. Die Konsequenz ist häufig, dass sich eine lange Liste von Issues „in Bearbeitung“ befindet. 

Die Wahrheit ist: Die meisten Issues sind gar nicht so dringend. Eine bewusste Priorisierung hilft dabei, die richtigen Anforderungen umzusetzen und so den Business Value zu optimieren. Das agile Team bearbeitet immer nur so viele Issues, wie tatsächlich umgesetzt werden können. Es stellt diese fertig, bevor es neue aus dem Backlog annimmt. 

Fazit: Wer nach dem Pull-Prinzip vorgeht, statt nach dem Push-Prinzip, arbeitet effizienter, erledigt mehr und wird mit den wirklich wichtigen Aufgaben verlässlich fertig. Dies gilt auch in der Wartung.

Mythos 4: das Highlander Syndrom

Die Entwickler sagen: „Wir sind kein Team. Jeder von uns hat sein Spezialgebiet.“

In der Vergangenheit waren Produktentwicklungsteams häufig eher eine Gruppe von Spezialisten als ein Team. Die zugrundeliegende Annahme war, dass Experten Probleme aufgrund ihres tiefen Wissens effizienter lösen, jedoch wurden bald die Nachteile dieser Arbeitsteilung evident:

  • Viele Kommunikationsschnittstellen zwischen den einzelnen Experten 
  • Langwierige Fehleranalysen unter Beteiligung mehrerer Experten 
  • Jede Person wird zum Flaschenhals für das ganze System und verursacht bei Abwesenheit oder zu hoher Auslastung lange Wartezeiten für das gesamte System

Mit der Verlagerung zu Full-Stack Entwicklung und T-Shaped oder M-Shaped Skills rückt auch die Zusammenarbeit stärker in den Vordergrund. Teams mit bewusst gestalteter Zusammenarbeit bauen gemeinsames Wissen auf und können gerade komplexe Probleme in Altanwendungen schneller lösen. Personalwechsel können so auch wesentlich leichter kompensiert werden. In Summe überwiegen die Vorteile der Zusammenarbeit nach agilen Prinzipien.  

Fazit: Agile Teamarbeit unterstützt die hohen Anforderungen, die in der Softwarewartung an Reaktionsfähigkeit und Aufrechterhaltung des Wissens gestellt werden, besser als Expertentum.  

Kein Mythos: die wahre Herausforderung für Agilität in der Softwarewartung

Die wahre Herausforderung für Agilität liegt bei Altanwendungen meistens in der Qualitätssicherung. Mangelnde Wissensteilung, geringe Abdeckung mit dokumentierten – am besten automatisierten – Tests und eine intransparente Schnittstelle zum Betrieb sind die unausgesprochenen Gründe, warum viele Entwickler nicht in der Wartung arbeiten wollen. 

Hinzu kommt ein hoher Aufwand für die Qualitätssicherung auf allen festgelegten Ebenen (Stages). Es muss sichergestellt sein, dass Änderungen im Code keine unerwünschten Nebenwirkungen verursachen. Hierfür sind zahlreiche manuelle Schritte mit langen Wartezeiten und enormem Koordinationsaufwand notwendig.

Zu den wichtigsten agilen Prinzipien gehört, häufig zu releasen und inkrementelle Änderungen für die Benutzer bereitzustellen. Bei Altanwendungen hilft das agile Vorgehen oft, die Flaschenhälse zu identifizieren und Schritt für Schritt zu beseitigen.

Schlussendlich wird auch eine Releaseplanung mit fixen Releasezeitpunkten durch agiles Arbeiten unterstützt. Durch laufende Priorisierung wird sichergestellt, dass die jeweils wichtigsten Features (bzw. Fehlerbehebungen) umgesetzt werden und der Releasetermin eingehalten wird.  

Wie schaut agiles Arbeiten in der Softwarewartung konkret aus?  

Bei TechTalk arbeiten wir in der Wartung agil mit einem fixen Team. Das bedeutet für unsere Kunden geteiltes Wissen und garantierte Reaktionsfähigkeit – auch langfristig. 

Wir kombinieren ein Kanbanboard mit regelmäßigen Retrospektiven und Plannings nach Scrum. Das Kanbanboard erlaubt einerseits flexible Reaktion, wenn ein dringender Fehler gemeldet wird, unterstützt aber andererseits auch jederzeit die Selbstorganisation des Teams. Die Prioritäten werden klar abgebildet, was kontinuierliche fokussierte Umsetzung bedeutet. Die sogenannte „Emergency Lane“ zeigt auf einen Blick, ob etwas Dringendes außerplanmäßig zu erledigen ist.  

Sowohl Kanban als auch Scrum bieten einen Rahmen, in dem Entwickler fokussiert arbeiten können.  

Die Elemente aus Scrum erleichtern den Abgleich mit der Roadmap aus der Planung und unterstützen die laufende Evaluierung und Anpassung der Prozesse. Durch die regelmäßige rollierende Planung haben auch unsere Kunden mehr Transparenz. Planänderungen können von beiden Seiten frühzeitig eingebracht und auf ihre Konsequenzen geprüft werden.  

Im Umsetzungsteam sind agile Praktiken etabliert, mit denen ein durchgängiger Qualitätsstandard sichergestellt wird. Mehr Informationen dazu finden sich im Experteninterview mit Thomas Korosa


Haben Sie eine Legacy Software im Einsatz, die modernisiert gehört?

Nutzen Sie unser Angebot der kostenlosen Analyse im Rahmen des TechTalk Relax Application Management Service.

Business Agility Dialogue mit Erste Bank CEO Peter Bosek (Teil 1/2)

Der Business Agility Dialogue von TechTalk hat das Ziel mit hochkarätigen Vertretern von Unternehmen in Österreich ein Gespräch über Agilität zu führen. Ein kritisches Auge auf sogenannte „agile Transformationen“ und ein hoher „no-bullshit“ Faktor sind uns dabei wichtig.

Im ersten Teil dieser Serie spricht Erste Bank CEO Peter Bosek mit mir über die Kernelemente des Erfolges von George, die Herausforderungen ein innovatives Produkt wie George zu entwickeln und dieses letztendlich in bestehende Strukturen zu integrieren. Ein wesentliches Element dabei ist auch die notwendige Führungskultur.

Mit Peter Bosek konnten wir einen der bekanntesten Bank-Manager des Landes gewinnen. Peter ist mitverantwortlich für das moderne Online-Banking George der Erste Bank.

Ausgewählte Highlights aus der Diskussion:

  • Business Opportunities entstehen aus der rasanten technologischen Entwicklung heraus. Es braucht starke IT Sparring Partner, die Möglichkeiten für Innovationen aufzeigen, sodass diese gemeinsam agil entwickelt werden können.
  • Eine wesentlicher Erfolgsfaktor für Innovation ist ein diverses Team. Und mindestens genauso wichtig ist: Loslassen. Dem Team vertrauen und es machen lassen. 
  • Mit dem Vorantreiben der Innovation bleiben wir somit auch als Arbeitgeber interessant. Nur mit guter Bezahlung alleine bekommt man heute keine guten Leute mehr!
  • „Die Unternehmenskultur muss zu einer ’safe to fail‘ Kultur gewandelt werden. Wenn es dir gelingt, eine Unternehmskultur zu prägen, in der es kein Fingerpointing mehr gibt, sondern gemeinsames Lernen aus Fehlschlägen, dann ist schon viel erreicht.“
  • „Im Innovationsprozess darf es im Unternehmen nie so weit kommen, dass sich ein Teil im Unternehmen als Verlierer fühlt. Ganz gefährlich. Es kann immer nur ein gemeinsamer Erfolg sein, sonst führt es nicht zu einer Weiterentwicklung des Unternehmens.“

In Teil 2 des Interviews mit Peter Bosek, spreche ich mit Peter Bosek über die Zukunft der Agilität.

Nur unsere Newsletter Abonnenten bekommen alle Artikel!

Bleiben Sie Up2Date mit unseren Interviews und Artikeln zu Agile Transformation. Für Agile Experts, Change Leader, Digital Transformation Experts.

Agile at Scale: How „The Spotify Model“ came to life and how it can be applied in a remote-work environment

Joakim Sunden
Consultant at Crisp

Joakim Sunden was one of the Agile Coaches at Spotify working together with the CTO to develop a new approach to Agile at scale, aka “The Spotify Model” with Tribes, Squads, Chapters and Guilds. He is also a well-known figure in the agile community, having organized and spoken at many international conferences and community events over the years. In 2016 he held a keynote at Agile Tour Vienna, since then we partner with Joakim and also offer a training course about SAFe and the „The Spotify Model“. For this post, we asked Joakim how „the Spotify Model“ came to life and how it evolved since then.

How would you explain the Agile at Scale (Spotify Model) to someone who has never heard about it?

There’s no short answer to that so you’ll have to bear with me for some background story. Back in 2011 when I joined Spotify we had fewer than ten teams, or squads as we could come to call them. But we already experienced some growing pains and we knew that we would grow a lot as we had big plans and a lot of VC funding. We wanted to desperately avoid the increased bureaucracy and slow speed many of us had experienced with other big companies so we tried to come up with a new way of organizing ourselves to stay agile even at scale.

At it’s core it’s all about trusting the people you hire to do a great job and support them the best you can without getting in their way. This is why we called the core of our org an “autonomous squad”, a 5-10 people small and empowered product development team who are free to make a lot of more choices than any other team I had ever worked with in the past. Not just how to build things, but also to a large extent what to build. Within bounds of course.

One example of such bounds is the product direction, or goal, of your tribe. Each squad was part of a mission, or product area, called a “tribe”, together with maybe four to ten other squads. The Tribe Trio leadership would set a direction in dialogue with the squad and upper management, within which the squads would have freedom to explore different experiments to push the metrics the right way. Leadership is all about supporting you, making sure you have clarity of direction and everything you need to get there, in terms of skills, resources, decision power, etc.

How can you apply some of Spotify’s organizational structures and practices to your SAFe ARTs?

That’s also true for your closest manager who leads the functional area, or Chapter as our name was, you’re part of together with 5-10 coworkers with similar skill sets. Kind of a matrix model where the manager is a servant leader responsible for your development and success rather than for making decisions and relaying information, and so on.

On a surface level this is what most people understand as “the Spotify Model”; Squads, Chapters, and Tribes. Because that’s the visible most apparent structural parts of it. In practice it’s much more about mindset, culture, leadership, all those things that’s really different and makes it tick, but harder to observe and understand. And that’s what we drill down into in the course. That and the finer mechanics of some of what we learned along the way and from living with this model and evolving it  for several years.

So the first white paper on the Spotify model came out in 2012. What has happened since then?

Wow, a lot really… One of the most concrete things that we abandoned rather quickly after the paper came out was the idea that a Chapter Lead, that is, an engineering manager, should work 50% as a manager and 50% as an individual contributor in a squad. That simply didn’t work, it was too much. Which is not to say that it’s not the right thing for other companies to be doing, but it didn’t work for us with very high expectations on the people development part of the role.

Great experience. Completely realistic view. Down to earth presenter.

– Attendee feedback, Agile at Scale Workshop with Joakim Sunden in 2019

This is by the way a reason I don’t want to talk a lot about changes to Spotify’s way of working, since people seem to perceive it as some kind of evolution and “what Spotify’s doing now must be so much better than the old white paper, so let’s take a short cut and go straight to where they are now”. How Spotify evolved is not necessarily the way your organization needs to evolve. What was working well at some point in one context may not be working well in another context. In an organizations of Spotify’s size there’s now also multiple different solutions to similar problems in different parts of the company. Some held on to the Chapter Lead model while others tried other approaches to solve for other problems, reach other goals.

So rather than talking about the evolution of a specific model we spend a lot of time in the course talking about what we learned from different things, the thinking behind it, how things evolved. All with the goal of course participants being better equipped to solve their own issues themselves when they get back to work. Using Spotify as an inspiration, for different types of solutions, but also the approach to change and problem solving that we applied. And not just Spotify, we drew inspiration from plenty of sources ourselves, and so should you of course.

Can the Spotify model also be applied in a remote work environment?

Absolutely! Spotify was early on a distributed company with product development in Stockholm, Gothenburg, New York and San Francisco. Later we added Boston, where I lived and worked for a few years, and more recently London. So a remote work environment was there pretty much from the start for me.

Working in a remote environment it’s even more important to let go of control and trust your people and teams to work autonomously to solve problems. It’s even more important to have good practices in place for collaborating and communicating, to create clarity of direction and communicate progress when working remotely.

When I left Spotify and started consulting with companies I was shocked to learn how bad most of them were at remote work practices and how many companies just lack the tools to be able to collaborate efficiently in a remote environment. Even though the course is very little about remote work practices per se, indirectly it’s a lot about supporting that way of working. Since we’re also running it remote, participants will be able to learn some really good tools for remote workshops, should they not already be familiar with them.  

Wie finde ich den passenden agilen Anbieter für mein Projekt?

Der Preis ist häufig das entscheidende Kriterium, wenn es um die Auswahl eines agilen Anbieters geht. Denn es ermöglicht, die verschiedene Angebote einfach zu vergleichen und so eine scheinbar sichere Auswahl zu treffen. Zumindest auf den ersten Blick. 

Wenn Sie jedoch die Eignung des Anbieters außer Acht lassen oder zu gering bewerten, können sich die anfänglichen Einsparungen schnell revidieren. So kann es sein, dass der Anbieter die Anforderungen des Projektes nicht erfüllt und das Projektteam darunter leidet. Wenn Sie am falschen Ende sparen, sind die zusätzliche Kosten und der Zeitaufwand deutlich höher, als die Einsparungen zu Beginn. 

Wir zeigen Ihnen, welche Qualitätskriterien aus unserer Sicht wichtig für agiles Vorgehen sind und wie Sie in einem strukturierten Prozess den richtigen Anbieter für Ihr agiles Projekt auswählen können.

Kriterien für die agile Anbieterauswahl

Es ist wichtig, dass Sie sich bereits vor dem Auswahlprozess mit dem Thema Qualitätskriterien beschäftigen. Nur so können Sie wissen, worauf Sie bei den Auswahlgesprächen achten müssen. Unser Meinung nach sollten Sie auf jeden Fall folgende Kriterien berücksichtigen:

  • Erfahrung Agilität: Je mehr Erfahrung ein Anbieter mit agilen Methoden hat, desto besser. Nur wenn eine „Agile Culture“ gelebt wird, kann auch eine agile Projektentwicklung erfolgreich sein.
  • Eingespieltes Team: Ein eingespieltes Team ist einem neu zusammengestellten Team vorzuziehen. Denn eingespielte Teams können oftmals ein Vielfaches der Produktivität eines neuen Teams erzielen. Bei längeren Projekten sollten Sie außerdem die Fluktuation im Team berücksichtigen. Wir kennen die Thematik insbesondere bei Offshore-Teams, in denen einzelne Entwickler jederzeit getauscht werden können.
  • Direkte Kommunikation: Dieser Faktor ist für agile Projekte besonders wichtig. Es muss sichergestellt sein, dass Ihre Experten mit den Experten des Anbieters direkt zusammenarbeiten können — im Idealfall sogar im gleichen Scrum-Team. Aus unserer eigenen Erfahrung kommt es häufig zu Problemen, wenn es zu viele Übergaben zwischen den einzelnen Teammitgliedern gibt. Entscheidungen müssen schnell, ohne langwierige Entscheidungswege getroffen werden können. 
  • Erfahrung Domäne: Die Erfahrung in der Domäne spielt ebenfalls eine wichtige Rolle — vor allem auf dem Level der Teammitglieder. Es werden oft internationale Referenzen genannt, das entsprechende Team besitzt diese Erfahrungen jedoch nicht. 
  • Culture Fit: Es wichtig, das Mindset und die Entwicklungsprozesse des Anbieters zu verstehen. Sie sollten im Vorfeld prüfen, inwieweit diese zum eigenen Unternehmen passen und eine enge Zusammenarbeit ermöglichen.
  • Grad der Abhängigkeit: Es ist sinnvoll, zu überlegen, wie man den Grad der Abhängigkeit zum Anbieter auch im weiteren Verlauf gering hält. Eine Möglichkeit ist es, auf offene Standards zu setzen. Diese ermöglichen zu einem späteren Zeitpunkt einen leichteren Anbieterwechsel bzw. eigene Entwickler zu schulen, die am Produkt entwickeln. 
  • System Architektur: Es ist entscheidend, dass die Architektur der neuen Lösung zur bestehenden Systemlandschaft passt. Ein völlig neuartiges System mit neuen Technologien erhöht die Komplexität und erschwert später die Wartung, wenn die Skills nicht ausreichend innerhalb der Organisation vorhanden sind. Die Abhängigkeit zum Hersteller wird dadurch auch erhöht.
  • Wartung: Nachdem die Software entwickelt ist, beginnt die Wartungsphase. Diese dauert bekannterweise weitaus länger als die Entwicklung. Daher sollten Sie die Strategien der Anbieter für diese Phase prüfen und testen, wie schnell sie z.B. auf unvorhergesehene Fehler wie Produktions-Incidents reagieren.

Neben den Qualitätskriterien sollten Sie als Kunde Ihre wichtigsten NFRs (Nichtfunktionale Anforderungen; engl. Non-functional Requirements), wie Security, Skalierbarkeit, Testbarkeit  kennen. Nur so können Sie im Auswahlprozess überprüfen, ob die Anbieter diese erfüllen können und diese direkt kommunizieren. Andernfalls kann es zum Beispiel sein, dass Sicherheitsanforderungen zu deutlich höheren Kosten oder im schlimmsten Fall gar nicht vom System umgesetzt werden können. Bekannterweise beeinflussen NFRs die System-Architektur stärker als funktionale Anforderungen. Daher kann es im schlimmsten Fall sein, dass ein Produkt diese NFRs gar nicht mehr umsetzen kann.

In 4 Schritten zum passenden agilen Anbieter 

Diese Vorüberlegungen bieten die Grundlage für einen strukturierten Prozess, mit dem Sie die Anbieter anhand der wichtigsten Kriterien in vier Schritten auswählen können. 

1. Vorauswahl treffen

Wenn Sie eine Ausschreibung für ein agiles Projekt starten, werden Sie eine Reihe von Angeboten erhalten. Im ersten Schritt geht es darum, eine Vorauswahl der Angebote vorzunehmen. 

In der Regel wird die Vorauswahl von der Einkaufsabteilung getroffen. Diese wählt die Anbieter anhand der zuvor beschriebenen Qualifikationskriterien und des Preises aus. 

 2. Intensive Gespräche führen

Nachdem die Vorauswahl getroffen wurde, finden intensive Gespräche zwischen Ihren Experten und den Experten des Anbieters statt. Diese Gespräche dienen dazu, den ersten Eindruck zu validieren. 

Zusätzlich können in dieser Phase Anforderungen, wie die NFRs angesprochen werden, um den Anbietern eine detaillierte Vorstellung zu geben, was von ihm während der Projektumsetzung erwartet wird.

 3. Prototypen-Phase durchführen

Die Prototypen-Phase ist eine entscheidende Phase, die jedoch häufig nicht gemacht wird. Vor allem, wenn Sie mit den Anbietern noch nicht zusammengearbeitet haben, sollten Sie diese Phase auf keinen Fall überspringen. 

Die Prototypen-Phase wird im Idealfall sogar mit mehreren ausgewählten Anbietern durchgeführt. Das Ziel dieser Phase ist es, die Zusammenarbeit anhand von lauffähiger Software zu beurteilen. Dadurch erhalten Sie ein viel besseres Verständnis, ob die Zusammenarbeit mit einem Anbieter funktioniert und ob alle Qualitätskriterien erfüllt werden können. 

Wichtig hierbei: Sie sollten bei der Prototypen-Phase darauf achten, dass diese mit dem finalen Team durchgeführt wird. Die Mitarbeiter, die für die spätere Produktentwicklung zuständig sein werden, sollten bereits in dieser Phase in der finalen Konstellation am Prototypen arbeiten.

4. Produktentwicklung starten

Die Software, die während der Prototypen-Phase entsteht, sowie das Feedback der Experten über die Zusammenarbeit mit dem Anbieter dient als Entscheidungsgrundlage, um die Auswahl weiter zu reduzieren. Am Ende dieser Phase sollten Sie einen Anbieter auswählen, mit dem Sie die Produktentwicklung durchführen.
Bevor es jedoch in die Entwicklungsphase geht, steht die Vertragsverhandlung an. Bei agilen Projekten gibt es einige Fallstricke, auf die Sie bei der Vertragsgestaltung achten sollten. Wir haben Ihnen die wichtigsten Tipps zusammengefasst, um eine solide Vertragsgrundlage für Ihre agilen Projekte zu schaffen.

Der Auswahl-Funnel zur Findung des passenden agilen Anbieters

Der Preis ist nicht das entscheidende Kriterium

Der Preis ist in der Regel nicht das beste Auswahlkriterium, selbst wenn es auf den ersten Blick so scheint. Es sich wichtig, sich im Vorfeld über die wichtigsten Qualitätskriterien bewusst zu sein und diese in einem strukturierten Prozess für die möglichen Anbieter zu validieren.

Der folgende Fragenkatalog bietet Ihnen dabei eine erste Hilfestellung zur Beurteilung der Anbieter-Qualität:

  • Wie groß ist die Erfahrung des Anbieters mit agilen Methoden?
  • Ist sichergestellt, dass ich ein eingespieltes, erfahrenes Team bekomme? Habe ich direkten Einfluss auf die Personen, die in meinem Team arbeiten?
  • Ist eine direkte Kommunikation der Teammitglieder zwischen Kunde und Anbieter sichergestellt?
  • Hat der Anbieter und insbesondere das Team, das mein Projekt umsetzt Erfahrung in meiner Domäne?
  • Bei länger laufenden Initiativen: Wie hoch ist die Fluktuation der Personen im Team?
  • Kennen Sie Ihre nicht-funktionalen Anforderungen?
  • Wie direkt können Sie mit dem Umsetzungsteam kommunizieren?
  • Ist das Umsetzungsteam vielleicht direkt Teil des eigenen Teams?
  • Wie gut ist der agile Anbieter in der Wartungsphase?

Nur unsere Newsletter Abonnenten bekommen alle Artikel!

Bleiben Sie Up2Date mit unseren Interviews und Artikeln zu Agile Transformation. Für Agile Experts, Change Leader, Digital Transformation Experts.