HALLO
HÄNDLER!
Björn Schotte
bjoern.schotte@mayflower.de
0931/35965-15
Herzlich Willkommen zum Vortrag „IT vom Supporter zu...
EURE ORG-
STRUKTUREN
SIND KAPUTT
Beginnen möchte ich mit einer provokanten These: Eure Organisationsstrukturen sind regelr...
Komplexität bei
Konsumenten/Märkten
+
Software
Wir kämpfen mit einer zunehmenden Komplexität auf zwei bis drei Achsen: zum...
Wachstum in den Bubble
Menschen Online, in Milliarden
0
0,125
0,25
0,375
0,5
1995 2000
Quelle: http://ben-evans.com/benedi...
Wachstum seit dem Bubble
(in Milliarden)
0
0,75
1,5
2,25
3
1995 2000 2014
Menschen Online Smartphones
Quelle: http://ben-e...
Tendenz bis 2020:
+1 Mrd. Menschen
Bis 2020 wird erwartet, dass noch einmal 1 Milliarde Menschen hinzukommen - bevorzugt ü...
1995-2000:
Websites, Nachrichten,
Amazon (Bücher)
Wir haben also damals, in den grauen Vorzeiten des Internets, nur wenige...
Heute?
Und wie sieht die Situation heute aus?
Leben Online organisiert
Heute organisieren wir unser Leben online. Wir sind immer auf dem Sprung, haben das Smartphone be...
Viele Anbieter
(GAFA Dominanz)
Es gibt eine Unmenge an Anbietern, die für uns Konsumenten bereitstehen, mit einer „kleinen...
Konsumenten haben
Auswahl-Macht
Wir Konsumenten haben die Auswahl-Macht. Wir können uns entscheiden, welche Angebote wir
n...
Das Leben in der IT
Und wie schaut nun das Leben in der IT aus, bei uns Softwareentwicklern?
Erfolg von IT Projekten
43 %
18 %
39 %
Successful Failed Challenged
2012 CHAOS Research
Wenn wir uns anschauen, wie es um ...
Erfolg im Vergleich
Waterfall
57 % 29 %
14 %
Success Failed Challenged
Agile
49 %
9 %
42 %
Ich spreche ja heute auch über ...
Nutzung Funktionen in
Software
7 %
13 %
16 %
45 %
19 %
Rarely Never Used Sometimes Often Always
2011 Standish Group
2/3: s...
Cynefin Wissensmodell
in Systemen
Damit nicht genug, sollten wir uns noch das „Kanefin“ Wissensmodell in Systemen anschauen....
http://wandelweb.de/galerie/13_Cynefin/Cynefin-06.png
Softwareentwicklung
Cynefin ist ein Wissenschaftler, der untersucht hat...
Wann Agile Methoden?
Stacey Diagram
https://crossbolt.files.wordpress.com/2013/11/when-to-use-scrum1.jpg
Neben dem Kollegen...
Warum also Agile?
Komplexität in Markt und Softwareentwicklung
Es gibt also zwei Achsen, an denen wir nahezu gezwungen sin...
Techniken der
Vergangenheit
Lastenheft, Pflichtenheft, Abteilungsgrenzen,
Feature-Checklisten, Standard-Software
(=Mittelma...
Das Agile Manifest
Als Scrum erfunden wurde, haben sich zwölf sehr bekannte Softwareentwickler um die
Jahrtausendwende in ...
Individuen+Interaktionen
>>
Prozesse+Tools
Individuen und ihre Interaktionen untereinander sind wichtiger als Prozesse und...
Funktionierende Software
>>
ausführliche Dokumentation
Funktionierende Software ist wichtiger als ausführliche Dokumentati...
Zusammenarbeit mit dem Kunden
>>
Verträge
Die Zusammenarbeit mit dem Kunden ist wichtiger als Verträge. Der Kunde soll nic...
Veränderung begegnen
>>
einen Plan verfolgen
Was die mutigen Männer schon damals erkannt hatten, ist heute gnadenlose Real...
empirisch
iterativ
inkrementell
Ich werde oft gefragt, was Scrum ist. Zum einen ist Scrum ein empirisch (Erkenntnis aus Er...
einfaches
Rahmenwerk
ziemlich
schwierig
umzusetzen
Man sagt auch, es ist ein einfaches Rahmenwerk, das allerdings ziemlich...
Inspect & Adapt

Good Enough
Zwei Prinzipien, die ganz wichtig für Agiles Arbeiten sind:

- Inspect & Adapt: wir inspizier...
Wert der
Software
erhöhen
(zum Wohle der Shopkunden)
Zudem geht es darum, den Wert einer Software kontinuierlich zu erhöhe...
Anwender
geben Ziel vor
Die Anwender einer Software geben das Ziel vor. Da die Anwender durchaus etwas „launisch“ sind,
ve...
Wir folgen dem
Marktsog
Anders ausgedrückt: wir folgen dem Sog der Märkte und realisieren dort die Gewinne von heute und
m...
Version 1
Wie kann man sich das bildlich vorstellen? Nun, zu Beginn des Projekts wissen wir, dass wir für unsere
Kundschaf...
Version 2
Doch relativ zeitnah stellen wir fest, dass unsere Kunden ein etwas robusteres und stabileres Fahrzeug
haben möc...
Version 3
Mit der Zeit entwickelt sich das Bedürfnis der Kunden weiter. Das Fahrzeug soll nicht nur zur
Fortbewegung, sond...
Version 4
http://images.fotocommunity.de/bilder/spezial/karten-und-kalender/weihnachtsmann-auf-motorrad-in-wilhelmshaven-8...
Anforderungen
an die
Organisation
Die Arbeit im agilen Umfeld stellt eine Organisation vor oftmals große Herausforderungen.
Hallo Händler!
Echte IT-Kompetenz
im Vorstand/GL?
Das fängt schon bei der IT-Kompetenz im Vorstand/der Geschäftsleitung an...
Alle Firmen
werden zu
Software-
Firmen
06.11. http://www.cio.de/a/digitale-transformation-laesst-keinen-stein-auf-dem-ande...
Vergangenheit (1985)
http://www.kassenzone.de/2015/05/11/die-ergebnislose-suche-nach-einem-cto/
IT/HR = „Unterstützungsakt...
Dezentralität für
mehr
Geschwindigkeit
Zum einen ist da der ewige Kampf Zentral gegen Dezentral. Im Agilen Umfeld wollen w...
Autonomy
Mastery
Purpose
=
Motivation
Dan Pink’s Drive sagt: Motivation entsteht durch Autonomy, Mastery & Purpose. Die Me...
Produkt
Team 4
Produkt
Team 1
Produkt
Team 5
Produkt
Team 6
Produkt
Team 7
Produkt
Team 2
Produkt
Team 3
Interne IT
Produk...
Beispiel Spotify
http://blog.crisp.se/2012/11/14/henrikkniberg/scaling-agile-at-spotify
Squad Produkt Team
Tribe
Squads mi...
Beispiel Zalando
http://de.slideshare.net/ZalandoTech/radical-agility-with-autonomous-teams-and-microservices-in-the-cloud...
Rolle des
Vorgesetzten
(ver)schwindet
People Lead = eher Coach
Die Rolle des Vorgesetzten tritt in agilen Umgebungen zurüc...
Eigenschaften
eines
Produktteams
Wie sind also die Eigenschaften eines Produktteams? Was zeichnet die Team-Mitglieder aus?
Mitglieder sind
(fühlen sich)
verantwortlich
für das Produkt
Idealerweise fühlen sich die Mitglieder verantwortlich für da...
Mitglieder haben
alle notwendigen
Fähigkeiten und
Fertigkeiten
Die Mitglieder haben alle notwendigen Fähigkeiten und Ferti...
Fachabteilungen
sind eng am Dev-
Team
Die Fachabteilungen wiederum kommunizieren sehr eng mit den Entwicklern. Das bedeute...
T
shaped
… die einzelnen Personen sind T-shaped. Auf der Vertikalen gibt es ein oder zwei Kernkompetenzen,
auf der Horizon...
Keine Spezial-
Funktionen
(„der Architekt“)
Es gibt keine singulären Spezialfunktionen im Produktteam. Das gesamte Team ar...
Kein
Scrummerfall
(Konzept -> Design ->
Implementierung)
Sie wollen scheitern? Prima! Dann trennen Sie Konzept- von der De...
Stabil
https://mercureaace2013.files.wordpress.com/2013/01/groupstages.png
In der BWL hat sich irgendwann die Überzeugung d...
Produkt Team
Product Owner + Delivery
Team
Arbeit/Projekt
Arbeit/Projekt
Arbeit/Projekt
Arbeit/Projekt
Arbeit/Projekt
Arbe...
Autonom in
Entscheidungen
Damit die Produktentwicklung schnell funktioniert, muss das Team Autonomie für Entscheidungen zB...
Möglichst
gewählte Rollen
Idealerweise bestimmt nicht der Vorgesetzte, wer Scrum Master sein sollte oder der Ansprechpartn...
Verantwortlich
für Technologie
Das Team sollte die Verantwortung für die Wahl der Technologien haben. Standardisierung und...
Verantwortlich
für Betrieb
(DevOps)
Die Rolle der IT wird auch im Rahmen des Betriebs zurück gedrängt. Gut funktionierende...
Verantwortlich
für Support
(keine Support-Abteilung notwendig!)
Manchmal ist das Team auch direkt für den Support zuständi...
Anwender in
Produktentwicklung
einbinden
Wo immer es geht, binden Sie Ihre Anwender möglichst direkt in Ihre Feedback-Schl...
Interne
Zusammenarbeit
modernisieren
Doch auch die interne Zusammenarbeit muss modernisiert werden, damit Ihre Arbeit als ...
Wiki
(ja, auch 2015 muss ich das
noch auf Slides packen)
Ich bin immer wieder überrascht, wie häufig ich auf Personen treffe...
Slacktime
Schaffen Sie Freiräume für Ihre Crew. Damit diese abseits vom Tagesgeschäft arbeiten kann. Sich neu
erfinden kann....
Lightning Talks
Brownbag Sessions
Verführen Sie zu Lightning Talks (15-minütige spontane Vorträge) oder Brownbag Sessions
...
Work Expo
zwischen den
Teams
Regelmäßige „Work Expos“ (ein Begriff aus dem „Management 3.0“ von Jurgen Appelo) sind Tage, a...
Firmeninterne
Barcamps
(+ Guests)
Machen Sie doch ein firmeninternes Barcamp, organisiert im Open Space Format. Wir selbst ...
Was
Arbeitnehmer
in Zukunft
können müssen
http://www.faz.net/aktuell/beruf-chance/arbeitswelt/studie-von-linkedin-und-bitk...
In 10 Jahren wichtigste
Kompetenz:
Wissensmanagement
Wer hätte das gedacht: der Umgang mit Wissen ist also die wichtigste ...
Verständnis für
Programmierung wird
wichtig
Uh? Hallo, liebe Marketing-Manager! Technik-Verständnis wird immer wichtiger. ...
Allgemeine
Digitalkompetenz
Ein Ergebnis war auch noch eine „Allgemeine Digitalkompetenz“. Für die nächste Generation, die...
43% der Manager:
wir haben
Schwierigkeiten, den
IT-Personalbedarf zu
decken
Mein erster Gedanke, als ich dies las: „Ach wa...
„Unternehmergeist“
Unternehmergeist wird gewünscht und doch so häufig nicht gefunden. Verständlich, nicht jeder will
prinzi...
„Führungskompetenz“
(Selbstführung,
Teamarbeit)
Wer von Führung spricht, vergißt häufig, dass ein großer Anker in der Selbs...
Was bedeutet
das für uns
Nerds?
Was bedeutet das nun für uns Entwickler-Nerds?
Technologie +
Business-Domäne
verstehen
Es reicht nicht mehr aus, nur in Software zu denken. Wir müssen uns auch für die B...
In Fach-Themen auf
Augenhöhe
eingebunden sein
Das bedeutet allerdings auch, dass wir in Fach-Themen auf Augenhöhe eingebun...
Eher Generalist als
Spezialist sein
Wir müssen „generalisierende Spezialisten“ werden. Ein paar Spezialgebiete zu haben is...
Neues begrüßen
Und zu guter letzt: wir müssen Neues begrüßen. Die Welt wird sich weiterdrehen, und wir sind gut darin
bera...
kthxbai!
Glauben Sie immer noch, dass ich mit meiner These zu Beginn Unrecht habe? Oder stimmen Sie mir
sogar zu? In jedem...
Nächste SlideShare
Wird geladen in …5
×

E-Commerce Organisationsstrukturen

1.358 Aufrufe

Veröffentlicht am

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.

Veröffentlicht in: Internet
0 Kommentare
1 Gefällt mir
Statistik
Notizen
  • Als Erste(r) kommentieren

Keine Downloads
Aufrufe
Aufrufe insgesamt
1.358
Auf SlideShare
0
Aus Einbettungen
0
Anzahl an Einbettungen
38
Aktionen
Geteilt
0
Downloads
9
Kommentare
0
Gefällt mir
1
Einbettungen 0
Keine Einbettungen

Keine Notizen für die Folie

E-Commerce Organisationsstrukturen

  1. 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. 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. 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. 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. 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. 6. Tendenz bis 2020: +1 Mrd. Menschen Bis 2020 wird erwartet, dass noch einmal 1 Milliarde Menschen hinzukommen - bevorzugt über Mobile Devices.
  7. 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. 8. Heute? Und wie sieht die Situation heute aus?
  9. 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. 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. 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. 12. Das Leben in der IT Und wie schaut nun das Leben in der IT aus, bei uns Softwareentwicklern?
  13. 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. 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. 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. 16. Cynefin Wissensmodell in Systemen Damit nicht genug, sollten wir uns noch das „Kanefin“ Wissensmodell in Systemen anschauen. Was das ist?
  17. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 36. Anforderungen an die Organisation Die Arbeit im agilen Umfeld stellt eine Organisation vor oftmals große Herausforderungen.
  37. 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. 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. 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. 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. 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. 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. 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. 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. 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. 46. Eigenschaften eines Produktteams Wie sind also die Eigenschaften eines Produktteams? Was zeichnet die Team-Mitglieder aus?
  47. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 61. Interne Zusammenarbeit modernisieren Doch auch die interne Zusammenarbeit muss modernisiert werden, damit Ihre Arbeit als Organisation von Erfolg gekrönt wird.
  62. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 74. Was bedeutet das für uns Nerds? Was bedeutet das nun für uns Entwickler-Nerds?
  75. 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. 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. 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. 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. 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

×