Probleme beim Einloggen

Agile Talks

Wir wollen miteinander über Agilität reden, in Beiträgen und Events, in Erfahrungsberichten und gemeinsamer Diskussion.

Timo Ricky Möbes Lean oder Agile – eine Frage der Vorgehensweise
Erfahren Sie jetzt mehr zum Artikel kostenlos hier: http://bit.ly/2Htb2f9
Sollte man Agile für die Softwareentwicklung nutzen? Läuft Agile ganz anders ab als Lean? Für Anwender ist es wichtig, die Unterschiede und Gemeinsamkeiten zwischen Lean und Agile zu verstehen, um die korrekte Anwendung und eine effektive und effiziente Unternehmensorganisation zu erreichen.
Lesen Sie u.a. mehr zu folgenden Themen:
- Welches Toolkit für den erfolgreichen agilen Workflow?
- Historischer Rückblick auf Lean und Agile
- Gemeinsamkeiten und Unterschiede zwischen Lean und Agile
- Die Rolle des Kunden in der agilen Unternehmensorganisation
Nur für XING Mitglieder sichtbar A Risk-Driven Model for Agile Software Architecture
This article introduces the risk-driven model of architectural design. Its essential idea is that the effort you spend on designing your software architecture should be commensurate with the risks faced by your project.
Nina Bauer Forums Blog: “Learn to walk before you run”
“Learn to walk before you run”
Eine heute viel verwendete Metapher in Unternehmen und in der Geschäftssprache, welche laut Expertenschätzungen jedoch bereits im 15. Jahrhundert in Gebrauch war.
Folgen wir dieser Metapher, verdeutlichen und veranschaulichen wir diese Aussage, dann wird sie wohl kaum jemand anzweifeln. Selbstverständlich lernen wir erst das Laufen, bevor wir anfangen zu rennen. Oder gibt es doch vielleicht mir unbekannte Fälle von Babys, die eben noch um den Wohnzimmertisch krabbeln und im nächsten Moment aufstehen, zur Haustür rennen und dann nix wie los zum nächsten Spielplatz?
Wir tun das! Wir rennen nicht nur einfach los, wir sprinten sogar. Auch wenn jedem Einzelnen sicherlich bewusst ist, dass das nicht funktionieren kann und dass ein Sturz nicht zu vermeiden sein wird. Und trotzdem tun wir es, weil uns gesagt wird, dass wir das können. Alle können Agile und damit schneller, besser und effizienter werden. Agile ist ganz einfach. Genau das suggerieren viele Consulting Unternehmen, deren Portfolio sich ganz plötzlich um Agile Methoden jeglicher Art erweitert hat. Und wenn uns versprochen wird, dass auch wir nach einem zweitägigen Workshop lossprinten können, dann dürfen wir uns die Chance doch nicht entgehen lassen.
Blöderweise sitzen die meisten aber immernoch mitten auf ihrer Krabbeldecke und sind sich nicht einmal im Klaren darüber, dass mehr dazu gehört, als einfach aufzustehen und loszurennen. Wohin wollen wir denn überhaupt rennen? Rennen wir alle gleichzeitig los? Rennen wir alle im gleichen Tempo und müssen wir auf die langsamen Läufer warten? Ach ja, und Schuhe brauchen wir auch noch. Auf der Krabbeldecke waren die Socken bislang ja ausreichend.
Artikel, Blogs und Meinungen, in denen Agile nicht gerade positiv bewertet wird, sind mittlerweile viele im Netz zu finden. Wer selbst an einer Methode scheitert, oder beobachten kann, wie andere Unternehmen scheitern, der gerät sehr schnell in die Versuchung, der Methode selbst die Schuld daran zu geben. Die eigenen Fehler zu suchen ist oft schwierig und unangenehm. Und wenn es eh schon so viele Unternehmen gibt, die lossprinten und dann fallen … na dann ist es doch offensichtlich, dass es nicht an uns selbst liegen kann.
So simpel und logisch Agile auch sein mag, so hochkomplex kann dieses Denkweise auch sein. Zumindest für uns alle, die unflexible Prozesse und hierarchische Strukturen über Jahrzehnte hinweg gewohnt waren.
Wir müssen bereit sein, Agile zu erlernen. Schritt für Schritt und anfangs sicherlich noch ein wenig wacklig auf den Beinen. Und wenn wir das Laufen irgendwann gelernt haben und es zu einer unbewussten Handlung übergegangen ist – oder denken Sie noch bewusst übers Laufen nach? – dann können wir auch ganz bald rennen. Versprochen!
Herzliche Grüße
Nina Bauer
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
Peter Fürst Nina Bauer
+6 weitere Kommentare
Letzter Kommentar:
Nina Bauer Wiki Autoren gesucht
Herzliches Hallo an alle Gruppenmitglieder,
dasAgileForum ist gerade am Aufbau eines Wikis rund um das Thema Agile. Ich lade daher alle Interessierten dazu ein, uns mit Ihrem Wissen und Ihren Erfahrungen zu unterstützen und sich als Autor zu versuchen.
https://www.dasagileforum.de/t65f18-Wiki-Autoren-gesucht.html
Herzliche Grüße
Nina Bauer
http://www.dasagileforum.de

Events dieser Gruppe

Alle Events

Moderatoren

Infos zu den Moderatoren

Über die Gruppe "Agile Talks"

  • Gegründet: 31.10.2014
  • Mitglieder: 1.483
  • Sichtbarkeit: offen
  • Beiträge: 280
  • Kommentare: 93
  • Marktplatz-Beiträge: 5