Swiss Softball National Team Training

January 18, 2010, No Comments

I used these kinds of pictures for the Trainingsday of the Swiss National Softball Team to explain some common mistakes. All the pictures here [pdf], in case somebody wants to have a closer look at them later on.

First Swiss Testing Night - Impressions

June 12, 2009, 4 Comments

Here are some impressions from the first Swiss Testing Night:

I think this was the moment I was the most nervous: Being introduced by Adrian Zwingli (Chief Organizer). Everybody is ready, waiting for you. Then you realize: There’s no way back - only one way to go. That’s when most of the nervousness goes away - kind of like in baseball when you take the mound.

Setting things up. The remote control didn’t work, probably because the infrared receiver was blocked by the podium. And no headset style microphone - the room was set up for a speaker talking from behind the podium. No chance I was going to do that though. So I turned the podium sideways and picked the micro up - Rockstar style

I think that’s the moment I realized that saying “one of the reason for the existence of bugs are bug tracking tools” might not sit too well with our sponsor HP - who sells Quality Center and Winrunner among other things.

Oh well - sometimes you step on somebodys toe - life goes on. That plus HP has a mighty big toe.

This is one of my favorite slides (introducing the second part of the speech). A reference to Starship Troopers (how could you leave out a reference to the best movie ever, if your topic is “Crusade against Bugs”)?

A misunderstanding between the organizers and the location provided for about 20 chairs - the other 80 people had to stand the whole time. Before the speech I thought about having people rotate after every part of the speech. That way most people would get at least 15 min of sitting time. I’m afraid I forgot. Not that it was a good idea to begin with.

All the photos here were taken by Stephan Wiesner (@Stephan: If you’re reading - thanks a lot for letting me use them on my site).

Swiss Testing Night - Presentation

May 29, 2009, No Comments

The first Swiss Testing Night takes place on June 9th 2009 in Zurich. I’ll have 45 minutes to talk about “the crusade against bugs in software” to an audience of QA/Testing Specialists.

I’m totally excited! 

This is a similar talk I gave at a bbv Q-Event last year. I’ll change things a little bit (especially the last part, which I wasn’t all happy with).

I hope to meet a lot of people and have some interesting, stimulating and world changing discussions. Let’s create software that works. Let’s rock!

Auf dem Kreuzzug gegen Fehler (in Software)

September 4, 2008, 5 Comments

“Auf dem Kreuzzug gegen Fehler in Software” ist eine Präsentation die ich am 4.9.2008 für die bbv Software Services AG gehalten habe. Hier ist die Präsentation als Artikel Form - für all diejenigen die nicht an die Präsentation kommen konnten.

Der erste Teil behandelt einige Dinge die auf den ersten Blick normal und richtig erscheinen - aber beim näheren hinschauen Fehler garantieren.

Software wird getestet, wenn sie fertig ist. Das Problem dabei ist die Interpretation von “Fertig”. Wann ist die Software soweit, dass sie getestet werden kann. Das folgende ist die Interpretation der Entwickler und zeigt warum Software oft mit sehr vielen Fehlern in die “Testphase” geht.

Auf der Y-Koordinate haben wir den Prozentgrad der Fertigstellung der Software. Auf der X-Achse ist die Zeit die vergeht und die Deadline, die gesetzt ist. Die Entwickler machen stetigen Fortschritt und merken dann nach etwa zwei Drittel dass es knapp wird. An diesem Punkt beginnen sie härter, schlauer und mehr zu arbeiten und werden genau auf die Deadline fertig. “YEAH!” - Zeit für die Entwickler bei einem Apero anzustossen und sich gegenseitig auf die Schulter zu klopfen.

Was allerdings passiert ist, dass neben der eigentlichen Arbeit noch zusätzliche Arbeit gemacht wird. Versteckte Arbeit. Oder Negative Arbeit. Je näher wir zur Deadline kommen, desto mehr unentdeckte Fehler sind in der Software.

Fertig heisst für die Entwickler eigentlich nur: “Wir haben alle Features implementiert und jedes Features hat mindestens einmal Fehlerfrei (zumindest fast) funktioniert.”

Hier ein verwandtes Problem: Die Y-Achse zeigt an wie viel Zeit wir für eine Arbeit aufwenden. Auf der X-Achse haben wir wieder die vergehende Zeit. Die erste Linie ist: Wie viel Zeit verbringen wir mit dem eigentlichen erstellen der Software (Coding). In der Phase 1 wird wenig gemacht - die Entwickler versuchen die Business Domäne zu verstehen, schauen sich Frameworks an etc. Je näher die Deadline rückt, desto mehr fokussieren sie sich auf das erstellen der Features.

Auf der anderen Seite kümmern sich die Entwickler am Anfang sehr stark um das korrekte Verständnis der Anforderungen. Je näher die Deadline kommt, desto weniger arbeiten sie daran.

Auf den ersten Blick scheint das Sinn zu machen. Wenn man die Anforderungen einmal verstanden hat, dann muss man es ja nur noch umsetzen.

Das trügt leider.

In Phase 1 verbringen die Entwickler viel Zeit bei Diskussionen mit den Leuten die die Anforderungen gestellt haben und passen die nötigen Dokumente an. In dieser Zeit werden praktisch keine Fehler erstellt - es wird ja auch nur wenig Code erstellt.

In Phase 2 beginnen die Entwickler mit der “richtigen” Arbeit - sie haben die Anforderungen einigermassen Verstanden. Programmieren ist allerdings eine Detailarbeit - es kommen immer wieder Fälle vor, die nicht klar sind. Diese Fälle werden mit dem Kunden besprochen und meistens ins Anforderungsdokument aufgenommen.

In Phase 3 wird es langsam zeitkritisch. Die Deadline naht. Die Entwickler kennen die Domäne des Kunden schon recht gut. Sie haben jetzt keine Zeit mehr für Fragen (vor allem wenn der Kunde nicht grad “griffbereit” ist) und sie entscheiden z. T. selber wie sie die Anforderungen interpretieren. Wenn zwei Interpretationen etwa gleich wahrscheinlich sind, macht es aus logischer Sicht Sinn diejenige zu wählen die weniger Arbeit gibt. Das Anforderungsdokument wird nicht mehr angepasst.

Das bedeutet dann häufig, dass das Anforderungsdokument nicht mehr mit der Software übereinstimmt. Es bedeutet auch, dass in der Testphase viele Fehler gefunden werden, die eigentlich gar keine sind. Und dass Fehler NICHT gefunden werden, weil der Tester die Interpretation des Entwicklers versteht und ihm “Recht” gibt, dass das Verhalten der Software so spezifiziert ist.

Nehmen Sie sich einmal die Mühe und fragen sie einen Entwickler wie die Applikation aufgebaut ist. Mit grösster Wahrscheinlichkeit wird er Aussagen machen wie: “Der Business Layer benutzt dann den Persistence Layer. Den Persistence Layer haben wir um die Datenbankunabhängigkeit zu gewährleisten. Und den Business Layer können wir auf verschiedenen Maschinen deployen und so skalieren.”

Die Software wird für alles designed! Wechsel von Oracle auf XML Files? Kein Problem! Wechsel von Windows auf Linux? Kein Problem! Anstelle der Logfiles sollen die Logeinträge an einen Webservice geschickt werden? Piece of cake!

Nachdem Sie dann den Entwickler entsprechend gelobt haben, fragen Sie ihn einmal welche Konzepte er eingebaut hat, dass die Applikation “testbar” wird. Kann ich jede Bildschirm Maske innerhalb von 3s öffnen und einstellen, in welchem Zustand die angezeigten Daten sind, damit ich das UI Verhalten testen kann? Wie erstelle ich Testdaten? etc.

Die Antwort ist leider meistens sehr kurz und kann in Null Worten zusammengefasst werden.

Mit anderen Worten: Wir Entwickler designen die Software für alle Eventualitäten - aber wir designen sie nicht, damit sie einfach zu testen ist. Sorry - aber wir dachten das Testen sei nicht unser Problem…

Bugfix Iterationen und Flexible Iterationen kommen häufig in Firmen vor die denken “agile” Entwicklung zu machen. Beides sind aber eigentlich “Agile Anti-Patterns” - wer das macht, hat die agilen Entwicklungsmethoden noch nicht ganz verstanden (Ausnahmen bestätigen die Regel und die Chance dass Ihre Firma eine Ausnahme ist, ist klein).

Die Bugfix Iteration kommt folgendermassen zu Stande: Die Entwickler programmieren eine Zeit friedlich vor sich her und erstellen mehr und mehr Features. Sie generieren auch Fehler, die nicht sofort entdeckt werden. Die versteckte Arbeit halt. Beim ersten “x” geht die Software zum ersten Mal an die Testabteilung über. Die Entwickler entwickeln weiter, kommen aber nicht mehr ganz so schnell voran, weil sie den Testern helfen müssen mit Infos wie: “Wie kann ich xyz testen?” “Wie setze ich die DB neu auf?” “Warum kann ich die Applikation jetzt nicht mehr starten?”

Am Ende dieser Iteration hat die Testabteilung 50 Fehler gefunden. Was passiert jetzt? Die Fehler müssen behoben werden - es wird eine Bugfix “Iteration” eingeschoben. Für die Projektleitung ist eine Bugfix Iteration eine Iteration die keinen Mehrwert generiert. Die Software kann nachher nicht mehr als sie vorher schon hätte tun können sollen (hätte können sollen? gekonnt haben sollte? OK, dieser Satz ist nicht der Glanzpunkt dieses Artikels).

Die Worte Flexibel und Iteration sollten nie nacheinander kommen. Iterationen ist ein fixer Zeitraum. Der wird nicht ausgedehnt. Wenn man sagt 2 Wochen, dann sind es nicht plötzlich 3 oder 4. Das ist einer der wichtigen Punkte der agilen Entwicklungsmethoden. Nach 2 Wochen ist man fertig. Eventuell hat man NICHT ALLES fertig. Aber man kann den Fortschritt (oder die Absenz davon) zeigen und festlegen wies weiter gehen soll.

Nach 1.8 Wochen feststellen, dass man noch viele Fehler hat und nicht fertig wird und deshalb die Iteration um 1 Woche ausdehnt - das ist vieles - aber ganz sicher kein agiles Vorgehen.

Ich will die Tools nicht generell als schlechtes Zeichen interpretieren. Aber wenn es als Kommunikationsmittel zwischen den Entwicklern und den Testern eingesetzt wird ist das völlig falsch! Wie viele Fehler sollen wir in die Software programmieren? Maximum 5? Wozu brauchen wir da ein Bugzilla? Wenn es natürlich nicht darauf ankommt wie viele Bugs wir erstellen und es wichtig ist so schnell wie möglich irgendwas zu machen - dann ist Bugzilla super. Rettet aber das Projekt auch nicht…

Bugzilla und Jira und wie sie alle heissen machen in gewissen Umfeldern sicher Sinn. Zum Beispiel für Open Source Projekte oder für die Kommunikation mit vielen Kunden etc.

Diese Verhalten - obwohl sie auf den ersten Blick sinnvoll erscheinen - gewährleisten dass die Software voller Fehler ist.

Die Frage ist, können wir diese Verhalten verändern? Und zwar so dass die Wahrscheinlichkeit Fehler einzubauen minimiert wird?

Und die agilen Software Entwicklungsmethoden bringen eine Antwort. Diese Methoden definieren den Ablauf zum erstellen von Software neu (im Vergleich zu Wasserfall) - und dadurch auch die Verhaltensweisen.

Einer der fundamentalen Grundsätze von Agilen Entwicklungsmethoden sind die Iterationen. Ein Konzept das zwar einfach ist, aber praktisch immer falsch angewendet wird. Es ist auch ein Konzept, das es ermöglicht den Bugs das Leben schwer zu machen.

Also schauen wir uns dieses Konzept mal etwas genauer an.

Eigentlich gibt es nur zwei Punkte zur Definition einer Iteration benötigt werden:

1. Timeboxed. Iterationen haben eine bestimmte Länge (z. B. 2 Wochen). Nach 2 Wochen ist die Iteration abgeschlossen. Es gibt keine “Verlängerung”. Die Iterationen geben dem Projekt einen Rythmus - oder Puls. Wenn der Puls einmal ausbleibt, ist das schon ein Grund zur Sorge.

2. Software ist fertig. Das heisst installiert und funktionsfähig. Ein Architekturdokument gilt nicht als lauffähige installierte Software. Test Dokumente auch nicht. Und ein Feature das Fehler hat auch nicht. Fertige Software bedeutet, dass wir am Ende einer Iteration immer feststellen können, wie gut wir vorwärts kommen. Dadurch wird das Projekt steuerbar, weil der Projektfortschritt sichtbar wird.

Hier ist die Entwicklungsmethode “Scrum” - ein bisschen abstrahiert. Auf dem Backlog befinden sich Features die implementiert werden müssen. Die Iteration beginnt mit Planung. Es wird entschlossen, welche Features von der Liste genommen und in den nächsten 2 Wochen implementiert werden. Danach werden diese Features produziert. In dieser Zeit kommen keine “zusätzlichen” Features dazu. Oder andere, weil sich die Prioritäten geändert haben. Das Team ist dafür verantwortlich, dass die Features (und alle vorherigen) am Schluss der Iteration fehlerfrei laufen.

Denn dann wird die Software demonstriert - das heisst sie ist installiert und sie funktioniert (hoffentlich - sonst sieht das Team ein bisschen alt aus an der Demo). Nach der Demo nimmt man sich die Zeit und überlegt: Gibt es Dinge, die wir besser machen können? Gibt es Probleme die auf uns zukommen, wenn wir so weitermachen?

Danach nimmt man die nächsten Features vom Backlog und vervollständigt/erweitert die Software.

Ron Jeffries hat auf der Scrum Mailliste einmal geschildert warum Scrum funktioniert und auf zwei Schritte herunter gebgrochen. 1. Regelmässig FERTIGE Software herstellen. 2. Alle Hindernisse zu Punkt 1 aus dem Weg räumen.

Done-Done Software heisst, dass die Software getestet und fehlerfrei ist. OK, nun die Frage - ist es ein Hindernis wenn wir die Software an eine QA Abteilung übergeben müssen, damit wir wissen ob sie fehlerfrei ist? Ja? Dann siehe Punkt 2!

Auf der ersten Y-Achse ist die Metrik “Running Tested Features”. Auf dieser Achse geht man nach oben, wenn 1 Feature implementiert ist UND all seine Tests erfolgreich besteht. Auf der zweiten Y-Achse ist die Zeit, die für die MANUELLE Testdurchführung gebraucht wird.

Nach 2 Wochen ist die erste Iteration abgeschlossen. Es sind 2 Features implementiert worden, die problemlos am Ende der Iteration manuell getestet werden können. Der Testaufwand ist vielleicht 1 h. Nach der zweiten Iteration sind 2 weitere Features dazu gekommen, die z. T. das Verhalten der ersten etwas beeinflusst. Um die Software zu testen, müssen alle Tests der ersten Iteration durchgeführt werden plus alle neuen. Der Aufwand ist immer noch absehbar, vielleicht 2.5 h.

Aber während die Entwicklung Iteration für Iteration mehr Features produziert, brauchen die Manuellen Tests immer länger (es muss ja immer wieder die ganze Vergangenheit getestet werden). Nach einigen Iterationen brauchen die Manuellen Tests 10 h. Das bedeutet, dass der Code jetzt schon 2 Tage vor Ende der Iteration fertig sein muss. Einige Iterationen später dauern die manuellen Tests 1 Woche. Das heisst die Entwickler haben noch 4 Tage zum entwickeln. Irgendwann brauchen die Manuellen Tests länger als die Dauer der Iteration… Was machen wir dann?

Ich sehe da nur drei mögliche Auswege:

1. Die Entwickler geben sich endlich etwas Mühe und erstellen keine Bugs mehr.
2. Wir testen nicht jede Iteration, sondern nur jeden Release
3. Wir automatisieren die Tests als Bestandteil der Iteration

Punkt 1 funktioniert leider nicht. Das haben wir probiert. Fehler passieren sogar den Entwicklern.
Punkt 2 führt zu dem Problem das wir im ersten Teil der Präsentation gesehen haben. Es werden Fehler erstellt, die spät entdeckt werden. Wir können nicht sagen welche Teile der Software funktionieren und welche nicht.
Das lässt nur noch den 3 Punkt als Ausweg und - man höre und staune - das könnte klappen!

Mit anderen Worten: Automatisierte Tests müssen Bestandteil der Entwicklungsmethode werden. Wenn wir das nicht tun, dann müssen wir einen der beiden anderen Wege begehen - und die funktionieren nicht. Wie binden wir also die zu automatisierenden Tests in den Prozess ein?

Einfach gesagt: als Spezifikation bevor das Codieren beginnt. Aber ich möchte da noch etwas ausholen um zu zeigen warum das Sinn macht.

In einigen Projekten gibts ein Requirements.doc (Anforderungsspezifikation). Wozu brauchen wir das während der Entwicklung? Eigentlich für 3 Sachen. Wir brauchen es um Schätzungen zu machen, um zu lehren wie das Business funktioniert und um zu beweisen, dass die erstellte Software das tut was sie tun soll.

Die meisten agilen Methoden brauchen für diese drei verschiedenen Aspekte auch drei verschiedene Mittel. Für die Planung reichen Feature Beschreibungen. Das erlernen der Business Domäne passiert vorzugsweise über Konversationen und das Beweisen ist am besten durch automatisierte Tests gelöst.

Das bedeutet aber auch, dass die automatisierten Tests nicht kryptisch sein dürfen. Das heisst, ich muss sie meiner Grossmutter geben können und sie muss sie verstehen. Und das ist da, wo ein Word Dokument brilliert. Da es “normale” Worte sind wie sie in jedem Buch zu finden sind, sollte sie auch jeder Verstehen…

Zeit für ein kleines Praxis Beispiel!

Das ist ein Auszug aus der Feature Liste für ein Ausleihsystem an dem ich zur Zeit mitarbeite. Es hat Dinge drauf, die klar vom Business her kommen: Bestellungen bestätigen, Modelle auswählen und bestellen, Verfügbarkeit von Modellen.

Aber auch Dinge, die vom technischen Umfeld her kommen: Authentifizierung über LDAP, Zugriffsberechtigungen.

Im folgenden nehmen wir das Feature “Bestellungen bestätigen” etwas genauer unter die Lupe.

Hier nun der Ablauf, wie wir vom Feature zum Code kommen.

Das Feature haben wir ja bereits ausgewählt. In der Konversation versuchen wir Details zum Feature rauszufinden und schreiben nachher Tests, die unser Verständnis des Features ausdrücken (wie gesagt, der Test muss für jeden verständlich sein). Danach wird der Code geschrieben, damit diese Tests erfolgreich durchlaufen.

Eventuell tauchen bei der Implementation Fragen auf - worauf die Konversation wieder aufgenommen wird, die Frage geklärt und neue Tests geschrieben werden. Der Code wird angepasst oder erweitert. So wachsen unsere Requirements, die automatisierten Tests und der Code gleichzeitig. Die Software wird immer vollständiger.

Hier ein Beispiel eines automatisierten Tests. Es geht um das Feature “Bestellung bestätigen”. Wir haben eine kurze Beschreibung die vor allem erklärt, wer das Feature will und wozu es gebraucht wird.

Jedes Feature hat verschiedene Szenarien (nichts anderes als Tests), mit einem eigenen Namen. Hier ein ganz simples: “Die Liste mit neu erstellten Bestellungen”

Dann die Testbeschreibung.

Dort wird die Ausgangslage festgelegt: Die Liste der neuen Bestellungen ist leer und ein User mit dem Namen ‘Joe’ macht eine neue Bestellung.
Aktionen werden ausgeführt: Der Lagerverwalter klickt auf “bestätigen”
Und festgelegt, was dann passiert: Der Lagerverwalter sieht eine Bestellung und dass sie vom User ‘Joe’ erstellt wurde.

Hier ein etwas komplizierteres Beispiel.

Joe hat eine Bestellung gemacht, der Lagerverwalter wählt diese Bestellung aus.

Es geht ein neuer Tab auf mit dem Namen ‘Order: Joe’ und der Verwalter hat die Möglichkeiten zu bestätigen oder Abzulehnen

Er bestätigt, was dazu führt dass Joe ein Email mit der ‘Reservation Confirmation’ erhält.

Die Tests die wir gesehen haben sind für ein Programm sehr einfach zu parsen und auf die entsprechende Business Logik zu mappen. Die Tests sind aber auch für jeden mit nur wenig Aufwand verständlich.

Fertig im agilen Sinne heisst also: Wir haben ein Feature, das durch X Tests definiert wird. Wenn ALLE Tests erfolgreich durchlaufen, ist das Feature vollständig implementiert.

Hmmm. Das tönt ja alle recht interessant und spannend, aber warum ist das wichtig. Oder vielmehr: was bedeutet das für die Testabteilung.

Naja, wenn wir die automatisierten Tests während der Entwicklung machen und wir die Testphase abschaffen. Was passiert dann mit den Testern?

Ganz offensichtlich verändert dies den Job der Tester sehr stark! Keine Angst, es verändert auch den Job des Entwicklers sehr stark! Und denjenigen des Kunden! Viele Entwickler haben sich schon verändert und es macht ihnen mehr Spass. Ich glaube für die Tester ist das ebenfalls eine Riesenchance sich neu zu platzieren und neue spannende Aufgaben zu finden. Der Agile Tester ist ein ganz anderer Job als der Wasserfall Tester!

Ich will das nochmals in aller Deutlichkeit sagen: Es braucht nicht keine Tester mehr.

Aber es heisst, dass die Tester und Entwickler im gleichen Team über das ganze Projekt zusammenarbeiten müssen. Der Tester muss jedes Feature verstehen - genau wie die Entwickler auch. Der Tester teilt die Verantwortlichkeit mit allen anderen Teammitgliedern, dass am Ende jeder Iteration releasebare Software rauskommt.

Eventuell übernimmt er sogar einige der folgenden Aufgaben. Das sind alles Aufgaben, bei denen die Zuständigkeit noch nicht so klar ist. Agile Methoden legen viel Wert auf die Leute die mitarbeiten (People over Process etc.). Jeder hat seine eigenen individuellen Fähigkeiten die er in ein agiles Team bringen kann - die folgenden Aufgaben sollen lediglich als Startpunkt dienen. Am Schluss sollte sich jeder selber überlegen welche Aufgaben ihn interessieren und wo er dem Team am meisten helfen kann.

Wenn der Kunde es nicht fertig bringt die Tests so zu schreiben, dass sie für Menschen und Computer lesbar sind, dann muss da jemand helfen. Entweder als Mentor oder als Übersetzer. Wenn man das den Entwicklern überlässt, schreiben sie die Tests selber und das vermindert den Buy-In des Kunden.

Viele Entwickler kennen ihr Unit-Testtool (JUnit) und damit hat sichs. Testtool impliziert für Entwickler, dass es sich da um ein Gebiet handelt, das sie gar nicht zu genau kennen wollen. Es braucht jemand der weiss, welches Tool wann und wie sinnvoll eingesetzt werden kann.

Es gibt sicher auch Tools, die im agilen Umfeld keinen Sinn machen. Eine Person die diese Tools kennt und sagen kann dass man damit keine Zeit verschwenden muss, ist natürlich viel Wert.

Für Kunden ist es manchmal schwierig ein Feature in kleinere Features zu unterteilen, von denen jedes einzeln getestet werden kann. Kleinere Teile können einfacher getestet werden. Idealerweise können kleinere Features rausgelöst werden, die den grössten Teil des Business Values haben. So kann dem Kunden sogar geholfen werden, schneller eine Software auf die Beine zu stellen, die Wert generiert.

Kunden denken hauptsächlich darüber nach, was sie wollen. Weniger über das, was sie nicht wollen. Stress Tests, Negativ Tests, Security etc. sollten immer auch mit einbezogen werden.

Ich war noch nie in einem Projekt, in dem die Testdaten gut und einfach gelöst waren. Wie bekomme ich das System in den richtigen Zustand um genau DAS zu testen? Wie stelle ich diese Daten den automatisierten Tests zur Verfügung? Wie den Entwicklern, die ihre Änderungen ausprobieren wollen? Wie können wir sie für die Demo verwenden?

Eventuell hat jemand von Euch da Antworten drauf und ich bin sicher dass die Entwickler dieses Wissen mit offenen Armen begrüssen würden.

Direkt = Fehler werden verhindert. Nicht wie “früher”, wo der Tester lediglich da war um Bugs zu finden. Hat ein Tester ein gutes Gefühl wenn er einen Bug findet? Oder hat er ein gutes Gefühl, wenn die Software richtig funktioniert? Das Erfolgserlebnis sollte das zweite sein.

Es reicht nicht, wenn wir versuchen die Bugs mit einer Testphase zu erschrecken und zu hoffen dass sie verschwinden. Wir müssen die Art wie wir Software entwickeln umstellen. Und wenn ich “Software entwickeln” sage, dann ist das Testen mit dabei. Tester die bugfreie Software wollen, setzen sich dafür ein, dass die Testphase abgeschafft wird.

Viele Betriebe wollen in naher Zukunft auf Agile Entwicklungsmethoden umsteigen. Ich hoffe ich konnte ihnen zeigen, dass diese Idee gut ist. Und ich hoffe ich konnte ihnen ein paar Gedankenanstösse geben, damit sie, wenn es dann soweit ist, schon einen kleinen Vorsprung haben.

Jerome Co-Commenting on Star-TV

, No Comments

On the 24th of August I had the pleasure to be a commentator for the Swiss Baseball Cup Final between the Cardinals and the Indians. Lots of fun! In case you missed it, you can still watch the game on internettv.

On a crusade against boring presentations

September 22, 2007, 4 Comments

Have you ever been to a presentation that was so boring, you could barely keep your eyes open? It seems like presentations are getting more and more common these days and too often they’re presentations you’re expected to attend. Too bad that more presentations also means more

Boring Presentations

Today I want to look at things that boring presentations have in common. And above all: how you can prevent giving a boring presentation yourself.

Change the world

Every presentation is a chance to change the world. Well maybe not the world, but the people in the audience. Choose a topic that you care about. If you don’t think the topic is important - why should the audience care? Sometimes you’ll be “forced” to present a topic you don’t care about. Remember that you are given an opportunity to change the world. Find something in that topic you care about - or be doomed to hold a boring presentation.Your enthusiasm for the topic is most important. Of course you need to research the topic well and yes, sexy slides can help make the message stick. But nothing beats enthusiasm.

Avoid Bulletpoints

If you look at the slides of boring presentations, you often find massive amounts of bullet points. Look at Aaron Swartz’s PowerPoint Remix for reasons why bullet points aren’t good (written as bullet points no less).

I don’t like them because most people in the audience can read faster than the speaker can talk. The time the speaker spends to catch up to where the reader is, is - well - boring. I also think they are totally uncreative.

Slides <> Script

Sometimes I get the feeling that the speaker needs the slides more then the audience. Who’d miss them more if you took them away? For some speakers the slides are the script - the tool to make sure they don’t forget to tell something. Everybody knows that you shouldn’t read from a paper. Why is reading from a screen different?

The slide show is not the script. Write a real script. Then practice. Until you know what you want to say - and when.

Slides <> Handout

The slide show is not a hand out. The slide show is for the people that are sitting in the audience. If you plan to use it as both: the handout and the medium to support your words, it’ll end up doing neither. As a handout it won’t have enough information and as a slide show it will be boring.

So, what is the slide show if it isn’t the script and the handout? It’s a tool to help make a message stick. Your job as a speaker is to figure out how they may achieve that. Pictures are a good starting point.

Use Corporate Design Template to stifle creativity

Corporate Design and templates = boring. They force you to use certain colors, certain fonts and sizes. Logos and pictures reduce available space. I’m totally OK that the company paying for the presentation gets its share of publicity - but templates just aren’t a good way.

Templates (the branded versions in particular) add too much visual clutter. How many times does the name of the company have to be on one slide? The creation time is only interesting if it shows that the speaker probably didn’t spend a lot of time preparing. And the only thing that “page 10 of 93″ indicates is how much longer the audience has to suffer.

Ask yourself: What does this slide have to communicate. Remove every element that doesn’t support that.

Corporate Designed Templates exist to restrict creativity and to save time (and to save the world from the occassional speaker with bad color taste).

The message a template sends to the speaker is: “You don’t need to worry about the slide show. Concentrate on the content.” Sure the content is very important. But if the content doesn’t make it into the audiences head because the presentation was boring then that’s sad. And a waste.

No Complex Diagrams on Slides

Complex architectures don’t belong on a slide. Neither do class diagrams. Or anything else with a lot of rectangles, lines and small text. Most of the time some people won’t be able to read the words, because they are too small. And it doesn’t help, if you read all words out loud, because keeping it all in the head is just too much to ask, some won’t even try. Very often those diagrams are too exhaustive. Above all, don’t use symbols that aren’t clear to everybody. Explaining symbols (that might not even be important for the point you’re trying to make) is boring for everyone who already knows the symbol.

If you need a diagram anyway, it might be a good idea to draw it live, for example on a flip chart. For a lot of diagrams there is meaning in the sequence the symbols are drawn. In a class diagram, you don’t start with the least important class in the system. If you explain the meaning of a symbol while drawing, that’s less boring because it doesn’t slow the presentation down (talking is faster than drawing). You also will not run into the problem of being too exhaustive.

The Speaker - not the slides - is the most important part of the show

Let’s say the slide show is perfect - exciting and visually pleasing. Not flashy, but fitting the words of the speaker nicely.

The presentation can still be boring - because the speaker is the most important part of the presentation. He may talk monotonously, or too quietly, sentences that are too long etc. However, presentation technique is usually not a problem, if he’s talking about a topic he cares about. Enthusiasm just doesn’t go with talking monotonously.

Long sentences are a problem: people in the audiance can’t go back and hear the beginning of the sentence again. In other words: long sentences need a lot of concentration from your audience. Not everybody is willing (or able) to concentrate over a long period of time (like say 30 min). Some will loose their concentration and inevitably get bored.

Explain Technical Terms - Maybe even twice

If you’re holding a technical talk, make sure you cut down on your use of technical terms. If you can’t avoid them make sure to explain them if necessary (you don’t need to explain what HTML is to a web developer, but you have to explain it when you talk to a group carpenters). If you use the same term again later (after not using it for a few minutes) - you might have to remind the audience of what that meant.

Mask of Complexity - to hide absence of ideas

Technical terms are often used as a mask. As a mask to hide the absence of ideas. If you fear that somebody finds out that your presentation has little content, you can always hide that fact behind the “mask of complexity”. Make everything appear complicated, use a lot of technical terms. If somebody dares to ask a question, throw more complexity and other terms at them. People will be in awe of your intelligence. And bored.

If you really understand what you’re talking about, you will be able to make things simple enough for everybody to understand.

It’s about the audience

One last point: If you give a presentation, it isn’t about you. It’s about the audience. It isn’t about making yourself look good. It isn’t to prove you’re the guru and the others are not. Think about what the audience is interested in. How you can help them solve a problem they have. Make it be valuable for them.

And one more thing: if you don’t have anything more to say - stop your presentation even if you have time left.

Do you know any other things that boring presentations have in common? And what techniques do you use to spice up your presentations?

---

Auf Deutsch: Auf dem Kreuzzug gegen langweilige Präsentationen