Schlagwortarchiv für: leading safe

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.

Warum wir jetzt SAFe Partner sind – und an den Erfolg des Scaled Agile Frameworks glauben

Im Zeitalter der Digitalisierung und COVID Krise haben viele Unternehmen erlebt, dass die Geschwindigkeit am Markt zunimmt und es immer wesentlicher wird zur richtigen Zeit die richtigen Produkte am Markt zu haben. Die eigenen Ansätze müssen immer wieder hinterfragt werden, und sich ändern. 

Die Methoden des agilen Arbeitens haben daher längst alle Unternehmensbereiche erfasst. Agile ist also kein IT- und Software-Department Thema, sondern betrifft das gesamte Unternehmen, daher auch Business Agility

Viele Unternehmen suchen nach Lösungen und Praxisberichten, die aufzeigen wie andere es geschafft haben ein ganzes Unternehmen zu transformieren. Die Frage nach einem Kochrezept ist immer wieder da. 

Wir bei TechTalk wissen, dass jeder Kunde und jedes Unternehmen mit seinen MitarbeiterInnen verschieden ist, dennoch braucht es einen Startpunkt und einen holistischen Ansatz, der bei der Reise helfen kann. 

Dabei greifen wir immer wieder auf das Scaled Agile Framework zurück, welches ein Business Agility Framework ist, und viele gute Prinzipien und Werte vertritt. Gepaart mit Praktiken, die uns auf der Reise zu einer agilen Organisation helfen. 

Schlussendlich glauben wir, dass das Framework dabei hilft unnötige Fehler zu vermeiden, da wir es selbst so in der Praxis erlebt haben. 

Um unseren Kunden bestmöglichen Support liefern zu können, haben wir beschlossen nicht nur einzelne SAFe Berater auszubilden, sondern als TechTalk strategisch eine Partnerschaft mit Scaled Agile einzugehen. Das erlaubt es uns näher an den Entwicklungen des Frameworks beteiligt zu sein und auch aktiv in der Community mitzugestalten. Und während Transformations-Projekten mit Kunden können wir durch diese Partnerschaft einen besseren Support bieten. 

Wir wissen, dass es gegenüber SAFe sehr viel kritische Stimmen gibt, daher würden wir gerne in den Dialog mit Ihnen treten, ob SAFe oder Aspekte davon in Ihrem Kontext sinnvoll sind. Mit unserer pragmatischen Vorgehensweise finden wir sicherlich den geeigneten Ansatz, unabhängig vom Framework. 

Wir haben den passenden SAFe-Kurs für Sie!

In den nächsten Monaten werden wir das SAFe Framework ausführlich vorstellen. Sind Sie bereits überzeugt? Dann können Sie einen Leading SAFe Kurs bei uns besuchen.

Ausgewählte weitere themenverwandte Artikel:

Skalierung und Agilität für Ihre Organisation

Laden Sie sich hier das kostenlose Whitepaper zum Thema „Achieving Business Agility with SAFe® 5.0“ runter.

Beurteile ein Agile Framework nicht nach seiner Implementierung!

So funktioniert Scrum in der Praxis: Der Projektmanager wird der Scrum Master. Der Business Analyst wird zum Product Owner. Die Entwickler bleiben Entwickler, und die Tester sind in in der Qualitätssicherung. Das Backlog wird zu einer “storified” Version vom Requirements-Dokument. Es macht keinen Unterschied ob eine Story in einem 4-Wochen Sprint fertig wird oder nicht – weil es einen fixen Scope und Deadline gibt. Nach einigen Sprints und 6 Wochen vor dem Release gibt es einen Code Freeze und SIT / CAT machen Tests und fixen Bugs. Dann wird der neue Code veröffentlicht.” 

Einem Scrum-Puristen stellt es bei dieser Darstellung die Haare auf. Das hat doch nichts mit Scrum zu tun, werden sie sagen. Wer das für Scrum hält macht grundsätzlich etwas falsch. 

Jetzt schauen wir uns ein anderes Beispiel an. 

So funktioniert SAFe in der Praxis: Der Programm-Manager wird zum Produktmanager. Der Projektmanager wird zum Release Train Engineer. Die Product Owner sind glorifizierte Business-Analysten, die tun, was der Produktmanager sagt. Die bestehenden Plattform-Teams werden in Agile Teams umbenannt. Die Gruppen/Team-Leads werden zu Scrum-Mastern. Folgend arbeiten alle daran, den im Program Increment (PI) festgelegten Scope bis zum vierteljährlichen Release-Termin fertig zu stellen. Und so läuft das immer wieder ab. 

Nicken Sie gerade zustimmend und meinen “Ja, das beschreibt SAFe perfekt!”? Es passt zu dem was Sie über SAFe wissen? Aber wenn Sie wirklich viel über SAFe wissen würden, dann wären Sie über diese Beschreibung erbost. Ähnlich der Beschreibung von Scrum eingangs in diesem Post besteht die einzige Gemeinsamkeit in der Verwendung bestimmter Schlüsselwörter. Nichts vom SAFe Spirit oder der Essenz von SAFe ist in der Beschreibung erkennbar. 

Es ist jedoch nicht ungewöhnlich, dass diese Missverständnisse mit Hingabe herumgeworfen werden. “SAFe ist nicht agil, es ist nur ein überarbeitetes Waterfall-Konzept mit einer Prise agiler Begriffe”. Aber haben Sie SAFe in der Praxis gesehen? Können Sie das mit Ihrer Erfahrung bestätigen? Ich habe Scrum auch in der Praxis gesehen. Und es ist nicht immer schön. Eigentlich ist es oft nicht schön – es sieht oft aus wie Frankensteins Monster mit missverstandenen Konzepten und Praktiken.  

Glücklicherweise beurteile ich Scrum nicht danach. Ich habe an Kursen teilgenommen, Bücher gelesen, in Scrum-Teams als Entwickler, Tester, Product Owner und Scrum Master gearbeitet. Ich kann den Unterschied zwischen echtem Scrum und dem halbherzigen Pseudo-Scrum, den das obere Management als agil präsentiert bekommt, erkennen. 

Haben Sie sich eigentlich schon die Zeit genommen, SAFe genauer zu studieren? Hat Sie schon der Umfang des SAFe Big Picture allein überzeugt, dass SAFe schlecht sein muss? Haben Sie Bücher über SAFe gelesen oder einen Kurs besucht? Haben Sie es in seiner Tiefe wie XP, Scrum oder Kanban kennengelernt? Mit welchen anderen Business-Agilitäts-Frameworks haben Sie es verglichen? 

Oder lassen Sie einfach nur Ihre Vorurteile und Selbstgerechtigkeit Ihre Meinung über SAFe bestimmen? 

Lassen Sie sich nicht von SAFe kritischen Artikeln, die oft voll von Vorurteilen sind, blenden. Ich lade Sie ein SAFe kennenzulernen. Wir praktizieren SAFe in Kundenprojekten und laden Sie ein SAFe in unserem Leading SAFe Training kennenzulernen.

Eine englische Version dieses Artikels von mir finden Sie auch auf meinem LinkedIn Profil.

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.

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