Accessibility Testing – Das Web-Zugänglichkeits-Gesetz und seine Folgen für Unternehmen

/0 Kommentare/in /von

Barrierefreiheit und „Design for All„ ist ein Thema, welches immer mehr an Relevanz gewinnt und heute zur digitalen Strategie eines jeden Unternehmens gehört. Die rechtliche Umsetzung von inklusivem Webdesign für Webseiten und Apps war lange Zeit nicht geregelt, durch das Inkrafttreten des neuen Web-Zugänglichkeits-Gesetz (WZG) ist die barrierefreie Gestaltung von Webseiten und mobilen Anwendungen jedoch zur gesetzlichen Verpflichtung geworden.

Unternehmen die eigene Webseiten betreiben oder Apps anbieten sind nun gefragt, diese einem Accessibility Test zu unterziehen und nötige Anpassungen vorzunehmen. Auf welche Art und Weise der Accessibility Test durchgeführt werden kann, welche Aspekte hierbei zu beachten sind und wo Unternehmen Unterstützung bei der Durchführung erhalten stellen wir Ihnen im Folgenden übersichtlich dar.

Accessibility Review & Web-Zugänglichkeits-Gesetz

Österreichische Unternehmen müssen als Konsequenz auf das Inkrafttreten des Web-Zugänglichkeits-Gesetz (WZG) ein Zertifikat erwerben, welches bestätigt, dass ihre Webseite oder App barrierefrei ist. Vorab können Unternehmen anhand einiger Faktoren einen Selbsttest durchführen und anhand der neuen Kriterien definieren welche Anpassungen nötig sind, oder alternativ über einen Experten wie TechTalk einen solchen Test durchführen lassen. 

TechTalk ist Experte für Accessibility und das Testen von Accessibility in Apps und auf Webseiten. Wir unterstützen Unternehmen bei der Durchführung von Accessibility Tests ihrer Webseiten und Apps. Nehmen Sie Kontakt mit uns auf uns lassen Sie sich beraten.

Barrierefreiheit & Design – Web Accessibility in der Praxis

Inklusion und Barrierefreiheit spielen auch in der Wirtschaft sowie in der öffentlichen Verwaltung eine immer größere Bedeutung – nun hat auch der Gesetzgeber erkannt, dass Menschen mit Beeinträchtigungen in vielfacher Art und Weise Diskriminierung im Internet erleben.

Einen guten Einstieg in das Thema Accessibility Test erhalten Sie hier:

Das Betrachten von Inhalten in Apps und auf Webseiten kann für Menschen mit Beeinträchtigungen zu Komplikationen führen. Mit Hilfe einer Zumutbarkeitsprüfung können Unternehmen ermitteln, ob beim Betrachten einer Webseite oder App Barrieren bestehen und somit eine Diskriminierung vorliegt. Im Folgeschritt wird die Gestaltung der Seite unter die Lupe genommen und soweit wie möglich angepasst.

Eine 100% Anpassung mag nicht immer möglich sein. Ziel der Initiative ist es jedoch, dass möglichst viele Inhalte im Internet barrierefrei dargestellt werden und auf diese Weise zu mehr Inklusion von Menschen mit vermindertem Sehvermögen erreicht wird.

Web-Zugänglichkeits-Gesetz – Auswirkung auf Unternehmen

Gemäss des Web-Zugänglichkeits-Gesetzes müssen alle Webseiten des Bundes oder einer seiner Einrichtungen, die nach 23.9.2019 veröffentlicht wurden die im WZG aufgeführten Kriterien erfüllen. Für ältere Webseiten gilt die Frist 23.9.2020. Apps müssen die genannten Kriterien bis 23.6.2021 erfüllen.

Accessibility Testing in der Praxis – Unser Testbericht

Das TechTalk Team ist Experte in Sachen Accessibility Tests und testet sowohl Webseite als auch Apps anhand der durch das WZG festgelegten Kriterien. Welche Möglichkeiten Unternehmen haben um vorab einige der Kriterien zu testen haben wir anhand eines Tests einer App für Sie zusammengestellt.

Ziel hierbei war es den aktuellen Stand zur Barrierefreiheit der getesteten App festzustellen um im Anschluss gemeinsam mit den Entwicklern zu entscheiden, welche Verbesserungen mit höchster Priorität umgesetzt werden sollen.

Einige der gängigen Methoden zum Test der Barrierefreiheit sind bei einer Smartphone-App anders als bei einer Webseite nicht möglich – hierzu gehört die Nutzung eines Kontrast-Tools, oder die Entwicklertools des Browsers für einfachen Zugriff zum Programmcode.

Im Folgenden stellen wir vier verschiedene Ansätze zur Durchführung Accessibility Testings von Apps vor:

  • Kontrast-Check 
  • Screenreader-Check
  • Vergrößerung des Texts
  • Vergrößerung via Smartphone-Lupe

Mittels dieser vier Ansätze lässt sich bereits ein Großteil der WCAG-Guidelines (Web Content Accessibility Guidelines) abdecken und einen Einblick in die Barrierefreiheit der Smartphone-App bekommen. Die Ergebnisse zeigten dass die von uns getestete App nicht besonders gut an die Bedürfnisse von sehbehinderten Menschen angepasst ist.

Testmöglichkeiten im Überblick

Überprüfen der Lesbarkeit mit Kontrast-Check

Ebenso wie im Internet ist auch für die Nutzung von Smartphone Apps das Zusammenspiel von Farben bedeutsam für die Zugänglichkeit.

Ziel: Überprüfung des Kontrastes um sicherzustellen dass Menschen trotz einer Sehbehinderung oder einer Farbschwäche eine Applikation benutzen und verstehen können.
Zielgruppe: Menschen mit einer Sehschwäche oder einer Farbschwäche, wie zum Beispiel die Rot-Grün-Sehschwäche.
Kriterium: Die Applikation ist ohne Probleme bedienbar, Elemente unterscheiden sich nicht nur anhand von Farbe, sondern haben auch ein zusätzliches Unterscheidungsmerkmal (wie Icons oder Text).

Ein spezifisches tool um die Lesbarkeit von Inhalten in Smartphone Apps zu testen gibt es bisher nicht. Für unseren Test haben wir daher Screenshot erstellt und diese am PC bezüglich ihrer Lesbarkeit analysiert. Für das Testen von Webseiten im Browser empfehlen wir den Colour Contrast Analyser (CCA). Das Tool beinhaltet einen Farbpicker, zudem zeigt es an, welche WCAG Richtlinien der Kontrast der Webseite erfüllt.

Der Screenreader-Check

Der Test mit hilfe des Screenreader Checks nimmt etwas mehr Zeit in Anspruch. Hierzu wurde der NVDA Screenreader verwendet, folgende Punkte wurden getestet:

  1. Fokus auf die Navigation
    1. Kann ich jeden Menüpunkt erreichen?
    2. Kann ich jeden Menüpunkt auch wieder verlassen / wechseln?
    3. Wo ist der Fokus beim Öffnen einer neuen Seite platziert?
    4. Ist der Wechsel einer Seite nachvollziehbar?
  2. Fokus auf die einzelnen Elemente (Buttons, Formularelemente, Einstiegspunkte, Links ..)
    1. Welcher Text wird beim Anklicken der einzelnen Elemente vorgelesen?
    2. Sind die Elemente verständlich beschrieben?
    3. Verstehe ich den Aufbau der Seite, ohne dass ich etwas sehe? 
  3. Fokus auf die “Führung” des Benutzers
    1. Ist verständlich, auf welcher Seite ich mich befinde? 
    2. Ist beschrieben, was ich auf der Seite “zu tun” habe?
    3. Ist verständlich, was ich zu tun habe wenn sich die Tastatur / die Kamera / ein Popup öffnet? 
    4. Kann ich die Tastatur / die Kamera / ein Popup / das Menü wieder verlassen?

Ein Beispiel aus der Praxis möchten wir genauer beschreiben:

Zur einfacheren Veranschaulichung haben wir den Homescreen nachgebaut.

Im Idealfall liest der Screenreader beim ersten Menüpunkt (siehe Wireframe „Torte Schalter“) vor. Bei der getesteten App liest der Screenreader, wenn der Fokus zum ersten Menüpunkt ”Torte” kommt, statt ”Torte Schalter” – ”Text Unterstrich 18 Schalter” vor. Durch den Begriff ”Schalter” erkennt der Benutzer des Screenreaders, dass es sich um einen Button handelt und dieser anklickbar ist. Durch die Wörter ”Text Unterstrich 18” erkennt er aber nicht um was es sich bei diesem Menüpunkt handelt. Als blinder Benutzer sieht man das Icon nicht, deshalb ist es hier unmöglich zu wissen, was passiert, wenn man auf den Button klickt und auf welche Seite man dann kommt.  Wenn man den Fokus nun auf den Menüpunkt ”Kaffee” setzt, hört man statt ”Kaffee Schalter” – ”Text Unterstrich 12 Schalter”. Dies geschieht mit allen Menüpunkten, was es unmöglich macht sich bewusst durch die App zu navigieren.

Ein weiteres Problem befindet sich auf der Schaltfläche links unten am Screen. Die Schaltfläche mit dem Icon und dem Text “Mehr Infos” wird vom Screenreader als “TBD” vorgelesen. Natürlich ist es damit auch nicht möglich zu wissen, was sich auf der Seite verbirgt, auf die man darauf navigiert.

Der Screenreader Test wurde sowohl am iPhone als auch am Android durchgeführt, in den Einstellungen des Smartphones kann man den Screenreader einschalten.

Vergrößerung des Texts

Eine weiteren Testoptionen ist die Veränderung des Textgröße in den Smartphone Einstellungen und die Analyse der Folgen bei der Nutzung der App.

Ziel: Sicherzustellen, dass sich die Schriftgröße dynamisch angepasst, wenn dies in den Einstellungen so eingestellt wurde.
Zielgruppe: Menschen mit einer Sehschwäche.
Kriterium: Unabhängig davon welche Schriftgröße eingestellt ist ist der Text ist lesbar und auch Schaltflächen und Tabellen werden dementsprechend angepasst. Die Textgröße passt sich nicht nur im Smartphone, sondern auch in der Applikation an und wird automatisch vergrößert.

In der getesteten Applikation was das Ergebnis ernüchternd, die Änderung der Schriftgröße hatte keine Auswirkung auf die getestete Applikation. Weder der Text der Menüpunkte noch der Text innerhalb der Applikation (z.B. im Impressum, Beschreibungstext) wurden vergrößert dargestellt. Stattdess einer dynamischen bzw. relativen Schriftgröße wurde eine fixe Schriftgröße verwendet wurde (wie px).

Vergrößerung via Smartphone-Lupe

Eine weitere Testoption ist die Vergrößerung mit der Smartphone Lupe.

Ziel: Sicherstellen, dass Menschen, welche die Smartphone-Lupe verwenden, deine Applikation benutzen können.
Zielgruppe: Menschen mit einer Sehschwäche.
Kriterium: Die Lupe ist wie gewohnt verwendbar und hat den gewünschten Effekt. Die Lupe lässt sich auch in der Applikation aktivieren und ist wie gewohnt bedienbar.

Bei der von uns getestete Smartphone-Applikation hat dies gut funktioniert.

Barrierefreiheit professionell testen und optimieren

Unternehmen die sich bisher noch wenig mit dem Thema Accessibility Testing und Barrierefreiheit von Webseiten und Apps auseinander gesetzt haben sind nun in der Pflicht, die im WZGs gelisteten Kriterien umzusetzen und ihre Webseiten und Apps dementsprechend zu aktualisieren.

Die von und beschriebenen Möglichkeiten eines vorab Tests bieten eine praktische Heranführung an das Thema Barrierefreiheit von Apps für sehbehinderte Menschen und helfen Unternehmen, Handlungsbedarf zu erkennen. Bei der gründlichen Analyse und der technischen Umsetzung von vorhandenen Defizienten helfen UX Experten und Web Designer, die über das nötige Know how verfügen.

Haben Sie Fragen?

Unser Team unterstützt Unternehmen bei der Umsetzung des WZGs und hilft Ihnen Schritt-für-Schritt bei der Umsetzung. Kontaktieren Sie uns um ein unverbindliches Erstgespräch zu vereinbaren.

Lernen Sie unser UX Team kennen.
Bitte kontaktieren Sie mich gerne via eMail mit Ihren Fragen.

Questions About Test Frameworks: Q&A Part #3 with J.B. Rainsberger

/0 Kommentare/in /von

This is the third chapter of our three-part Q&A blog series with J. B. Rainsberger. In this chapter he adresses questions about „Questions About Test Frameworks„. The first chapter and the second chapter is in our blog in case you missed it.

On June 3, 2020 J.B. Rainsberger spoke in our remote Intro Talk about managing the various kinds of uncertainty that we routinely encounter on projects that involve legacy code. He presented a handful of ideas for how we might improve our practices related to testing, design, planning, and collaboration. These ideas and practices help us with general software project work, but they help us even more when working with legacy code, since legacy code tends to add significant uncertainty and pressure to every bit of our work. Fortunately, we can build our skill while doing everyday work away from legacy code, then exploit that extra skill when we work with legacy code.

J. B. Rainsberger helps software companies better satisfy their customers and the business that they support.

Our next remote course Surviving Legacy Code from 14-17 September 2020.

Course Outline & Registration

If the code base is too old even for any available test frameworks, how you handle it?

**Testing does not need frameworks. Testing never needed frameworks.** You can always start by just writing tests and refactoring them. If you do this long enough, you will extract a testing framework. If you’ve never tried it, then I recommend it! Kent Beck’s _Test-Driven Development: By Example_ included this exercise.

Every test framework began life with `if (!condition) { throw Error(„Test failure.“) }`. If you can write this, then you can build a testing framework; if this suffices, then you don’t need a testing framework. Start there!

If you can execute one part of the system in isolation from the rest, then you can write unit tests. In the early days of web browsers, we could only execute Javascript in the browser, because even so, we could (and did!) write unit tests without frameworks. We merely had to run those tests in a browser window. Eventually, someone decided to run Javascript outside the browser, which made it easier to write microtests for Javascript code. This made it _easier_ to write tests, but we were writing tests long before NodeJS existed.

If you can invoke a function (or procedure or division or block of code) and you can signal failure (such as by raising an error), then you can write tests without waiting for someone else to build a framework.

In addition, you don’t need to write your tests in the same language or environment as the running system. Golden Master technique helps us write tests for any system that offers a text-based interface. Any protocol could help us here: for example, think of HTTP as „merely“ a special way of formatting requests and responses with text. If you have (or can easily add) this kind of interface or protocol to your system, then you can write tests in any language that might offer a convenient test framework. Use Python to test your COBOL code. Why not?

Finally, not all testing must be automated. As I wrote earlier, programmers have a strong habit of forgetting alternatives to techniques that they’ve found helpful. If you don’t know how to automate your tests easily, then don’t automate them yet. Instead, make them repeatable and document them. One day, someone will have a good idea about how to automate them.

You may have to write your own test framework but it can prove a daunting task.

In addition to what I wrote in the previous answer, I encourage you to follow the general advice about building any software with a Lightweight (Agile, Lean, …) approach: build the first feature that you need, then start using it, then add more features one at a time. You don’t need to build a fully-featured testing framework before you start to benefit from it. Start with `if (!assertion) throw Error()` and then use it! The testing framework SUnit was built incrementally. All the testing frameworks you know began from there. You can do it, too. Merely start, then take one step at a time.

You also need this refactoring-without-tests skill, to effectively refactor your tests!

Maybe! I don’t say you _need_ it, but it would probably help you. Your production code helps you to refactor your tests: if you change your tests and they now expect the wrong behavior, then your production code will fail that test for „the right reasons“. It doesn’t provide perfect coverage, but it helps more than you might expect. In that way, the production code helps to test the tests.

There are testing frameworks for COBOL and NATURAL. What could be older?

Indeed, the „framework“ portion of testing relates to identifying tests, collecting test results, and reporting them in a unified way, as well as adding standard mechanisms for „set up“ and „tear down“. We don’t need those things to start writing tests, although eventually we will probably want to have them. **Simply start writing tests, then remove duplication in any way that your programing language allows.** I don’t know what might be older than COBOL or NATURAL.

➡️ Also read our last two Q & A Blogposts with J.B. Rainsberger Part #1 „Managing the Uncertainty of Legacy Code“ and Part #2 „The Risks Related to Refactoring Without Tests„! Follow us on Twitter or LinkedIn to get new posts.

Gamification, Mixed Reality, Barrierefreiheit: Die Trends und Highlights der German CHI Week

/0 Kommentare/in /von

Vom 25. bis 29. Mai hat Veronika Winter von Techtalk an der German CHI Week teilgenommen und die virtuelle Konferenz genutzt, um neue UX Trends zu erforschen und einen Einblick in Tendenzen rund um das Thema Human-Computer-Interaction (HCI)  zu bekommen. Über ZOOM kamen Experten der User Experience (UX) Community zusammen und lernten in über 120 Präsentationen die Arbeit von Forschungseinrichtungen deutscher Universitäten kennen.

Bei der diesjährigen German CHI Week standen die Themenschwerpunkte Mixed Reality, Games and Gamification, CSCW and InfoVis (Cross-Device-Interaction and InfoVisualisations), Eye and Brain, Accessibility & Well-Being, Wearables, VR (Virtual Reality), Artificial Intelligence & Smart Home Data, Usable Security and Privacy, Input, Methodology, Automotive & Robots and At the Workplace auf dem Programm.

Highlights zu den unterschiedlichen Themenbereichen

Die präsentierten Inhalte stammen direkt aus der Forschung und bieten die Möglichkeit, Trends von Anfang an zu beobachten und auf dem neuesten Stand zu bleiben. Von den verschiedenen Vorträgen zu neuen Technologien und zukünftigen Entwicklungen haben wir daher viel mitnehmen können und sind gespannt, wie diese sich in den nächsten Jahren positionieren werden und welche Themen sich durchsetzen.

Forschungsarbeiten aus dem Bereich “Games und Gamification”

Im Bereich “Games und Gamification” gibt es viele vielversprechende Forschungsprojekte:

  • Figure 1: Storyboard of the gamification element „Badges“
  • Figure 2: Storyboard of the gamification element „Cheating“
  • Eine der Präsentationen hat sich mit verschiedenen Aspekten von Social Interaction und Social Anxiety in Spielen auseinandergesetzt und eine Methode entwickelt um toxisches und schädliches Verhaltens von Spielern in Online-Spielen zu erkennen.
  • Normalerweise werden Gamification Elemente vom Development-Team ausgesucht. In einem der vorgestellten Forschungsprojekte konnten die User einer Anwendung ein eigenes Gamification-Konzept auswählen. Auf diese Weise wurde getestet, welches Konzept die höchste User Motivation hervorbringt.

Forschungsarbeiten aus dem Bereich “Barrierefreiheit”

Die Themen Barrierefreiheit und Accessibility werden in der Zukunft mehr Aufmerksamkeit erhalten. Hierzu wurden verschiedene Benutzerstudien präsentiert, welche speziell mit älteren Menschen durchgeführt wurden. Besonders Projekte in den Bereichen Mobilität, Coaching und physikalisches Training von älteren Menschen standen dieses Jahr mehrfach im Fokus der Veranstaltung. Einige spannenden Projekte haben uns besonders beeindruckt:

  • Ein besonders innovatives Team hat zum Beispiel ein Prototyp präsentiert, der den typischen Blindenstock mit Virtual Reality kombiniert. 
  • Ein weiteres Beispiel war ein Forschungsprojekt zum Thema Augmented Reality for Older Adults, welches das Thema Augmented Reality mit älteren Menschen in den Fokus stellt und untersucht, ob die Zielgruppe mittels eines virtuellen Coaches besseres Balance-Training erleben können.

TechTalk hat zum Thema Barrierefreiheit für Webseiten und mobilen Anwendungen bereits in einem anderen Kontext berichtet.

Forschungsarbeiten aus dem Bereich “Cross-Device-Interaction and InfoVisualisations

Forschungsarbeiten aus dem Bereich “Mixed Reality”

Die Forschungsarbeiten im Bereich “Mixed reality” boten einen spannenden Einblick in den aktuellen Forschungsstand. Einige Projekte in diesem Bereich waren besonders interessant: Ein System namens Ambi plant arbeitet mit künstlichen Pflanzen die sich zu Musik, Spielen oder bei Filmen bewegen. Auch eine Forschungsarbeit mit Benutzerstudien zur Sicherheit von Fahrradfahrern im Straßenverkehr sowie ein Experiment zur Visualisierung von Objekten in einer neuen Umgebung welches AR glasses Hololense sowie 3D Modelle nutzt um Usern eine bessere Vorstellung zu ermöglicht boten neue Erkenntnisse.

Forschungsarbeiten aus dem Bereich “Wearables”

Ein weiterer Themenschwerpunkt waren Wearables, also tragbare Computertechnologien, wie zum Beispiel die Smart Watch. Hierzu gibt ein Forschungsprojekt zur Erhöhung der Bildschirmgröße einer Smart Watch, indem auch das Uhrband als Screen verwendet wird. Weitere Projekte gibt es zu den Themen Smart Textiles, also smarte Kleidungsstücke, welche mit Sensoren ausgestattet sind und zum Beispiel Druck und Verformung erfassen können.

Trends auf der Spur: 120 Sessions an fünf Tagen

Das Format der German CHI Week ermöglichte es, dass viele verschiedene Themen in kurzer Zeit behandelt werden konnten:

  • Programm von Montag bis Freitag je 17.00 – 19.00 CET
  • Täglich drei Sessions hintereinander, je 40 Minuten

Für jedes Paper wurden vorab von den Autoren aufgezeichnete Videopräsentationen von je 3 Minuten vorbereitet. Auf diese Weise erhielten die Teilnehmenden einen kurzen Überblick zum Thema und konnten dann direkt in die 20-minütige Podiumsdiskussion starten.

Videoaufnahmen der German CHI Week & UX Support

Alle Videoaufnahme der German CHI Week finden Sie auf Youtube, die Publikationen sind auf der Webseite des Veranstalters online.

Haben Sie weitere Fragen rund um UX?

Unser Team unterstützt Sie bei Ihren Herausforderungen im Bereich UX um sicherzustellen dass ihre AnwenderInnen zufriedene Benutzer werden.

Lernen Sie unser UX Team kennen.
Bitte kontaktieren Sie mich gerne via eMail mit Ihren Fragen.

The Risks Related to Refactoring Without Tests: Q&A Part #2 with J.B. Rainsberger

/0 Kommentare/in /von

This is the second chapter of our three-part Q&A blog series with J. B. Rainsberger. In this chapter he adresses questions about „The Risks Related to Refactoring Without Tests„. The first chapter is in our blog in case you missed it.

On June 3, 2020 J.B. Rainsberger spoke in our remote Intro Talk about managing the various kinds of uncertainty that we routinely encounter on projects that involve legacy code. He presented a handful of ideas for how we might improve our practices related to testing, design, planning, and collaboration. These ideas and practices help us with general software project work, but they help us even more when working with legacy code, since legacy code tends to add significant uncertainty and pressure to every bit of our work. Fortunately, we can build our skill while doing everyday work away from legacy code, then exploit that extra skill when we work with legacy code.

J. B. Rainsberger helps software companies better satisfy their customers and the business that they support

Our next remote course Surviving Legacy Code from 14-17 September 2020.

Course Outline & Registration

What we should say to project planners who are afraid to let us do refactoring without tests, because some folks in our team are not very good at refactoring and make mistakes? How to convince them it can work for some good programmers?

First, I recognize that if I were the project planner, then I would worry about this, too! I probably don’t know how to judge the refactoring skill of the programmers in the group, so I wouldn’t know whom to trust to refactor without tests. Moreover, I probably can’t calculate the risk associated with refactoring without tests, so I wouldn’t know when to trust _anyone_ to refactor without tests, even if I feel confident in their skill. Once I have thought about these things, it becomes easier to formulate a strategy, because I can ask myself what would make _me_ feel better in this situation? I encourage you to ask yourself this question and write down a few ways that you believe you could increase your confidence from the point of view of the project planner. I can provide a few general ideas here.

I encourage you to build trust by telling the project planner that you are aware of the risks, that you care about protecting the profit stream of the code base, and that you are prepared to discuss the details with them. It often helps a lot simply to show them that you and they are working together to solve this problem and not that you are doing what helps you while creating problems for them.

I would ask the project planners what specifically they are worried about, then matching my strategies to their worries. For example, microcommitting provides one way to manage the risk of refactoring without tests, because it reduces the cost of recovering from a mistake. At the same time, if the project planner worries about different risks than the ones I have thought about, then my strategies might not make them feel any more secure! If I know more about which risks affect them more or concern them more, then I can focus my risk-management work on those points, which also helps to build trust.

I would emphasize that we do not intend to do this as a primary strategy forever. We don’t feel comfortable doing it, either! Even so, we _must_ make progress _somehow_. We refactor without tests because it would be even more expensive to add „enough“ tests than to recover from our mistakes. Of course, we have to be willing to explain our judgment here and we have to be prepared that we are wrong in that judgment! I am always prepared to take suggestions from anyone who has better ideas, but outside of that, they hired me to do good work and make sound decisions, so if they don’t trust me, then I must try to earn their trust or they should give my job to someone that they trust more. I don’t mean this last part as a threat, but merely as a reminder that if they hire me to do the job, but they never trust me, then they _should_ hire someone else!

How about pair-refactoring?

I love it! Refactoring legacy code is often difficult and tiring work, so pair-refactoring fits well even in places where „ordinary“ pair programing might not be needed. Refactoring legacy code often alternates periods of difficulty understanding what to do next with long periods of tedious work. Working in pairs significantly increases the profit from both of those kinds of tasks.

You also need this refactoring-without-tests skill, to effectively refactor your tests!

Maybe! I don’t say you _need_ it, but it would probably help you. Your production code helps you to refactor your tests: if you change your tests and they now expect the wrong behavior, then your production code will fail that test for „the right reasons“. It doesn’t provide perfect coverage, but it helps more than you might expect. In that way, the production code helps to test the tests.

Moreover, tests tend to have simpler design than the production code. This means that we might never need to refactor tests in certain ways that feel common when we refactor production code. I almost always write tests with a cyclomatic complexity of 1 (no branching), so the risk when refactoring tests tends to be much lower than when refactoring legacy code. This makes refactoring tests generally safer.

➡️ Also read our two Q&A Blogposts with J.B. Rainsberger Part #1 „The Risks Related to Refactoring Without Tests“ and Part #3 „Questions About Test Frameworks„! Follow us on Twitter or LinkedIn to get new posts.

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

/0 Kommentare/in /von
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 „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.

Course Outline & Registration

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.

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.  

Course Outline & Registration

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

/0 Kommentare/in /von

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 Anbieter wechseln 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?

Haben Sie weitere Fragen zur Auswahl von agilen Anbietern?

Oder wollen Sie in Ihrem Unternehmen ein Umfeld entwickeln um die Arbeit nach agilen Methoden zu ermöglichen?

Bitte kontaktieren Sie mich gerne via eMail oder auf LinkedIn mit Ihren Fragen.

Managing the Uncertainty of Legacy Code: Q&A Part #1 with J.B. Rainsberger

/in /von

In this first chapter of our three-part Q&A blog series he adressed questions that came up during his session.

On June 3, 2020 J.B. Rainsberger spoke in our remote Intro Talk about managing the various kinds of uncertainty that we routinely encounter on projects that involve legacy code. He presented a handful of ideas for how we might improve our practices related to testing, design, planning, and collaboration. These ideas and practices help us with general software project work, but they help us even more when working with legacy code, since legacy code tends to add significant uncertainty and pressure to every bit of our work. Fortunately, we can build our skill while doing everyday work away from legacy code, then exploit that extra skill when we work with legacy code.

Our next remote course Surviving Legacy Code from 14-17 September 2020.

J. B. Rainsberger helps software companies better satisfy their customers and the business that they support.
Course Outline & Registration

Here are some questions that came up during this session and some answers to those questions.

One of the issues is that the legacy code base consists of useful code and dead code and it’s hard to know which is which.

Indeed so. Working with legacy code tends to increase the likelihood of wasting time working with dead code before we feel confident to delete it. I don’t know how to avoid this risk, so I combine monitoring, testing, and microcommitting to mitigate the risk.

Microcommits make it easier to remove code safely because we can recover it more safely. Committing frequently helps, but also committing surgically (the smallest portion of code that we know is dead) and cohesively (portions of code that seem logically related to each other) helps. If our commits are more independent, then it’s easier to move them backward and forward in time, which makes it easier to recover some code that we mistakenly deleted earlier while disturbing the live code less. We will probably never do this perfectly, but smaller and more-cohesive commits make it more likely to succeed. This seems like a special case of the general principle that as I trust my ability to recover from mistakes more, I feel less worried about making mistakes, so I change things more aggressively. When I learned test-driven development in the early years of my career, I noticed that I become much more confident to change things, because I could change them back more safely. Practising test-driven development in general and microcommitting when working with legacy code combine to help the programmer feel more confident to delete code—not only code that seems dead.

Even with all this, you might still feel afraid to delete that code. In that case, you could add “Someone executed this code” logging statements, then monitor the system for those logging statements. You could track the length of time since you last saw each of these “heartbeat” logging messages, then make a guess when it becomes safe to delete that code. You might decide that if nothing has executed that code in 6 months, then you judge it as dead and plan to remove it. This could never give us perfect confidence, but at least it goes beyond guessing to gathering some amount of evidence to support our guesses

More testing, especially microtesting, puts more positive pressure on the design to become simpler: less duplication, better names, healthier dependencies, more referential transparency. I have noticed a pattern: as I simplify the design, I find it easier to notice parts that look irrelevant and I find it clearer that those parts are indeed dead code. Moreover, sometimes obviously dead code simply appears before my eyes without trying! This makes it safer to delete that code, using the microcommitting and monitoring as a recovery strategy in case I get it wrong.

So not all legacy code adds value to the business… but it is hard to know which part does.

Indeed so. We have to spend time, energy, and money to figure this out. I accept responsibility as a programmer to give the business more options to decide when to keep the more-profitable parts running and to retire the less-profitable parts. As I improve the design of the system, I create more options by making it less expensive to separate and isolate parts of the system from each other, which reduces the cost of replacing or removing various parts. Remember: we refactor in order to reduce volatility in the marginal cost of features, but more-generally in the marginal cost of any changes, which might include strangling a troublesome subsystem or a less-profitable feature area.

The Strangler approach describes incrementally replacing something in place: adding the new thing alongside the old thing, then gradually sending traffic to the new thing until the old thing becomes dead. Refactoring the system to improve the health of the dependencies makes this strangling strategy more effective, which gives the business more options to replace parts of the legacy system as they determine that a replacement would likely generate more profit. As we improve the dependencies within the system, we give the business more options by reducing the size of the smallest part that we’d need to replace. If we make every part of the system easier to replace, then we increase the chances of investing less to replace less-profitable code with more-profitable code.

This illustrates a general principle of risk management: if we don’t know how to reduce the probability of failure, then we try reducing the cost of failure. If we can’t clearly see which parts of the legacy code generate more profit and which ones generate less, then we could instead work to reduce the cost of replacing anything, so that we waste less money trying to replace things. This uses the strategy outlined in Black Swan of accepting small losses more often in order to create the possibility of unplanned large wins.

What do you think about exploratory refactoring? Do you use this technique sometimes?

Yes, I absolutely do! I believe that programmers can benefit from both exploratory refactoring and feature-oriented refactoring, but they need to remain aware of which they are doing at any time, because they might need to work differently with each strategy to achieve those benefits.

When I’m refactoring in order to add a feature or change a specific part of the code, I remind myself to focus on that part of the code and to treat any other issues I find as distractions. I write down other design problems or testing tasks in my Inbox as I work. I relentlessly resist the urge to do those things “while I’m in this part of the code”. I don’t even follow the Two-Minute Rule here: I insist on refactoring only the code that right now stands between me and finishing the task. Once I have added my feature, I release the changes, then spend perhaps 30 minutes cleaning up before moving on, which might include finishing a few of those Two-Minute tasks.

The rest of the time, I’m exploring. I’m removing duplication, improving names, trying to add microtests, and hoping that those activities lead somewhere helpful. This reminds me of the part of The Goal, when the manufacturing floor workers engineered a sale by creating an efficiency that nobody in the sales department had previously thought possible. When I do this, I take great care to timebox the activity. I use timers to monitor how much time I’m investing and I stop when my time runs out. I take frequent breaks—I use programming episodes of about 40 minutes—in order to give my mind a chance to rise out of the details and notice higher-level patterns. I don’t worry about making progress, because I donI ’t yet know what progress would look like—instead I know it when I see it. By putting all these safeguards in place, I feel confident in letting myself focus deeply on exploring by refactoring. I avoid distracting feelings of guilt or pressure while I do this work. I also feel comfortable throwing it all away in case it leads nowhere good or somewhere bad. This combination of enabling focus and limiting investment leads me over time to increasingly better results. As I learn more about the code, exploratory refactoring turns into feature-oriented refactoring, which provides more slack for more exploratory refactoring, creating a virtuous cycle.

What is your experience with Approval Tests, in cases where writing conventional unit tests might be to expensive?

I like the Golden Master technique (and particularly using the Approval Tests library), especially when text is already a convenient format for describing the output of the system. I use it freely and teach it as part of my Surviving Legacy Code course. It provides a way to create tests from whatever text output the system might already produce.

I get nervous when programmers start going out of their way to add a text-based interfaces to code that doesn’t otherwise need it only for the purpose of writing Golden Master tests. In this case, checking objects in memory with equals() tends to work well enough and costs less. I notice it often that programmers discover a helpful technique, then try to use it everywhere, then run into difficulties, then invest more in overcoming those difficulties than they would invest in merely doing things another way. Golden Master/Approval Tests represents merely another situation in which this risk comes to the surface.

I get nervous when programmers start choosing to write integrated tests for code where microtests would work equally well. When programmers think about adding Golden Master tests, they tend to think of these as end-to-end tests, because they often judge that as the wisest place to start. Just as in the previous paragraph, they sometimes fall into the trap of believing that “since it has helped so far, we must always do it this way”. No law prevents you from writing unit tests using Golden Master/Approval Tests! Indeed, some of the participants of my Surviving Legacy Code training independently discover this idea and use it to great effect. Imagine a single function that tangles together complicated calculations and JSON integration: it might help a lot to use Approval Tests to write Golden Master tests for this function while you slowly isolate the calculations from the JSON parsing and formatting. The Golden Master tests work very well with multiline text, such as values expressed in JSON format, but probably make the calculation tests awkward, compared with merely checking numeric values in memory using assertEquals().

When programmers use Golden Master/Approval Tests, they need to treat it as just one tool in their toolbox. This is the same as with any technique! I tend to treat Golden Master as a temporary and complementary technique. I use it when I focus on writing tests as a testing technique, even though I tend to prefer to write tests for design feedback. Not everyone does this! If you find yourself in the stage where you’re drowning in defects and need to focus on fixing them, then Golden Master can be a great tool to get many tests running early. Once you’ve stopped drowning, it becomes easier to look at replacing Golden Master with simpler and more-powerful unit tests—eventually microtests.

➡️ Also read our two Q&A Blogposts with J.B. Rainsberger Part #2 „The Risks Related to Refactoring Without Tests„ and Part #3 „Questions About Test Frameworks„! Follow us on Twitter or LinkedIn to get new posts.

Klassische oder agile Verträge: So finden Sie die passende Vertragsart

/in /von

Klassische Projekte und deren Verträge haben eine entscheidende Schwäche. Obwohl sie ein großes Maß an (vermeintlicher) Budget-Sicherheit bieten, können sie bei der Geschwindigkeit der schnelllebigen Unternehmenswelt kaum noch mithalten.

So wird aus der Sicherheit, genau zu wissen, wann ein Produkt fertig ist und welche Funktionen es umfasst, die Gefahr, ein veraltetes Produkt zu erhalten, das nicht mehr den aktuellen Anforderungen entspricht.

Gerade bei komplexen Softwareproblemen stoßen Sie mit klassischen Verträgen schnell an die Grenze. Denn in der modernen Softwareentwicklung wird zunehmend agil entwickelt. Das bedeutet: Weder das Produkt, das geliefert wird, noch wann das Produkt fertig wird, stehen zu Beginn der Zusammenarbeit eindeutig fest. Vertraglich lässt sich dies nur über Verträge abdecken, die eine agile Zusammenarbeit ermöglichen.

In diesem Artikel erfahren Sie, was genau „agile Verträge“ ausmacht und ob sie auch für Ihr Projekt geeignet sind.

4 entscheidende Unterschiede von klassischen und agilen Verträgen

Zunächst einmal schauen wir uns an, wie sich klassische und agile Verträge unterscheiden. Ich habe die wichtigsten Unterschiede in einem kurzen Video auf den Punkt gebracht:

Es lässt sich festhalten, dass sich die beiden Vertragsarten vor allem in vier grundlegenden Punkten unterscheiden:

  1. Projektumfang: Bei einem klassischen Werkvertrag ist der Projektumfang meistens auf einen langen Zeitraum festgelegt. Das bedeutet, alle Anforderungen werden in einem Pflichtenheft gesammelt und anschließend abgearbeitet. Nicht so bei einem agilen Vertrag. Hier können Änderungen nach jedem Sprint vorgenommen werden. Dadurch kann das Entwicklerteam Feedback zeitnah berücksichtigen. Die Basis ist jedoch auch hier ein Backlog, bei dem der Aufwand zu Beginn geschätzt wird.
  2. Projektzeitraum: Der Zeitpunkt der Releases und Milestones ist bei klassischen Verträgen festgelegt. Bei agilen Verträgen gilt: Das Projekt ist beendet, sobald das Produkt fertig ist. Natürlich können Sie auch einen Zeitraum bzw. eine fixe Anzahl an Sprints festlegen. Ergebnisse, die zu diesem Zeitpunkt bereits vorhanden sind, können Sie übernehmen.
  3. Release-Zyklen: Die Release-Zyklen bei klassischen Projekten betragen mehrere Monate bis Jahre. Bei agilen Verträgen gibt es im Idealfall nach jedem Zyklus (Sprint) einen Prototypen, der getestet werden kann.
  4. Budget: Das Budget kann bei beiden Vertragsmodellen sowohl nach T&M (Time & Material, oder auf deutsch Vertrag auf Zeit und Materialbasis) abgerechnet werden oder auch fixiert werden. Im agilen Fall heißt das, dass eine bestimmte „Run-Rate“ des Teams budgetiert wird.
  5. Steuerung: Hier gilt Output vs. Outcome. Bei klassischen Verträgen wird zum Beispiel gemessen, ob das Entwicklerteam zum Zeitpunkt X den entsprechenden Milestone erreicht hat. Bei agilen Verträgen wird geprüft, ob das Produkt die Anforderungen der Kunden erfüllt.

Zusammenfassend lässt sich festhalten, dass bei klassischen Verträgen ganz klar die Budget-Sicherheit im Vordergrund steht. Agile Verträge geben dem Entwicklerteam deutlich größere Freiheiten, auf kurzfristige Änderungen zu reagieren und regelmäßig Feedback zu sammeln, um schlussendlich das beste Produkt für Kunden zu entwickeln.

So finden Sie die passende Vertragsart

Ob agile oder klassische Verträge die bessere Wahl sind, hängt von zwei grundlegenden Faktoren ab: der Projektkomplexität und der Arbeitsweise in Ihrem Unternehmen.

Komplexe Projekte brauchen agile Verträge

Agile Verträge sind nicht für jedes Projekt die richtige Wahl. Es ist entscheidend, dass Sie sich im Vorfeld Gedanken machen, welche Aufgaben im Projekt anfallen und wie gut Sie sie definieren können. Hierbei können Ihnen folgende Fragen helfen:

  • Sind Sie sich sicher, dass sich die Rahmenbedingungen während des Projekts nicht ändern werden? 
  • Sind Sie sicher, dass sich der Wert für Ihr Unternehmen genauso erreichen lässt, wie Sie es definiert haben?
  • Bestehen die Aufgaben ausschließlich aus wiederkehrenden Tätigkeiten?
  • Sind die Risiken der technischen Implementierung gering bzw. sind die Anforderungen klar formulierbar? 
  • Ist das Projekt eher klein und nicht langfristig angelegt, sodass Sie kein Team für die Betreuung und Weiterentwicklung des Produkts benötigen?
  • Kaufen Sie ein standardisiertes Produkt, dass keine Integration in ein bestehendes Produkt benötigt? 

Wenn Sie alle Fragen mit „Ja“ beantworten können, ist vermutlich ein klassischer Vertrag ausreichend. Ihr Projekt und die Anforderungen lassen sich im Vorfeld bereits genau definieren. Anders sieht es aus, wenn Sie nur einige der Fragen mit „Ja“ beantworten können. In diesem Fall ist es lohnenswert, sich das Thema agile Verträge genauer anzuschauen.

Keine agilen Verträge ohne agile Arbeitsweise

Die Komplexität Ihres Projekts ist allerdings nicht der einzige entscheidende Faktor. Wenn Sie in Ihrem Unternehmen nicht in der Lage sind, agile Projekte umzusetzen, bringt Sie auch ein agiler Vertrag nicht weiter.

Denn um das bestmögliche Produkt agil zu entwickeln, muss bei einer Anbieter-Kunden-Beziehung eine Kultur herrschen, die eine enge Zusammenarbeit und Anpassungsfähigkeit ermöglicht. Die Grundlage bilden hierbei die Prinzipien des agilen Manifestos. Ursprünglich stammt das Manifesto aus der Softwareentwicklung. Es lässt sich jedoch auch auf Unternehmen übertragen. 

Überlegen Sie sich, ob Sie in Ihrem Unternehmen eine Basis für agile Projekte besitzen und folgende Punkte gewährleisten können:

  • Feedback-Zyklen: Sie sind in der Lage, schnelle Feedback-Zyklen (idealerweise alle 2 bis 4 Wochen) umzusetzen und dem Entwicklerteam kontinuierliches Feedback zu geben.
  • Transparenz: Sie können während des Projekts vollständige Transparenz gewährleisten. Das bedeutet das Entwicklerteam hat einen Zugang zum Backlog, dem Fortschritt der Implementierung unterschiedlicher Features und den Ergebnissen nach jedem Feedback-Zyklus.
  • Variabler Projektumfang: Sie sind damit einverstanden, dass das Feedback nach jedem Zyklus mit in die weitere Produktentwicklung einfließt. Projektumfang und Aufgaben können entsprechend angepasst werden. Die Option muss auch vertraglich festgehalten werden, zum Beispiel über eine „Changes for free“ Klausel. Sie ermöglicht Änderungen im Backlog, sofern sie keinen Mehraufwand bedeuten.
  • Effektive Zusammenarbeit: Sie können eine enge Zusammenarbeit zwischen sich, dem Entwicklerteam und dem Endkunden gewährleisten. Idealerweise arbeitet das Team an einem Ort, sodass eine direkte und informelle Kommunikation möglich ist. Wenn der Anbieter eine Person vor Ort stellt, die eine aktive Rolle im Projekt übernimmt (keine Managementrolle, die nur als Verbindung zum Entwicklerteam dient) ist dies von Vorteil.

Wenn Sie die folgenden Punkten umsetzen können und außerdem komplexe Projekte haben, sind agile Verträge vermutlich eine gute Wahl. Sollten Sie noch kein agiles Mindset in Ihrem Unternehmen etabliert haben und dennoch mit agilen Projekten arbeiten wollen, können Sie sich mit Workshops diesem Ziel nach und nach annähern. Schreiben Sie uns gerne, wenn Sie weitere Informationen benötigen. 

Wann ist eine agile Arbeitsweise sinnvoll?

Kein Projekt ist wie das andere. Und kein Unternehmen gleicht dem anderen. Daher können für die Zusammenarbeit mit Ihren Kunden und Partnern nicht immer die gleichen starren Rahmenbedingungen gelten.

Überlegen Sie sich im Voraus, welche Rahmenbedingungen Sie für das jeweilige Projekt benötigen und ob Ihr Unternehmen eine agile Arbeitsweise lebt. Vor allem, wenn Sie komplexe Projekte umsetzen wollen, bieten eine agile Arbeitsweise bzw. agile Verträge eine solide Grundlage.

Haben Sie weitere Fragen zur Umsetzung von Projekten mit agilen Verträgen?

Oder wollen Sie in Ihrem Unternehmen ein Umfeld entwickeln um die Arbeit nach agilen Methoden zu ermöglichen?

Bitte kontaktieren Sie mich gerne via eMail oder auf LinkedIn mit Ihren Fragen.

Approval Testing: What It Is and How It Helps You To Manage Legacy Code

/in /von

Emily Bache is a Technical Agile Coach, she helps software development teams to get better at the technical practices needed to be agile, including Test-Driven Development, Refactoring, and Incremental Design. Emily is known as the author of the book, “The Coding Dojo Handbook”. For the second time, we organize a training course with Emily on Approval Testing. In this email interview we asked Emily what counts as legacy code, how to get into approval testing, and what her upcoming book will be about.

What is the optimal way of learning Approval Testing? What is the role of Gilded Rose Kata and other exercises in this process? 

Approval Testing is a style and approach to writing automated tests that changes the way you verify behaviour. Basically, the ‘assert’ part of the test. As with any new tool or approach, it helps to have actual code examples to play with when you’re learning it. Once you start to see it in action then you’re bound to have lots of questions so it’s good to have people around you to discuss it with.

The Gilded Rose Kata is a fun little exercise that I maintain. It actually comes with approval tests, as well as being translated into about 40 programming languages. Whatever your coding background and language preferences, you can try it out and see how it works for yourself. When you’ve done that, you should easily be able to find other people to discuss it with, since it’s quite a popular exercise. For example Ron Jeffries recently wrote 13(!) blog posts about his experience with it.

You talk about refactoring and handling legacy code? What is actually legacy code? How would you define it? 

Many developers struggle with code they inherited which has poor design and lacks automated tests. On their own, any one of those difficulties could probably be overcome, but in combination developers get a kind of paralyzing fear of changing the code. That’s how I would define legacy code. Code that you need to change but you’re afraid to in case you break it.

The antidote to that fear, I find, is feedback. High-quality feedback telling the developer when they are making safe changes. The feedback that gives them the confidence to improve the design and get in control. Approval testing is one way to get that feedback – you create regression tests that give you good information when behaviour changes.

Course Outline & Registration

What are the main things one should know before starting working with Approval Testing? 

Since it’s a style of automated testing, it helps to have experience with unit testing already, perhaps with JUnit or similar. Approval Testing is often used in larger-granularity tests too, so experience with tools like Selenium or Cucumber would give you a good perspective, although it works a bit differently. This way of testing also fits extremely well into Agile methods, BDD, and Specification by Example. If you are working in a more traditional process, you may find adding these kinds of tests will help you to increase your agility.

For which situations is Approval Testing the best solution? When shouldn’t it be used? 

If you’re facing legacy code, this can be a great addition to your strategy for getting control. I wouldn’t discount it for new development though, particularly if your system will produce some kind of detailed artifact where the user really cares about how it looks. For example I’ve seen this approach used to verify things like invoices, airline crew schedules, 3D molecular visualizations, and hospital blood test results.

Of course there are situations where I wouldn’t use Approval Testing, for example where the output is a single number – the result of a complex calculation. If you can calculate the expected result before you write the code, testing it with an ordinary assertion is a sensible approach.

Can Behaviour Driven Development be considered as the future of the industry and Approval Testing as an essential part of it? Why is it so?  

The main priority of BDD is to improve collaboration and communication so we build the right software. In my experience Approval testing promotes good conversations. I’m giving a keynote speech at Cukenfest soon, (a conference about BDD), and I’m going to be talking about exactly this topic. For the test automation part of BDD most teams use the Gherkin syntax with Cucumber or SpecFlow. I think you can use Approval testing in a similar way.

You have been working on this topic for a while  – what excites you about it? 

There is so much potential for this technique! I see a lot of legacy code out there, and I see a lot of test cases that are unnecessarily difficult to maintain. If I can spread these testing techniques to even a small proportion of all those places it will make a huge positive difference to the quality of the software in the world.

You wrote a book about Coding Dojo, what can we expect from your follow-up book? 

The motivation for my upcoming book “Technical Agile Coaching” is largely the same as for the previous one – I write for people who want to make a difference and improve the way software is built. In 2011 I published „The Coding Dojo Handbook“ which is full of advice and experiences setting up a forum for practicing coding skills. You can see my new book as an expansion of those ideas, seasoned with ten years of additional experience.

The focus of the coaching method I describe in the book is specifically on technical practices and how people write code. There are two main elements to the coaching. Firstly teaching techniques via interactive exercises and code katas. Secondly coaching a whole team to work effectively together as they do mob programming.

Course Outline & Registration

WZG verstehen und umsetzen – Barrierefreiheit in der öffentlichen Verwaltung

/in /von

Vergangenes Jahr wurde für die Barrierefreiheit in der öffentlichen Verwaltung wieder ein wichtiger Schritt gemacht – das Web-Zugänglichkeits-Gesetz (kurz: WZG) wurde im Juli 2019 in Österreich verabschiedet. 

Ähnlich der BIT-Verordnung in Deutschland wurde nun eine verpflichtende Regelung geschaffen, dass die Webseiten und mobilen Anwendungen des Bundes bzw. vom Bund finanzierten Einrichtungen die Anforderungen an die Barrierefreiheit erfüllen müssen und vor allem auch durch welche Aktivitäten dies gewährleistet werden soll. 

Anforderungen an die Barrierefreiheit laut WZG  

Im WZG verweisen die Anforderungen an die Barrierefreiheit vor allem auf die bereits länger festgelegten Richtlinien und damit gilt als Richtschnur die Erfüllung der Stufe AA der „Richtlinien für barrierefreie Webinhalte Web – WCAG 2.0“.  

In der Folgeabschätzung im Rahmen des Gesetzgebungsprozesses wurde davon ausgegangen, dass die Einführung des WZG keine zusätzlichen Kosten verursacht, da bereits seit 2004 mit dem E-Government-Gesetz behördliche Internetauftritte so zu gestalten sind, dass internationale Standards über die Web-Zugänglichkeit erfüllt werden. Aus meiner Sicht ist dies etwas zu kurz gegriffen, da nicht die volle Breite aller Angebot die Barrierefreiheit mit Stufe AA bisher berücksichtigt hat bzw. nun explizit auf mobile Anwendungen mit eingeschlossen sind. 

Aufgaben im Zusammenhang mit der Web-Zugänglichkeit 

Neben der Sicherstellung der Barrierefreiheit an sich, ist auch festgelegt, welche Aufgaben im Zusammenhang mit der Web-Zugänglichkeit zu erfüllen sind. So sind unter anderem die Mitarbeiterinnen und Mitarbeiter zum Thema barrierefreien Zugang zu schulen und zu sensibilisieren.

Darüber hinaus muss eine Erklärung zur Barrierefreiheit im Internet veröffentlicht werden – vergleichbar etwa mit der Datenschutzerklärung. Mit dieser Erklärung wird unter anderem dargelegt inwiefern die Anforderungen zur Barrierefreiheit erfüllt werden und wie dies überprüft wurde. Auch kann dargelegt werden wieso Anforderungen nicht erfüllt wurden, wenn die Behebung eine unverhältnismäßige Belastung für die Einrichtung darstellen würde. 

Screenshot der Barrierefreiheitserklärung von oesterreich.gv.at  

Wissen im Bereich Barrierefreiheit 

Mit der Umsetzung von Anwendungen vor allem im öffentlichen Bereich setzt sich unser Team schon lange mit dem Thema Accessibility und Barrierefreiheit auseinander. Veronika Winter hat letztes Jahr zum Beispiel im Rahmen der Projektarbeit intensiv mit den aktuellen Anforderungen des BIT-V auseinandergesetzt.   

Auch im Bereich des Web-Zugänglichkeits-Gesetzes unterstützen wir gerne mit einer Statuserhebung mit konkreten Verbesserungsvorschlägen, einer individuellen Beratung oder Schulung.

Fragen Sie einfach unverbindlich bei Claudia Oster an.  

  • User Experience & Design Thinking Newsletter

    Jetzt abonnieren und keine Ausgabe verpassen. Max. 4 Ausgaben im Jahr.