Problems logging in
Peter Fürst Ja-Sager: Die größte Bremse bei Innovationsprojekten
Klaus S. ist Gruppenleiter in der F&E eines mittelständischen Maschinenbauers. Er ist einer der Besten in seinem Fach. Dennoch ist sein Vorgesetzter mit ihm nicht zufrieden. Denn eine Kennzahl macht Sorgen: die Neuprodukt-Projekte, an denen Klaus beteiligt ist, haben eine durchschnittliche Time-to-Market von 48 Monaten. Aus einer Benchmarking-Studie weiß Klaus´ Vorgesetzter, dass ein wichtiger Mitbewerber im Durchschnitt nur etwa 36 Monate für eine Neuproduktentwicklung braucht. Die Zielvereinbarung für Klaus ist somit schnell definiert: seine Projekte müssen schneller werden - um mindestens 25%.
Klaus sieht sich nun mit einer Reihe von Herausforderungen konfrontiert:
• In seinen Augen arbeitet er bislang schon so gut und schnell wie möglich. Um deutlich schneller zu werden, müsste er die Qualität seiner Arbeit deutlich zurückschrauben. Aber das liegt gar nicht in seinem Naturell und wohl auch nicht im Interesse des Unternehmens.
• Einige der Projekte erfordern neue technische Lösungen, für welche die eine oder andere Lernschleife notwendig sein wird. Da ist es schwierig einen Zeitplan zu erstellen, auf den man sich verlassen kann. Ob die Entwicklungszeit verkürzt werden kann, lässt sich im Vorhinein nicht sagen.
• Grundsätzlich könnte er mehr Aufgaben an sein Team delegieren. Seine Teammitglieder sind jedoch alle noch ziemlich unerfahren, und Klaus hat ein besseres Gefühl, wenn er deren Projektarbeit überprüft. Das kostet Zeit.
Wie Klaus und sein Vorgesetzter diese Herausforderung weiter analysiert und gelöst haben, lesen Sie hier: http://www.five-is.com/innovationsprojekte-beschleunigen
Peter Fürst Agile Development: Das neue Silodenken
Viele Unternehmen haben begonnen, agile Methodik in der Neuprodukt-Entwicklung intensiv zu testen und breit zu implementieren. Mit großem Interesse verfolgen wir die kommunizierten Erkenntnisse und Diskussionen. Dabei beschleicht uns der Verdacht, dass die eine oder andere Umsetzung agilen Entwickelns ein Rückschritt in „altes“ Silodenken ist. Kann das denn sein?
Wir beziehen uns hier auf Berichte vornehmlich großer deutscher Unternehmen. Die eingesetzte Methodik baut meist auf SCRUM bzw. skalierenden Modellen wie LeSS, Scrum of Scrum oder SaFE auf.
Typische Spielregeln dieser Modelle sind:
• Der Product Owner (PO, in manchen Fällen auch ein Product Owner Team) definiert das Backlog für die Produktentwicklung. Der PO entscheidet, woran das bzw. die Entwicklungs-Teams in den Sprints arbeiten.
• Die agilen Entwicklungs-Teams sind meist interdisziplinäre Entwickler-Teams, sprich Teams mit Mitgliedern unterschiedlicher technischer Expertise (z.B. Mechanik, Elektronik, Software). Idealerweise gibt es keine Hierarchie innerhalb dieser Teams, um eine gute Voraussetzung für Selbstorganisation und Selbstverantwortung zu schaffen.
• Das Projekt ist in gleichmäßige Sprints getaktet. Die Entwicklungs-Teams agieren alle im gleichen Takt und nutzen die gleichen Werkzeuge (wie z.B. Kanban oder Standup Meetings).
• Die eingesetzten Methoden sehen eine kundenzentrierte Produktentwicklung vor, also eine Entwicklung, in welcher der Nutzen der Anwender im Fokus steht. Hierzu werden im Zuge eines Projekts mehrere Iterationen zum Kunden geplant (z.B. in jedem 5. Sprint).
• Agile Coaches unterstützen Product Owner und Linienmanager und begleiten die Entwicklungs-Teams bei der Einführung und Durchführung der neuen Vorgehensweise.
Die Agile Coaches berichten von zwei wesentlichen, positiven Veränderungen durch die neue Vorgehensweise:
 Die Transparenz in den Projekten nimmt deutlich zu. Es besteht eine sehr gute Übersicht, welche Teams und Personen an welchen Arbeitspaketen und Baugruppen gerade arbeiten und bis wann diese erledigt sein sollen. Dies ermöglicht eine bessere Koordination der Entwicklungsteams und auch der unterschiedlichen technischen Disziplinen untereinander.
 Die Teams erhalten im Rahmen der Sprints größere Entfaltungsspielräume. Durch regelmäßige Retrospektiven steigt die Qualität der Zusammenarbeit des Teams kontinuierlich an. Dies ermöglicht eine hohe Dynamik im Team und äußert sich in hoher Motivation der Teammitglieder.
Die geschilderten Spielregeln klingen einleuchtend, die berichteten positiven Effekte sind bereits durch Studien nachgewiesen. Wo orten wir also das Silodenken?
Aus der Innovationsmanagement-Forschung (u.a. durch Professor Robert G. Cooper) wissen wir, dass interdisziplinäre Projektteams zu den wichtigsten Erfolgsfaktoren für erfolgreiche Neuproduktentwicklung gehören. Gemeint ist damit die enge Zusammenarbeit von mindestens Produktmanagement/Marketing, Entwicklung und Produktion (ggf. zusätzlich noch Vertrieb, Supply Chain, Prozesstechnologie, Qualität, etc.).
Dieses Team aus Experten der wichtigsten Disziplinen ist gemeinsam für die erfolgreiche Entwicklung und Markteinführung der neuen Leistung verantwortlich – jedes einzelne Teammitglied für das gesamte Projekt und nicht nur für seinen Beitrag.
Ein entsprechendes Teamverständnis ist auch eine der wichtigsten Voraussetzungen für hohe Geschwindigkeit in Produktinnovationsprojekten.
In SCRUM bekommt das Produktmanagement die Rolle des Product Owners. Zunächst liegt es in seiner Verantwortung, ein Product Backlog aufzubauen. Hierzu ist dieser (hoffentlich) in direktem Kontakt mit Kunden bzw. Nutzern, um deren Bedürfnisse und Probleme möglichst im Detail zu verstehen und ein attraktives Werteversprechen zu definieren.
In der Folge vertritt der PO den Kunden gegenüber dem Entwicklungsteam. Er spricht „für den Kunden“, priorisiert die Kundennutzen und Features und diktiert somit die Projektinhalte. Dadurch wird Produktmanagement zum „Auftraggeber“ für das Entwicklungsteam und steht gefühlt über den Entwicklern.
Die Verantwortung eines Produktmanagers in der Rolle eines PO ist deutlich höher als in einem Entwicklungsteam, in dem alle Kernteam-Mitglieder für das Gesamtprojekt verantwortlich sind. Neben der Verantwortung steigen in SCRUM aber auch die negativen Folgen einer Fehleinschätzung durch die einzelne Person des Produktmanager.
Die Mitglieder des Entwicklungsteams in SCRUM haben meist nur direkten Kontakt mit dem „internen Kunden bzw. Stakeholder“. Somit sind alle Informationen und Vorgaben im Product Backlog bereits mindestens durch einen Wahrnehmungsfilter (nämlich den des Product Owners, im schlimmsten Fall durch weitere Filter der Key Accounts / Vertriebsmitarbeiter) gegangen. Es geht für die Entwickler die Möglichkeit verloren, die Anwendung und die vom Kunden kommunizierten Bedürfnisse und Probleme aus erster Hand zu verstehen und aus der Entwickler-Perspektive zu interpretieren. Ein fehlendes oder falsches Verständnis bei den Entwicklern führt aber möglicherweise zur Auswahl der falschen technischen Lösung …
Auch scheinen Fertigungstechniker, Produktions- und Supply Chain Mitarbeiter, etc. keinen „Stammplatz“ in den Entwicklungsteams zu haben. Diese werden gegen Ende des Entwicklungsprojekts eingebunden, und schließlich wird das Projekt dann an „Operations“ übergeben.
Wenn wir den Blick von den vielen hilfreichen und absolut sinnvollen Methoden aus SCRUM auf den übergeordneten Projektaufbau richten, stellen wir fest, dass dieser der Entwicklungspraxis der 80er Jahren gleicht: Produktmanagement schreibt ein Lastenheft (Backlog?), die Entwicklung erarbeitet ein Pflichtenheft und entwickelt einen Prototypen (Ergebnis der Entwicklungs-Teams), die Fertigungstechnik überführt es in die Produktion, welche dann die Fähigkeiten auf eine Serienproduktion hochskaliert, schließlich landet das Produkt beim Vertrieb und nach viel Geduld beim Kunden. Jede Projektphase wird von einer anderen Disziplin beherrscht und verantwortet – Silo für Silo. Diese Art der Projektabwicklung galt mit dem Aufkommen von Stage-Gate® Ende der 80er Jahre als langsam und veraltet.
Damit wollen wir keineswegs behaupten, dass agiles Entwickeln veraltet ist. Wir denken jedoch, dass der Fokus weniger auf den Werkzeugen und Methoden der Entwicklungs-Teams liegen sollte, als vielmehr auf der Frage, wie echte Interdisziplinarität mit gemeinsam getragener Verantwortung sichergestellt werden kann.
In einigen Unternehmen wird diese „echte“ Interdisziplinarität in einem Product Owner Team sichergestellt. Dieses erfüllt dann die Funktion des verantwortlichen Projektteams für das Neuproduktprojekt – von der Idee bis zur erfolgreichen Markteinführung, wie von Prof. Cooper beschrieben. Dieses Product Owner Team vergibt dann Entwicklungsaufgaben an Entwicklungs-Teams und steuert diese mit Hilfe des Product Backlog.
Dies wiederum bedeutet, dass der größere Hebel zur schnellen und erfolgreichen Umsetzung eines Neuproduktprojekts in Gestaltung, Arbeitsweise und Methoden des PO Teams liegt.
Die aktuelle Diskussion der agilen Methodik liegt aber nach wie vor beinahe ausschließlich bei den Entwicklungsteams.
Wenn Sie mehr über die neuesten Erkenntnisse und Erfahrungen von agilen Methoden in einem ganzheitlichen Innovationssystem erfahren wollen, empfehlen wir das Buch „Winning at New Products – 5th edition“. Oder Sie lassen sich die Inhalte des Buches vom Autor Prof. Robert G. Cooper persönlich erläutern und besuchen das Seminar zum Buch nahe Frankfurt am 23. und 24. April 2018. Weitere Informationen dazu finden Sie hier: http://www.five-is.com/thema/winning-at-new-products
Martin Stallmaier
Uijuijui da wurde in den beobachteten Produktentwicklungen entscheidendes übersehen bzw. mangelhaft umgesetzt.
Wenn die Entwicklungsexperten vom User-Feedback angeschnitten sind und zusätzlich in die Backlogerstellung nicht eingebunden wird ganz ganz viel Wirkung nicht generiert.
Peter Fürst Führen Ihre Gate-Kriterien zu objektiv beurteilbaren Ergebnissen?
An Gates wird anhand definierter Erfolgskriterien die Attraktivität eines Projektes evaluiert und ggf. Ressourcen der nächsten Phase freigegeben. Die Kriterien wurden in intensiven Studien von mehr als 2.000 Projekten aus über 400 Projekten identifiziert.
In den frühen Gates stehen den Gatekeepern meist eher vage Informationen zur Verfügung. In Gate 1 und 2 sind manche Kriterien möglicherweise noch nicht wirklich bewertbar, wie z.B. mögliche Wettbewerbsvorteile. Es sollte auch nicht zu früh im Projekt der Fokus auf wirtschaftliche Kalkulation gelegt werden, da die Annahmen in Stage 1 und oft auch noch in Stage 2 eher wunsch- als faktenbasiert sind und somit in die Irre leiten können.
Die Tabelle (Beitragsbild) ist eine grobe Orientierung, welche Kriterien in welchem Gate Anwendung finden sollten.
Eine ganz entscheidende Frage ist natürlich: Wie nutzen wir diese Kriterien? Der effizienteste Einsatz ist unserer Erfahrung nach in Form einer Scorecard in einem „physischen“ Gatemeeting.
Nach der Klärung, ob die notwendigen Informationen verfügbar sind, um eine gute Gate-Entscheidung treffen zu können, beurteilt jeder Gatekeeper für sich das Projekt entlang der Kriterien. Ob die Bewertungsskala hierbei 4-, 6-, 10- oder 100-teilig ist, spielt eine untergeordnete Rolle.
Der Moderator des Gatemeetings sammelt die Ergebnisse und stellt diese z.B. in einer Tabelle einander gegenüber. Er identifiziert jene Kriterien, deren Bewertung die größten Abweichungen erfahren haben und fordert die Gatekeeper auf, ihre unterschiedlichen Einschätzungen zu erläutern und diese dann zu diskutieren. Vielfach haben unterschiedliche Einschätzungen ihre Ursache in unterschiedlichem Verständnis des neuen Produkts. Die Diskussion hilft, das gemeinsame Bild des Produkts zu schärfen. Jene Kriterien bei denen die Bewertung mehr oder weniger einheitlich ist, werden gar nicht diskutiert. Dies spart unnötige Diskussionen und damit Zeit.
Es gibt nun die Möglichkeit, Spielregeln für den Durchschnittswert oder den Gesamtscore einer Bewertung zu definieren und einen Mindestwert für eine Go-Entscheidung festzulegen (z.B. > 65/100 Punkten = Go). Im deutschsprachigen Raum beobachten wir, dass die Nutzung der Scorecard mehr der Entscheidungsvorbereitung dient, der Score aber nicht direkt zu einer Entscheidung führt. Vor dem Hintergrund der Diskussion entscheiden die Gatekeeper über Go oder Stopp.
Unternehmen, die eine Scorecard mit den richtigen Kriterien auf diese Art nutzen,
• stellen sicher, dass alle Gatekeeper ein ähnliches Verständnis vom neuen Produkt haben und somit in die gleiche Richtung ziehen,
• überprüfen systematisch die wichtigsten Erfolgsfaktoren eines Innovationsprojekts und verhindern mit dem Vorgehen, dass in der Euphorie wichtige Faktoren übersehen werden,
• können Entscheidungen – insbesondere emotional schwierige Kill-Entscheidungen – transparent und nachvollziehbar erläutern und somit die Akzeptanz solcher Entscheidungen erhöhen.
• stellen sicher, dass alle Innovationsprojekte nach einem einheitlichen Raster bewertet werden und somit vergleichbar sind.
Wenn Sie mehr über Ihre Möglichkeiten zur Einschätzung der Erfolgswahrscheinlichkeit Ihrer Innovationsprojekten erfahren möchten, lesen Sie hier http://www.five-is.com/impulse/blog
Peter Fürst Alexander Kriegisch
+5 more comments
Last comment:
Peter Fürst
Für die Software-Entwicklung mag das richtig sein. Das Entwickeln neuer Hardware-Produkten (oder auch HW-SW-Kombinationen) ist jedoch etwas komplexer. Zunächst mal nehme man Personen unterschiedlicher Disziplinen. In den meisten Projekten spielen Produktmanager, Entwickler, Prozessentwickler, Fertigungsmitarbeiter, Supply Chain Mitarbeiter, Qualitätsmanager, und manch anderer eine wichtige Rolle.
Vielleicht mit Ausnahme der Entwickler hat jede der Personen auch noch ein Tagesgeschäft zu bewerkstelligen. An 100% Verfügbarkeit für ein Projekt ist also allein aus dieser Überlegung heraus nicht zu denken.
Zweitens füllen die meisten Projekte ein Full Time Equivalent einer speziellen Expertise nicht aus (z.B. Einkauf). Ein Teammitglied würde also einen wesentlichen Teil seiner Zeit mit Aufgaben verbringen, die nicht der Expertise und möglicherweise auch nicht Neigung einer Person entsprechend würde. Das hat dann mit Effizienz auch eher wenig zu tun.
Und drittens gibt es in Hardware-Entwicklungsprojekten Wartezeiten, die manchmal einfach nicht umgangen werden können. Ein Laborversuch dauert einfach mal ein paar Tage oder Bestellzeiten für eine Maschine sind von Extern vorgegeben. Es wäre wohl wenig effizient, wenn das Team derweilen Däumchen dreht oder Aktivitäten niedriger Priorität durchführt, die sich durch das Ergebnis des Versuchs möglicherweise als vollkommen sinnlos entpuppen.
Dass 100% dedicated Teams von Vorteil sind, stelle ich nicht in Frage - alleine die Praxis sieht heutzutage anders aus. Manche große Unternehmen setzen 100% Teams auf große Projekte an. Diese Projekte laufen dann mitunter außerhalb der klassischen Organisation und werden eher wie ein Start-up organisiert. Nichts desto trotz besteht für wahrscheinlich 95% der Innovationsprojekte diese Möglichkeit heute nicht.
Ich sehe aber auf der anderen Seite keinen Grund, diesen 95% der Projekten agile Prinzipien zu verweigern. Agile Stage-Gate ist ein Schritt das Beste aus zwei Welten zusammenzuführen. Jene Unternehmen, die dies bisher ausprobiert haben, berichten von sehr guten Resultaten.
Marco Kuhrmann Industrieanforderungen vs. Forschung im Softwaretest
Im Rahmen eines internationalen Forschungsprojekts wollen wir herausarbeiten, wo genau Diskrepanzen in der Forschung und in der industriellen Praxis zum Thema Softwaretest bestehen. Insbesondere geht es uns darum, herauszuarbeiten wie Praktiker Themen des Softwaretests gewichten und was sich Praktiker von der Forschung an konkreten Themen bzw. Unterstützung erwarten.
Die Umfrage is sehr kurz - man braucht max. 10 Minuten. Wir würden uns sehr über eine Rege Teilnahme und eine anschließende Diskussion freuen.
Link zur Umfrage: https://t.co/ETZXBCctNK
Vielen Dank, M. Kuhrmann

Moderators

Moderator details

About the group: Agile Methods

  • Founded: 03/11/2005
  • Members: 2.815
  • Visibility: open
  • Posts: 2.178
  • Comments: 646