Probleme beim Einloggen

Agiles Produkt- und Projektmanagement mit Scrum und Kanban

Alles rund um die Produktentwicklung und das Projektmanagement mit Scrum und Kanban.

Michael Schenkel Die Verschiebung von Systemgrenzen
Der Systemkontext beschreibt die Interaktion eines Systems mit seiner Umgebung. Für ein zu entwickelndes System ist die Betrachtung des Systemkontexts wichtig, denn mit der Festlegung von System und Systemgrenze, sowie relevanter und irrelevanter Systemumgebung definieren Sie, welche Aspekte im Rahmen einer Entwicklung zu beachten sind. Unter https://t2informatik.de/wissen-kompakt/systemkontext/ finden Sie alles Wichtige zum Systemkontext auf einen Blick.
In der Praxis stehen aber häufig nicht alle Informationen zur Bestimmung von Systemgrenzen zur Verfügung oder notwendige Managemententscheidungen werden nicht getroffen. Haben Sie Erfahrungen gesammelt, was bei der nachträglichen Verschiebung von Systemgrenzen passiert? Wie würden Sie diese Verschiebung managen? Über Meinungen und Erfahrungen würde ich mich sehr freuen.
Sonnige Grüße aus Berlin
Michael Schenkel
Stefan Wolpers Checklisten für Agile Praktiken?
Sind Checklisten ein Sakrileg am “Mindset” agiler Methoden? Oder sind diese eine brauche Erleichterung, wenn mit Bedacht genutzt?
Nur für XING Mitglieder sichtbar Agile@Hardware
Unsere Ergebnisse zu den tatsächlichen Effekten agiler Hardware Entwicklung sind nun online! #AgileHardwareDev #AgileMunich http://go.unibw.de/agile
Peter Fürst Agiles 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
Franz Fischer Agilität und Qualitätsmanagement 900x
Es gibt ja einerseits agile Methoden, Verfahren, Projekte und wahrscheinlich auch agile Unternehmen. Andererseits, gibt es auch agile Unternehmen, die sich in den letzten 3-5 Jahren einer QM Zertifizierung in Österreich erfolgreich gestellt haben?
Solche Erfahrungen würden mich interessieren. Sind soclche Unternehmen mit der Zertifizierung in ihren täglichen Konsequenzen zufrieden oder existieren alternative Wege, Qualität in agilen Unternehmen nachzuweisen?
Für diesbzgl. Informationen/Kontakte wäre ich dankbar, da in meinem Unternehmen gerade der nächste Level im Projektmanagement in Bezug auf Agilität erreicht werden soll.
Beste Grüße
Franz Fischer

Moderatoren

Infos zu den Moderatoren

Über die Gruppe "Agiles Produkt- und Projektmanagement mit Scrum und Kanban"

  • Gegründet: 07.08.2008
  • Mitglieder: 6.949
  • Sichtbarkeit: offen
  • Beiträge: 3.387
  • Kommentare: 1.635
  • Marktplatz-Beiträge: 38