Vortrag eTailment Kongress 2015. Meine These: liebe Händler, Eure Organisationsstrukturen sind kaputt. Diese These (die auch für viele andere Branchen gilt :-) ) versuche ich in diesem Vortrag zu belegen.

1. HALLO
HÄNDLER!
Björn Schotte
bjoern.schotte@mayflower.de
0931/35965-15
Herzlich Willkommen zum Vortrag „IT vom Supporter zum Enabler“ auf dem eTailment Kongress 2015.
Mein Name ist Björn Schotte. Mit meinem Unternehmen MAYFLOWER GmbH realisieren wir digitale
Produkte für unsere Kunden, auf Basis von kompetenten Software-Teams die integriert Konzept,
Design und Implementation umsetzen. Und weil wir schon seit 2005 agil entwickeln (und immer noch
lernen ;-) ), beschäftigen wir uns intensiv mit Team-Strukturen, Team-Aufbau, Team-Psychologie. Denn
Software ist vor allem eines: gute Kommunikation zwischen allen Beteiligten.

2. EURE ORG-
STRUKTUREN
SIND KAPUTT
Beginnen möchte ich mit einer provokanten These: Eure Organisationsstrukturen sind regelrecht
KAPUTT. Hier dürfen Sie mich gerne herausfordern - beim persönlichen Gespräch oder in einem
Telefonat. Einstweilen versuche ich nun Belege für diese These in meinem Vortrag herzuleiten.

3. Komplexität bei
Konsumenten/Märkten
+
Software
Wir kämpfen mit einer zunehmenden Komplexität auf zwei bis drei Achsen: zum einen bei den
Konsumenten und damit unseren Märkten, die immer dynamischer werden. Zum anderen auch bei der
Entwicklung von Software, die grundsätzlich komplex ist - allen „Standard“-Prophezeiungen des
Vertriebs von Software-Produktherstellern zum Trotz ;-)

4. Wachstum in den Bubble
Menschen Online, in Milliarden
0
0,125
0,25
0,375
0,5
1995 2000
Quelle: http://ben-evans.com/benedictevans/2015/6/19/presentation-mobile-is-eating-the-world
Benedict Evans, Partner von Andreessen Horowitz, einem der bekanntesten VCs im Silicon Valley, hat
jüngst in einer Präsentation zum Auftrieb von Mobile Devices dargestellt, wie viele Menschen im Lauf
der Zeit online waren. Während 1995 noch nicht einmal eine Viertelmilliarde Menschen einen Online
Zugang hatten, waren es bis zum berühmten Tech-Bubble 2000 bereits knapp 0,5 Milliarden Menschen,
die einen Online Zugang hatten.

5. Wachstum seit dem Bubble
(in Milliarden)
0
0,75
1,5
2,25
3
1995 2000 2014
Menschen Online Smartphones
Quelle: http://ben-evans.com/benedictevans/2015/6/19/presentation-mobile-is-eating-the-world
Betrachtet man die Zeitspanne bis 2014, so sieht man, dass wir 2014 bereits knapp 3 Milliarden
Menschen online haben, und davon ca. 2 Milliarden die per Smartphone online sind.

6. Tendenz bis 2020:
+1 Mrd. Menschen
Bis 2020 wird erwartet, dass noch einmal 1 Milliarde Menschen hinzukommen - bevorzugt über Mobile
Devices.

7. 1995-2000:
Websites, Nachrichten,
Amazon (Bücher)
Wir haben also damals, in den grauen Vorzeiten des Internets, nur wenige Angebote gehabt. Es gab ein
paar Websites mit lustigen animierten Baustellenschildern, ein paar Nachrichten Websites wie zB
SPIEGEL Online, und auch Amazon gab es damals schon und verkaufte Papier-Bücher online.

8. Heute?
Und wie sieht die Situation heute aus?

9. Leben Online organisiert
Heute organisieren wir unser Leben online. Wir sind immer auf dem Sprung, haben das Smartphone bei
uns, das Tablet auf der Couch und neuerdings auch einen kleinen Supercomputer am Handgelenk.

10. Viele Anbieter
(GAFA Dominanz)
Es gibt eine Unmenge an Anbietern, die für uns Konsumenten bereitstehen, mit einer „kleinen“
Dominanz bei der GAFA Gang - Google, Amazon, Facebook, Apple.

11. Konsumenten haben
Auswahl-Macht
Wir Konsumenten haben die Auswahl-Macht. Wir können uns entscheiden, welche Angebote wir
nutzen wollen. Dank Globalisierung ist die Konkurrenz meist nur einen oder zwei Mausklicks entfernt.

12. Das Leben in der IT
Und wie schaut nun das Leben in der IT aus, bei uns Softwareentwicklern?

13. Erfolg von IT Projekten
43 %
18 %
39 %
Successful Failed Challenged
2012 CHAOS Research
Wenn wir uns anschauen, wie es um den Erfolg von IT Projekten steht, so kommt einem immer wieder
die CHAOS Studie in den Sinn. Die hat Softwareprojekte aller Art untersucht und festgestellt, dass die
Mehrzahl an Projekten scheitert oder zumindest „challenged“ (in Zeit, Geld und Funktionsumfang) ist.

14. Erfolg im Vergleich
Waterfall
57 % 29 %
14 %
Success Failed Challenged
Agile
49 %
9 %
42 %
Ich spreche ja heute auch über Agile Produktentwicklung, und da muss natürlich auch ein Vergleich der
unterschiedlichen Vorgehensmethoden mit enthalten sein. Die „klassische“ Art der Softwareentwicklung
basierte früher auf der Wasserfall-Methode. Vergleicht man beide Schulen miteinander, so sehen wir,
dass wasserfallartige Projekte deutlich im Erfolg gefährdet sind: 86% aller gemessenen Projekte
scheitern oder sind mal wieder gechallenged.
Doch wer glaubt, dass agile Methoden die Allheilmethoden sind, der sieht auch hier, dass es immerhin
über 50% der agilen Projekte schwer haben. Jedoch: sie scheitern dreimal so wenig wie klassische
Projekte, und sind dreimal so erfolgreich wie Wasserfall-Projekte.

15. Nutzung Funktionen in
Software
7 %
13 %
16 %
45 %
19 %
Rarely Never Used Sometimes Often Always
2011 Standish Group
2/3: selten oder nie
Doch selbst wenn man es einmal geschafft hat, ein Projekt online zu bringen, so haben wir an einen
nicht gedacht: den Endanwender. Zu dieser besonderen Spezies gibt es Untersuchungen, welche
Funktionen die Anwender in einer Software überhaupt nutzen. Die Zahlen sind zwar von 2011, haben
jedoch immer noch Gewicht. Was sagt die Grafik aus? So gut wie 80% aller Funktionen in Software
werden nie, manchmal oder kaum genutzt.
Hier ergibt sich also ein gewaltiges Potenzial zur Wertschöpfung für uns Produktentwickler!

16. Cynefin Wissensmodell
in Systemen
Damit nicht genug, sollten wir uns noch das „Kanefin“ Wissensmodell in Systemen anschauen. Was
das ist?

17. http://wandelweb.de/galerie/13_Cynefin/Cynefin-06.png
Softwareentwicklung
Cynefin ist ein Wissenschaftler, der untersucht hat, wie Management bei IBM funktioniert. Also so in
richtig, und nicht wie IBM das immer behauptet. Dabei hat er festgestellt, dass sich die Vorgehen zur
Lösung von Problemen in vier Quadranten einteilen lassen: einfach, kompliziert, komplex und
chaotisch.
Für jeden dieser Quadranten gibt es unterschiedliche Lösungsstrategien, und alle haben damit zu tun,
über wieviel Wissen man zur Lösung des Problems verfügt. Die bahnbrechende Erkenntnis:
Softwareentwicklung findet meist im komplex-chaotischen Umfeld statt, und das bedeutet dass man
anders als bisher vorgehen muss, um Probleme zu lösen, nämlich emergent, das heisst zunächst
ausprobieren oder handeln und dann schauen was passiert und daraus seine Schlüsse ziehen.

18. Wann Agile Methoden?
Stacey Diagram
https://crossbolt.files.wordpress.com/2013/11/when-to-use-scrum1.jpg
Neben dem Kollegen „Kanefin“ gibt es auch noch einen Wissenschaftler namens Stacey, der folgendes
Diagramm gemalt hat. Er hat das Wissen über technische Lösungen/Vorgaben und die Anforderungen
der Nutzer in Bezug gesetzt. Daraus lässt sich die Schlussfolgerung ableiten: wenn wir ganz genau alle
technischen Gegebenheiten und Lösungen wissen und auch ganz genau die Anforderungen der Nutzer,
dann können wir Projekte wasserfallartig abwickeln. Je ungenauer wir in beiden Achsen werden, desto
eher sind agile Methoden wie Kanban oder Scrum die sinnvollen Methoden.
Vereinfacht gesagt: wenn das Bekannte deutlich größer als das Unbekannte ist, dann Wasserfall. Wenn
das Unbekannte größer ist als das Bekannte, dann agile Techniken verwenden.

19. Warum also Agile?
Komplexität in Markt und Softwareentwicklung
Es gibt also zwei Achsen, an denen wir nahezu gezwungen sind, auf Agile Methoden zu schwenken:
durch die Komplexität, die uns durch den Markt gegeben wird und die Tatsache, dass diese
Undurchsichtigkeit auch auf die Softwareentwicklung durchschlägt, die ebenfalls komplexer Natur ist
(„unknown unknowns“). Und das liegt nicht daran, dass wir Softwareentwickler doof sind :-)

20. Techniken der
Vergangenheit
Lastenheft, Pflichtenheft, Abteilungsgrenzen,
Feature-Checklisten, Standard-Software
(=Mittelmaß), „Das haben wir schon immer
so gemacht“, „Das muss der Head of
entscheiden“, …
Um eine gute Unterscheidung treffen zu können, sollten wir uns anschauen, welche Techniken für die
alte Welt - die Vergangenheit - stehen, die uns so viele Schwierigkeiten bereiten. Dazu gehören neben
Lasten-/Pflichtenheften auch Feature-Checklisten und die Idee, man bräuchte ja nur eine Standard-
Software nehmen und „die zu 20% anpassen“ und schon wäre alles in Ordnung. Ein Reizwort, das
noch nicht auf den Folien zu finden ist: Dienstleister-Pitches. Sie glauben gar nicht, wieviel Unsinn ich
hier in den letzten 15 Jahren gesehen habe …

21. Das Agile Manifest
Als Scrum erfunden wurde, haben sich zwölf sehr bekannte Softwareentwickler um die
Jahrtausendwende in einem amerikanischen Skiressort getroffen und das Agile Manifest aufgestellt.
„So geht es nicht weiter“, war die einhellige Meinung. Daraus sind 12 Prinzipien entstanden, von denen
ich die vier Haupt-Prinzipien kurz vorstellen möchte. Denn diese sind wichtig, um zu verstehen, worum
es geht wenn die ganze Welt von „Agil“ spricht. Ich möchte hier auch Aufklärung betreiben: Agil ist
Mainstream geworden. Aber die wenigsten verstehen, worum es dabei eigentlich geht!

22. Individuen+Interaktionen
>>
Prozesse+Tools
Individuen und ihre Interaktionen untereinander sind wichtiger als Prozesse und Tools. Während also
Prozesse und Tools durchaus noch ihre Daseinsberechtigung haben, ist für den Erfolg eines Projekts
viel wichtiger, dass motivierte Individuen zusammenarbeiten und sich vor allem durch eine hohe
Interaktionsdichte untereinander auszeichnen. Das bedeutet auch: lieber Kunde! Du musst mitarbeiten,
dich involvieren, Zeit investieren!

23. Funktionierende Software
>>
ausführliche Dokumentation
Funktionierende Software ist wichtiger als ausführliche Dokumentation. Während Dokumentation
durchaus noch eine gewisse Wichtigkeit hat, ist es für das Vorankommen in einem Software-Projekt viel
wichtiger, regelmäßig ein Stück funktionierende Software zu sehen und darauf aufzubauen. Ausserdem
ist es für beide Seiten vertrauensbildend, wenn regelmäßig ein weiteres kleines Stückchen
funktionierende Software entsteht.

24. Zusammenarbeit mit dem Kunden
>>
Verträge
Die Zusammenarbeit mit dem Kunden ist wichtiger als Verträge. Der Kunde soll nicht durch
Vertragswerk erschlagen werden, sondern viel wichtiger ist es auch hier, mit dem Kunden auf
Augenhöhe zusammenzuarbeiten und ihn in die Softwareentwicklung mit einzubinden.

25. Veränderung begegnen
>>
einen Plan verfolgen
Was die mutigen Männer schon damals erkannt hatten, ist heute gnadenlose Realität: es ist für uns viel
wichtiger, der Veränderung zu begegnen als stur einen Plan zu verfolgen. Die Märkte sind
undurchsichtig, Konsumenten schneller weg als uns lieb ist. Also ist es nur folgerichtig, dass wir eine
Umgebung schaffen, in der wir schnell auf Veränderung reagieren können anstatt weiter tote Pferde zu
reiten. Machen Sie keine agile Software-Entwicklung, wenn Sie nicht per se mit Veränderung rechnen
(wollen). Veränderung ist eingebaut!

26. empirisch
iterativ
inkrementell
Ich werde oft gefragt, was Scrum ist. Zum einen ist Scrum ein empirisch (Erkenntnis aus Erfahrung)
orientiertes Verfahren, das über Iterationen lauffähige Software-Inkremente ermöglicht.

27. einfaches
Rahmenwerk
ziemlich
schwierig
umzusetzen
Man sagt auch, es ist ein einfaches Rahmenwerk, das allerdings ziemlich schwierig umzusetzen ist.
Viele Kunden denken „Wir machen jetzt agil, führen ein paar Prozesse ein, und schon läuft’s!“ - fataler
FAIL!

28. Inspect & Adapt
Good Enough
Zwei Prinzipien, die ganz wichtig für Agiles Arbeiten sind:
- Inspect & Adapt: wir inspizieren unsere tägliche Arbeit und leiten daraus Verbesserungen/
Veränderungen ab
- Good Enough: wir wollen keine Vollständigkeit, denn wie wir gelernt haben, gibt es die sowieso nicht.
„Good enough“ reicht aus, um weiter zu kommen. Wir haben ja eh die Chance, demnächst wieder zu
ändern.

29. Wert der
Software
erhöhen
(zum Wohle der Shopkunden)
Zudem geht es darum, den Wert einer Software kontinuierlich zu erhöhen. Wie man das macht? Nun,
indem man nur die Dinge baut, die auch einen Wert (für unsere Kunden, aber auch uns selbst) haben.
All die Dinge, die keinen Wert haben, werden nicht realisiert. Manchmal weiß man das allerdings nicht
so genau. Also müssen wir experimentieren. Am besten machen wir dies, indem wir eine Funktion nicht
„vollständig“ ausprogrammieren, sondern nur eine kleine Ausprägung davon implementieren und online
stellen. Dann gucken wir, was unsere Anwender damit machen. Wenn die glücklich damit sind, können
wir vielleicht weitere Ausprägungen dieser Funktion bauen. Und wieder testen. Oder wir stellen früh
fest, dass die Funktion keinen Wert hat.
Es ist also besser, nach einer Investition von 5.000 EUR festzustellen dass eine Funktion Unsinn war als
nach 20.000 EUR. Ob es allerdings nun 5kEUR oder 20kEUR Invest bedarf, kann ich zu Beginn nicht
sehen - wir müssen experimentieren.

30. Anwender
geben Ziel vor
Die Anwender einer Software geben das Ziel vor. Da die Anwender durchaus etwas „launisch“ sind,
verändert sich das Ziel regelmäßig. Sie können dem entgegen steuern, indem Sie das Verhalten Ihrer
Anwender in den Funktionen der Software messen.

31. Wir folgen dem
Marktsog
Anders ausgedrückt: wir folgen dem Sog der Märkte und realisieren dort die Gewinne von heute und
morgen.

32. Version 1
Wie kann man sich das bildlich vorstellen? Nun, zu Beginn des Projekts wissen wir, dass wir für unsere
Kundschaft ein Fortbewegungsmittel bauen, um von A nach B zu kommen. Schnelle Befragungen der
Nutzer haben uns ein klares Bild verschafft, was wir zunächst in Version 1 bauen. Während wir Version
1 entwickeln, unterhalten wir uns mit unseren Kunden. Die finden die ersten Prototypen ganz toll, was
uns darin bestärkt, Version 1 fertig zu stellen und auszuliefern.

33. Version 2
Doch relativ zeitnah stellen wir fest, dass unsere Kunden ein etwas robusteres und stabileres Fahrzeug
haben möchten. Das haben schon erste Umfragen während Version 1 ergeben. Also haben wir nun in
der weiteren Entwicklung unser Fahrzeug umgebaut und konnten Version 2 erfolgreich ausliefern. Die
Konstruktions- und Realisierungszeit betrug übrigens nur wenige Wochen.

34. Version 3
Mit der Zeit entwickelt sich das Bedürfnis der Kunden weiter. Das Fahrzeug soll nicht nur zur
Fortbewegung, sondern auch zum Transport dienen. Da wir kontinuierlich das Produkt weiter
entwickeln, ergibt sich, dass wir in Version 3 diesen Transporter ausliefern.

35. Version 4
http://images.fotocommunity.de/bilder/spezial/karten-und-kalender/weihnachtsmann-auf-motorrad-in-wilhelmshaven-8880f69c-4017-4b6f-ae33-3972505417de.jpg
Die Zeiten ändern sich und unsere Kunden wollen wieder zurück auf das Fortbewegungsmittel. Mit
Version 4 kommen wir den verändernden Wünschen nach und haben im Rahmen der kontinuierlichen
Entwicklung am Produkt das Produkt abermals verändert.

36. Anforderungen
an die
Organisation
Die Arbeit im agilen Umfeld stellt eine Organisation vor oftmals große Herausforderungen.

37. Hallo Händler!
Echte IT-Kompetenz
im Vorstand/GL?
Das fängt schon bei der IT-Kompetenz im Vorstand/der Geschäftsleitung an. Ich meine damit übrigens
nicht den „EDV-Leiter“. Viele sprechen heute vom „Chief Digital Officer“. Ok Leute, wenn Ihr dieses
Label unbedingt braucht … es geht doch darum, dass „ganz oben“ das Verständnis verankert ist, wie
das digitale Business heute funktioniert. Dass Haltungen wie „Experimente“, „Fail fast and cheap“,
„Good Enough“, „Inspect & Adapt“ verankert sind.

38. Alle Firmen
werden zu
Software-
Firmen
06.11. http://www.cio.de/a/digitale-transformation-laesst-keinen-stein-auf-dem-anderen,3231493
Steile Behauptung, aber als ITler gefällt mir das natürlich: alle Firmen werden zu Software-Firmen. Oder
„Software is eating the world“, wie Marc Andreessen (der der den ersten Browser erfand) vor einigen
Jahren titelte.

39. Vergangenheit (1985)
http://www.kassenzone.de/2015/05/11/die-ergebnislose-suche-nach-einem-cto/
IT/HR = „Unterstützungsaktivitäten“ WTF?
Hier sehen wir ein Bild der Vergangenheit. Porter wird seit den Achtzigern des vergangenen
Jahrhunderts an den Unis gelehrt - heutige Manager haben teilweise noch dieses Weltbild, das sie
leider 1:1 umsetzen. Der damaligen Theorie nach war IT nur eine Unterstützungsaktivität. Heute, dank
des Internets, rückt allerdings die IT ins Zentrum der Unternehmensaktivitäten. Organisationen, die in IT
nicht intensiv intensivieren, werden kaum Wettbewerbsvorteile abschöpfen können.

40. Dezentralität für
mehr
Geschwindigkeit
Zum einen ist da der ewige Kampf Zentral gegen Dezentral. Im Agilen Umfeld wollen wir möglichst viel
Entscheidungskraft in das Produktentwicklungsteam stecken, damit diese sehr schnell die
TimeToMarket realisieren können und nicht über unnötige Feedback-Schleifen durch Gremien,
langwierige Budgetierungsprozesse etc. ausgebremst werden.

41. Autonomy
Mastery
Purpose
=
Motivation
Dan Pink’s Drive sagt: Motivation entsteht durch Autonomy, Mastery & Purpose. Die Menschen wollen
ihre Arbeit so gut es geht eigenständig erledigen können (fokussiert/aligned durch Mission und „Ziele“).
Sie wollen dabei Mastery erleben. Und ihre Arbeit soll einen Sinn haben. Sinn stiften ist also eine
wichtige und zugleich sehr schwierige Aufgabe.

42. Produkt
Team 4
Produkt
Team 1
Produkt
Team 5
Produkt
Team 6
Produkt
Team 7
Produkt
Team 2
Produkt
Team 3
Interne IT
Produkt
Team 10
Produkt
Team 9
Produkt
Team 8
IT=Service bei Bedarf
Kunde
Kunde
Kunde
Kunde
Kunde
Kunde
Kunde
Kunde Kunde Kunde
PHP
Java
Mobile
JavaScript
API
Ein Teil einer Organisationsstruktur kann so aussehen. Wie man sieht, ist die interne IT nur Zulieferer der
einzelnen Produkt-Teams, die ihrerseits für ihren jeweiligen Markt arbeiten. Auch hier gibt es eine
Dezentralisierung der verwendeten Technologien, darauf komme ich später zu sprechen. Idealerweise
organisiert sich die interne IT auch nach agilen Methoden wie zB Kanban, denn als Zulieferer bekommt
sie die Anforderungen aus den Produktteams diktiert. Hier ist Loslassen gefragt, damit die
Produktteams volle Marktkraft entfalten können.

43. Beispiel Spotify
http://blog.crisp.se/2012/11/14/henrikkniberg/scaling-agile-at-spotify
Squad Produkt Team
Tribe
Squads mit
ähnlichen
Bereichen
Chapter
Leute mit
ähnlichen
Themen (zB
Testing)
Guild
Community of
Interest, Tribe-
übergreifend
Schauen wir uns mal an, wie Spotify arbeitet. Dort haben sich die Produkt-Teams in Squads unterteilt.
Jede Squad hat eine Mission für das Produkt oder den Produktteil, den sie bearbeiten. Sie haben einen
Product Owner, der die Anforderungen definiert, und alle notwendigen Fähigkeiten, um ihren Teil zu
erledigen. Damit sind sie jederzeit lieferfähig.
Ein Tribe ist eine Ansammlung von Squads, die in ähnlichen Bereichen des Produkts tätig sind. Ein
Chapter ist eine lose Verbindung von Personen, die in ähnlichen Bereichen (zB Testing, Architektur)
tätig sind bzw Know-how haben und sich locker und regelmäßig Squad-übergreifend austauschen, um
Synergie-Effekte zu heben und Erkenntnisse wieder in ihre Squads tragen.
In der Guild versammeln sich Personen mit ähnlichen Interessen tribe-übergreifend.

44. Beispiel Zalando
http://de.slideshare.net/ZalandoTech/radical-agility-with-autonomous-teams-and-microservices-in-the-cloud
Wechseln wir zurück nach Deutschland und schauen uns an, wie Zalando sich organisiert. Dort gibt es
ebenfalls Produkt-Entwicklungsteams, die agil organisiert sind und über Product Owner verfügen. Neu
hier ist eine Art „People Lead“, auf den ich später noch zu sprechen komme. Auch hier ist den Teams
gemein, dass sie eigenständig sind und jederzeit lieferfähig sind, um TimeToMarket zu realisieren. Die
Gründer von Zalando haben übrigens neulich postuliert, dass Zalando zu einer IT-Plattform für Mode
wird und alle (Marken, Händler, …) miteinander vernetzt. Wow.

45. Rolle des
Vorgesetzten
(ver)schwindet
People Lead = eher Coach
Die Rolle des Vorgesetzten tritt in agilen Umgebungen zurück. Wir erinnern uns: wir haben ein Team aus
motivierten Individuen, das mit einer Produktvision und -mission ausgestattet ist sowie einem Product
Owner, der die Gleise für die anstehenden Entwicklungen legt. Das Team verfügt mit der Retrospektive
über eigenständige Werkzeuge, um sich selbst zu verbessern und weiterzubilden. Die Rolle des
Vorgesetzten tritt also in den Hintergrund, es wird eher ein Coaching Ansatz. Reife Teams coachen sich
selbst oder die Individuen suchen sich die Leute selbst, von denen sie gecoached werden wollen.

46. Eigenschaften
eines
Produktteams
Wie sind also die Eigenschaften eines Produktteams? Was zeichnet die Team-Mitglieder aus?

47. Mitglieder sind
(fühlen sich)
verantwortlich
für das Produkt
Idealerweise fühlen sich die Mitglieder verantwortlich für das Produkt. Dafür notwendig sind wie
beschrieben Purpose, Mastery und Autonomy.

48. Mitglieder haben
alle notwendigen
Fähigkeiten und
Fertigkeiten
Die Mitglieder haben alle notwendigen Fähigkeiten und Fertigkeiten, um liefern zu können. Das
bedeutet: wir brauchen eine andere Form von Kompetenzerwerb und Kompetenz-Entwicklung als Sie
das bisher im klassischen Sinn kennen.

49. Fachabteilungen
sind eng am Dev-
Team
Die Fachabteilungen wiederum kommunizieren sehr eng mit den Entwicklern. Das bedeutet nicht
„Kannste mal schnell umsetzen“ (Hey-Joe-Prinzip), sondern es geht um den Dialog auf der Business
Domäne, damit die Entwickler verstehen worum es eigentlich im Fachlichen geht.

50. T
shaped
… die einzelnen Personen sind T-shaped. Auf der Vertikalen gibt es ein oder zwei Kernkompetenzen,
auf der Horizontalen eine Vielzahl an weiterer Know-how Gebiete, die die Personen haben und im Laufe
des Projekts (der Projekte) immer neu hinzu bekommen.

51. Keine Spezial-
Funktionen
(„der Architekt“)
Es gibt keine singulären Spezialfunktionen im Produktteam. Das gesamte Team arbeitet zusammen an
der Abarbeitung der jeweils wichtigsten Anforderung in einem Sprint. Singuläre Verantwortlichkeiten
sind zu vermeiden - deswegen ist ein ideales Produktteam eines, das aus Generalisten besteht, bei
denen jeder möglichst alle Aufgaben abdecken kann. So ist Geschwindigkeit und TimeToMarket zu
erreichen.
Ein Prinzip in der agilen Softwareentwicklung heisst zum Beispiel: die besten Architekturen in einer
Software entstehen emergent aus dem gesamten Team.

52. Kein
Scrummerfall
(Konzept -> Design ->
Implementierung)
Sie wollen scheitern? Prima! Dann trennen Sie Konzept- von der Design- von der
Implementierungsphase! Engagieren Sie Agenturen, die für teures Geld ein Screendesign und UX
Design abliefern und den Entwicklern zur Implementierung „hinwerfen“! Glauben Sie weiter daran, dass
es eines industriellen Mechanismus bedarf, bei dem man fachlich „schneidet“ und die einzelnen Stücke
voneinander getrennten „Experten“ gibt. Kommen Sie auf gar keinen Fall in Versuchung, alle an einen
Tisch zu bringen und während der gesamten Projektlaufzeit kontinuierlich über Anforderung, Design,
User eXperience und Implementierung zu sprechen.

53. Stabil
https://mercureaace2013.files.wordpress.com/2013/01/groupstages.png
In der BWL hat sich irgendwann die Überzeugung durchgesetzt, Personen auf Projekte zu verplanen
und hin- und herzushiften. Das ist ein Trugschluss, der einer schnellen TimeToMarket entgegensteht.
Nicht nur aufgrund der 5-Teambuilding-Phasen nach Tuckman gebietet es sich, ein möglichst stabiles
Team zu haben, das während der gesamten Laufzeit des Produkts möglichst 100% seiner Zeit
zusammen arbeitet. Es darf nicht das berühmte „Tagesgeschäft“ geben, denn das Produkt ist das
Tagesgeschäft!
A propos Team: Vorsicht vor „Group Thinking“, und haben Sie immer ein paar kleine Interventionen
griffbereit.

54. Produkt Team
Product Owner + Delivery
Team
Arbeit/Projekt
Arbeit/Projekt
Arbeit/Projekt
Arbeit/Projekt
Arbeit/Projekt
Arbeit/Projekt
Value
Vereinfacht gesagt gilt es, den FLOW der Arbeit durch das stabile Team zu schleusen, damit am Ende
Value entsteht. Ist ein Vorhaben zu klein, um ein eigenes Team dauerhaft auszulasten, so wird es einem
bestehenden Team zugeordnet, das diese Arbeit erledigen kann. Dann wird in Sprint 1 am Projekt A
gearbeitet, in Sprint 2 an Projekt B und in Sprint 3 wieder an Projekt A. So ist gesichert, dass das Team
schnell arbeiten kann.
Wenn das Projekt groß genug ist, dann wird ein Team an Projekt A dauerhaft daran arbeiten.

55. Autonom in
Entscheidungen
Damit die Produktentwicklung schnell funktioniert, muss das Team Autonomie für Entscheidungen zB in
der Wahl der verwendeten Technologien und Tools bekommen. Es darf keine übergeordneten,
langwierigen Entscheidungsgremien geben, die über den Einsatz von Technologien befinden ohne den
Kontext der Anforderungen zu kennen. Wenn, dann sollte dies in gemeinsamen Meetings (zB
Architektur-Workshops) geschehen in denen Produktteam und Stakeholder zusammensitzen und über
entsprechende Verfahren ein gemeinsames Verständnis für Optionen entwickeln und zu
Entscheidungen kommen.

56. Möglichst
gewählte Rollen
Idealerweise bestimmt nicht der Vorgesetzte, wer Scrum Master sein sollte oder der Ansprechpartner
für Architekturthemen im Team ist. Sondern das Team bestimmt, welche Rollen es für das Vorhaben
benötigt und wer diese idealerweise ausfüllen kann. Die entsprechenden realen Kompetenzen und
damit Ansprechpartner entstehen sowieso im Laufe der Zeit, unabhängig von Bestimmung, Titel oder
Seniorität. Starten Sie klein, denn nicht immer wird dieses „Wählen“ möglich sein. Was kein Nachteil ist.

57. Verantwortlich
für Technologie
Das Team sollte die Verantwortung für die Wahl der Technologien haben. Standardisierung und
Zentralisierung ist der Feind von Innovation - und gerade darum geht es doch, innovative
Wertschöpfung?!

58. Verantwortlich
für Betrieb
(DevOps)
Die Rolle der IT wird auch im Rahmen des Betriebs zurück gedrängt. Gut funktionierende Teams
betreiben das Produkt selbst und haben alle Fähigkeiten, die Live-Stellung zu ermöglichen und sich um
den Betrieb zu kümmern. Wenn mal etwas schief geht, kann das Team sehr schnell Fehler beheben.
DevOps - als Kultur-Prinzip und weniger als Tool - ist hier das Stichwort.

59. Verantwortlich
für Support
(keine Support-Abteilung notwendig!)
Manchmal ist das Team auch direkt für den Support zuständig. Ohne Filterung über Personen, die keine
Ahnung vom Produkt haben, gelangt der Anwender direkt zu einem Ansprechpartner im Team. Was gibt
es schöneres, als direkt und ohne Umwege vom Endanwender zu lernen, was das Produkt braucht
oder nicht braucht?

60. Anwender in
Produktentwicklung
einbinden
Wo immer es geht, binden Sie Ihre Anwender möglichst direkt in Ihre Feedback-Schleifen an.
Plattformen wie uservoice.com sind ideal, um Funktionswünsche der Anwender zu sammeln und nach
Popularität bewerten zu lassen. Bauen Sie „Fake-Funktionen“ in Ihre Software ein um zu erfragen, ob
Ihre Anwender eine bestimmte Funktion gerne haben wollen - und hinterfragen Sie auf Basis von
KANO-Fragen den Nutzwert dieser Funktionen.

61. Interne
Zusammenarbeit
modernisieren
Doch auch die interne Zusammenarbeit muss modernisiert werden, damit Ihre Arbeit als Organisation
von Erfolg gekrönt wird.

62. Wiki
(ja, auch 2015 muss ich das
noch auf Slides packen)
Ich bin immer wieder überrascht, wie häufig ich auf Personen treffe, die kein Wiki in ihrer Organisation
haben. Ein Sharepoint, ja, aber das ist ja eigentlich eine Dokumentenablage. Ach so, ein Intranet, das
aber eher als „PR von oben nach unten“ von der Unternehmensleitung genutzt wird. Digitales,
kollaboratives Arbeiten, über Bereichsgrenzen hinweg, das ist für viele noch neu. Und dennoch sooo
wichtig für die gemeinsame, schnelle Zusammenarbeit.

63. Slacktime
Schaffen Sie Freiräume für Ihre Crew. Damit diese abseits vom Tagesgeschäft arbeiten kann. Sich neu
erfinden kann. Neue Ideen und Technologien ausprobieren kann. Bei Mayflower machen wir dies seit
über 3 Jahren alle 14 Tage Freitags. Wir nehmen uns „frei“ von Kundenprojekten und verfolgen eigene
Ideen. Denn Wissen ist unser Rohstoff - und unser Wettbewerbsvorteil.

64. Lightning Talks
Brownbag Sessions
Verführen Sie zu Lightning Talks (15-minütige spontane Vorträge) oder Brownbag Sessions
(themenzentrierte Unterhaltung beim Mittagessen). Sorgen Sie mit „random lunches“ dafür, dass Leute
aus unterschiedlichen Bereichen zusammenkommen und sich austauschen. Accidential Conversations,
wusste auch schon Steve Jobs, sind der Treiber für 1+1=3.

65. Work Expo
zwischen den
Teams
Regelmäßige „Work Expos“ (ein Begriff aus dem „Management 3.0“ von Jurgen Appelo) sind Tage, an
denen Teams sich gegenseitig ihre Arbeit vorstellen. Somit wird ein Austausch zwischen Teams
gefördert.

66. Firmeninterne
Barcamps
(+ Guests)
Machen Sie doch ein firmeninternes Barcamp, organisiert im Open Space Format. Wir selbst machen
dies seit vielen Jahren regelmäßig und organisieren dies auch für Kunden. Ein Open Space ist ein
offenes Format: die Themen entstehen frei durch die vorhandenen Teilnehmer, ohne feste Agenda,
idealerweise mit vorgegebenen Zeitslots.
Und wenn Sie ganz mutig sind: machen Sie ein Barcamp mit Ihrer Konkurrenz. Wir machten dies 2013
mit unserem Mitbewerber aus der Schweiz, 130 Leute insgesamt, für 2 Tage. Es war eine phänomenale
Energie und ein unglaublicher Austausch, der beide Unternehmen nach vorne gebracht hat. Haben Sie
keine Angst vor „Kopien“: die Welt ist komplex, und alles was komplex ist, kann nicht so einfach 1:1
kopiert werden. Wozu auch? Wir wollen doch unseren eigenen Weg finden.

67. Was
Arbeitnehmer
in Zukunft
können müssen
http://www.faz.net/aktuell/beruf-chance/arbeitswelt/studie-von-linkedin-und-bitkom-zu-arbeitnehmerfaehigkeiten-13868684.html?GEPC=s3
306 befragte Führungskräfte
Bitkom hat in Zusammenarbeit mit LinkedIn eine Studie unter 306 Führungskräften durchgeführt, was
Arbeitnehmer in Zukunft kommen müssen. Schauen wir uns doch mal die wichtigsten Ergebnisse an.

68. In 10 Jahren wichtigste
Kompetenz:
Wissensmanagement
Wer hätte das gedacht: der Umgang mit Wissen ist also die wichtigste Kompetenz, die erwartet wird.
Das passt zum „Agilen Vorgehen“: dort, wo wir mit Überraschungen und Veränderungen umzugehen
haben, benötigen wir ein Rahmenwerk, Prinzipien und Haltungen, um mit dem dadurch sich
verändernden Wissen gut umgehen zu können. Passt also.

69. Verständnis für
Programmierung wird
wichtig
Uh? Hallo, liebe Marketing-Manager! Technik-Verständnis wird immer wichtiger. Ich weiß ja, dass Ihr
Euch gerne beratende Agenturen zur Seite nehmt, die dann irgendwelche Auswahl-Pitches machen.
Das ist okay, aber bitte bitte bitte: entwickelt Verständnis für Technik und Programmierung. Ihr müsst
verstehen, warum und wieso Business-Domänen in Software gegossen werden. Ihr müsst nicht
programmieren lernen. Aber auf Augenhöhe sein, denn Ihr seid immer stärker in der Mitverantwortung
und in der Mitarbeit gefragt.

70. Allgemeine
Digitalkompetenz
Ein Ergebnis war auch noch eine „Allgemeine Digitalkompetenz“. Für die nächste Generation, die
heranwächst, ist das sicher kein Problem, denn die ist ja mit dem Smartphone aufgewachsen.

71. 43% der Manager:
wir haben
Schwierigkeiten, den
IT-Personalbedarf zu
decken
Mein erster Gedanke, als ich dies las: „Ach was!?“ Ich kenne leider ganz ganz viele, die aus Konzernen
raus wollen. Und kaum jemanden, der da rein will. Doch blasen wir keine Trübsal: hier steckt eine
unglaubliche Chance darin, sich selbst zu verändern und attraktiver zu werden.

72. „Unternehmergeist“
Unternehmergeist wird gewünscht und doch so häufig nicht gefunden. Verständlich, nicht jeder will
prinzipiell Unternehmer werden. Für mich steckt eher etwas anderes dahinter: eine Bereitschaft zu
entfachen, verantwortlich mitzuarbeiten, verrückte Ideen zu entwickeln und: auszuprobieren.

73. „Führungskompetenz“
(Selbstführung,
Teamarbeit)
Wer von Führung spricht, vergißt häufig, dass ein großer Anker in der Selbstführung steckt. Denn nur
wenn ich mich selbst gut führen kann, dann strahlt dies auch auf meine Umwelt aus. Fangen wir also
an, mehr bei uns zu verändern, und weniger bei „den Anderen“ (ganz egal, aus welcher Perspektive).

74. Was bedeutet
das für uns
Nerds?
Was bedeutet das nun für uns Entwickler-Nerds?

75. Technologie +
Business-Domäne
verstehen
Es reicht nicht mehr aus, nur in Software zu denken. Wir müssen uns auch für die Business-Domäne
interessieren, für die wir die Software entwickeln. Wir müssen dort Verantwortung mit übernehmen -
denn sonst kann kein gutes Software-Produkt entstehen. Software ist vor allem Kommunikation, und
zwar nicht nur auf der technischen Ebene, sondern auf der Fach-Ebene.
Vielleicht einer der Gründe, warum Near-/Offshoring nicht immer so gut abläuft, wie sich die
tayloristische Zunft das vorstellt.

76. In Fach-Themen auf
Augenhöhe
eingebunden sein
Das bedeutet allerdings auch, dass wir in Fach-Themen auf Augenhöhe eingebunden sein müssen. Die
IT ist also nicht die „im Keller“, die nur umsetzt, was anderswo ausgedacht worden ist. Packen Sie IT
und Business in einen Raum, lassen Sie die Leute miteinander sprechen, und es wird bessere Software
entstehen. Garantiert.

77. Eher Generalist als
Spezialist sein
Wir müssen „generalisierende Spezialisten“ werden. Ein paar Spezialgebiete zu haben ist in Ordnung,
aber weil wir im Team Anforderungen umsetzen, die aus Business-Sicht beschrieben sind, müssen wir
im „vertikalen Durchstich“ denken. Damit wir hier effektiv sind (Stichworte „Truck Faktor“, Single Point
of Failure etc), benötigen wir ein breites Wissen, um uns im Team gegenseitig zu unterstützen.

78. Neues begrüßen
Und zu guter letzt: wir müssen Neues begrüßen. Die Welt wird sich weiterdrehen, und wir sind gut darin
beraten, diese Welle zu surfen.

79. kthxbai!
Glauben Sie immer noch, dass ich mit meiner These zu Beginn Unrecht habe? Oder stimmen Sie mir
sogar zu? In jedem Fall freue ich mich auf den Dialog mit Ihnen: unter bjoern.schotte@mayflower.de
oder telefonisch 0931/35965-15