1. Let’s rock IT
http://creativecommons.org/licenses/by-sa/4.0/Björn Schotte - bjoern.schotte@mayflower.de
Denkwerkzeuge für moderne Organisation & IT
Willkommen zum Talk Let’s Rock IT - wie die IT vom Supporter zum Enabler wird.
Ich möchte aufzeigen, warum in Zeiten hoher Dynamik Unternehmens-Strukturen kaputt sind und wie Unternehmen auf der Online-Welle reiten können, um auch Morgen
noch eine Rolle zu spielen.
„Digitale Transformation“ ist das - meist inhaltsleere - Buzzword. Hier erfahrt Ihr, was eine moderne IT/Software-Entwicklung ausmacht. Wie Ihr Silos vermeidet und zu
einer guten Zusammenarbeit mit anderen Unternehmensbereichen kommt. Und welche Denkwerkzeuge nützlich sein können, um Eure Organisation zu modernisieren.
Natürlich erhebe ich in diesem Talk keinen Anspruch auf Vollständigkeit. Praktischerweise werden die Folien regelmäßig erweitert werden. ;-) Die Folien stehen unter
Creative Commons License, das PDF könnt Ihr Euch gerne downloaden und weiter verteilen.
Und nun: Anschnallen & los geht’s!

2. Hallo, ich bin Björn.
#agile #software #delivery #consulting
#discovery #leanstartup #coaching
Wir lösen harte IT-Probleme.
https://mayflower.de/
Hallo, ich bin Björn Schotte. Geschäftsführer und Señor Consultant bei MAYFLOWER. Mit unseren cross-funktionalen Teams realisieren wir digitale Produkte und lösen
harte IT-Probleme für unsere Kunden. Meine Themen sind dabei Agile Software Delivery, Consulting, Product/Feature Discovery, Lean Startup für Enterprises und Agiles
(Management) Coaching.

3. Was treibt Euch Manager um?
Wann wird unsere
IT endlich schneller?
Wieso machen die
Entwickler nicht das
was ich will?
Auf welchem
Kanal finde ich nun
meine Kunden?
Was will mein
Kunde?
Wie halten wir die
Konkurrenz auf
Abstand?
Die
Zusammenarbeit
mit den Abteilungen
klappt nicht!
80% unseres
Budgets geht auf
„Run the
Business“
„Change the
Business“ WTF?
In der Vorbereitung für diesen Talk bin ich all die Gespräche durchgegangen, die ich mit zahlreichen Managern und C-level Executives geführt habe. Die wichtigsten
Fragestellungen, die das Management umtreibt, versuche ich hier zu destillieren. Besonderes Augenmerk legen Manager darauf, wieviel Prozent des IT-Budgets für „run
the business“ drauf geht und wieviel Prozent des Budgets für echte Innovationen, also „Change the Business“, übrig bleibt. Leider ist dies häufig in einem ungünstigen
Verhältnis - der größte Teil des IT-Budgets geht für „Run the Business“ drauf.

4. Was treibt Euch Developer um?
Alle reden von
Continuous
Deployment :-(
Diese tausend
PDF-Dokumente mit
versteckten
Anforderungen
Kann die
Agentur das Design
mal pünktlich
liefern?
Warum muss
$manager sich
immer einmischen?
Wieso müssen wir
hier unsinnige Dinge
tun?
Würde gerne mal
technical debt
verringern
Diese blöde
Maintenance von
altem Code
Die Leute aus
dem Marketing
verstehen uns
nicht
Auch Entwickler haben eine ganze Menge Fragen in Zeiten hoher Dynamik. Da ist zum Einen der Eindruck, das Management mische sich zu häufig ein. Manchmal findet
sich auch der Eindruck wieder, die Entwickler müssten Dinge tun, die aus ihrer Sicht total unsinnig sind. Wie so häufig haben wir hier ein Kommunikationsproblem.
Technisch spannend wird es, wenn weitere Dienstleister wie zB Design-Zulieferer eingebunden sind. Arbeitet das Entwicklungs-Team nach agilen Prinzipien & Praktiken,
so ist es schwierig, dies mit der „tayloristischen“ Zerteilung der Arbeitspakete durch das Management zu vereinbaren - und so sind Design-Agenturen abgekoppelt von
den Sprints und geliefert wird dann meist etwas, was nicht mehr benötigt wird oder so viel Änderung erfährt (iterativ), dass ein permanentes „Mitlaufen“ der Designer in
den Sprints angebrachter gewesen wäre. Viel nerviger ist es für Entwickler, wenn keine vernünftige Continuous Deployment/Delivery Infrastruktur zur Verfügung steht
oder gar von Product Owner oder Stakeholder Seite nicht gewünscht wird. Liebe Manager, Euch entgeht hiermit die Infrastruktur für frühzeitige Lern-Möglichkeiten in
Eurem Markt!

5. Managers Antwort
„Lasst uns Agil
arbeiten!“
Sicher, auch wir Manager besuchen Konferenzen oder lesen schlaue Bücher. Daher sind wir der Meinung, dass es doch super praktisch ist, wenn wir jetzt alle Agil
arbeiten. Schließlich bedeutet das doch, dass wir die Dinge schneller und zu kleineren Kosten bekommen, nicht wahr?

6. Scrum funktioniert nicht.
(Die Organisation ist im Weg)
Ich stelle die Behauptung auf, dass Scrum nicht funktioniert. Warum ich das mache? Weil ich durch die vielen Gespräche und Einblicke in Unternehmen den Eindruck
habe, dass die Organisation in ihrer Summe aus Kultur und DNA einem erfolgreichen Anwenden von Agilen Prinzipien und Praktiken im Wege steht. Oder anders
ausgedrückt: um das volle Potenzial heben zu können, benötigt es eine andere Geisteshaltung.

7. Alle reden von
Komplexität und
Dynamik?
In vielen Vorträgen hört man immer wieder von Komplexität und hoher Dynamik. Ich will keine weitere Erklärungsschleife drehen, sondern eher ergründen, wie es denn zu
dieser hohen Komplexität und dieser hohen Dynamik gekommen ist …

8. 3 Gründe für hohe (Markt-)Dynamik
… also lasst uns ergründen, warum es eine hohe Dynamik insgesamt und an den Märkten, an denen Ihr tätig seid, gibt. Ach, und bevor Ihr jetzt sagt „Also bei uns nicht,
wir sind doch (B2B | whatever)! *abwink*“, möchte ich mit Steve Jobs antworten: „You cannot connect the dots forward, you can only connect them backwards“.

9. #1
5,5 Mrd. Menschen
haben ein Smartphone
Prognose 2020, 8 Mrd. Weltbevölkerung
http://ben-evans.com/benedictevans/2016/3/29/presentation-mobile-ate-the-world
Einer der wichtigsten Gründe ist die Tatsache, dass das Internet so richtig abhebt. 1994, als ich mit dem Internet begonnen habe, da gab es nur das popelige 19,2kBit
Modem. Nach Ende des DotCom Crashs ist jedoch die Zahl der Menschen, die einen Internet-Zugang haben, stark gestiegen. In den vergangenen Jahren haben wir es
mit einem exponentiellen Anstieg zu tun. Dieser wurde ausgelöst durch die Revolution des Smartphones.
Von Benedict Evans, Partner bei Andreessen Horowitz (Marc Andreessen erfand den ersten Internet-Browser Netscape), gibt es eine schöne Prognose zur mobile
Nutzung in der Weltbevölkerung. Sein Fazit: „Mobile ate the world“ (angelehnt an Marcs Bonmot „Software is eating the world“). Im Jahr 2020 werden bei einer
Gesamtbevölkerung von 8 Mrd. Menschen etwa 5,5 Mrd. Menschen über ein internet-fähiges Smartphone verfügen.
Phew!

10. #2
Konsumenten sind mündig,
fluide im Kanal und lassen
sich nicht mehr beeinflussen
Der zweite Grund liegt an uns, den Konsumenten: wir treffen heutzutage souverän Einkaufsentscheidungen und nutzen das Internet aktiv, um Kaufentscheidungen
vorzubereiten. Schon seit 1999, als das Cluetrain Manifest veröffentlicht wurde, war klar, dass Konsumenten sich nicht mehr steuern oder gar beeinflussen lassen
(wollen). Das wiederum ist ein Grund, warum wir Unternehmen umdenken müssen und platte PR schon seit langem nicht mehr so gut funktioniert.
Gleichzeitig agiert der Kunde „kanalübergreifend“. Wenn ich mich selbst aus der Rolle des Konsumenten betrachte, dann muss ich Euch sagen, dass es für mich gar
keine „Kanäle“ gibt. Ich achte da nicht drauf. Wenn ich irgendwo unterwegs bin und Zeit habe, dann öffne ich auf meinem Smartphone vielleicht die Amazon-App und
packe dort einen Artikel in den Warenkorb. Komme ich ins Büro, öffne ich amazon.de im Browser und shoppe weiter meinen Warenkorb voll. Und Abends, auf der Couch,
nehme ich mein Tablet zur Hand, wahlweise mal mit dem Browser oder mit der App, shoppe kurz weiter und mache schlussendlich den Checkout.
Und wer weiß, vielleicht bestellt der Konsument morgen schon über Apps, die in den Facebook Messenger integriert sind?

11. #3
Softwareentwicklung ist
komplex
(no Cynefin attached)
Viele Manager denken, Softwareentwicklung sei doch ganz einfach. Wenn wir im Cynefin System-Modell denken, dann findet Softwareentwicklung jedoch im Bereich der
„unordered domain“ statt, also meist im komplexen oder chaotischen Feld („chaotisch“ hat hier nichts mit der landläufigen Meinung von „unüberlegt = doof“ zu tun).
Ich will das hier nicht weiter ausführen, schließlich ist dies ein „Advanced“ Talk, und das Cynefin Diagramm wird schon zu genüge in praktisch jedem agilen Talk aufgelegt
;-) Lasst es uns einfach als gegeben hinnehmen …

12. Liebe Unternehmen,
Eure Organisations-
Strukturen sind kaputt.
All dies sagt mir, liebe Unternehmen, dass Eure Organisations-Strukturen kaputt sind. Weil sie nicht zu dem passen, wie die Welt da draussen schon seit einiger Zeit ist.
Wir haben hohe Marktdynamiken, eine massive Verlagerung von Themen in das Internet, nicht mehr steuerbare Kunden und Anforderungen an Software, die dadurch
immer komplexer wird. Die Strukturen, die Ihr in Eurer Organisation habt, passen dazu nicht mehr. Deswegen fällt es Euch vielleicht auch schwer, diesen ganzen
modernen „heißen Schei*“ wie Scrum gut zu nutzen - viele haben das Gefühl „das ist doof, weil bei uns hat das nicht funktioniert“.
Mein Denkanstoß an Euch: vielleicht funktioniert die Anwendung nicht, weil Euer System nicht (mehr) dazu passt.

13. Denkwerkzeuge
Ich habe für Euch keine „einzige, einmalige Lösung“ parat. Das geht auch nicht, weil jede Organisation anders tickt. In den Workshops und Consultings, die ich mit
Organisationen durchführe, kommt es mehr auf die Beobachtung an. Und auf passende „Denkwerkzeuge“, die helfen können, das (Organisations-)System zu besser zu
beobachten, zu verstehen und Veränderung zu ermöglichen.
Einige dieser Denkwerkzeuge habe ich Euch mitgebracht. Lasst uns mal reinschauen, was so alles drin ist.

14. IT = UnterstützungCore
Schauen wir uns einmal an, was häufig im BWL-Umfeld gelehrt wird, nach Porter: dort wird die IT (Technologie-Entwicklung) bei den Unterstützungsaktivitäten
eingeordnet, hingegen Logistik, Produktion, Marketing & Vertrieb sowie als Service als Primäraktivitäten, die letzten Endes zur Marge beitragen.
Heutzutage ist es aber tatsächlich umgekehrt: wenn der Konsument überwiegend Online-„Kanäle“ dazu nutzt, um sich zu informieren, Einkaufsentscheidungen zu treffen
und Einzukaufen, dann ist die Software und damit die IT ein primäres Merkmal dessen, was entscheidend dazu beiträgt, dass gekauft wird.
Mit anderen Worten: die bisherige, vorherrschende Ansicht, dass IT nur eine unterstützende Aktivität ist (und damit auch eher ein „Cost Center“), ist völlig überholt.
Unternehmen, die so denken, werden in der Marktdynamik und den Anforderungen der Konsumenten nicht bestehen können. Es braucht also eine Abkehr der Kosten-
Denke in Bezug auf IT als „unterstützende Aktivität“, hin zu IT als zentrale Aktivität.
Im E-Commerce Umfeld kennt man das ganz klar von den Online Pure Playern, die den etablierten Anbietern das Wasser abgraben. Warum ist das so? Weil IT ein Kern
ihrer DNA in der Organisation ist, und sie nicht so denken, wie hier zur Schau gestellt.
Ich sage immer salopp: „Amazon ist eigentlich ein IT-Unternehmen, das nebenbei noch ein paar Millionen Produkte verkauft“

15. Bimodale IT
Ein weiteres Denkwerkzeug, nämlich als Anti-Pattern, ist die sogenannte „Bimodale IT“, die uns Gartner seit einigen Jahren einreden will. Ich sage dazu nur: „Bimodale IT
sind die Stützrädchen im Argumentationskasten des CIOs“, damit er eine Denkrichtung hat, um sowohl die schwerfälligen internen IT-Systeme zu rechtfertigen als auch
eine Möglichkeit im Unternehmen zu haben, an einigen Stellen „schneller“ und „agiler“ zu arbeiten. Forrester hat das mittlerweile als Anti-Pattern erkannt und versucht
nun, uns das - zum Glück - wieder auszureden.
Mein Gedankengang, und damit das Denkwerkzeug, ist jedoch ein anderer: wenn wir anerkennen, dass Agilität viel mehr eine Geisteshaltung (Prinzipien und Praktiken)
ist und weniger der „Kauf“ von Methoden wie Scrum, dann verhindern wir die Etablierung dieser Geisteshaltung durch das Offenhalten der „bimodalen IT“. Schließlich ist
doch nicht einzusehen, warum der „langsamere Teil“ in der Bimodalen IT nicht auch von agiler Geisteshaltung profitieren könnte. Oder?

16. Alle Firmen werden zu
Software-Firmen
www.cio.de/a/digitale-transformation-laesst-keinen-stein-auf-dem-anderen,3231493
Ihr erinnert Euch noch an mein saloppes „Amazon ist eigentlich ein IT-Unternehmen, das nebenher Waren verkauft“? Im Zuge des Oberbegriffs der digitalen
Transformation hat das CIO Magazin ein Statement gebracht, das ich bezeichnend finde: alle Firmen werden zu Software-Firmen.
„Und was daran ist das Denkwerkzeug“? Mein Denkwerkzeug ist die logische Herleitung aus all dem, was wir in den vergangenen Folien gesehen haben. Wir wissen,
dass Märkte an Dynamik hinzugewinnen. Dass kein Stein mehr auf dem anderen bleibt. Wir wissen, dass der Konsument flexibler und anspruchsvoller geworden ist -
schließlich ist DEIN Mitbewerb für den Konsumenten oftmals nur wenige Mausklicks entfernt.
Als Organisation müssen wir darauf also eine Antwort haben. Unsere Ankerpunkte, ausgedrückt durch den berechenbaren Konsumenten und das in den Markt gedrückte
Angebot, gibt es in dieser Form nicht mehr. Stattdessen gibt es die „wave of uncertainty“, die wir reiten müssen.
Am besten gelingt dies uns als Organisation in Form von Digitalem Brennstoff, denn Software können wir flexibel anpassen. Unsere Produkte mögen heute noch zB
Hardware sein, doch das befriedigt den Kunden nicht mehr. Für viele Unternehmen ist zusätzliche Software als „digitaler Service“ ein Unterscheidungsmerkmal, um im
Geschäft bleiben zu können. Andere - die „Pure Player“ - setzen gleich direkt auf digitale Produkte.
Daher wächst der Anteil an Software in der „Fertigung“, um mal mit dem klassischen Produktions-Sprech zu antworten. Der Sog entsteht dabei durch den Konsumenten
und die „Infrastruktur“ des Marktes, die global ist. Wer morgen noch mitspielen möchte, muss darauf eine Antwort haben. Online Pure Player haben eine „digitale
Fertigungstiefe“ von 100%.
Daher werden alle Firmen zu Software-Firmen. Endgame. Jetzt ist es an der Zeit, gut aufgestellt zu sein. Und das bedeutet, dass deine Organisations-DNA in der Lage
sein muss, Software zu produzieren (oder produzieren zu lassen). Und vor allem: Verständnis dafür zu entwickeln, wie das Software-Business funktioniert.

17. Tight social cohesion
vs
Innovationsfähigkeit
Wo wir gerade bei Innovationsfähigkeit waren: die „social cohesion“ eines Systems, also der soziale Zusammenhalt zB in einer Organisation, hat eine gewisse „Enge“.
Man kann feststellen, dass Systeme, die einen sehr engen sozialen Zusammenhalt haben, über eine geringe Innovationsfähigkeit verfügen. Eine hohe Enge erkennt man
zB daran, dass es im sozialen System strenge (implizite) Aufnahmekriterien gibt. Oder dass es explizite Bezeichnungen für die Mitarbeiter gibt, die man vielleicht sogar
sein ganzes Leben lang behält, selbst wenn man dort nicht mehr arbeitet.
Eine zu starke „social cohesion“ ist also eher schädlich für die Innovationsfähigkeit einer Organisation. Ist sie extrem, so entsteht ein Kult.

18. Conway’s Law
Conway’s Law stammt von einem Informatiker und besagt im Wesentlichen: Organisationen, die Systeme entwerfen, […] sind auf Entwürfe festgelegt, welche die
Kommunikationsstrukturen dieser Organisationen abbilden.
Das bedeutet also für Eure Software-Entwicklung, dass Kommunikationsstrukturen Eurer Organisation sich in der Software wiederfinden, die Ihr baut. Ihr dürft jetzt gerne
selber darüber nachdenken, wie das zB in einer hierarchischen Organisation mit starren Entscheidungswegen so läuft und was das für Vor- und Nachteile auf die
Software hat. ;-)
Mein Denkwerkzeug an dieser Stelle ist: wenn ich Conway’s Law als gegeben hinnehme, wie muss ich dann die (Kommunikations-/Entscheidungs-)Struktur in meiner
Organisation verändern, um eine gute Software bauen zu können - vielleicht sogar agil, durch kleine, inhaltlich autonom arbeitende Teams?
Oder anders gesagt: wie gut kann ich Agile Prinzipien (cross-funktionales Produkt-Team, PO der das „Was“ bestimmt, Devteam dass sich eigenständig um das „Wie“
kümmert) überhaupt in meiner Organisation anwenden, wenn ich diese durch „Conways Brille“ betrachte?

19. Inspect & Adapt
Good Enough
BWLer so: §$!“$!!!
Im Agilen Umfeld gibt es zwei Leitbilder, die BWLern und Controllern grauslig und schwer verständlich vorkommen, jedoch ein gutes Denkwerkzeug sind, um Software
sinnvoll zu entwickeln: Inspect & Adapt geht einher mit der Erkenntnis, dass wir uns in der „unordered domain“ von komplex befinden und Prinzipien benötigen, um diese
unordered domain handhaben zu können. Wenn wir also schrittweise arbeiten, dabei beobachten und uns immer wieder anpassen, werden wir am Ende erfolgreicher
sein, als alles vorherzubestimmen - um dann am Ende als BWLer enttäuscht zu werden, weil der große Plan nicht passte.
„good enough“ bedeutet, dass ich akzeptiere dass es auf dem Weg Veränderung geben wird. Ich also nicht in einer hohen Detail-Tiefe alles vorab planen will, weil sich
das nicht lohnt. Daher will ich den sweet spot finden - und dafür ist das Leitbild „good enough“ hilfreich.
Wieviel „good enough“ bei dir, in deiner Organisation oder deinem Software-Team bedeutet? Tja, das kannst du nur für dich selbst herausfinden. Und wirst es vermutlich
gemäß „Inspect & Adapt“ immer wieder anpassen :-)

20. Yeah! Wasserfall!
Konzept Design Implementation
Wir arbeiten nach Agil
Wir arbeiten nach Agil
Wir arbeiten nach Agil
Als Dienstleister, sowohl in Umsetzung als auch Beratung tätig, kommen wir viel herum. Blöderweise begegnet uns dabei diese gezeigte „Realität“ oft genug. Eine
Initiative/Projekt wird, ganz in tayloristischer Manier, in einzelne Bestandteile zerlegt. Für die Konzeption wird ein Spezialist eingekauft, für Design noch ein anderer, und
das Ergebnis des Designs wird dann an den Dienstleister, der für die Implementation zuständig ist, weiter gegeben.
Das Management, das die Initiative/Projekt verantwortet, geht dabei aus, dass alles agil abläuft. Schließlich arbeiten die einzelnen Dienstleister ja für die Teilbereiche agil.
Super Sache!
Du siehst den Fehler? Durch die „Gewaltenteilung“ entsteht ein Scrummerfall: einzelne Teilbereiche, die in sich angeblich agil (nach Scrum) abgearbeitet werden, bei der
Betrachtung durch die Makro-Brille aber eher wie ein Wasserfall erscheinen.
Dein Denkwerkzeug ist also, genau hinzusehen und mit etwas Abstand auf die Vorgehensweise zu schauen. Wenn du wirklich nach agilen Prinzipien arbeiten willst, dann
sind alle drei Bereiche ineinander integriert, Design vielleicht gar nicht mehr notwendig (weil du Devs hast, die CSS3/HTML5 können und im Team einen UXer haben), und
das Team arbeitet als echtes cross-funktionales Team, das alle Fähigkeiten und Fertigkeiten enthält, um von Konzeption bis hin zur Implementation und Betrieb alles
abzudecken.
Du kennst den Amazon-Leitspruch? „You build it, you run it.“ …

21. DevProductSupportSecBizOps
Silos einreissen
Und was ist mit
Marketing?
A propos „You build it, you run it“… wo wir gerade beim Einreissen von Silos sind. Deswegen gibt es die DevOps Kultur, weil die früher Trennung zwischen „Development
wirft den Ops was über den Zaun und die kümmern sich darum“ als veraltet und überholt gilt.
Das Denkwerkzeug an dieser Stelle ist: du willst im Team alle Fähigkeiten und Fertigkeiten haben, um das (Teil-)Produkt eigenständig entwickeln zu können. Und das
bedeutet, dass du neben Entwicklung auch Product, Support, Security, Business Analyse, Ops etc. als Fähigkeiten & Fertigkeiten im Team hast.
Und bei größeren Produkten helfen Dir zB Microservices, um dennoch kleine autonome Teams zu ermöglichen und trotzdem in der Technik ohne Abhängigkeiten arbeiten
zu können.

22. 5 Phasen nach Tuckman
https://mercureaace2013.files.wordpress.com/2013/01/groupstages.png
Wir haben jetzt schon einiges über Teams gehört. Mir begegnen oftmals Organisationen, die Teams regelmäßig zusammenstellen und nach Projektende wieder
auseinander reissen. Vor einigen Jahren war das sogar mal ein ganzer Trend, der in der BWL-Controller-orientierten Welt en vogue war („für ein Projekt die Experten
zusammenstellen, die es für diese Aufgabe braucht“).
Das Problem im komplexen Umfeld der Software-Entwicklung dabei ist, dass Teams, die regelmäßig neu zusammengestellt werden, Schwierigkeiten haben, zu echter
Performance zu finden.
Das Denkwerkzeug, das Dir dabei helfen könnte, sind die 5 Teamphasen nach Tuckman. Danach durchläuft ein Team verschiedene Phasen, bis es zu echter Performance
findet. Reisst du ein „Team“ jedoch nach Projektende auseinander und stellst für ein neues Projekt ein neues Team zusammen, so fängt dies jedes Mal wieder in den
Phasen von vorne an, insbesondere wenn die Team-Mitglieder noch nie so richtig zusammen gearbeitet haben. Haben sie zuvor zusammengearbeitet, ist es vermutlich
einfacher, jedoch wird es immer kurzfristig zu Einbußen kommen. Das passiert auch, wenn du ein Team punktuell um weitere Leute ergänzt, die möglicherweise nicht
dauerhaft im Team verbleiben. Bei Erweiterung muss sehr genau abgewogen werden, wie du vorgehst.
Was ist also effektiver? Die Arbeit durch ein bestehendes Team durchfließen zu lassen. Damit gibst du dem Team die Möglichkeit, eine Teamkultur zu entwickeln und zu
echter Performance zu finden.
Doch das heisst nicht, dass alles optimal läuft …

23. Stabile Teams
VS
Group Think Effect
… denn ein stabiles Team kann auch Nachteile bekommen, und damit sind wir schon beim nächsten Denkwerkzeug.
In der Psychologie gibt es den Group Think Effect. In Wikipedia lesen wir: „Gruppendenken ist ein Prozess, bei dem eine Gruppe von an sich kompetenten Personen
schlechtere oder realitätsfernere Entscheidungen als möglich trifft, weil jede beteiligte Person ihre eigene Meinung an die erwartete Gruppenmeinung anpasst. Daraus
können Situationen entstehen, bei denen die Gruppe Handlungen oder Kompromissen zustimmt, die jedes einzelne Gruppenmitglied unter normalen Umständen
ablehnen würde.“
Darüber hinaus ist manches Team, das über einen starken Zusammenhalt verfügt, „blind“ für an sich gute Ideen und Impulse von außen.
Was kann hier getan werden? Manchmal hilft hier nur eine gezielte Intervention, um das Team darauf aufmerksam zu machen, dass es dem Group Think Effect unterliegt.
Dies kann eher von außen passieren, da das Team von innen gar kein Bewußtsein darüber hat, dass es diesem Group Think Effect unterliegt.
Die Folgen davon: Irrationalität, Dogma, fehlendes kritisches, hinterfragendes Denken.

24. Flexibilität & Speed
VS
Zentralität
Wer kennt sie nicht, die zentrale IT? Die vielleicht sogar einen Katalog herausgibt von Technologien, die „zertifiziert“ sind und eingesetzt werden dürfen?
Mein Denkwerkzeug hierbei: Zentralität kommt nur zu einem Preis. Der Preis ist der der fehlenden Flexibilität und Geschwindigkeit. Dieses steht im Widerspruch zu dem,
wie der Markt da draussen mittlerweile funktioniert, denn er ist zum Taktgeber geworden. Überall dort, wo du diesen Sog hast, aber dennoch zentrale Entscheidungen
hast, wirst du an Flexibilität und Geschwindigkeit verlieren. Dies kann dich deine Innovationskraft kosten, da du nicht dem mit dem Takt des Marktes mitgehen kannst.
Lässt sich beides vereinen? Lass uns mal schauen …

25. Makro-Architektur
… ein Ausweg könnte eine „Makro-Architektur“ in Form von Prinzipien sein. Repräsentanten aus einzelnen Teams treffen sich regelmäßig, zum Beispiel in einer
„Community of Practice“, und besprechen Makro-Prinzipien, wie die Architektur im Produkt oder den Produkten sein sollte. Das könnte zum Beispiel so etwas wie
„ReSTful Services, self-contained systems, freie Wahl der Programmiersprache, freie Wahl der Datenbank“ etc. sein. Diese Makro-Architektur bewegt sich regelmäßig
und wird aktualisiert.
„Und wo ist nun die zentrale IT, die mitredet?“ - tja …
;-)
Was möchtest Du: lieber die rote Softwarepille oder lieber die blaue? Du brauchst keine Sorge zu haben, dass mit einer Flexibilisierung im Einsatz vom Technologien
Nachteile einhergehen. Wenn du das Prinzip des „you build it, you run it“ beherzigst, also viel Know-how inkl „Betrieb“ im Produktentwicklungs-Team ist und damit auch
eine Verantwortung im Team, dann wirst du die Welle des Marktes sehr gut mitreiten können, und damit auch Morgen noch eine Rolle im Business spielen.

26. Lake Wobegon Effect
Ein weiteres Denkwerkzeug ist der sogenannte Lake Wobegon Effect. Der geht in etwa so: wenn du in einem Raum voller Software-Entwickler fragst, wer sich für einen
überdurchschnittlich kompetenten Entwickler hält, werden etwa 80% der Leute sich melden. :-)
Natürlich wissen wir, dass das vermutlich eher nicht der Fall sein wird. Jedoch das Bewusstsein darüber, dass es diesen Effekt gibt, hilft uns schon für die Einordnung im
Selbst- und Fremdbild.

27. Señor Developer
IT Architect
Lead Developer
Head of BlahBlah
Wir bei Mayflower haben die Positionen nach innen so ziemlich aufgegeben. Schließlich ist nicht einzusehen, warum die Software-Architektur ausschließlich vom
Architekten im Team kommen sollte. Wie wir wissen, entsteht die beste Architektur einer Software emergent aus dem ganzen Team heraus.
Und auch der „Junior“ Developer hat sicherlich auch gute Ideen, die vielleicht ein Señor Developer nicht hat. Stell dir vor, jemand hat die Position des Architekten: das
Team wird unbewusst immer dem Architekten folgen, auch wenn es selbst eigene Ideen hat.
Daher denkt lieber in Rollen. Die können auch mal wechseln. Wenn mehrere Projekte durch das Team nacheinander fliessen, dann wird es je nach Projekt auch
unterschiedlich benötigte Rollen geben. Somit hast Du also viel flexiblere Entwicklungsmöglichkeiten für die Menschen im Produkt-Team. Und ja, natürlich kann es
Spezial-Ausprägungen bei einzelnen Personen im Team geben. Es gibt also sicherlich den Einen, der mehr Know-how im Bereich Architektur hat als andere im Team. Er
wird jedoch mehr die Rolle eines Coachs und Mentors einnehmen als die Rolle desjenigen, der alleine die Architektur festlegt.

28. T
Damit das alles gut funktioniert, benötigst du als Denkwerkzeug den Begriff „T-shaped“. T-shaped bezeichnet eine Einordnung von Kompetenzen eines Developers (oder
allgemein eines Wissensarbeiters) auf zwei Achsen:
Auf der vertikalen Achse sind 1-2 Kernkompetenzen zu finden, also beispielsweise eine Programmiersprache wie JavaScript und/oder PHP. Auf der horizontalen Achse
sammelt die Person über die Zeit weitere Kompetenzen an, wie zB NodeJS, HTML5/CSS3, das Schreiben von guten Texten oder Projektmanagement-Kompetenz. Die
Person wird damit also zum flexiblen Wissensarbeiter, und ist damit viel viel besser in einem Team einsetzbar als ein einsamer Spezialist es wäre. Denn am Ende kommt
es bei echter Teamarbeit auf die Effektivität des Gesamt-Teams an, und weniger auf die Einzel-Expertise einzelner Personen.

29. FAIL-Kultur
First Attempt In Learning
Damit alles gut klappt, braucht es die berühmt-berüchtigte Fehler-Kultur, von der immer Alle sprechen.
Vielleicht hilft Dir als Denkwerkzeug, wenn Du Dir „FAIL“ als Akronym für „First Attempt In Learning“ vorstellst: ein Fehler ist die erste Gelegenheit, um hinzuzulernen, und
manchmal sogar die beste Möglichkeit, um zu Lernen. Wichtig dabei ist nur, dass danach „echtes Lernen“ stattfindet, um den gleichen Fehler nicht nochmal zu machen.
Schließlich wäre es ebenfalls ein Anti-Pattern, wenn unter dem Deckmantel von „Fehler sind erlaubt“ keine passenden Lern-Schleifen existieren.
Achte also bei Deinen Beobachtungen insbesondere darauf, ob es Raum und Möglichkeiten gibt, Lern-Schleifen in der Organisation zu haben. Diese sind ein wichtiger
Bestandteil, um mit Fehlern umgehen zu können.

30. Cost of Delay
Cost of Delay ist ein Begriff, den Donald Reinertsen geprägt hat. Vereinfacht gesagt kannst Du für jedes Work Item, das durch Dein System (also zB Dein Team) geht, eine
Cost of Delay bestimmen. Nämlich die Kosten, die entstehen, wenn Du dieses Work Item nicht abarbeitest (Verzögerungskosten).
Wenn Du die Kosten auf einem Graphen darstellst, bei der auf der x-Achse die Zeit notiert ist, dann bekommst Du eine schöne Shape-Darstellung der Cost of Delay für
ein einzelnes Work Item oder eine Kategorie von Arbeitsaufgaben.
Diese Betrachtung der Cost of Delay kann Dir helfen einzuplanen, wann ein guter Zeitpunkt ist, ein Work Item zu erledigen. Es hilft Dir auch einzuschätzen, ab welchem
Zeitpunkt die Verzögerungskosten ansteigen (und wenn ja, wie, zB linear oder exponentiell).

31. Little’s Law
WIP
Throughput
= Avg Cycle Time
Dazu passt Little’s Law. Im Durchfluss von Arbeit durch ein System sind zwei Metriken wichtig: die Cycle Time und die Lead Time. Während die Lead Time darüber
Auskunft gibt, wie lange ein Work Item von zum Beispiel „Idee wurde geboren“ bis „Done“ braucht, gibt Dir die Cycle Time Auskunft über die Zeit von „Idee geht in
Produktion“ bis „Idee ist auf Done, wurde also realisiert und ist in Produktion gekommen“.
Für die Berechnung der durchschnittlichen Cycle Time empfiehlt sich Little’s Law: der Quotient aus der Menge an Arbeit, die gleichzeitig „in Erledigung“ ist (Work In
Progress) geteilt durch den „Durchsatz“, den das System liefern kann in einer bestimmten Zeiteinheit. Das ergibt die durchschnittliche (!) Cycle Time deines Systems.
Lead Time und Cycle Time sind zwei wichtige Metriken, um den Fluss von Arbeit durch ein System - also zB in einem Team - zu betrachten.

32. MVP vs MMP
Lernfähigkeit Vermarktbarkeit
Wir alle kennen den Begriff des „MVP“, denn er ist uns im Kontext des Lean Startup begegnet. Roman Pichler hat zudem noch den Begriff des MMP geprägt. „MVP“
steht für „Minimum Viable Product“, „MMP für Minimum Marketable Product“.
Die Unterscheidung der beiden Begriffe hilft Dir, eine gute Einordnung für den Release-Fahrplan Deiner Software zu treffen: das MVP liefert Dir die Lernfähigkeit. Es ist die
minimale Variante Deines Produkts, die Du an Deinen Markt online stellst (zB mit Beta-/Key-Usern). Das MVP wird Dir die erste Möglichkeit zum Lernen liefern, anhand
dessen Du weitere Funktionen in der Software realisierst.
Das MMP hingegen ist die minimale Variante des Produkts, die „echt vermarktbar“ ist. Sie ist also durchaus „mehr“, als das MVP bietet. Und findet zu einem späteren
Zeitpunkt statt.
Wenn Du so willst, dann ist MVP in der alten Sprache gesprochen der „erste Meilenstein“. Mit dem Vorteil, dass Du Lernen kannst. Um dann zu einem späteren, jetzt
noch unbekannten „Meilenstein“ die erste „echte“ Vermarktbarkeit zu bekommen.

33. Frei-Zeit
vs
~100% Utilisation
Wir sind alle getrieben von Produktivität, nicht erst seit es lifehacker.org gibt ;-) Mit diesem Denkwerkzeug biete ich Dir eine Unterscheidung, die Dir hilft, bessere
Software zu entwickeln.
Wenn Du als Unternehmen heute innovationsfähig sein willst, dann müssen Innovationen entstehen können. Der Kristallisationspunkt einer Innovation entsteht aus vielen
Dingen, die mal mehr und viel weniger geplant gemacht werden.
Für diese vielen Dinge benötigt es Frei-Räume. Wenn Du jedoch in Deiner Organisation dem Gedankenmodell anhängst, dass nur „100% Auslastung“ (oder nahe 100%)
echte Produktivität bedeuten, dann beraubst Du Dich deiner Innovationskraft. Denn wenn durch die Produktivitäts-Auslastung kein Platz mehr für „freie Radikale“ ist -
woher soll dann die Innovation bitteschön kommen?
Wir bei Mayflower haben seit über vier Jahren eine sogenannte Slacktime. Weil bei uns alles etwas anders ist als in anderen Unternehmen, haben wir diese Slacktime
„Mayday“ getauft. Ich habe darüber auf https://www.impulse.de/management/unternehmensfuehrung/slacktime/2178126.html berichtet. Jeden zweiten Freitag nehmen
wir uns „frei“ von der kundenfinanzierten Utilisation. Wir geben auch keinen gesonderten Rahmen vor, ausser einer zeitlichen Struktur (die die Crew immer wieder
anpasst) und dem Prinzip, dass etwas sinnvolles für das Unternehmen getan wird.
Was, das bleibt den Leuten überlassen.
Ich muss zugeben, dass ich zu Beginn bei der Einführung sehr skeptisch war und anzweifelte, ob das funktioniert. Ein halbes Jahr später wurde mir bewusst, dass dies
eine sehr sehr gute Entscheidung war, dass sie uns als Organisation Innovation beschert, die Erneuerung von Wissen auch außerhalb von Kundenprojekten sowie zur
Steigerung der Mitarbeiter-Zufriedenheit beiträgt.

34. Fitness Metrics
• Delivery Time
• Quality
• Predictability
• Safety (i.e. regulatory reasons)
• Employee / Customer satisfaction
Wie kannst du also feststellen, ob ein System „fit“ ist? Frei nach David J. Anderson aus dem Lean Kanban Systems Thinking Denkmodell gibt es fünf wichtige Kern-
Metriken, nach denen Du Dein System beobachten solltest: wie gut ist deine Lieferfähigkeit/-zeit? Wie hoch ist die Qualität Deiner Software? Wie vorhersagbar ist die
Lieferung durch dieses Team? Wie „sicher“ arbeitet es (zB in Bezug auf regulative Vorgaben)? Und wie hoch ist die Kunden und Mitarbeiter Zufriedenheit?
Doch Vorsicht vor der Anwendung dieses Denkwerkzeugs: es bringt Dir nichts, wenn Du dich nur auf eine Metrik stützt. Wenn Du also zum Beispiel feststellst, dass Team
A eine deutlich bessere Lieferzeit hat als Team B, dann heißt das noch lange nicht, dass Team A das bessere Team ist. Denn die Qualität könnte niedriger sein, ebenso
die Kundenzufriedenheit. Du solltest also immer alle Metriken im Gesamtzusammenhang anschauen.
Damit das gut funktioniert, hilft Dir zum Beispiel ein Spider-Diagramm, auf dem Du alle Metriken an den Spider-Achsen aufzeichnen kannst und Dir dann ein Gesamtbild
machen kannst.

35. J-curve Effect
http://de.slideshare.net/DavidHawks1/deliver-double-the-value-in-half-the-time-43600722/34
Du hast jetzt also eine ganze Menge an Ideen an der Hand, um Veränderungen in Deinem System durchzuführen. Doch ganz so einfach ist es nicht: Willkommen beim J-
curve Effect.
Dieser wurde geprägt von Virginia Satir im Umfeld der Familientherapie. Als Denkwerkzeug auf die Organisation, die Software-Entwicklung zum Beispiel anders als bisher
angehen möchte, sei wie folgt erklärt:
Der J-curve Effect besagt, dass mit Beginn der Induzierung einer Veränderung - also weg vom Status Quo), zunächst einmal ein negativer Effekt eintritt. Dieser wird zu
Resistenz bei den Personen (denn wer will schon gerne verändert werden?) und möglicherweise auch zu Chaos führen. In dieser Phase ist eine Begleitung sehr wichtig,
denn das System (zB das Team) wird erst über einen mitunter sehr langen Zeitraum neue Praktiken akzeptieren/erlernen und kann diese entsprechend integrieren. Daher
die langsam ansteigende Kurve, die dann irgendwann bis hin in den neuen Status Quo führt.
Die Zeiträume für „Resistance and Chaos“ und „Integration and Practice“ können mitunter sehr lange sein - nicht nur einige Wochen, oftmals viele Monate, manchmal
Jahre. Sie setzen also eine hohe Geduld auf Management-Ebene voraus. Denn bricht das Management den Change vorzeitig ab oder induziert weitere Changes, die den
vorherigen überlagern, so fangt Ihr wieder von vorne an.
Vielleicht hilft Dir dieses Denkwerkzeug, bei Veränderungen im Team - zum Beispiel Etablierung agiler Praktiken - mehr Geduld zu haben und gleichzeitig durch eine
Begleitung sicherzustellen, dass das Team irgendwann den neuen Status Quo erreichen kann.

36. Was solltet Ihr tun? (no silver bullet)
Lass mich also zusammen fassen, was Ihr tun solltet oder könntet, um im Software-Umfeld den Anforderungen an dynamische Welten gerecht zu werden, und was das
für Eure Organisation insgesamt bedeutet …

37. #1 Goal
Schnelle, regelmäßige
Lieferfähigkeit
(Continuous Deployment / Delivery)
Eines der wichtigsten Ziele, wenn nicht gar das wichtigste, sollte die Herstellung einer schnellen, und regelmäßigen Lieferbarkeit lauten. Im technischen Sinne sind hier
die Stichwörter Continuous Deployment bzw. Continuous Delivery gemeint. Auf der „Menschenseite“ verbuchen wir Team-Praktiken sowie echte, bessere Zusammen-
Arbeit als Ziel.

38. Aufstellung der IT-Teams verändern
• kleine, unabhängige Teams als Schnellboote (Alignment vs. Autonomie)
• Flexibilität einbauen: jeder kann alles umsetzen, breite + tiefe Fähigkeiten
• DevProductSupportNetSecBizOps (+ BA, Marketing, Frontend/UX)
• Microservices to the rescue?! (Conway’s Law)
• schneller liefern um früher lernen zu können (Kanban, Scrum, oder andere
iterativ-inkrementelle Arbeitsmethoden)
Es geht also darum, die Aufstellung des Software-Teams anzupassen: weg von Einzel-Experten, hinzu den generalisierten Spezialisten ;-), so dass jeder alles umsetzen
kann und über breite und tiefe Fähigkeiten verfügt. Schneide kleine, unabhängige Teams als Schnellboote, die über Themen wie Makro-Architektur im Gesamt-Produkt/-
Ziel aligned sind. Über Microservices als Taktik ermöglichst Du, dass die menschliche Autonomie, die Du dem Team zugestehst, auch in der Software abbildest (stellt Dir
vor, was passiert, wenn Deine Teams zwar autonom sind, aber im Gesamt-Produkt technische Abhängigkeiten/Zusammenschlüsse zwischen den Teams existieren).
Breite und tiefe Fähigkeiten gehen damit einher, dass das Team „cross-funktional“ aufgestellt ist. Das Produkt wird also nicht durch einzelne Abteilungen bedient,
sondern Marketing+Development(QA)+Security+Ops etc. sind in einem Team vorhanden. Idealerweise kann jeder alles umsetzen. Dann spürst Du keine Einbußen bei
Krankheit und Urlaub :-)
Und denke daran: Du willst schneller liefern, damit Du früher lernen kannst.

39. Zusammenarbeit zwischen Bereichen
verändern
• kürzere Kommunikationswege schaffen: notwendige Disziplinen als
Gesamtteam etablieren, räumlich zusammen sitzend
• 3Cs schaffen Klarheit (Methoden zB Story Mapping)
• Stakeholder integrieren und mit in die Verantwortung nehmen (Methoden zB
Weighted Decision Matrix)
Verändere die Zusammenarbeit zwischen einzelnen Bereichen. Lass die Leute räumlich zusammen sitzen. Du kennst das? Entwicklung sitzt im 2. Stock,
Produktmanagement im 3. Stock, Marketing im anderen Gebäude … ;-)
Denk beim Schreiben von Anforderungen (User Stories) daran, dass es im Wesentlichen um Eines geht: ein Gespräch zwischen allen Beteiligten, um Klarheit zu schaffen!
Der Budget-Inhaber mit den vielen Steaks hat nie Zeit und das Produktmanagement möchte sich nicht mit Euch beschäftigen? Integriert Eure Stakeholder, und nehmt sie
mit in die Verantwortung, indem sie aktiv im Prozess beteiligt werden. Gute Entscheidungen kannst Du über Instrumente wie Weighted Decision Matrix facilitieren, denn
dort werden die Kriterien aller gegen die Lösungsvorschläge bewertet, um eine Empfehlung heraus zu bekommen.

40. Endanwender stärker einbinden
• Feature-Wünsche abfragen zB uservoice.com
• tiefergehende Analytics zB hotjar.com
• Feature-Flags: bestimmte Funktionen nur für bestimmte Anwender-Kohorten
verfügbar
• Fake-Features: Abfragen, ob Nutzer bestimmte Features haben wollen würden
• Analytics auf Funktionen / Buttons
Bindet Eure Endanwender - uns Konsumenten - ein. Zu „Fake Features“ möchte ich ein Wort verlieren, denn „Fake“ ist ja so ein negativ besetzter Begriff: es geht hierbei
nicht darum, die Anwender zu ärgern. Sondern gezielt bei Feature-Ideen zu prüfen, ob die Anwender dies haben wollen. Was liegt da manchmal näher, als eine Funktion
anzudeuten und im gleichen Atemzug den Anwender zu fragen, wie sehr er solch eine Funktion vermissen würde. Arbeitet sparsam mit dieser Form!
Bei allen Varianten, die hier vorgestellt werden, geht es um Eines: um eine Lern-Möglichkeit, die Dir die Anwender liefern, um bessere Entscheidungen für die Realisierung
von Features in Deinem Produkt zu treffen.

41. Frei-Räume für Innovation und
Wissensaustausch schaffen
• Wiki #workoutloud #microblogs
• Slacktime
• Firmeninterne Barcamps
• Lightning Talks / Brownbag Sessions / Random Lunch
• Entwickler hospitieren in anderen Unternehmens-Bereichen
• Work Expo (Management 3.0)
Schaffe Frei-Räume für Wissensaustausch, Kommunikationsmöglichkeiten und Innovation in Deiner Organisation. Ganz klasse sind firmeninterne, mehrtägige Barcamps
ohne vorgegebene Agenda, mit Mitarbeitern aus unterschiedlichen Bereichen.
Lightning Talks, also kurze, fünfzehnminütige Spontan-Vorträge, liefern punktuelle Impulse zu Themen, die bei Bedarf vertieft werden können.
Und lass Deine Entwickler in anderen Bereichen (zB Buchhaltung) hospitieren, und dort Arbeit erledigen. So bekommt der Entwickler ein besseres Bild von dem, was er
da gerade baut. Und wenn möglich, mach es auch umgekehrt. Damit die Stakeholder und „Bedarfsmelder“ besser verstehen, wie die Entwicklung arbeitet.

42. Warum Scrum nicht funktioniert?!
So, und warum funktioniert Scrum jetzt nicht, lieber Björn?
Nun, das wird Gegenstand eines weiteren, längeren Talks sein. Ich gebe Dir aber einen kleinen Sneak-Peak meiner Gedankenwelt zu diesem Thema …

43. Achtung: Nachdenken!
… doch Achtung: Nachdenken & Mitdenken ist in den folgenden Slides gefragt! Da sind ein paar provozierende Gedanken dabei, die Unruhe in Deinem Kopf stiften
wollen.

44. Aneinanderreihung von
Mini-Wasserfällen
Also: Scrum ist der Retter, weil das mit den großen Wasserfall-Projekten nicht funktioniert.
Ist Dir schon mal der Gedanke gekommen, dass Scrum oftmals von Unternehmen als eine Aneinanderreihung von Mini-Wasserfällen (im 14-Tage-Rhythmus) praktiziert
wird? ;-) Also alter Wein in neuen Schläuchen?

45. Planbarkeit des Sprints
vs
Flow + Liefern
Viele Organisationen optimieren in der Anwendung von Scrum auf die Plan- und Vorhersagbarkeit eines Sprints hin.
Aber geht es nicht eigentlich um etwas Anderes? Nämlich dass ein Team permanent lieferfähig ist, weil es „im Flow“ ist, und nicht nur alle 14 Tage etwas abliefert, was
vorher umständlich mit Hilfe von Planning Poker / Magic Estimation in ein 14-Tage-Kasterl eingepfercht wurde?
;-)

46. Optimierung auf
Velocity
Business Value?
Ich kenne viele Unternehmen, in denen die Velocity des Teams „optimiert“ wird. Jetzt, wo das Management nix mehr zu tun hat, weil das Dev-Team ja schon alles
übernimmt und entscheidet, wird den Managern langweilig. Also steuern und optimieren wir doch am besten die Velocity. Ist ja klar: die Velocity muss rauf!
Ach so… ja klar, viele Unternehmen kennen die „Business Value“ Metrik nicht. Oder meinen, die liegt immer bei „30kEUR“ und ist damit supersuperwichtig. Bei jedem
Work Item. Alles auf Prio 1!
Alles schon gesehen …

47. Gesehen: Optimierung
auf Einzel-Velocity
Alte Denke …
… a propos alles schon gesehen: es gibt auch Unternehmen, die Optimieren auf Velocity einzelner Team-Mitglieder.
Spätestens hier ist klar, dass mit alter Denke operiert und gehandelt wird. Obwohl es hier doch um das Gesamt-Team geht.

48. Kultur +
Handlungsweisen +
Haltung
!= Scrum
Scrum funktioniert also nicht. Und warum? Weil Kultur, Haltung und Handlungsweisen noch in einer „alten Denke“ in der Organisation verankert sind.
Oder anders ausgedrückt: Scrum und andere agile Methoden erfordern eine andere Herangehensweise und vor allem Geisteshaltung. Nur dann wirst Du Effekte aus der
Agilität für Dein Unternehmen verbuchen.
Und tatsächlich erfolgreich „auf der Welle der Unsicherheit“ in hoher Markt-Dynamik reiten können. Für die Gewinne von Morgen.

49. Q&A
Björn Schotte
https://slideshare.net/BjoernSchotte
bjoern.schotte@mayflower.de
0931 / 35965 - 15
@BjoernSchotte
Nun sind wir schon am Ende dieses Talks. Wenn Du ein oder zwei Ideen hast, wie Du deine Teams oder Organisation besser aufstellen kannst, um bessere Software
schneller zu entwickeln, dann hat sich dieser Talk für Dich gelohnt.
Was bleibt? Ich bin neugierig auf Deine Ansichten. Ich freue mich über Widerspruch, Kritik und Anmerkungen. Nur dann können wir voneinander lernen, und ich kann den
Talk weiter verbessern :-).
Daher freue ich mich auch, wenn Du dich bei mir meldest. Die Kontaktmöglichkeiten habe ich auf diesem Slide notiert.
Bis bald!