Führungskräfteentwicklung für chinesische Manager europäischer Unternehmen in China: Grundlagen und Erfolgsfaktoren - Ein Erfahrungsbericht http://www.usp-d.com/whitepapers/managemententwicklung-in-china/
[PDF] Pressemitteilung: 2011: Krankenstand steigt in ersten drei Quartalen weiter - BKK Gesundheitsreport 2011 "Zukunft der Arbeit" erschienen
[http://www.lifepr.de?boxid=275243]
von Bernd Dieschburg
56 Folien (1. Kapitel kostenlos zum herunterladen)
Kurzbeschreibung:
Grundlagen des Zeitmanagements, Prioritätensetzung, Organisationsprinzipien, Planungsprinzipien, Effektive Delegation, Umgang mit Zeitdieben und Störgrößen
www.vortragsfolien.de
Führungskräfteentwicklung für chinesische Manager europäischer Unternehmen in China: Grundlagen und Erfolgsfaktoren - Ein Erfahrungsbericht http://www.usp-d.com/whitepapers/managemententwicklung-in-china/
[PDF] Pressemitteilung: 2011: Krankenstand steigt in ersten drei Quartalen weiter - BKK Gesundheitsreport 2011 "Zukunft der Arbeit" erschienen
[http://www.lifepr.de?boxid=275243]
von Bernd Dieschburg
56 Folien (1. Kapitel kostenlos zum herunterladen)
Kurzbeschreibung:
Grundlagen des Zeitmanagements, Prioritätensetzung, Organisationsprinzipien, Planungsprinzipien, Effektive Delegation, Umgang mit Zeitdieben und Störgrößen
www.vortragsfolien.de
Workshop in einem nicht vertriebsorientierten Team, das einen großen Auftrag mit einer Präsentation gewinnen wollte. Am konkreten Thema orientierte Arbeit an Auftritt, innerer Haltung, Argumentation. Und: Auftrag gewonnen!
http://www.kathrinkoehler.com/kathrinkoehler_wordpress/wp-content/uploads/2016/06/Trainerprofil-Kathrin-Koehler_2016.pdf
The document discusses the transition away from fixed titles and positions at one company. Over time, various teams experimented with different approaches, such as abolishing fixed team lead roles, allowing teams to select their own roles, and having employees sign a document renouncing their titles. By 2013, all teams were selecting and defining their own roles. This emergence of roles replaced the previous rigid structure with one that was more flexible and adapted to the needs of teams and individuals.
Migriert man noch mit dem Spotify-Modell den Monolithen zu MicroServices oder bedient die serverlose Architektur schon das IoT? Wieviele Inverse Conway-Maneuvres braucht man eigentlich, um die papiergetriebene Marketing-Abteilung crossfunktional zum Security-neurotischen Betriebsteam zu bekommen? Gute Ratschläge für die zukünftigen Anforderungen und E-Commerce-Architekturen gibt es viele - aber welche ergibt im eigenen Fall Sinn? Ein Versuch, etwas Klarheit und Übersicht zu schaffen, die konkurrierenden Strategien und ihre Voraussetzungen und Rahmenbedingungen vorzustellen und Wege aufzuzeigen, die passende Architektur zu finden.
DevOps is mainstream - at least the tools, the automation and the metrics. But what happened to DevOps Culture? Does it still matter? If yes - how do we achieve it?
Von flachen Hierarchien zur Networked Company, von losen Netzwerken zur Holacracy, von Managern zur Bossless Organization: IT-Unternehmen diskutieren zurzeit viele Begriffe aus dem NewWork-Umfeld. Warum springt gerade unsere Branche auf diese Konzepte an? Dreht sich alles um den Arbeitsmarkt und die Generation Y, oder reagieren wir auf steigende Komplexität und Dynamik? Welche Folgen hat das auf das Unternehmen und unsere Arbeit? Ein Bericht aus Theorie und Praxis, von Hypes, offensichtlichen und nicht offensichtlichen Fehlern.
Jeder von uns kennt sie – die alten PHP-Projekte, die vor vielen Jahren entstanden und heute noch eine wichtige Funktion im Unternehmen erfüllen. Und es gibt ebenso viele Ratschläge, mit diesen Applikationen umzugehen: Tests und Continuous Deployment einführen. Kompatibel zu Symfony2 machen oder gleich dahin portieren – oder doch lieber Laravel? Domain-driven Design und Microservices nutzen, durch Node.js, Go, Rust ersetzen. Der Talk zeigt, welche Optionen man hat, welche Probleme sie jeweils mit sich bringen und wie man sich entscheiden kann.
Von der Governance-getriebenen Architektur der IT-Entscheider und Architecture Boards kamen wir zur emergenten, teambestimmten Architektur, und von dort über Strategien wie MicroServices zu Organisationsformen, die wir frei anhand unserer Wunscharchitektur definieren. Im Gegensatz zu den sich immer weiter beschleunigenden Architektur- und Technologietrends bewegen sich Team- und Abteilungsstrukturen mit ihrer eigenen Geschwindigkeit - und manchmal auch gar nicht. Ein Bericht aus der Praxis, vom Planen, Scheitern, Lernen und demütiger Architektur.
Die Diskussion über New Work findet meist entlang der Perks und der Autonomie der Kollegen statt. Aber lässt sich damit alleine Effizienz, Effektivität, Innovation und Adaptionsfähigkeit verbessern? Wie aligne ich die Firma, wenn die Kollegen und ihre Teams autonom arbeiten? Muss ich meine Organisationsform ändern? Scheitere ich an meiner Firmenkultur oder meinen Managern? Ein Bericht aus zehn Jahren Theorie und eigener Praxis.
Die großen Consultancies nennen es "Digitale Transformation", Marc Andreessen nennt es "Software eats the World". Eher aus Versehen haben wir IT-ler mit Unix und Internet etwas angestoßen, dass die ganze Wirtschaft - von Handel über Organisationsdesign bis zum Management - durch den Wolf dreht. Mit den Unternehmen schlägt das jetzt wieder auf die Systemadministratoren zurück, und stellt deren Rollen und Positionen in Frage. Im Gegensatz zu den Managern wird es aber vermutlich auch in Zukunft noch relevante Aufgaben für Administratoren geben.
Liquide Rollen statt fixer Positionen
- Warum klassische Positionen –inklusive Führungspositionen – Schaden anrichten
- Wie eine liquide Rollenverteilung in der Praxis aussieht
- Welche Vorrausetzungen braucht es, wie organisiert man Führung und Karriere
Seit 2009 ist DevOps ein wichtiges Thema auf den IT-Konferenzen, und inzwischen empfehlen auch die großen Beratungshäuser eine DevOps-Strategie. Doch während sich die Tools hoher Popularität erfreuen und Quasistandard wurden, sind Kultur und Organisationsdesign auf der Strecke geblieben. Die Tools alleine realisieren nur einen kleinen Teil des Benefits von DevOps, der große Vorteil entsteht erst mit der Integration von DevOps-Struktur, Organisation und Kultur im Unternehmen zu bekommen. Wie breche ich Silos jenseits von Dev und Ops auf? Wie schaffe ich gemeinsame Ziele über die Abteilungsgrenzen hinaus? Wie mache ich eine verlässliche Testphase bei einem Deploy am Tag? Welche Strukturen von heute stehen DevOps im Weg?
In der Softwareentwicklung sind wir schon lange agil, und die Operations-Leute arbeiten mit uns in DevOps-Manier zusammen. Eventuell ist das Product Development nach Lean Startup mit uns verzahnt, und mit viel Glück hat mein Chef eine Management 3.0-Schulung besucht. Trotzdem gibt es noch immer Politik im Unternehmen. Manche Kollegen übernehmen keine Verantwortung. Es gibt Teams oder Abteilungen, die nur eigene Ziele verfolgen und nicht mit anderen kooperieren. Und, ganz ehrlich, eigentlich sollten wir manche Dinge ganz anders machen, aber niemand kümmert sich so richtig darum. Aber wie repariere ich meine Firmenkultur? Wie sorge ich dafür, dass endlich alle mitarbeiten und Verantwortung übernehmen?
Wenn ITler Verträge machen steht der Schutz des eigenen Hinterteils im Vordergrund, und in Wahrheit versteht keiner die Konsequenzen des geschriebenen. Am Ende wird er ohnehin nichtig und durch einen Vergleich ersetzt, bei dem Anwälte das Bauchgefühl der Mandanten verhandeln, um nicht bei einem vollständig sachfremden Richter ein blaues Wunder zu erleben. Aber was hilft dann, wenn der Inhalt eines Projektes erst am Ende wirklich feststeht, und die meisten schwierigen Fragen sich erst im Verlauf ergeben?
Zappos uses Holacracy with elected team representatives instead of team leads. Netflix says "Hard work is not relevant" and discourages process adherence. Teams at Facebook have every freedom to do whatever they want as long as they have "impact" with their work. Things like management by objectives, strategic goals, matrix or line organisations are discarded.
Why are they doing that? What does that mean for your startup when it reaches the magic upper limit of "it just works" at 35-50 people? Is there a blueprint for a better way? And if you already ended up in a line organisation with management by objectives etc, what would be the benefit of change?
Workshop in einem nicht vertriebsorientierten Team, das einen großen Auftrag mit einer Präsentation gewinnen wollte. Am konkreten Thema orientierte Arbeit an Auftritt, innerer Haltung, Argumentation. Und: Auftrag gewonnen!
http://www.kathrinkoehler.com/kathrinkoehler_wordpress/wp-content/uploads/2016/06/Trainerprofil-Kathrin-Koehler_2016.pdf
The document discusses the transition away from fixed titles and positions at one company. Over time, various teams experimented with different approaches, such as abolishing fixed team lead roles, allowing teams to select their own roles, and having employees sign a document renouncing their titles. By 2013, all teams were selecting and defining their own roles. This emergence of roles replaced the previous rigid structure with one that was more flexible and adapted to the needs of teams and individuals.
Migriert man noch mit dem Spotify-Modell den Monolithen zu MicroServices oder bedient die serverlose Architektur schon das IoT? Wieviele Inverse Conway-Maneuvres braucht man eigentlich, um die papiergetriebene Marketing-Abteilung crossfunktional zum Security-neurotischen Betriebsteam zu bekommen? Gute Ratschläge für die zukünftigen Anforderungen und E-Commerce-Architekturen gibt es viele - aber welche ergibt im eigenen Fall Sinn? Ein Versuch, etwas Klarheit und Übersicht zu schaffen, die konkurrierenden Strategien und ihre Voraussetzungen und Rahmenbedingungen vorzustellen und Wege aufzuzeigen, die passende Architektur zu finden.
DevOps is mainstream - at least the tools, the automation and the metrics. But what happened to DevOps Culture? Does it still matter? If yes - how do we achieve it?
Von flachen Hierarchien zur Networked Company, von losen Netzwerken zur Holacracy, von Managern zur Bossless Organization: IT-Unternehmen diskutieren zurzeit viele Begriffe aus dem NewWork-Umfeld. Warum springt gerade unsere Branche auf diese Konzepte an? Dreht sich alles um den Arbeitsmarkt und die Generation Y, oder reagieren wir auf steigende Komplexität und Dynamik? Welche Folgen hat das auf das Unternehmen und unsere Arbeit? Ein Bericht aus Theorie und Praxis, von Hypes, offensichtlichen und nicht offensichtlichen Fehlern.
Jeder von uns kennt sie – die alten PHP-Projekte, die vor vielen Jahren entstanden und heute noch eine wichtige Funktion im Unternehmen erfüllen. Und es gibt ebenso viele Ratschläge, mit diesen Applikationen umzugehen: Tests und Continuous Deployment einführen. Kompatibel zu Symfony2 machen oder gleich dahin portieren – oder doch lieber Laravel? Domain-driven Design und Microservices nutzen, durch Node.js, Go, Rust ersetzen. Der Talk zeigt, welche Optionen man hat, welche Probleme sie jeweils mit sich bringen und wie man sich entscheiden kann.
Von der Governance-getriebenen Architektur der IT-Entscheider und Architecture Boards kamen wir zur emergenten, teambestimmten Architektur, und von dort über Strategien wie MicroServices zu Organisationsformen, die wir frei anhand unserer Wunscharchitektur definieren. Im Gegensatz zu den sich immer weiter beschleunigenden Architektur- und Technologietrends bewegen sich Team- und Abteilungsstrukturen mit ihrer eigenen Geschwindigkeit - und manchmal auch gar nicht. Ein Bericht aus der Praxis, vom Planen, Scheitern, Lernen und demütiger Architektur.
Die Diskussion über New Work findet meist entlang der Perks und der Autonomie der Kollegen statt. Aber lässt sich damit alleine Effizienz, Effektivität, Innovation und Adaptionsfähigkeit verbessern? Wie aligne ich die Firma, wenn die Kollegen und ihre Teams autonom arbeiten? Muss ich meine Organisationsform ändern? Scheitere ich an meiner Firmenkultur oder meinen Managern? Ein Bericht aus zehn Jahren Theorie und eigener Praxis.
Die großen Consultancies nennen es "Digitale Transformation", Marc Andreessen nennt es "Software eats the World". Eher aus Versehen haben wir IT-ler mit Unix und Internet etwas angestoßen, dass die ganze Wirtschaft - von Handel über Organisationsdesign bis zum Management - durch den Wolf dreht. Mit den Unternehmen schlägt das jetzt wieder auf die Systemadministratoren zurück, und stellt deren Rollen und Positionen in Frage. Im Gegensatz zu den Managern wird es aber vermutlich auch in Zukunft noch relevante Aufgaben für Administratoren geben.
Liquide Rollen statt fixer Positionen
- Warum klassische Positionen –inklusive Führungspositionen – Schaden anrichten
- Wie eine liquide Rollenverteilung in der Praxis aussieht
- Welche Vorrausetzungen braucht es, wie organisiert man Führung und Karriere
Seit 2009 ist DevOps ein wichtiges Thema auf den IT-Konferenzen, und inzwischen empfehlen auch die großen Beratungshäuser eine DevOps-Strategie. Doch während sich die Tools hoher Popularität erfreuen und Quasistandard wurden, sind Kultur und Organisationsdesign auf der Strecke geblieben. Die Tools alleine realisieren nur einen kleinen Teil des Benefits von DevOps, der große Vorteil entsteht erst mit der Integration von DevOps-Struktur, Organisation und Kultur im Unternehmen zu bekommen. Wie breche ich Silos jenseits von Dev und Ops auf? Wie schaffe ich gemeinsame Ziele über die Abteilungsgrenzen hinaus? Wie mache ich eine verlässliche Testphase bei einem Deploy am Tag? Welche Strukturen von heute stehen DevOps im Weg?
In der Softwareentwicklung sind wir schon lange agil, und die Operations-Leute arbeiten mit uns in DevOps-Manier zusammen. Eventuell ist das Product Development nach Lean Startup mit uns verzahnt, und mit viel Glück hat mein Chef eine Management 3.0-Schulung besucht. Trotzdem gibt es noch immer Politik im Unternehmen. Manche Kollegen übernehmen keine Verantwortung. Es gibt Teams oder Abteilungen, die nur eigene Ziele verfolgen und nicht mit anderen kooperieren. Und, ganz ehrlich, eigentlich sollten wir manche Dinge ganz anders machen, aber niemand kümmert sich so richtig darum. Aber wie repariere ich meine Firmenkultur? Wie sorge ich dafür, dass endlich alle mitarbeiten und Verantwortung übernehmen?
Wenn ITler Verträge machen steht der Schutz des eigenen Hinterteils im Vordergrund, und in Wahrheit versteht keiner die Konsequenzen des geschriebenen. Am Ende wird er ohnehin nichtig und durch einen Vergleich ersetzt, bei dem Anwälte das Bauchgefühl der Mandanten verhandeln, um nicht bei einem vollständig sachfremden Richter ein blaues Wunder zu erleben. Aber was hilft dann, wenn der Inhalt eines Projektes erst am Ende wirklich feststeht, und die meisten schwierigen Fragen sich erst im Verlauf ergeben?
Zappos uses Holacracy with elected team representatives instead of team leads. Netflix says "Hard work is not relevant" and discourages process adherence. Teams at Facebook have every freedom to do whatever they want as long as they have "impact" with their work. Things like management by objectives, strategic goals, matrix or line organisations are discarded.
Why are they doing that? What does that mean for your startup when it reaches the magic upper limit of "it just works" at 35-50 people? Is there a blueprint for a better way? And if you already ended up in a line organisation with management by objectives etc, what would be the benefit of change?
Keiner glaubt mehr an die Versprechen aus der IT, weder Druck, Motivation noch ein grösseres Team bringen auch nur etwas Performance. Es gibt viele Fehler in der Software und die Fluktuation geht nach oben. Wie fängt man so ein Projekt ein? Eine Geschichte von den offensichtlichen und nicht so offensichtlichen Dingen, die man dabei berücksichtigen muss - aus dem echten Leben erzählt.
Die modernisierte Fassung der "Management Brainfucks": Warum wehren sich Manager gegen agile Methoden, obwohl diese zu ihrem Vorteil wären? Warum behindern sie uns Entwickler bei der Arbeit mit Formalien, Blaming, naiven Lösungsvorschlägen und Kontrollillusion? Der Talk zeigt die Wurzeln dieses Missverständnisses und wie man sich darausbewegt.
Wer als Entwickler Führungskraft werden möchte - oder noch schlimmer - von anderen dazu erklärt wird, hat einen langen und schmerzhaften Weg vor sich. Und die Erfolgsquote, das belegen die eigenen Vorgesetzten jeden Tag, ist nicht hoch. Viele gute Pläne und logische Schlussfolgerungen funktionieren in der Praxis nicht mehr, und die kollegiale Unterstützung wird durch Politik ersetzt. Wir erzählen nicht nur unsere Geschichte, sondern auch darüber was heute als gute Führung gilt.
Wer als Entwickler Führungskraft werden möchte - oder noch schlimmer - von anderen zu erklärt wird, hat einen langen und schmerzhaften Weg vor sich. Und die Erfolgsquote, das belegen die eigenen Vorgesetzten jeden Tag, ist nicht hoch. Viele gute Pläne und logische Schlussfolgerungen funktionieren in der Praxis nicht mehr, und die kollegiale Unterstützung wird durch Politik ersetzt. Die schönsten instinktiven Fehler, die besten Katastrophen nach Lehrbuch und Methode werden von jemanden vorgestellt, der sie schon alle gemacht hat.
iele Applikationen sind über Jahre erfolgreich gewesen und haben jede Änderung mitgemacht - und sind in Folge unwartbar geworden, und entsprechen längst nicht mehr aktuellen Standards. Doch um weiter am Markt zu bestehen muss man schnell agieren können, also braucht es einen Rewrite auf ein modernes Framework. Aber Rewrites schlagen häufig durch jede Deadline oder ganz fehl, und während des Rewrites muss man auf die Konkurrenz reagieren können. Die Lösung ist ein Continuous Rewrite, der mit der alten Lösung beginnt und bei kontinuierlicher Nutzung mit der neuen Lösung endet. Wir stellen Methoden und Praxiserfahrungen vor.
IT und Management geht wenig bis gar nicht. Und schuld ist Komplexität. Denn IT lebt Komplexität, und klassisches, tayloristisch geprägtes Management weiss nicht, wie es damit umgehen soll. Also wird man sich nicht einig, und die offizielle Welt löst sich völlig von der inoffiziellen, die die Arbeit macht. Warum ist das so?
2. ? Tage von der Idee bis zur Produktion
nextdoor.fi
Schnelle Geschäfte I Mayflower GmbH I 201 I
1
Montag, 25. Juli 2011
3. Ship ? times a day.
Eric Ries, imvu.com, The Lean Startup
Schnelle Geschäfte I Mayflower GmbH I 201 I
1
Montag, 25. Juli 2011
4. Move fast and break things.
Facebook Engineering Welcome
Schnelle Geschäfte I Mayflower GmbH I 201 I
1
Montag, 25. Juli 2011
5. Move fast and break things.
Facebook Engineering Welcome
Schnelle Geschäfte I Mayflower GmbH I 201 I
1
Montag, 25. Juli 2011
6. „I believe the best way to convince Zuck that
something is a bad idea is to build it and let
him use it.“ Facebook, Working with Zuck
Schnelle Geschäfte I Mayflower GmbH I 201 I
1
Montag, 25. Juli 2011
7. „We take an approach to make changes to
what users are saying and adapting to what
they are saying; testing things in the real world
and getting their Feedback.“
Zynga Quality Engineering
Schnelle Geschäfte I Mayflower GmbH I 201 I
1
Montag, 25. Juli 2011
8. Nutzungshäufigkeit von vorhandenen Features
36%
45%
19%
Standish Group Chaos Report 2002
Schnelle Geschäfte I Mayflower GmbH I 201 I
1
Montag, 25. Juli 2011
9. Nutzungshäufigkeit von vorhandenen Features
Nie Selten Gelegentlich bis häufig
36%
45%
19%
Standish Group Chaos Report 2002
Schnelle Geschäfte I Mayflower GmbH I 201 I
1
Montag, 25. Juli 2011
14. Die eigene
Fachabteilung
Schnelle Geschäfte I Mayflower GmbH I 201 I
1
Montag, 25. Juli 2011
15. Wasserfall:
Wir kennen das Problem,
wir kennen die Lösung
Schnelle Geschäfte I Mayflower GmbH I 201 I
1
Montag, 25. Juli 2011
16. Agile:
Wir kennen das Problem,
wir kennen die Lösung noch nicht.
Schnelle Geschäfte I Mayflower GmbH I 201 I
1
Montag, 25. Juli 2011
17. Lean Startup:
Wir kennen das Problem noch nicht,
wir kennen die Lösung noch nicht.
Schnelle Geschäfte I Mayflower GmbH I 201 I
1
Montag, 25. Juli 2011
18. Lean Startup:
Wir kennen das Problem noch nicht,
wir kennen die Lösung noch nicht.
Schnelle Geschäfte I Mayflower GmbH I 201 I
1
Montag, 25. Juli 2011
21. Kanban
Interal & A/B-Testing,
Kunden- Themen Feature Review & Develop-
External Business Rollout
analyse Definition Definition Story Points ment
Testing Monitoring
Schnelle Geschäfte I Mayflower GmbH I 201 I
1
Montag, 25. Juli 2011
22. Interal & A/B-Testing,
Kunden- Themen Feature Review & Develop-
External Business Rollout
analyse Definition Definition Story Points ment
Testing Monitoring
•Regelmässige Nutzertreffen
•Feature Voting
•Nutzer-Feedback
•Business-Metriken
•Wettbewerberanalyse
•internes Brainstorming
•Development
Schnelle Geschäfte I Mayflower GmbH I 201 I
1
Montag, 25. Juli 2011
23. Interal & A/B-Testing,
Kunden- Epic Feature Review & Develop-
External Business Rollout
analyse Definition Definition Story Points ment
Testing Monitoring
•Kondensierung
•Epics
•Bewertung
Schnelle Geschäfte I Mayflower GmbH I 201 I
1
Montag, 25. Juli 2011
24. Interal & A/B-Testing,
Kunden- Epic Feature Review & Develop-
External Business Rollout
analyse Definition Definition Story Points ment
Testing Monitoring
•User Stories
•„Mininum Marketable Features“
•Akzeptanzkriterien
•Readyness
•Erwartete Wirkung auf Business-Metriken
Schnelle Geschäfte I Mayflower GmbH I 201 I
1
Montag, 25. Juli 2011
25. Interal & A/B-Testing,
Kunden- Themen Feature Review & Develop-
External Business Rollout
analyse Definition Definition Story Points ment
Testing Monitoring
•Machbarkeit und Abhängigkeiten
•Story Point Schätzung durch das Development
•Verfeinerung der Anforderungen
•erwarteter Business impact
•Priorisierung
Schnelle Geschäfte I Mayflower GmbH I 201 I
1
Montag, 25. Juli 2011
26. Interal & A/B-Testing,
Kunden- Themen Feature Review & Develop-
External Business Rollout
analyse Definition Definition Story Points ment
Testing Monitoring
•Bearbeitung nach Priorität
•Realisierung über Feature Flags
•Definition of Done
•Minimum Marketable Featureset
Schnelle Geschäfte I Mayflower GmbH I 201 I
1
Montag, 25. Juli 2011
27. Interal & A/B-Testing,
Kunden- Themen Feature Review & Develop-
External Business Rollout
analyse Definition Definition Story Points ment
Testing Monitoring
•internal Review
•internal Usability Testing
•external Usability Testing
•Customer Review
Schnelle Geschäfte I Mayflower GmbH I 201 I
1
Montag, 25. Juli 2011
28. Interal & A/B-Testing,
Kunden- Themen Feature Review & Develop-
External Business Rollout
analyse Definition Definition Story Points ment
Testing Monitoring
•Teilrollout in Produktion
•A/B-Testing
•Realtime Business Monitoring
•vollautomatischer Rollout / Rollback
Schnelle Geschäfte I Mayflower GmbH I 201 I
1
Montag, 25. Juli 2011
29. Interal & A/B-Testing,
Kunden- Themen Feature Review & Develop-
External Business Rollout
analyse Definition Definition Story Points ment
Testing Monitoring
•Voller Rollout bei Erfolg
•Modifikation des Features
•Verwerfen des Features
•Reduzieren von „Feature-Waste“
Schnelle Geschäfte I Mayflower GmbH I 201 I
1
Montag, 25. Juli 2011
30. Vorraussetzungen
• Funktionierender agiler Prozess
Schnelle Geschäfte I Mayflower GmbH I 201 I
1
Montag, 25. Juli 2011
31. Vorraussetzungen
• Funktionierender agiler Prozess
• Umstellung auf Kanban
Schnelle Geschäfte I Mayflower GmbH I 201 I
1
Montag, 25. Juli 2011
32. Vorraussetzungen
• Funktionierender agiler Prozess
• Umstellung auf Kanban
• schnelles Product / Customer Development
Schnelle Geschäfte I Mayflower GmbH I 201 I
1
Montag, 25. Juli 2011
33. Vorraussetzungen
• Funktionierender agiler Prozess
• Umstellung auf Kanban
• schnelles Product / Customer Development
• gutes Requirements-Management
Schnelle Geschäfte I Mayflower GmbH I 201 I
1
Montag, 25. Juli 2011
34. Vorraussetzungen
• Funktionierender agiler Prozess
• Umstellung auf Kanban
• schnelles Product / Customer Development
• gutes Requirements-Management
• Continuous Deployment-Infrastruktur
Schnelle Geschäfte I Mayflower GmbH I 201 I
1
Montag, 25. Juli 2011
35. Vorraussetzungen
• Funktionierender agiler Prozess
• Umstellung auf Kanban
• schnelles Product / Customer Development
• gutes Requirements-Management
• Continuous Deployment-Infrastruktur
• mächtiges Realtime Business Monitoring
Schnelle Geschäfte I Mayflower GmbH I 201 I
1
Montag, 25. Juli 2011
36. KPIs des Lean Startup
• Kanban Gesamtlaufzeit
Schnelle Geschäfte I Mayflower GmbH I 201 I
1
Montag, 25. Juli 2011
37. KPIs des Lean Startup
• Kanban Gesamtlaufzeit
• Feature Definition Cycle Time
Schnelle Geschäfte I Mayflower GmbH I 201 I
1
Montag, 25. Juli 2011
38. KPIs des Lean Startup
• Kanban Gesamtlaufzeit
• Feature Definition Cycle Time
• Feature Implementation Cycle Time
Schnelle Geschäfte I Mayflower GmbH I 201 I
1
Montag, 25. Juli 2011
39. KPIs des Lean Startup
• Kanban Gesamtlaufzeit
• Feature Definition Cycle Time
• Feature Implementation Cycle Time
• Anzahl Defekte
Schnelle Geschäfte I Mayflower GmbH I 201 I
1
Montag, 25. Juli 2011
40. KPIs des Lean Startup
• Kanban Gesamtlaufzeit
• Feature Definition Cycle Time
• Feature Implementation Cycle Time
• Anzahl Defekte
• Anteil Waste
Schnelle Geschäfte I Mayflower GmbH I 201 I
1
Montag, 25. Juli 2011
41. Tricks, Facebook
Schnelle Geschäfte I Mayflower GmbH I 201 I
1
Montag, 25. Juli 2011
42. Tricks, Facebook
• Productmanager pitchen Developer
Schnelle Geschäfte I Mayflower GmbH I 201 I
1
Montag, 25. Juli 2011
43. Tricks, Facebook
• Productmanager pitchen Developer
• Developer muss den Rollout begleiten
Schnelle Geschäfte I Mayflower GmbH I 201 I
1
Montag, 25. Juli 2011
44. Tricks, Facebook
• Productmanager pitchen Developer
• Developer muss den Rollout begleiten
• Developer betreut Feature vollständig
Schnelle Geschäfte I Mayflower GmbH I 201 I
1
Montag, 25. Juli 2011
45. Tricks, Facebook
• Productmanager pitchen Developer
• Developer muss den Rollout begleiten
• Developer betreut Feature vollständig
• Reputation = erfolgreiche Features
Schnelle Geschäfte I Mayflower GmbH I 201 I
1
Montag, 25. Juli 2011
46. Vielen Dank für Ihre Aufmerksamkeit!
Kontakt Johann-Peter Hartmann
johann-peter.hartmann@mayflower.de
089 24 20 54 13
Schnelle Geschäfte I Mayflower GmbH I 201 I
1
Montag, 25. Juli 2011
48. Functional Questions: „How would you feel if the product
had feature X?“
Dynfunctional Question: „How would you feel if the product
didn‘t have feature X?“
Schnelle Geschäfte I Mayflower GmbH I 201 I
1
Montag, 25. Juli 2011
49. (Relative Benefit + Relative Penalty) % of all
(Relative Costs) in % of all
Schnelle Geschäfte I Mayflower GmbH I 201 I
1
Montag, 25. Juli 2011
50. Relative Relative Total
Feature Value % Estimate Cost % Priority
Benefit Penalty Value
Graph Event Times 8 6 14 42 32 53 0,79
Can upload photos 9 2 11 33 21 34 0,97
Post autobiographical profile 3 5 8 25 8 13 1,92
Total 20 13 33 100 61 100
Schnelle Geschäfte I Mayflower GmbH I 201 I
1
Montag, 25. Juli 2011
51. Todos bei der Einführung von Lean Startup
• Readyness Kriterium bei fertigen Stories
• Feedback aus Development zu Story
• Selenium-Testinfrastruktur für Produktion
• Generell Stabilität der Plattform
• Kommunikationsinfrastruktur
Schnelle Geschäfte I Mayflower GmbH I 201 I
1
Montag, 25. Juli 2011