Begrüßung

In der Begrüßung vermittelte Margret Mergen (Bürgermeisterin der Stadt Karlsruhe) viele interessante Fakten zu Karlsruhe. Sie bezeichnete die Stadt als das “Silicon Valley Deutschlands” und nahm damit Bezug auf die räumliche Nähe der über 3.000 IT Firmen mit über 25.000 ITlern. Ebenfalls interessant war die Tatsache, dass jede vierte Informatiker aus Karlsruhe kommt.

Freundliche Eindringlinge – Moderne Web-Applikationen mit CDI

Wie den Teilnehmern des Entwicklertages versprochen, möchte ich an dieser Stelle die Tonspur und die Beispielapplikation zur Verfügung stellen. Da ich bereits darüber gebloggt habe, veröffentliche ich hier nur den Link zu meinem Beitrag Freundliche Eindringlinge – Moderne Web-Applikationen mit CDI.

Zum Vortrag kann ich nur sagen, dass es Spaß gemacht hat, ihn in den schönen Räumen der IHK Karlsruhe halten zu dürfen und dass ich auch das Glück einer aktiven Zuhörerschaft mit spannenden Fragen hatte.

Freundliche Eindringinge @ Entwicklertag 2012

Rechtliche Aspekte zu Cloud Computing

Prof. Dr. Rupert Vogel, Tobias Haar und Dr. Oliver Meyer-van Raay beleuchteten die rechtlichen Aspekte zum Thema Cloud. Nach der Definition des Cloud-Begriffs, den Ausprägungen (IaaS, PaaS, SaaS) und der Erkenntnis, dass es sich beim Thema Cloud Computing nicht um einen Rechtsbegriff handelt, wurden alle relevanten Rechtsbereiche erörtert.

IT-Recht

Sofern es sich um eine B2B-Beziehung handelt, kann die Rechtswahl selbst übernommen werden, d.h., ich kann mir ein Land aussuchen, gemäß dessen Rechtsprechung ich agieren möchte. Als Tipp wurde genannt, dass immer der Kunde auf Rechtswahl drängen sollte.

Handelt es sich jedoch um eine B2C-Beziehung, muss nach Recht des Verbrauchers verfahren werden, also nach dem Recht, das am günstigsten für den Verbraucher ist. Hier spielt in der Regel das Land, in dem der Verbraucher firmiert, eine Rolle. Ebenfalls interessant dazu ist, dass im Zweifelsfall das Recht des Landes, in dem der Schaden eintritt, gilt.
Zum Thema Vertragsgestaltung wurde erwähnt, dass es sich um Mietverträge nach deutschem Recht handelt, sodass der Vermieter für die Leistung verantwortlich ist. Um auf der sicheren Seite zu sein, müssen Service Level Agreements vereinbart werden. Spannend ist auch das Thema “Exit Management”. Wir wird mit Daten verfahren?

Zur Vertragsgestaltung wurde der Tipp gegeben, den Vetrag immer so zu gestalten, dass ein 60jähriger Richter diesen auch verstehen kann. Also nicht “Leistung 98% verfügbar”, sondern lieber alles detailliert beschreiben. Was ist denn beispielsweise “die Leistung”? Und was heißt “verfügbar”?

Ein Blick in das Amazon Web Services Customer Agreement zeigte, dass Amazon den Service einfach mal abschalten kann…

Urheberrecht

Beim Urheberrecht sind in der Regel drei Parteien betroffen. Der Kunde, der Cloud-Anbieter und das Software-Haus. Aufgepasst werden muss vor allem im Bereich des Software-Hauses. Wurde eine Lizenz für die Cloud erworben? Wie sieht es mit der Handhabung von Vervielfältigungen aus? Ist es nicht eine Vermietung, wenn ich die Software in der Cloud zur Verfügung stelle? All dies muss zwischen den Parteien vereinbart werden.

Wie steht es um Software, die ein Angestellter oder ein Freelancer für ein Unternehmen entwickelt hat? Kann diese einfach in die Cloud gehen? Beim Angestellten ist das recht einfach, hier hat der Arbeitgeber Verwertungsrechte. Bei Freelancern ist das ein wenig schwieriger, weil hier unter Umständen eine neue Nutzungsart hinzukommt.

Datenschutz/-sicherheit

Hier gilt das Territorialitätsprinzip, also die Rechtsprechung des Landes in dem die Daten verarbeitet werden. Problematisch wird das Ganze natürlich nur bei personenbezogenen Daten. Hier muss eine Anonymisierung stattfinden und optimalerweise auch noch eine Verschlüsselung, damit die Cloud-Anbieter diese Daten nicht im Zugriff haben. Spannend wird es auch beim Thema der Auftragsdatenverarbeitung: hier sollte man sich einen geeigneten Anbieter á la Microsoft oder Salesforce, die den Richtlinien der EU entsprechen, suchen.

Mehr dazu kann in den Vortragsfolien auf der Webseite des Entwicklertages 2012 nachgelesen werden.

In der Fragerunde zum Vortrag wurde noch erwähnt, dass man im rechtlichen Sinne nicht vom Besitz von Daten sprechen kann, sondern nur vom Zugriff.

Rechtliche Aspekte zu Cloud Computing @ Entwicklertag 2012

Software Engineering von Mobile Apps

Stefan Hellfeld zeigte sehr schön die Entwicklung der mobilen Endgeräte an seiner eigenen Handy-Historie auf. Danach machte er darauf aufmerksam, wer eigentlich aktuell die Software für mobile Endgeräte verkauft: Betriebssystem- und Gerätehersteller. Auch erfunden hat das Ganze nicht Apple mit dem App Store, sondern Nokia mit Symbian schon einige Jahre zuvor.

Was?

Was ist das größte Problem, wenn man eine Software in den App Store bringt? Die Konkurrenz! Wie kann man sich, abgesehen vom Preis, von seinen Konkurrenten absetzen? Durch Innovation! Wie diese Innovation vorangeschritten ist, zeigt die Gegenüberstellung einiger Features des Smartphones (GSM, GPRS, Kamera, Bewegungssender) gegenüber verschiedenen Features von Software (Virtuelle Realität, Wecker, Aufzeichnung, MP3-Player). Hier steht es 9:26 für die Software. Herr Hellfeld legte nahe, sich als Entwickler von Mobilen Apps als Integrator zu sehen und so mehrere Hardwarekomponenten für die Lösung eines Problems zu verknüpfen.

Wie?

Da wir jetzt wussten, was wir zu programmieren hatten, stellte sich natürlich die Frage nach dem Wie. Hier verglich Herr Hellfeld die mobile Entwicklung für iOS mit der klassischen Software-Entwicklung. Bei letzterer wurden in der Regel Lizenzen für IDEs gekauft und fertig war man, was die Ausgaben im Entwicklungsprozess anging. In der mobilen Entwicklung ist die IDE zwar kostenlos (sofern man einen Mac hat), aber man braucht Lizenzen für die Entwickler, muss auf externen Geräten testen und die Software dann auch noch im App Store zur Abnahme einreichen.

Zukunft iOS, Android, Windows Phone & JavaME

Es gibt schon jetzt mehr Smartphones als Handys. Android Apps sind im Schnitt teurer als iOS Apps, und JavaME liegt hinsichtlich des Marktanteils noch 15% hinter iOS und Android. Herr Hellfeld ist der Meinung, dass iOS weiter wachsen wird, Android auch – und zwar stärker – und Microsoft wird es zukünftig mit den beiden aufnehmen, da es noch keine richtige Office-Integration auf iOS oder Android gibt und es Windows Phone noch an Tablets fehlt.

Organisation

Was wird alles benötigt, um starten zu können? Eine Entwicklungsumgebung und ein SDK, ein Team, wobei sich die optimale Anzahl Mitarbeiter seiner Ansicht nach aus der Wurzel der Projektdauer in Personentagen ermittelt. Ferner benötigt man ein gutes Management, bei dem Enwickler 16 LOC (lines of code) pro Tag schaffen, die direkt in der Software verwendet werden, ein Vorgehensmodell und jede Menge Testgeräte. Es gibt zwar Simulatoren, aber diese ersetzen nicht die Tests auf Endgeräten.

Sicherlich neu in der mobilen Entwicklung ist die Rolle des Kunden, da man hier jetzt mit “Experten” redet, die genau wissen, wie eine mobile App auszusehen und wie sie sich anzufühlen hat.

Nativ, WebApp oder Hybrid?

Die Abgrenzung der unterschiedlichen App-Typen ist ja mittlerweile in aller Munde. Interessant ist jedoch Herr Hellfelds Abgrenzung im Detail. Native Apps sind bei ihm Apps, die nativ programmiert wurden, bei denen sich jedoch auch alle Daten auf dem Smartphone befinden. Hybrid sind bei ihm einerseits die Lösungen, die via Titanium oder PhoneGap auf beliebig viele Plattformen gebracht werden können, als auch Apps, die nativ implementiert wurden, aber ihre Daten aus dem Internet beziehen.

Als Best-Practice-Beispiele nannte er die Apps von Facebook und N-tv, die beide auf eine hybride Lösung setzen. Die UI-Elemente sind nativ implementiert, da sie flüssig sein müssen; die Informationsdarstellung erfolgt in Webviews.

Als gutes Feature von iOS wurde erwähnt, dass man es geschafft habe, auch Apps elegant abstürzen zu lassen, so dass sich der Nutzer selbst hinterfragt, bevor er davon ausgeht, dass die App fehlerhaft ist.

Spannend war auch ein Vergleich der Effizienz der Entwicklung zwischen iOS (Xcode) und Windows Phone (Visual Studio mit Expression Blend). So bräuchte man in Xcode für die Entwicklung einer Taschenlampen-App 80 Sekunden und in Visual Studio nur 32 Sekunden.

Zukunft der Apps

Apps sind in der Zukunft agil, sie passen sich an Anwender, Kontext, Gerät und Informationskanal an, sie sind intelligent, denken mit und treffen banale Entscheidungen, und darüber hinaus bilden sie Menschen auf Informationssystemen ab.
Software Engineering von Mobile Apps @ Entwicklertag 2012

Entspannte Nebenläufigkeit – Aktoren in Scala und Java

Andi Scharfstein und Ben Romberg motivierten Aktoren mit dem “Northeast blackout of 2003″. Als Ursache wurde eine Race Condition identifiziert. Um Race Conditions zu vermeiden, sollen Aktoren eingesetzt werden. Es muss also, getreu dem Aktoren-Paradigma, Datenfluss nur in gekapselten Systemen agiert werden.

Aktoren haben dabei einen eindeutigen Namen (Adresse), ein Verhalten (Code), einen Zustand (Daten) sowie eine Mailbox. Aktoren können Nachrichten verschicken, den eigenen Zustand bzw. ihr Verhalten ändern und neue Aktoren erstellen. In der Theorie laufen Aktoren parallel zueinander; es gibt keine Aussage zum Nachrichtenverhalten, und somit können Nachrichten theoretisch verloren gehen oder auch ihre Reihenfolge verändern.

In einem Bespiel, in dessen Rahmen Spielstände von Mannschaften verändert wurden (ja, es ist ja bald EM), wurde das Akka-Framework vorgestellt.

Für den Einsatz wurde vorgeschlagen, dass über Nachrichten kommuniziert werden soll und Nachrichten nur als immutable Objekte verwendet werden sollen, um Race Conditions zu vermeiden.

Als Fazit machten die Vortragenden Werbung für den Einsatz von Aktoren, da der Einarbeitungsaufwand gering sei, man nur seine Herangehensweise ändern müsse und so sehr performante nebenläufige Applikationen ohne Race Conditions bauen könne.

Mich haben die Jungs überzeugt und ich werde den nächsten passenden Anwendungsfall mal mit Aktoren umsetzen.

Entspannte Nebenläufigkeit – Aktoren in Scala und Java @ Entwicklertag 2012

Subjektorientorierung

Albert Fleischmann hat ein neues Modell für den Softwareentwicklungsprozess entwickelt. Eingangs rief er den Zuhörern den deutschen Satzbau im Aktiv mit Subjekt, Prädikat und Objekt ins Gedächtnis (Wer macht was womit?) Im Vergleich dazu skizzierte er unterschiedliche Modelle der Softwareentwicklung (Flussdiagramm, ER-Diagramm, UML etc.), die im nicht ausreichenden Maße Subjekt, Prädikat und Objekt beschreiben. Sein Anliegen war es, Anwender für die Subjektorientierung zu motivieren. Als Fallbeispiel stellte er die Steuerung eines ferngesteuerten Vogels vor, die er später in ein Bespiel zu einem Transportunternehmen verwandelte. Spätestens hier hatte er mich leider komplett abgehängt. Als nach 40 Minuten Motivation innerhalb von fünf Minuten das Modell vorgestellt werden sollte, konnte ich leider nicht mehr das Konzept und den Nutzen der Subjektorientierung verstehen. Falls die Folien online gestellt werden, werde ich auf jeden Fall noch mal hineinschauen.

Subjektorientierung @ Entwicklertag 2012

Fazit

Für mich eine sehr gelungene Veranstaltung – von der Organisation über die Referenten bis hin zum Veranstaltungsort. Dafür möchte ich mich bei den Veranstaltern und Referenten herzlich bedanken, und vielleicht bin ich ja nächstes Jahr auch wieder dabei.

Hidden Files

Die komfortabelste Lösung, versteckte Dateien in Finder ein- und auszublenden ist, sich jeweils eine einfache Automator-Aktion zu schreiben. Hierzu einfach das Programm Automator starten, als Vorlage “Dienst” auswählen und eine neue Aktion “Shell-Skript ausführen…” wie folgt anlegen (click to enlarge):

Nun einfach “Speichern unter…”, einen sprechenden Namen vergeben unter dem die Aktion dann als Dienst auftauchen soll (z.B. “Show Hidden Files”) und fertig. Nach dem gleichen Verfahren eine zweite Aktion “Hide Hidden Files” erstellen, wobei die erste Zeile des Skripts dann entsprechend wie folgt lautet:

defaults write com.apple.finder AppleShowAllFiles FALSE

Gespeichert sind diese Automator-Aktionen unter ~/Library/Services (nur für den Fall, dass man sie irgendwann mal wieder entfernen möchte). Aufrufen lassen sich diese Dienste jetzt über das Finder-Menü:

Damit aber nicht genug: richtig komfortabel wird es erst, wenn wir diesen Diensten noch Tastaturkürzel zuweisen. Hierzu einfach wie oben zu sehen auf “Dienste-Einstellungen…” gehen und dort jeweils rechts neben dem gewünschten Dienst einmal doppelklicken (sodass das Eingabefeld erscheint) und dann die gewünschte Tastenkombination drücken – schon wieder fertig.

Wem das Erstellen dieser Automationen noch zu aufwändig ist, der kann auch einfach die nachfolgende ZIP-Datei herunter laden, entpacken und die beiden enthaltenen Dateien einfach nach ~/Library/Services kopieren

hidden-files-services.zip

Stay tuned…

Man kann sich entschließen, im Team das agile Logbuch zu verwenden und jeden Tag über das Geschehene zu reflektieren. Dann hat man am Ende des Sprints eine Sammlung all seiner Gedanken, die in die Retrospektive einfließen können.

Als einen anderen Ansatz wider das Vergessen habe ich bei einem Team den Kummerkasten kennengelernt. Was ist das?

Befragen wir zuerst Wikipedia zum Begriff. Dort finden wir: ”Der abstrahierende Begriff Kummerkasten bezeichnet jede Form von Behältnis, das für einen oder mehrere Individuen als Aufbewahrungsort für seelisch belastende Gedanken und Gefühle gilt. Dabei kann es sich auch um einen Kasten im wörtlichen Sinne handeln, in den üblicherweise Schriftgut oder symbolträchtige Gegenstände geladen werden. [...] Der Begriff Kummerkasten hat sich auch in Firmen und anderen Organisationen etabliert. Dabei handelt es sich um Briefkästen, in denen Mitarbeiter oder Mitglieder anonym ihre zu Papier gebrachten Sorgen oder Beschwerden weitergeben können.”

Quelle: http://de.wikipedia.org/wiki/Kummerkasten

Das Team hatte einen agilen Kummerkasten aufgestellt, den man mit allem füttern konnte, was in der nächsten Retrospektive nicht vergessen werden sollte. Dazu lagen ein Stift und verschiedenfarbige Zettel immer in der Nähe:

• Grün: Mir ist etwas Positives aufgefallen, das ich auf jeden Fall lobend erwähnen möchte!
• Rot: Ich habe etwas Problematisches bemerkt, das wir nicht sofort klären müssen, das aber spätestens in der Retrospektive besprochen werden muss!
• Gelb: Mir ist eine Verbesserungsmaßnahme eingefallen, die ich in der kommenden Retrospektive mit allen besprechen und bis dahin nicht vergessen will!

So konnte man jederzeit mit wenigen Worten seine Gedanken aufschreiben und einfach einwerfen. Vor der Retrospektive leerte der Scrum Master den Kasten und nahm die Zettel mit in das Meeting. Der Autor bekam die Möglichkeit, genauer auf sein Anliegen einzugehen. Dann landeten sie zusammen mit den während der Retrospektive neu geschriebenen Zetteln in einer der Rubriken: Was war gut? Was wollen wir verbessern? Verbesserungs-Maßnahmen. Nichts ging verloren. Nichts konnte in Vergessenheit geraten.

Eine wunderbar einfaches Tool, das omnipräsent im Teamraum hängt und immer funktioniert, ganz ohne Bits und Bytes.
Einfach mal ausprobieren!

Foto: © stoonn, http://www.sxc.hu/photo/1360564

Das dritte Hamburg Web Performance Meetup fand am 25. April in den Räumlichkeiten von Telefónica in der City Nord statt. Den fast vierzig Teilnehmern, die sich trotz eines zeitgleich laufenden, hochkarätigen Champions-League-Spiels nicht vor den Fernseher gesetzt hatten, wurden zwei interessante Vorträge geboten.

Den Anfang machten Jan Vogel (DI UNTERNEHMER) und Uwe Beßle (Iteratec) mit dem Thema “Optimierung der gefühlten Performance – Web Performance Management für Fortgeschrittene”. Die beiden präsentierten ihre Erfahrungen, die sie im Umfeld einer der weltweit größten eCommerce-Sites gemacht haben. Vorgestellt wurden u.a. eigene Metriken für Performance und Kundenzufriedenheit.

Im Rahmen des Projekts wurden End-User-Tests mit etwa 1.500 Probanden sowie automatisierte Tests mit dem Tool WebPagetest (WPT) durchgeführt. Mit Best-Practise-Beispielen zu WPT und einem regen und ausführlichen Frage-und-Antwort-Teil endete dieser Vortrag.

Der zweite Teil des Abends bestritten Oliver Ochs und meine Wenigkeit mit unserer Präsentation “Building Performance, ein Frontend-Build-Prozess”.

Wir haben einen auf Maven basierenden Build-Prozess vorgestellt, mit dem die Frontent-Komponente des DSL-Portals von Telefónica O₂ erstellt wird. In mehreren Schritten sorgt dieser Build-Prozess automatisiert dafür, dass HTML, CSS, JavaScript und Bildelemente hinsichtlich der Web Performance optimiert werden. Dabei kommen unter anderem Werkzeuge wie OptiPng, Web Ressource Optimizer, JSLint, CSSLint und der Google Closure Optimizer zum Einsatz, die als Maven-Plugins ohne großen Aufwand in den Prozess integriert werden.

Der Abend endete mit einer Verlosung von Fachbüchern des Sponsors unseres Web Performance Meetups in Hamburg, dem O’Reilly Verlag.

Unser Vortrag zum Frontend-Build-Prozess ist bei SlideShare verfügbar:

• Building Performance – ein Frontend-Build-Prozess für Java mit Maven

Das Konferenzprogramm und weitere Informationen rund um die SEACON sind auf der Konferenzseite des Veranstalters SIGS DATACOM zu finden. In der XING-Gruppe geben die Referenten erste Details ihrer Vorträge bekannt. Gezwitschert wird unter @seacon_de. Aber all das kann den Besuch der SEACON nicht ersetzen. Deshalb freue ich mich auf ein Kennenlernen (oder Wiedersehen) am 4. Juni.

Umgangs-Formen

In klassischen Projekten entstehen, ehe die eigentliche Implementierung der Funktionalitäten beginnt, in der Regel mehr oder weniger schwergewichtige Dokumentationen und Feinkonzepte. Das Ziel ist dabei, möglichst genau festzuschreiben, was entwickelt werden soll. Je größer die Vorhaben, desto komplexer sind jedoch die Herausforderungen, und ab einer gewissen Größe können nicht mehr alle Einzelheiten im voraus bedacht und spezifiziert werden. Hinzu kommt, dass das geschriebene Wort interpretierbar und damit missverständlich ist – wie im übrigen jede Kommunikation. Und: Man kann als Entwickler mit einem Stoß Papier (dem Feinkonzept) schlecht über die konkreten Anforderungen sprechen.

Agiles Vorgehen erkennt an, dass sich Anforderungen im Laufe der Zeit ändern können und werden. Das beste, umfangreichste, ausführlichste und feingranularste Konzept kann immer nur einen Schnappschuss des aktuellen Kenntnisstands des Kunden widerspiegeln und schon morgen (oder in einem Monat …) veraltet sein. Deshalb also direkt ran an die Quelle - und den Kunden ins Projekt geholt!

Eine der radikalsten Formen findet man – wie der Name schon nahelegt – im Ansatz des Extreme Programming. Der Kunde wird zum Teil des Entwicklungsteams und ist permanent und rund um die Uhr für Fragen und Entscheidungen verfügbar. Auf diese Weise kann der Anteil der Vorab-Spezifikation und -Dokumentation extrem reduziert werden.

Nicht ganz so vereinnahmend sind andere agile Herangehensweisen in ihren Ansprüchen an den Kunden. Allen gemein ist jedoch, dass mindestens in festen Abständen (2-4 Wochen) auf der Basis lauffähiger Software-Stände mit dem Kunden das weitere Vorgehen im Projekt abgestimmt wird. Der klassische Schöpfungsakt eines Feinkonzepts wird im agilen Kontext in viele kleine Teilschritte zerlegt. Quasi just in time werden die fein ausspezifizierten Anforderungen geliefert und besprochen. Dies geschieht auf der Basis des aktuellen Projektforschritts.

Offensichtlich ist es also sinnvoll und hilfreich, den Kunden während des Projekts so nahe wie möglich an sich heranzuziehen.
Wie eine solch enge Kooperation zwischen Entwicklern und Kunden aussehen kann, ist mir vor kurzem bei der Supervision eines Scrum-Projekts begegnet.

Das Projekt hatte zur Aufgabe, auf Basis einer bestehenden Anwendung neue Funktionalitäten für vergleichbare Prozesse anderer Bereiche des Unternehmens zu schaffen. Gleichzeitig sollte sich die produktive Anwendung weiterentwickeln. Das hatte zur Folge, dass mehrere Interessengruppen ihre Anforderungen an das neue System formulierten. Wollte man all das im voraus detailliert spezifizieren, wären endlose Diskussionen um nicht verifizierbare Details sicher nicht zu vermeiden.

Key-User im Scrum-Team

Um all dem vorzubeugen, wurden in diesem Projekt die Key-User der (bestehenden und der künftigen) Anwendung in das Scrum-Team aufgenommen. Sie nehmen aktiv am Daily Scrum teil, spezifizieren und priorisieren gemeinsam mit dem Product Owner, bauen Testdaten auf, testen im laufenden Sprint die fertig entwickelten Stories und präsentieren am Sprintende im Review ‘ihre’ neuen Funktionalitäten. Das sichert eine ungeheuer tiefe Einbeziehung in die Entstehung des Produkts, fördert die Abstimmung zwischen der sich zum Teil widersprechenden Interessen der Stakeholder, schafft ein tiefes Verständnis für die entstehende Anwendung und garantiert eine Verfügbarkeit der fachlichen Ansprechpartner, die beispielhaft ist.
Das ist ‘on-site customer’ at its best!

Einbeziehung der Endanwender

Allerdings – wie so oft – schafft die Lösung eines Problems wieder neue. In diesem Fall war es so, dass das Team zunehmend das Gefühl hatte, dass das Review gar kein ausreichendes Kundenfeedback mehr liefert. Durch die tiefe Integration der Key-User, die auch noch selbst präsentierten, war das Review am Ende zu einer internen Veranstaltung des Teams und damit eigentlich überflüssig geworden.

Kann man sich nun die Frage stellen: Wer sind hier eigentlich die Kunden? Sind es wirklich die Key-User? Oder sind es nicht vielmehr die Kollegen der Key-User, also die Endanwender, die später mit der Anwendung arbeiten werden? Hat das Team die ‘richtigen’ Kunden im Projekt?

Um wieder ausreichend externes Feedback zu bekommen, entschloss sich das Team, künftig am Sprintende in die Abteilungen der Key-User zu gehen und als Review gezielt vor den Endanwendern zu präsentieren. Ob diese Anpassung den gewünschten Erfolg haben wird? Das Ergebnis des Experiments steht noch aus.

Foto: © http://www.sxc.hu/photo/916599

Den ganzen zweiten Tag lang besuchten wir den Business-Track. Darüber, ob das an dem beeindruckenden Vortrag von Herrn Konjovic über die Paid-mobile-Content-Strategie von Axel Springer am Vortag lag, lässt sich streiten.

“Es ist ja nur eine App” – oder vielleicht doch nicht?

Der zweite Tag startete für uns mit einem Vortrag von Dr. Ralf Carbon vom Fraunhofer Institut. Neben einem Ausblick in die unterschiedlichen Arten von Apps (Consumer / Business) stellte er die Konzepte zweier vom Fraunhofer Institut betreuten Mobile-Projekte vor.

Beeindruckend war der Nutzen, der im Bereich der Landwirtschaft durch verschiedene Apps für John Deere erzielt werden konnte. So gibt es Apps für die Wartung und den Service der Maschinen, eine App für den Landwirt, der auf seinem iPad die Task-Planung vornimmt und eine für den Arbeiter auf dem Feld, der durch eine iPhone-App diese Tasks bekommt und bei der Umsetzung, durch Standortermittlung (bin ich auf dem richtigen Feld?) etc. unterstützt wird. Hier fällt auf, dass für jeden individuellen Anwendungsfall eine eigenständige App gebaut wurde, die nur auf den Nutzen des jeweiligen Anwenders reduziert ist. Ergo kommt es bei Apps stets auf den Kontext an.

Ebenfalls spannend war der Exkurs zu Lufthansa Systems. Hier wurde eine App realisiert, die Piloten das Leben dahingehend erleichtert, dass sie ihre Karten nicht mehr in riesigen Aktenordnern in ihren Pilotenkoffern hinter sich herziehen und bei jeder Änderung neu in ihre Ordner einpflegen müssen. Eine App verwaltet dieses Kartenmaterial automatisch, stellt es dar und übernimmt auch die Aktualisierung des Kartenmaterials bei Änderungen.

Neben der Vorstellung der beiden realisierten Projekte wurde der Prozess namens “mConcAppt”, den das Fraunhofer Institut für die App-Entwicklung erstellt hat (und selbstverständlich auch jedem vorschlägt), vorgestellt.

Er soll helfen, eine Antwort auf die zentralen Fragen der App-Entwicklung zu finden.

• Welche Anforderungen habe ich an das Testen?
• Welche an die User Experience?
• Welche an das Variantenmanagement (Apps für spezifische Kontexte, verschiedene Plattformen)?
• Gibt es ein Mobilitätspotential für den Workflow, den Geschäftsprozess, die Aufgaben etc?
• Ist es die “richtige” App für den Score?
• Ist das Backend für den mobilen Anwendungsfall geeignet?
  Interessant ist hier das erwähnte Verhältnis von 80 zu 20, wenn es um den Arbeitsaufwand von Backend-Entwicklung und Frontend-Entwicklung geht. Dieses Verhältnis können wir nur bestätigen.
• Welche Architektur ist die richtige für meine App (Nativ, Hybrid oder Web)?
• Welche Anforderung stelle ich an die Interaktion (UI, UX etc.)?

Der “mConcAppt”-Prozess beginnt dabei mit einem eintägigen Workshop zur Anforderungserfassung mit Kunde, Anwender, Fachabteilung etc., um in den folgenden zwei bis drei Wochen ein komplettes Konzept für die App zu erarbeiten.

Sehr große Erfolge haben sie dabei mit einfachen Prototypen in Form von Bleistiftzeichnungen und Wireframetools wie Balsamiq erzielt.

Klingt für uns alles sehr stark nach Wasserfall, auch wenn Herr Dr. Carbon erwähnte, dass es mehrere Zyklen in den einzelnen Schritten von “mConcAppt” gibt. Interessant wäre, wie sich das Ganze mit agilen Methoden in Einklang bringen ließe.

Die Mobile-Plattform der Zukunft: Facebook

Martin Szugat gab uns einen Einblick die App-Welt von Facebook und nannte dabei viele interessante Fakten zu Facebook.

• In den USA verbringen die Leute 16% ihrer Online-Zeit auf Facebook
• 57% der Smartphone User sind bei Facebook
• 47% der Zeit verbringen die Amerikaner mit Spiele- und 32% mit Soziale-Netzwerke-Apps
• Als Nutzer zählt Facebook nur Nutzer, die innerhalb der letzten drei Tage online waren
• 7.000.000 Webseiten sind mit Facebook verbunden
• Jeden Tag kommen 10.000 hinzu
• 20 Millionen Facebook-Apps werden pro Tag installiert

All diese Fakten unterstreichen, dass über Facebook sehr viele Menschen erreicht werden können und dass Facebook sehr tief im Web “verankert” ist.

Ebenfalls erklärte er das neue Marketing-Buzzword “SoLoMo”. Die Leute wollen sich vernetzen (Social), wollen zeigen, wo sie sind bzw. sagen, was um sie herum los ist (Local) und wollen das auch noch alles mobil machen (Mobile). Als Beispiele, die “SoLoMo” sehr gut umsetzen, nannte er Glancee und Badoo. Einen Dienst, der eine “neue Ebene” in Facebook einführt, indem er Leute mit gleichen Interessen zusammenführt und eine etwas andere Dating-Plattform. Gemeinsam haben beide, dass sie in Verbindung mit Facebook extrem geringe Customer Acquisition Costs haben.

Nach einem Exkurs ins Marketing wurden die Technik von Facebook Apps und die Zukunft von Facebook thematisiert.

Facebook Apps könnnen bei Facebook einfach via iFrame eingebunden werden, d.h., der App-Anbieter muss sich selbst um das Hosting etc. kümmern. Jeder Nutzer muss die Daten, die eine App nutzen darf, explizit freigeben, es macht also den Eindruck, als ob ordentlich mit den Daten umgegangen wird.

Werden Apps für mobile Endgeräte erstellt, so können diese via HTML5 oder Nativ realisiert werden. Als Vorteil von HTML5 wurde erwähnt, dass eine APP nur einmal geschrieben werden muss und so für Desktop und für Mobile eingesetzt werden kann. Vorteilhaft ist auch, dass der Nutzer seine Daten nur einmal freigeben muss.

Interessant ist, dass Facebook die Anforderung “Social by Design” an Apps stellt, es Kampagnen-Apps somit schwer haben.

Am Ende gab Herr Szugat noch einen Ausblick in zukünftige, neue Features von Facebook. Da wären der Open Graph, welcher den App Entwicklern ermöglicht, einen Nutzer mit einer Aktion zu einem Objekt in Beziehung zu setzen (z.B. Frau Wunderlich hört Little Dragon), da ein “Like” nicht mehr aussagekräftig genug für gezielte Marketingaktionen ist. Auch auf die neue Online-Währung Credits, die Facebook etablieren möchte, wurde eingegangen. Auch hier ist interessant, dass, wann immer bei Facebook gezahlt werden soll, auch diese Credits als Zahlungsvariante angegeben werden müssen. Dabei verdient Facebook ganz nebenbei 30% mit.

Facebook stellt folglich eine echte Alternative zu App Stores bzw. zu einer eigenen mobilen Webseite dar, da viele Nutzer erreicht und auf mehreren Kanälen z.B. durch nur eine HTML5-App angesprochen werden können. Wenn Facebook Credits von den Nutzern angenommen wird, gibt es zusätzlich eine neue Internet-Währung.

Werbung auf mobilen Plattformen – mehr Relevanz für nachhaltig erfolgreiche Geschäftsmodelle

Herr Markus Breuer startete mit der Aussage “advertising sucks” und variierte diese Aussage noch zu “too much advertising sucks”, “stupid advertising sucks” und “irrelevant advertising sucks”.

Er ging auf eine Statistik ein, die wir auf der Konferenz schon mehrfach gesehen hatten: Ab 2014 werden mehr mobile Endgeräte als “klassische” Rechner genutzt werden. Diese Zahl ist umso bedeutender, wenn man bedenkt, dass Apps und mobile Webseiten derzeit nahezu werbefrei sind. “Mobile – It’s a wonderful world?” Wir als Nutzer würden selbstverständlich sagen: ja, aber “kostenfreier” Content wird in der Regel durch Werbung finanziert. Die schöne neue Welt wird folglich leider nicht so bleiben.

Nach einem Exkurs, dass sich mit Android schwerer Geld verdienen lässt als mit iOS (3% Paid Apps vs. 17%), stellte er das Werbekonzept vor, das nugg.ad anbietet.

Um das “sucks” in “advertising sucks” zu entkräften, müsse Werbung effektiv gemacht werden. Dies soll durch Targeting erreicht werden. Das Verhalten des Nutzers wird durch Cookies und andere Technologien, “die jeder Entwickler kennt”, beobachtet und analysiert; ab und zu werden Nutzer zusätzlich durch Umfragen um weitere Informationen gebeten. Ziel ist es, dem Nutzer Werbung zu zeigen, die zu Ihm passt bzw. die die Marketingabteilungen als zur Zielgruppe passend definieren.

Neue Herausforderungen zum Thema Mobil sind jetzt natürlich, wie dieses Beobachten des Nutzers auf mobilen Endgeräten geschehen kann. Konkrete Lösungsansätze wurde aber leider noch nicht vorgestellt. Es bleibt spannend.

UX-Webdesign für Tablets. Eine Anleitung

Christian Kuhn legte den Teilnehmern User Experience durch Unterstützung zahlreicher Werbevideos nahe. Nach der Viedeoshow gab er Hinweise auf Dokumente, Tools und Links, die helfen, um eine User Experience, die diesen Namen auch verdient, umzusetzen:

• Tablet-screendesign.info/ – eine Liste aller gängigen Tablets mit Auflösung, Betriebssystem etc.
• iMockups – eine Software, um Wireframes für Apps und Webseiten zu erstellen
• Die User Experience Design Guidelines von Windows Phone 7 und iOS
• Onswipe – ein Tool zur Realisierung der Tablet-Unterstützung von Webinhalten
• Loadtimer – für das Testen der Ladezeiten auf mobilen Endgeräten
• Aside – ein in HTML5 umgesetztes Magazin als gelungenes Beispiel

Für das Gelingen von User Experience in der Praxis gab es folgende Tipps:

• unterschiedliche mobile Betriebsysteme unterstützen unterschiedliche Anzahl an Gesten – es gibt dafür leider noch keinen Standard
• UX der Hardware, des Betriebsystems und der Webseite sind von Bedeutung
• Um Bereitstellung der Schriftart kümmern – einige mobile Betriebsysteme nehmen sonst eigene
• Informationen weglassen – Tablet first
• 1 cm Platz um Navigationselemente
• Responsive Design – evtl. jedoch nicht für mobile Version
• Einsatz Adaptive Images
• Minimalistisches & helles Design

Interactive TV – mit HTML5 auf den 2nd Screen

Andreas Lohmann gab uns einen Einblick in die Welt des interaktiven TVs. Neben den Anfängen von Interactive TV durch Text, Home Shopping und der Gameshow Hugo zeigte er uns, wohin die Reise geht. Zu 2nd Screens, die wir in Form von Smartphones oder Tablets in Zukunft nutzen können, um uns am Geschehen im TV zu beteiligen.

Fazit

Betrachte ich den zweiten Tag der Konferenz in Summe, nehme ich mit, dass es bei Apps stets auf den Kontext ankommt, das Thema Facebook Apps in Zukunft auch für uns spannend wird, “advertising sucks”, auf Tablets Content + Context = King gilt und beim interaktiven Fernsehen Context King ist.

Selbstverständlich bedanken wir uns bei den Sprechern, Ausstellern und Organisatoren für eine gelungene Konferenz.

Die Eröffnung der MobileTechCon 2012

Die Konferenz wurde durch Sebastian Meyen vom Software&Support-Verlag eröffnet. Er übergab die Session an Maks Giordano von Nunatak. Wer vom Design mobiler Applikationen spricht, meint dabei meist das Design von grafischen Oberflächen. Dass Audio genauso wichtig sein kann, liegt schon in der Historie der Telekommunikation begründet. Mobile Anwendungen laufen auf modernen Telefonen. Telefone wurden erfunden, um Sprache zu übertragen.

Manfred Lutzky von Fraunhofer IIS stellte den AAC-ELD-Codec vor. Dieser Codec ist ein Full HD Voice-Codec, der heute schon in Apple Facetime verwendet wird und in iOS 5 auch Entwicklern von Apps zur Verfügung steht. Der AAC-ELD-Codec ähnelt dem AAC-Codec, ist aber auf geringe Verzögerungen optimiert, was wichtig für die Real-Time-Kommunikation ist.

Philipp Eibach stellte sein neues Startup wahwah.fm vor. Eibach war schon an der Gründung von last.fm beteiligt und ist schon lange im Bereich Social Music unterwegs. Auf dem Smartphone hört jeder Musik für sich allein. Das Ziel von wahwah.fm ist, dass Musik wieder gemeinsam und zusammen gehört wird. So lässt sich Musik von Bekannten und Unbekannten entdecken. In wahwah.fm kann jeder Nutzer mit seiner Playlist auf Sendung gehen. Jeder Nutzer ist damit ein eigener, kleiner Radiosender. Andere Nutzer können sich in diese Sendung einklinken und mithören. Hörer einer laufenden Sendung können über Chats etc. interagieren. Die Location eines Senders lässt sich bei der Suche nach Sendern berücksichtigen. wahwah.fm ist eine prima Möglichkeit, Musik neu zu entdecken.

Michael Breidenbrücker von Reality Jockey Ltd. zeigte RjDj. RjDj lässt einen Nutzer selbst Musik erschaffen. Dabei verwendet RjDj nicht ein klassisches User Interface, sondern bezieht das komplette Sensor-Netzwerk des Smartphones ein. Musik wird also durch die Location, die Bewegung des Nutzers und sein Umfeld erschaffen. Der Nutzer taucht so in eine audiovisuelle Umgebung ein, in der die Intensität der Immersion sehr hoch ist. Auf Basis von RjDj wurden bereits weitere Apps entwickelt – wie die Audio-App zum Film Inception, die in Zusammenarbeit mit dem Soundtrack-Komponisten Hans Zimmer und dem Regisseur Christopher Nolan entstanden sind.

Anika Brinkmann, die als Kommunikationsdesigner Mobile-Knowledge.de verantwortet, eröffnete den Mobile Web-Track. Sie gab einen allgemeinen Überblick über die Themen des Tracks: Was bedeutet „Always on“? Hat always online nur gute oder auch unangenehme Seiten wie die allzeitige Bereitschaft von Arbeitnehmern, die mit modernen Kommunikationsendgeräten ausgestattet werden? Ist „Always on“ nur ein Versprechen oder schon heute Realität? Gibt es immer noch die Schere zwischen Stadt und Land, was die Netzabdeckung von UMTS und LTE angeht? Der Footprint (die Größe) der Seiten wächst im Moment noch stärker als die verfügbare mobile Bandbreite. Was nutzt die Cloud, wenn gerade keine Verbindung zum Internet hergestellt werden kann? Wie muss mit Nutzerdaten umgegangen werden – besonders im Spannungsfeld zwischen den Wünschen des Marketings und den Anforderungen des Datenschutzes? Wie befreie ich Daten aus Datensilos wie SAP oder gängigen CRM-Systemen? Content (sprich: Daten) muss in unterschiedlichen Kontexten unterschiedlich genutzt werden können. Daher muss er in offenen Formaten (kein Flash) und in unterschiedlichen Ausprägungen (z.B. auch in hoher Auflösung für Retina-Displays) vorliegen, um genutzt werden zu können. Um all diese Fragen zu beantworten, sollte zunächst eine Strategie erarbeitet werden, aus der wiederum Konzepte entwickelt werden können. Content sollte sowohl für’s Web als auch für mobile Anwendungen verwendet werden können. Dabei sollte man auf offene, zukunftssichere Plattformen statt auf proprietäre Technologien setzen. Wir sind hier und jetzt dabei, ein neues Level der Kommunikation zu erreichen. Zu den Technologien, mit dem dies umgesetzt werden wird, gehören sicherlich HTML5 und CSS3.

Ulrich Schmidt von sevenval zeigte die Offlinemöglichkeiten von HTML5-Webapplikationen. Der Grund, warum man überhaupt Offline-fähige Applikationen braucht, ist die unvollständige Netzabdeckung. Gerade wenn man beispielsweise in der Bahn unterwegs oder im Ausland-Urlaub ist, dann hat man oft kein Netz. Offline zu sein ist ein temporäres Problem, das durch HTML5 gelöst werden kann. Konzeptionell ist zwischen Daten und Funktionen zu trennen: Entweder man kann nur Daten oder nur Funktionen offline vorhalten. Oder man kann eine komplett Offline-fähige Webapplikation erstellen. Technologien für ein „Aktives Offline“ für Daten sind Local Storage, das als Cookie-Ersatz in allen Browsern läuft, WebSQL, das inzwischen deprecated ist aber zumindest auf iOS und Android zur Verfügung steht, und IndexDB, die in neueren Browsern (allerdings noch nicht in mobilen Browsern) als Weiterentwicklung von Local Storage und WebSQL angesehen werden kann. Als Bleeding Edge kann die FileSystem API angesehen werden, die ab Chrome 13 einen direkten Zugriff aufs Filesystem zur Ablage von Binärdaten erlaubt. „Passives Offline“ für Funktionalität (JavaScript) und Ressourcen (HTML, CSS, Bilder) bietet der Application Cache. Die Herausforderung bei der Verwendung des Application Caches ist es, diesen „aktuell“ zu halten und das Update-Verhalten sinnvoll zu implementieren. Der Application Cache schlägt HTTP-Header (außer beim Firefox). Die Schritte zur Erstellung einer Offline-fähigen Webapplikation sind laut Schmidt zuerst das Erstellen von Layout und Struktur (analog zu einer normalen Webapplikation), danach das Einführen von Local Storage zur Speicherung der Daten und anschließend die Verwendung des Application Caches zur Speicherung des bereits erstellten Layouts und der Struktur. Der Vortrag schloss mit Empfehlungen aus der Praxis zum Umgehen von Fallstricken.

Sven Günther von it-agile stellte die API des Zeitungskiosks in iOS 5 vor. Zeitschriften-Apps lassen sich mit NewsstandKit implementieren. Dieses bietet Features wie Push Notificiation und Background Downloads. Außerdem lässt sich programmatisch das Programm-Icon verändern, so dass das Cover der aktuellen Ausgabe als Icon verwendet werden kann. Payments lassen sich über das StoreKit abwickeln. Zur Anzeige von Content sind WebViews ungeeignet, da sich mit WebViews nur schwer die Anmutung einer Zeitung oder eines Magazins nachahmen lässt. Besser geeignet dazu sind CoreText und der UIPageViewController.

Torsten Drees präsentierte die MEAP (Mobile Enterprise Application Plattform), die mit einer Multi-Channel-Architektur die Herausforderung aktueller Enterprise Mobility Trends lösen soll. Eine Implementierung der MEAP ist die Magic Integration Plattform von Magic Software. Diese Präsentation kann als reiner Marketing-Vortrag bewertet werden.

Georg Konjovic, der als Director Premium Content die Konzern-weite Paid Content-Stratgie bei Axel Springer verantwortet, präsentierte die Ziele des Verlags. ASV sieht sinkende Print-Reichweiten nicht als Gefahr, sondern als neue Chance für den Qualitätsjournalismus. Die Paid Content-Stragie vom Axel Springer Verlag äußert sich in ca. 70 Apps (teilweise HD-Apps für das iPad), der Plattform iKiosk (ePapers im Portable Document Format, der iKiosk steht für andere Verlagshäuser offen), einem News-Aggregator (myEdition), der sich zurzeit in einer Closed Beta befindet, und zahlreichen News-Sites. Die größte Herausforderung ist die Schaffung neuer Abo-Modelle bzw. die Migration der Nutzer von kostenlosen Web-Diensten zu Nutzern kostenpflichtiger Dienste. Anders als in den USA entwickelt sich der Markt für Qualitätsjournalismus in Deutschland positiv. Vor allem Nutzer des iPads haben eine hohe Zahlungsbereitschaft. Alle zukünftigen Angebote bei Axels Springer sollen ein Preisschild bzw. einen Abo-Preis haben.

Rosemarie Wirtsmüller von Antenna International zeige Apps für Museumsbesucher. Diese Apps sind viel mehr als reine eGuides. Sie informieren den Nutzer schon vor dem Besuch des Museums (Pre-Visit-Kontakt) und unterstützen in bei der Nachbereitung (Post-Visit-Kontakt). Dies äußert sich auch in den Download-Zahlen. Diese Apps werden sogar von Nutzern verwendet, die gar nicht das Museum besuchen, sondern sich mit der App über das Thema einer Ausstellung selbst lange nach der eigentlichen Ausstellung informieren möchen.

Nach dem tollen Erfolg des Seminars im letzten Jahr haben wir es auch 2012 geschafft, diese Veranstaltung wieder nach Hamburg zu holen.

Wer sollte dieses Seminar besuchen? Jeder, der Scrum in einem Unternehmen einführt, es als Scrum Master oder Product Owner im wesentlichen treibt und der sich schon immer gefragt hat, warum das, was er sagt und meint, von den “anderen” anders verstanden und gemeint wird. Jeder, der Feedback geben will und doch nicht weiß, wie das eigentlich wirklich geht. Jeder, der die Fallstricke im persönlichen Umgang miteinander besser verstehen möchte, um sie frühzeitig erkennen zu können.

Stimmen von Teilnehmern vergangener Trainings:

“Ich kann mich nicht daran erinnern, so effizient, effektiv und nachhaltig Inhalte vermittelt bekommen zu haben.”

“Kompetenz auf allen Ebenen! Wobei ich mir bestimmt nicht jeder Ebene bewusst war. “

Weitere Informationen finden sich hier, eine Anmeldung kann formlos per Mail an training@holisticon.de erfolgen.

Das Aufgabengebiet eines ScrumMasters umfasst mehr als die Überwachung der Scrum-Regeln. Er ist Mentor, Coach, Schlichter, Tröster, Motivator, kurz: die gute Seele und das Gewissen des Teams. Auch wenn die Mechaniken von Scrum im Team funktionieren, gibt es für einen ScrumMaster noch genug zu tun. Es werden immer wieder Hindernisse auftauchen, die aus dem Weg geräumt werden müssen. Teammitglieder werden auf fachlicher und persönlicher Ebene Auseinandersetzungen führen, bei denen der ScrumMaster als Vermittler gefragt ist. Fluktuation im Team erfordert Unterstützung bei der Integration neuer Teammitglieder. Und wenn Scrum zur Routine wird und die Retrospektiven nur noch lustlos abgearbeitet werden, anstatt sie als Chance zur Verbesserung zu nutzen, dann tritt der ScrumMaster auf den Plan, um wieder frischen Wind ins Team zu bringen: durch neue Arbeitsweisen, agile Spiele oder eine gemeinsame Unternehmung. Sie sehen: dem ScrumMaster wird auch in einem routiniert arbeitenden Scrum-Team nicht langweilig.

Wenn meine Kollegen und ich neue Scrum-Teams unterstützen, dann stoßen wir oft auf die Erwartungshaltung, dass es ausreicht, ein Team durch die ersten zwei Sprints zu begleiten. Spätestens dann – so die Meinung unserer Auftraggeber –  sollte jedes Team die Scrum-Mechaniken verstanden haben. Das mag in vielen Fällen zutreffen. Aber gerade in der Phase, in der man zum ersten Mal meint, alles verstanden zu haben, besteht die Gefahr, wieder in alte Verhaltensmuster zu verfallen. Dazu ein Beispiel.

Foto: Mat Connolley

Haben Sie schon einmal in einem Land mit Linksverkehr (bzw. Rechtsverkehr – je nachdem, wo Sie leben) hinter dem Steuer eines Fahrzeugs gesessen? Ich habe die Erfahrung gemacht, dass ich zu Beginn sehr gut mit der ungewohnten Situation klarkomme, weil ich mich stark auf meine Fahrweise konzentriere. Irgendwann komme ich dann an den Punkt, an dem ich mich sicher fühle und glaube, dass mir der Linksverkehr in Fleisch und Blut übergegangen ist. Meine Konzentration lässt nach, ich habe wieder Augen für die Landschaft um mich herum. Und dann passiert es: beim Abbiegen steuere ich plötzlich die rechte Fahrspur an. Offensichtlich arbeitet mein Unterbewusstsein immer noch im Rechtsverkehr-Modus.

Ähnlich geht es vielen frisch gebackenen Scrum-Teammitgliedern: die oft über viele Jahre praktizierten traditionellen Vorgehensmodelle der Softwareentwicklung sind tief im Unterbewusstsein der Teammitglieder verankert. Sobald den Scrum-Mechanismen nicht mehr viel Aufmerksamkeit geschenkt wird (“Ich weiß ja jetzt, wie’s geht”), übernimmt das Unterbewusstsein die Kontrolle. Der ScrumMaster ist dann – um im Bild zu bleiben – der Autofahrer im Gegenverkehr, der mit seiner Lichthupe auf die Regelverletzung aufmerksam macht.

Deshalb: Augen auf im Straßenverkehr – und im agilen Projekt!