+ All Categories
Home > Internet > E-Commerce Organisationsstrukturen

E-Commerce Organisationsstrukturen

Date post: 08-Feb-2017
Category:
Upload: bjoern-schotte
View: 1,465 times
Download: 1 times
Share this document with a friend
79
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.
Transcript

HALLO HÄNDLER!

Björn Schotte [email protected]

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 BubbleMenschen 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 VergleichWaterfall

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

Softw

aree

ntw

ickl

ung

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

umzusetzenMan 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-

Firmen06.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

KundeKunde

Kunde Kunde Kunde

PHPJava

MobileJavaScript

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

TribeSquads mit ähnlichen Bereichen

ChapterLeute mit ähnlichen

Themen (zB Testing)

GuildCommunity 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)schwindetPeople 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

deckenMein 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 [email protected] oder telefonisch 0931/35965-15


Recommended