Agile Methoden wie Scrum in Nicht-Software-Entwicklungsprojekten

Es gibt zwei Hauptgrundsätze von Scrum, die es meiner Meinung nach definieren und Ihnen den Wert für jedes Projekt oder Produkt aufzeigen. Diese beiden sind: sich ändernde Anforderungen und iterative Releases.

Es gibt viele großartige Beiträge auf dieser Seite über Agile vs. Waterfall. Das Fazit ist, dass Waterfall erstaunlich ist, wenn Sie alle Anforderungen im Voraus sammeln können, und sie werden sich nicht viel ändern. Der schwierige Teil besteht darin, diese Anforderungen auf dem Papier richtig zu formulieren, bevor Sie sich an die Arbeit machen.

Dies bedeutet, dass Wasserfall sehr gut für Branchen wie Automobil, Gesundheitswesen, Luft- und Raumfahrt usw. geeignet wäre, in denen es einfacher ist, im Voraus zu klären, was genau Sie benötigen.

Andererseits sind iterative Releases sehr, sehr nützlich – selbst bei festen und unveränderlichen Anforderungen. Theoretisch könntest du das machen, aber ich sehe nicht, welchen Nutzen du daraus ziehen würdest.

Stattdessen würde ich mich auf einige andere nützliche Teile von Scrum konzentrieren, wie zum Beispiel:

• Schätzen von Aufgaben in vageren Einheiten (Story Points) statt Zeit – wenn die Anforderungen unbekannt sind und/oder sich ändern.
• Aufteilen der Arbeit in kleine Einheiten, die in ein oder zwei Wochen oder weniger abgeschlossen werden können.
• Tägliche Kommunikation im gesamten Team, um zu sagen: „Hier ist, was ich gestern getan habe, was ich heute tun werde und wo ich hängengeblieben bin.“

Ihr Kilometerstand kann variieren. Ich würde sagen, schauen Sie sich Scrum/Agile an und beginnen Sie mit den Praktiken, von denen Sie sehen können, dass sie Ihnen zugute kommen.

Ken Schwaber hat tatsächlich ein Buch mit dem Titel „ Agiles Projektmanagement mit Scrum“ veröffentlicht , das eine Reihe von Fallstudien in Branchen außerhalb der Softwareentwicklung durchführt.

Es ist durchaus möglich, agile Prinzipien und den Scrum-Prozess außerhalb von Software anzuwenden, und wird in einer Vielzahl von Umgebungen durchgeführt.

Die jüngste Scrum Beyond Software -Konferenz, die im September 2010 in Phoenix stattfand, untersuchte dieses Thema sehr detailliert in einem Open-Space-Format. Als Teilnehmer gehörte ich zu einer Reihe von Personen, die ihre Erfahrungen mit Scrum in verschiedenen Umgebungen, darunter Bildung, Marketing, Vertrieb und Behörden, austauschten. Ich habe persönlich eine Marketingorganisation darin gecoacht, das Scrum-Framework für ihre Kampagnenplanung und -implementierung anzuwenden, und kenne mindestens ein Vertriebsteam, das Scrum aktiv anwendet (und dabei Software-Projektmanagement-Tools effektiv einsetzt).

Außerdem sind mir persönlich zwei Sessions bekannt, die für die Agile 2011-Konferenz angenommen wurden und sich mit der Anwendung von Scrum über die Softwareentwicklung hinaus befassen. Das eine gilt für Scrum im Vertrieb und das andere für Agile in der Wissenschaft . Es mag viele andere geben, die ich nicht bemerkt habe.

(Anmerkung: Ich bin mir nicht sicher, ob diese Links nach Abschluss des Einreichungsprozesses für Agile 2011 Bestand haben. Da beide akzeptiert werden, werden die Erfahrungsberichte schließlich in den Tagungsbänden veröffentlicht, die von der IEEE herausgegeben werden.)

Dies ist derzeit eine ziemlich offene Frage, und ich denke, dass wir mit der Weiterentwicklung von Agile erwarten können, dass es außerhalb der Softwareentwicklungsumgebungen häufiger eingesetzt wird.

Siehe diese Diskussion für einen guten Schlag-für-Schlag: https://stackoverflow.com/questions/1702128/can-i-use-agile-in-a-non-development-project

Übrigens, ich werde pedantisch sein: Scrum ist ein agiles Werkzeug. Außerdem wurde Agile für Softwareprojekte entwickelt - es gibt keine Schwerpunktverlagerung, wie Sie vermuten.

Wenn Sie nach Agile außerhalb der Softwarebranche fragen, gehe ich auf die Arbeit von W. Edwards Deming in der Fertigung zurück. Eines seiner Grundprinzipien war der Plan-Do-Check-Act-Zyklus. AKA der Deming-Zyklus. Dieser Zyklus bildet zusammen mit seinen 14 Pints ​​und 7 Todsünden die Grundlage für einen Großteil des modernen Herstellungsprozesses und war der Schlüssel zur Wiedergeburt und zum Erfolg der Herstellung in Japan nach dem Zweiten Weltkrieg.

Mit der Betonung eines iterativen Prozesses und der Konzentration auf die Produktqualität anstelle der Qualitätssicherung nach der Produktion ist Demings Arbeit der logische Ausgangspunkt für die Anwendung von Agile außerhalb der Softwareentwicklung.

Indem Sie Demings Arbeit nehmen und ihr die agilen Prinzipien rund um Sprints, Geschwindigkeit, Häufigkeit und Retros hinzufügen, erhalten Sie einen funktionierenden Hybrid für Nicht-IT-Anwendungen. Sie erhalten zusätzlich 60 Jahre gesammelte Erfahrung in Herstellungsprozessen, die funktionieren.

Die meisten agilen Methoden sind Entwicklungsmethoden. Wenn Sie zum Beispiel Extreme Programming nehmen, ist es offensichtlich unmöglich, es in einer anderen Domäne als der Softwareentwicklung anzuwenden.

Scrum hingegen ist eine Möglichkeit, ein Projektteam zu organisieren. Es ist wirklich gut für Softwareentwicklungsteams geeignet, aber es gibt keinen Grund, warum es nicht für Projektteams in anderen Bereichen als der Softwareentwicklung geeignet wäre.

Bearbeiten: Ich habe gerade Jugaad entdeckt, was für Ihr Interesse relevant sein könnte. Werfen Sie einen Blick auf die offizielle Website: http://jugaadinnovation.com/

Es gibt auch ein Buch: http://www.wiley.com/WileyCDA/WileyTitle/productCd-1118249747.html

Jugaad ist eine Möglichkeit, Innovationen sparsam und agil zu betrachten.

Agile funktioniert am besten, wenn Sie in der komplexen Domäne arbeiten.

Das Cynefin Framework klassifiziert Projekte in vier Domänen: Einfach, kompliziert, komplex und chaotisch. Agile funktioniert am besten, wenn Sie in der komplexen Domäne arbeiten.

In der einfachen Domäne arbeiten Sie mit einem gut verstandenen Bereich und können ihn einfach abschließen, indem Sie eine Reihe von Regeln und Verfahren befolgen. Zum Beispiel wäre das Zusammenbauen von Ikea-Möbeln ein Projekt im einfachen Bereich; Sie folgen einfach den Anweisungen in der Box.

Im komplizierten Bereich haben Sie es mit bekannten Unbekannten zu tun, und Sie können ein Ergebnis erzielen, indem Sie herausfinden, was das ist, und sich dann an die Arbeit machen. Viel Ingenieursarbeit findet im Bereich „Kompliziert“ statt, und Wasserfall eignet sich gut für Projekte hier.

In der komplexen Domäne haben Sie es mit unbekannten Unbekannten zu tun, und Sie müssen in der Lage sein, Ihren Kurs flexibel zu ändern, um sich an sie anzupassen, weshalb Agile hier am besten funktioniert. Software-Engineering fällt meistens in diesen Bereich, weshalb Agile in diesem Bereich so beliebt ist, aber es ist auch für andere Projekte möglich, dies zu tun.

In der chaotischen Domäne haben Sie es mit einer Situation zu tun, in der Sie die Informationen nicht auf kohärente Weise erstellen können und handeln müssen, um Ordnung zu schaffen. Ein Beispiel wären Feuerwehrleute, die sich um ein brennendes Gebäude kümmern, oder Polizisten, die sich um einen Aufruhr kümmern.

Um Ihre eigentliche Frage zu beantworten, formulieren Sie sie einfach so um: Sind die Probleme in der Automobilindustrie komplex?

Abgesehen von der großartigen Antwort von Ashes999 gibt es eine weitere bemerkenswerte Erwähnung darüber, wie man Agile in Nicht-IT-Organisationen oder -Teams einführt. Ich mag den Teil sehr, in dem es darum geht, nicht alle Schlagworte zu verwenden und hauptsächlich aus der Perspektive der agilen Werte zu arbeiten.

Es gibt eine 5-Schritte-Methode gemäß diesem Beitrag: https://teamhood.com/agile/agile-for-non-it/

1. Menschen über agile Werte aufklären
2. Definieren Sie Rollen und Verantwortlichkeiten
3. Erstellen Sie ein zentralisiertes Work Backlog
4. Formen und üben Sie agile Gewohnheiten (Techniken/Zeremonien/etc.)
5. Machen Sie agile Zyklen (Sprints) vorhersehbar und von wiederholbarem Erfolg

Beispiel für nicht IT-meinende Sprache für Agile

Eine offene Frage ist dies in der Tat. Außerdem gibt es darauf keine gute Antwort. Sie können nur der Meinung anderer vertrauen, ob dies funktioniert, oder es selbst versuchen und sehen, wie es läuft. Ich empfehle letzteres. Trotzdem kann ich die Rolle des „Anderen“ übernehmen und eine kurze Lektüre darüber empfehlen, warum agile Methoden für jedes Unternehmen funktionieren: https://kanbantool.com/blog/bringing-agile-into-non-tech-environments Ob ob man Scrum oder Kanban übernimmt, ist eine andere Frage – meiner Erfahrung nach ist Kanban für Einsteiger einfacher, aber Scrum kann mehr Struktur in den Workflow bringen, wenn man das braucht, aber ich würde nicht gleich damit anfangen.

Nun, „nachdem nun all dies gesagt wurde“, schätze ich jetzt die Weisheit eines E-Books mit dem Titel „Managing the Mechanism“ , das die Beobachtung machte, dass Computersoftware „eine autonome, sich selbst steuernde Maschine“ ist .

Die Aufgabe des „Teams“ sei natürlich, „Computersoftware zu produzieren“. Aber wenn "die Computersoftware, die sie produziert haben" endlich zum Einsatz kommt, ist "das Team, das sie produziert hat" ... machtlos. Sie wurden gezwungen, sich in den Umkleideraum zurückzuziehen, während die Roboter , die sie erschaffen haben, tatsächlich das Spiel spielen.

Ich habe dieses kleine E-Book noch nie in Papierform gesehen. Aber für mich war es ein augenöffnender Perspektivwechsel. Weder „ein gut gestalteter Dosenöffner“ noch „ein Fließbandroboter“ sollen jemals … „autonom“ sein.