Zugegebenermaßen ist Scrum natürlich nicht komplett übertragbar, schon allein weil eine Mindestgröße von 5 Personen - product owner, scrum master, dev-team - eher unrealistisch ist. Und wenn ich meinem Mann erkläre, dass er zukünftig mein Scrum Master ist, findet er das wahrscheinlich so lange interessant, bis ich erkläre, dass er mir damit alle Probleme, die mich am effektiven Schreiben und Fokus behalten hindern, nicht nur vom Hals hält, sondern sie auch beseitigt.
Auch wenn mir die Idee gefällt
Weshalb es mir in den Sinn kam, war die doch recht freie Arbeit Planung auf Basis des Product Backlogs, als den Ort für alle Szenen-Ideen, die mir einfallen, sortiert nach Plot-Wert. Für einen Sprint kann man sich dann auf die Szenen konzentrieren, die man im aktuellen Stadion als besonders Plot-relevant eingeschätzt hat. Review: Szenen-basierte Betaleser, Retro: was kann ich für den nächsten Sprint verbessern. Die Sprint-Time-Box könnte einem am rumwurschteln hindern, das Sprint Backlog könnte einem Fokus auf die Inhalte ermöglichen, die man sich bereits ausgesucht hat.
Für jemanden, der gerne alles im voraus plant ist das sicher uninteressant, aber für jemanden wie mich, der eigentlich nur ungern plant, könnte das zu einem Mindestmaß an Planung und Vorausschauen führen, das nicht lästig ist. Strukturiert, aber variabel war mein Gedanke.
Ich seh schon, Du bist dabei, eine ganz neue Entwicklungsmethode zu erfinden, die in fünf Jahren genauso berühmt sein wird wie heuer die „Snowflake Method“ …
Ach, ich wäre beglückt wenn es bei mir funktioniert, auch wenn niemand anderes was damit anfangen kann.
Allerdings führt mich das zu einer weiteren Frage: Gibt es denn wirklich zwei Autoren, die auf die gleiche Weise planen und schreiben? Ich würde vermuten, dass selbst zwei Autoren, die von sich sagen, sie benutzen Snowflake, trotzdem zwei unterschiedliche Herangehensweisen haben. Liege ich mit dieser Annahme falsch?
Nein. Deine Annahme teile ich voll und ganz. Die individuellen Neigungen prägen immer das Vorgehen. Da ist doch nichts fix zementiert, auch wenn dies in zahlreichen Schreibratgebern unermüdlich als der einzige Weg zum Erfolg dargestellt wird.
Gäbe es die eine Arbeitsweise, gäbe es nicht zahlreiche Schreibratgeber, sondern das Standardwerk und dann gäbe es auch eine geregelte Ausbildung in Deutschland.
Neulich hatten wir in einem Schreibforum eine gemeinsame Übung zur Snowflake und sie wurde sehr unterschiedlich ausgeführt. :D:roll_eyes:
Näh. Seit ich bei den „44 Stunden von Wolfenbüttel“ 15 Autoren zugleich über die Schulter schauen konnte, wage ich sogar zu sagen: Es gibt nicht mal zwei Autoren, die Manuskripte auf die gleiche Weise formatieren.
Na ja, hierbei geht es ja nicht um das Schreiben sondern um das Planen. Und nur weil man eine vorgefertigte Planungsmethode verwendet, bedeutet das nicht, dass das Produkt oder der Entstehungsprozess in irgendeiner Form identisch wäre.
In IT Projektmanagement gibt es sehr viele sehr detailliert vorgegebene Methoden, Regelwerke oder Frameworks. Dennoch laufen die Projekt deswegen nicht identisch ab oder erzeugen vergleichbare Produkte. Man sieht einem Produkt niemals eine Planungsmethode an. Von außen betrachtet sieht man es einem Produkt zumeist nicht mal an, wenn es völlig chaotisch und ohne Planung abgewickelt wurde. Außer am UI wurde ebenfalls Chaos zelebriert, aber selbst das kann mit toller Planung chaotisch aussehen.
Der einzige, der das Chaos bemerken würde, wäre ein Programmierer, der das Produkt warten soll. Und das ist ein sehr kleiner Part im Vergleich.
Nina, probiers doch einfach mal aus, ob es funktioniert - und berichte dann.
Ich verstehe zuwenig vom IT Management, um da richtig einsteigen zu können, aber für mich als jemand, der mit Planen & Plotten auch immer ziemliche Schwierigkeiten hat, klingt es sehr interessant.
Bei der Software geht es um die trockene Logik, das Innenleben spielt für die Entwickler eine Rolle, nicht für den product owner. Der *owner *will ein Modul, das funktioniert, eine black box. Die Planung erfolgt auf der black box-Ebene, die Entwickler sollen sich um die Umsetzung kümmern.
Das würde bedeuten, der *owner *definiert die Anzahl der Kapitel und deren Thema. Der Entwickler ist der Schreiberling.
Mit *scrum *bist du auf der *owner *Ebene, aber beim Schreiben geht es um den Leser, um den Inhalt, da mußt Du vom *owner *zum *developer *werden.
Ich glaube, top-down (Kapitel, Unterkapitel) ist fürs Grobe nicht verkehrt, aber wenn Du schreibst, entdeckst Du vielleicht, was fehlt, woran der *owner *gar nicht gedacht hat. Man muß dann, bottom-up, als Schreiberling (developer), das eine oder andere Kapitel ergänzen und/oder an den owner herangehen und fragen stellen (was die meisten i.d.Regel begeistert).
Ich bin immer mit einer Mischung aus beiden gut gefahren, sowohl beim Schreiben, als auch beim Entwickeln.
ich habe das tatsächlich in der Rolle Scrum Master in zwei Fällen erfolgreich angewendet.
Das geschah im privaten Freundeskreis in einer Art 1:1 Coaching alle 2-4 Wochen. Scrum / Kanban wurde nicht streng mit allen Artefakten gelebt, sondern die Methoden und Werkzeuge in einem iterativen / inkrementellen Verfahren experimentell angewendet.
Im Fall 1 hat eine Freundin, die zwei Jahre lang ein sehr persönliches Buch geschrieben hat und in der Komplexität stecken geblieben ist, dieses Buch zünde geschrieben (1 weiteres Jahr). In einem anderen Fall hat jemand, der seit 10 Jahren ein Bich schreiben möchte und nie den Anfang gefunden hat, jetzt seit 40 Tagen mit nur einem Tag Unterbrechung jeden Tag mindestens 30min an dem Buch geschrieben.
Ich überlege mehr daraus zu machen und das ganze methodisch und wissenschaftlich weiterzuentwickeln.
Um zu beurteilen, ob der Schreibfortschritt mit der IT in Zusammenhang steht, bräuchte man eine Kontrollgruppe, die man ohne Zusammenhang mit IT regelmäßig trifft und mit echtem Interesse und einer gewissen Erwartungshaltung nach den Schreibfortschritten fragt.
Ich würde mal behaupten, dass es die meisten Hobbyautoren zu mehr Schreiben motiviert, wenn sie sich alle 2-4 Wochen mit einem Freund treffen und ihre Fortschritte besprechen. Unabhängig von der benutzten Software.
Als noch aktiver IT-ler kenne ich Scrum natürlich, habe aber noch nicht (bewusst) ausprobiert, dieses Verfahren auf das Schreiben anzuwenden. Zwar fallen Romane im Moment nicht in meinen Erfahrungshorizont, aber für Fachartikel ist eine gewisse Planung vorab durchaus von Wichtigkeit.
Begonnen habe ich oft (auch vor Papyrus) mit einer Stichwortsammlung. Dann habe ich grob einige Kapitel verschiedener Ebenen angelegt und diese früher oder später mit Leben (Text) gefüllt. Eine Erweiterung um Szenen halte ich für denkbar, weiß aber nicht so genau, wofür ich die nutzen würde. Damit wären wir gedanklich im Organizer angekommen und hätten somit eine gewisse Grobplanung des Artikels vorgenommen.
Wenn ich nun die fett gedruckten Begriffe in den Scrum-Jargon übersetze, sieht das gar nicht mal so verschieden aus:
Stichwortsammlung, Grobplanung = Backlog
Organizer = Scrum-Board (Sprint-Planung und -Ausführung)
Statusanzeige des Organizers = verschiedene Spalten auf dem Board
Kapitel und Szenen = verschiedenfarbige Task-Karten
Vielleicht habe ich Scrum also doch unbewusst ausprobiert, oder es gibt ganz einfach gewisse Parallelen.
Ob das direkt auf das Schreiben eines Romans übertragbar ist, weiß ich nicht. Zumindest die zusätzlichen Elemente Personen und Orte sind im Fachartikel eher nicht enthalten. Allerdings wäre es vielleicht mal eine Idee, einen Fachartikel in narrativer Weise zu gestalten.
Mindestens im zweiten Fall liegt es tatsächlich an der Methode, weil langjährig schon alles mögliche probiert wurde inklusive Schreibgruppen usw. Beide „Probanden“ sagen dass es wohl eine Mischung aus Methode und persönlichem Kontakt sei.
Software habe ich keine benutzt bzw. erstmal offen gelassen, in einem Fall waren es Post-It’s, im zweiten Fall Trello
Ich möchte gar nicht wissen, wie viele Steinplatten der für seine Poetik verballert hat, bis er es endlich hatte. Das müssen Tonnen gewesen sein. Und die Schwielen und Abschürfungen erst. Und das alles auf einem echt vorzeitlichen Kognitiv-Niveau.
Ich frage mich, wieso um alles in der Welt das alles - trotz aller SCRUM-Master und Prince2-Könner (zum Beispiel ich) - heute noch immer Gültigkeit hat und noch nicht widerlegt wurde.
Ich habe damit unterschiedliche Arfahrungen gemacht. Je nachdem, wer den Artikel bestellt hatte, war man in der Redaktion bzw. später auf Kundenseite von positiv überrascht bis total irritiert.
:D:roll_eyes:
