Björn Schotte, profile picture
Hochgeladen vonBjörn Schotte
4,500 aufrufe

E-Commerce Organisationsstrukturen

In dem Vortrag von Björn Schotte wird die Transformation der IT von einem unterstützenden zu einem entscheidenden Faktor in Unternehmen thematisiert, insbesondere im Kontext agiler Methoden. Er argumentiert, dass die zunehmende Komplexität in Märkten und Softwareentwicklungen den Einsatz agiler Techniken erfordere, um erfolgreich zu bleiben. Der Vortrag hebt die wichtigsten Prinzipien des agilen Manifests hervor und betont die Notwendigkeit, die Zusammenarbeit mit Kunden und die Anpassung an Veränderungen in den Vordergrund zu stellen.

Präsentation einbetten

30-mal heruntergeladen
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.
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.
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 ;-)
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.
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.
Tendenz bis 2020: +1 Mrd. Menschen Bis 2020 wird erwartet, dass noch einmal 1 Milliarde Menschen hinzukommen - bevorzugt über Mobile Devices.
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.
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 bei uns, das Tablet auf der Couch und neuerdings auch einen kleinen Supercomputer am Handgelenk.
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.
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.
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 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.
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.
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!
Cynefin Wissensmodell in Systemen Damit nicht genug, sollten wir uns noch das „Kanefin“ Wissensmodell in Systemen anschauen. Was das ist?
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.
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.
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 :-)
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 …
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!
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!
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.
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.
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!
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.
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!
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.
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.
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.
Wir folgen dem Marktsog Anders ausgedrückt: wir folgen dem Sog der Märkte und realisieren dort die Gewinne von heute und morgen.
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.
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.
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.
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.
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. 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.
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.
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.
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.
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.
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.
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.
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.
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.
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 das Produkt. Dafür notwendig sind wie beschrieben Purpose, Mastery und Autonomy.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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?!
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.
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?
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.
Interne Zusammenarbeit modernisieren Doch auch die interne Zusammenarbeit muss modernisiert werden, damit Ihre Arbeit als Organisation von Erfolg gekrönt wird.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
„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.
„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).
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 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.
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.
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.
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.
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

Weitere ähnliche Inhalte

PDF
2013 OS E-Commerce Magento OXID Shopware
vonBjörn Schotte
 
PDF
IT Probleme loesen
vonBjörn Schotte
 
PDF
Scrum im Marketing
vonBjörn Schotte
 
PDF
Scrum als agiles Vorgehensmodell für Programmierer
vonTobias Schlüter
 
PDF
Bessere Software schneller liefern
vonMayflower GmbH
 
PDF
Agile Anti-Patterns
vonMayflower GmbH
 
PDF
Technologiemanagement Agile Transformationen
vonBjörn Schotte
 
PDF
Scrum & Kanban im Agenturgeschäft
vonPaul Herwarth von Bittenfeld
 
2013 OS E-Commerce Magento OXID Shopware
vonBjörn Schotte
 
IT Probleme loesen
vonBjörn Schotte
 
Scrum im Marketing
vonBjörn Schotte
 
Scrum als agiles Vorgehensmodell für Programmierer
vonTobias Schlüter
 
Bessere Software schneller liefern
vonMayflower GmbH
 
Agile Anti-Patterns
vonMayflower GmbH
 
Technologiemanagement Agile Transformationen
vonBjörn Schotte
 
Scrum & Kanban im Agenturgeschäft
vonPaul Herwarth von Bittenfeld
 

Was ist angesagt?

PDF
Vertraege in Agilen Projekten
vonBjörn Schotte
 
ODP
Projektmanagement und IBM Lotus Quickr - Olav Behrens (PAVONE AG)
vonUdo Sill
 
PDF
Von Quickr bis PAVONE PM
vonUdo Sill
 
PDF
DevOps jenseits der Tools
vonJohann-Peter Hartmann
 
PDF
Meine! Deine! Keine! Verantwortung in agilen Teams
vonFrank Düsterbeck
 
PDF
Mit Maintenance umgehen können- Fixt du noch Bugs oder lieferst du schon neue...
vonMayflower GmbH
 
PDF
Anforderungen haben immer Schuld
vonFrank Düsterbeck
 
PDF
Agile in Marketing HR Business Teams
vonBjörn Schotte
 
ODP
Scrum Workshop
vonmrdoubleb
 
PDF
Status Quo Agile - Ergebnis-Highlights der Studie zu Verbreitung und Nutzen a...
vonAyelt Komus
 
PDF
Agiles PM –Evidenzbasiertes PM -Ansätze zur Produktenentwickung
vonAyelt Komus
 
PDF
Scrum-Einführung bei mobile.de
vonMarkus Andrezak
 
PDF
Work smarter: Change Management im Marketing mit Kanban
vonJulia Kümmel
 
PDF
OKR und BVB - Warum OKR der bessere Cristiano Ronaldo ist oder warum Scrum ni...
vondie.agilen GmbH
 
PDF
Scrum in der Praxis - Ein Blick hinter die Kulissen von Scrum
vonRobert Wiechmann
 
PDF
Expertentagung Agiles Projektmanagement 2015: Projektmanagement neu gedacht: ...
vonAyelt Komus
 
PDF
Scrum und Lean-Startup
vonStefan ROOCK
 
PDF
Agil ist nicht genug
vonFrank Düsterbeck
 
PPTX
Learning out Loud
vonedutrainment company
 
PPT
eparo – IA und agile Softwareentwicklung verbinden (Vortrag IA-Konferenz 2009...
voneparo GmbH
 
Vertraege in Agilen Projekten
vonBjörn Schotte
 
Projektmanagement und IBM Lotus Quickr - Olav Behrens (PAVONE AG)
vonUdo Sill
 
Von Quickr bis PAVONE PM
vonUdo Sill
 
DevOps jenseits der Tools
vonJohann-Peter Hartmann
 
Meine! Deine! Keine! Verantwortung in agilen Teams
vonFrank Düsterbeck
 
Mit Maintenance umgehen können- Fixt du noch Bugs oder lieferst du schon neue...
vonMayflower GmbH
 
Anforderungen haben immer Schuld
vonFrank Düsterbeck
 
Agile in Marketing HR Business Teams
vonBjörn Schotte
 
Scrum Workshop
vonmrdoubleb
 
Status Quo Agile - Ergebnis-Highlights der Studie zu Verbreitung und Nutzen a...
vonAyelt Komus
 
Agiles PM –Evidenzbasiertes PM -Ansätze zur Produktenentwickung
vonAyelt Komus
 
Scrum-Einführung bei mobile.de
vonMarkus Andrezak
 
Work smarter: Change Management im Marketing mit Kanban
vonJulia Kümmel
 
OKR und BVB - Warum OKR der bessere Cristiano Ronaldo ist oder warum Scrum ni...
vondie.agilen GmbH
 
Scrum in der Praxis - Ein Blick hinter die Kulissen von Scrum
vonRobert Wiechmann
 
Expertentagung Agiles Projektmanagement 2015: Projektmanagement neu gedacht: ...
vonAyelt Komus
 
Scrum und Lean-Startup
vonStefan ROOCK
 
Agil ist nicht genug
vonFrank Düsterbeck
 
Learning out Loud
vonedutrainment company
 
eparo – IA und agile Softwareentwicklung verbinden (Vortrag IA-Konferenz 2009...
voneparo GmbH
 

Andere mochten auch

PPTX
Ausprägungsformen des e-Commerce
vonDaniel Trautmann
 
PDF
Radical Agility with Autonomous Teams and Microservices in the Cloud
vonZalando Technology
 
PDF
Zalando Overview 2014
vonJoerg Strotmann
 
PPTX
The Five Marketers Your eCommerce Business Needs
vonnChannel, Inc.
 
PDF
Näher geht nicht! Wie Redaktionen WhatsApp als News-Kanal nutzen. #AFBMC
vonAllFacebook.de
 
PDF
Einfache Prozessmodellierung in der IBM Cloud
vonJennifer Schroen
 
PDF
Unic AG - Einstieg in den E-Commerce
vonUnic
 
PDF
The CMO's Guide to Marketing Org Structure
vonHubSpot
 
PPTX
2011 - E-Commerce Shopsysteme im Vergleich - Magento, hybris und Sitecore
vonJohannes Waibel
 
Ausprägungsformen des e-Commerce
vonDaniel Trautmann
 
Radical Agility with Autonomous Teams and Microservices in the Cloud
vonZalando Technology
 
Zalando Overview 2014
vonJoerg Strotmann
 
The Five Marketers Your eCommerce Business Needs
vonnChannel, Inc.
 
Näher geht nicht! Wie Redaktionen WhatsApp als News-Kanal nutzen. #AFBMC
vonAllFacebook.de
 
Einfache Prozessmodellierung in der IBM Cloud
vonJennifer Schroen
 
Unic AG - Einstieg in den E-Commerce
vonUnic
 
The CMO's Guide to Marketing Org Structure
vonHubSpot
 
2011 - E-Commerce Shopsysteme im Vergleich - Magento, hybris und Sitecore
vonJohannes Waibel
 

Ähnlich wie E-Commerce Organisationsstrukturen

PDF
Was macht ein Start Up erfolgreich?
vonManuel Blechschmidt
 
PDF
IAK13 Darwin und die Kreativen
vonWebster59
 
PDF
2017 05-23 agil arbeiten
vonStephan Dahrendorf
 
PDF
E-Commerce vs Architektur CodeTalks.Commerce_2018
vonJohann-Peter Hartmann
 
PDF
IA/ UX in Scrum Entwicklungs-Prozessen - 2009
vonWolf Noeding
 
PDF
Hybrides Projektmanagement – Wie Sie agile und klassische Methoden verbinden
vonAchim Schmidt-Sibeth
 
PDF
Agile developmentphp usergroup
vonCypher Deimos
 
PDF
Agiles Management für erfolgreiche IT-Projekte
vonJustRelate
 
KEY
Digitale Produktentwicklung für Verlage
vonGunnar Lott
 
PDF
Collaboratives entwickeln in Bachelorprojekten
vonManuel Blechschmidt
 
PDF
Agil ins Web - Adam Musial-Bright und Detlef Pirnack
vonJustRelate
 
PDF
Erfolgsfaktoren in der Digitalisierung - ein Erfahrungsbericht
vonChristoph Schmiedinger
 
PDF
Software trends veranstaltungsprogramm_neu
vonCON.ECT Eventmanagement
 
PDF
Magenta Telekom - Step by Step: Die New kids on the Block-Methode, AAC 2021
vonAgile Austria Conference
 
PDF
Scrum - Von traditionellen Ansaetzen zu agilen Methoden wie Scrum
vonRalf Ohlenbostel
 
PPTX
Evolution der Softwareentwicklung: Von Wasserfall über Agile zu DevOps
vonDieter Ziegler
 
PDF
Reparier Deine Unternehmenskultur!
vonJohann-Peter Hartmann
 
PDF
NewWork in der Praxis
vonJohann-Peter Hartmann
 
PDF
Digitalisierung ja - aber wie managen?
vonChristoph Schmiedinger
 
PPT
Agilität und Verträge - Vertragsmodelle - Agiler Festpreis
vonIT-Service-PN
 
Was macht ein Start Up erfolgreich?
vonManuel Blechschmidt
 
IAK13 Darwin und die Kreativen
vonWebster59
 
2017 05-23 agil arbeiten
vonStephan Dahrendorf
 
E-Commerce vs Architektur CodeTalks.Commerce_2018
vonJohann-Peter Hartmann
 
IA/ UX in Scrum Entwicklungs-Prozessen - 2009
vonWolf Noeding
 
Hybrides Projektmanagement – Wie Sie agile und klassische Methoden verbinden
vonAchim Schmidt-Sibeth
 
Agile developmentphp usergroup
vonCypher Deimos
 
Agiles Management für erfolgreiche IT-Projekte
vonJustRelate
 
Digitale Produktentwicklung für Verlage
vonGunnar Lott
 
Collaboratives entwickeln in Bachelorprojekten
vonManuel Blechschmidt
 
Agil ins Web - Adam Musial-Bright und Detlef Pirnack
vonJustRelate
 
Erfolgsfaktoren in der Digitalisierung - ein Erfahrungsbericht
vonChristoph Schmiedinger
 
Software trends veranstaltungsprogramm_neu
vonCON.ECT Eventmanagement
 
Magenta Telekom - Step by Step: Die New kids on the Block-Methode, AAC 2021
vonAgile Austria Conference
 
Scrum - Von traditionellen Ansaetzen zu agilen Methoden wie Scrum
vonRalf Ohlenbostel
 
Evolution der Softwareentwicklung: Von Wasserfall über Agile zu DevOps
vonDieter Ziegler
 
Reparier Deine Unternehmenskultur!
vonJohann-Peter Hartmann
 
NewWork in der Praxis
vonJohann-Peter Hartmann
 
Digitalisierung ja - aber wie managen?
vonChristoph Schmiedinger
 
Agilität und Verträge - Vertragsmodelle - Agiler Festpreis
vonIT-Service-PN
 

Mehr von Björn Schotte

PDF
Stakeholder zu Fans des Produkts machen
vonBjörn Schotte
 
PDF
Product Owner 2 Product CEO
vonBjörn Schotte
 
PDF
Wie ein kleiner Product Owner Grossartiges bewirken kann
vonBjörn Schotte
 
PDF
Employer branding braucht niemand
vonBjörn Schotte
 
PDF
OKR, Ziele und Zielsysteme im Agilen
vonBjörn Schotte
 
PDF
Lean Requirements - von 0 auf 100
vonBjörn Schotte
 
PDF
Gehaltsworkflow Mayflower
vonBjörn Schotte
 
PDF
Mentale Modelle für bessere Zusammenarbeit
vonBjörn Schotte
 
PDF
Digitalisierung alles in Bewegung
vonBjörn Schotte
 
PDF
Die Leiden des Jungen Konsumenten
vonBjörn Schotte
 
PDF
20 tips for product owners 2014 NewYearEdition
vonBjörn Schotte
 
Stakeholder zu Fans des Produkts machen
vonBjörn Schotte
 
Product Owner 2 Product CEO
vonBjörn Schotte
 
Wie ein kleiner Product Owner Grossartiges bewirken kann
vonBjörn Schotte
 
Employer branding braucht niemand
vonBjörn Schotte
 
OKR, Ziele und Zielsysteme im Agilen
vonBjörn Schotte
 
Lean Requirements - von 0 auf 100
vonBjörn Schotte
 
Gehaltsworkflow Mayflower
vonBjörn Schotte
 
Mentale Modelle für bessere Zusammenarbeit
vonBjörn Schotte
 
Digitalisierung alles in Bewegung
vonBjörn Schotte
 
Die Leiden des Jungen Konsumenten
vonBjörn Schotte
 
20 tips for product owners 2014 NewYearEdition
vonBjörn Schotte
 

E-Commerce Organisationsstrukturen

  • 1.
    HALLO HÄNDLER! Björn Schotte bjoern.schotte@mayflower.de 0931/35965-15 Herzlich Willkommenzum 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 Beginnenmö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ämpfenmit 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 denBubble 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 demBubble (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: +1Mrd. Menschen Bis 2020 wird erwartet, dass noch einmal 1 Milliarde Menschen hinzukommen - bevorzugt über Mobile Devices.
  • 7.
    1995-2000: Websites, Nachrichten, Amazon (Bücher) Wirhaben 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 siehtdie Situation heute aus?
  • 9.
    Leben Online organisiert Heuteorganisieren 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) Esgibt 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 Konsumentenhaben 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 inder IT Und wie schaut nun das Leben in der IT aus, bei uns Softwareentwicklern?
  • 13.
    Erfolg von ITProjekten 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 % RarelyNever 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 Damitnicht 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 einWissenschaftler, 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? StaceyDiagram 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ätin 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 AlsScrum 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 ihreInteraktionen 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 FunktionierendeSoftware 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 demKunden >> 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 Planverfolgen 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 oftgefragt, 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
 GoodEnough 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 Wohleder 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 DieAnwender 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 Andersausgedrückt: wir folgen dem Sog der Märkte und realisieren dort die Gewinne von heute und morgen.
  • 32.
    Version 1 Wie kannman 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 relativzeitnah 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 derZeit 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 Arbeitim agilen Umfeld stellt eine Organisation vor oftmals große Herausforderungen.
  • 37.
    Hallo Händler! Echte IT-Kompetenz imVorstand/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 einenist 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 Drivesagt: 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 Team5 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 ProduktTeam 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 wirzurü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 alsodie Eigenschaften eines Produktteams? Was zeichnet die Team-Mitglieder aus?
  • 47.
    Mitglieder sind (fühlen sich) verantwortlich fürdas 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ähigkeitenund 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 amDev- 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 einzelnenPersonen 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“) Esgibt 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 BWLhat 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 dieProduktentwicklung 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 bestimmtnicht 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 Teamsollte 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 Rolleder 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-Abteilungnotwendig!) 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 immeres 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 dieinterne Zusammenarbeit muss modernisiert werden, damit Ihre Arbeit als Organisation von Erfolg gekrönt wird.
  • 62.
    Wiki (ja, auch 2015muss 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äumefü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ührenSie 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 Siedoch 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 306befragte 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 Jahrenwichtigste 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 warauch 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: wirhaben 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ünschtund 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ührungspricht, 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üruns Nerds? Was bedeutet das nun für uns Entwickler-Nerds?
  • 75.
    Technologie + Business-Domäne verstehen Es reichtnicht 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 eingebundensein 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 Spezialistsein 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 zuguter 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 immernoch, 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