Writing And Metaphor

(This column is posted at www.StevenSavage.com and Steve’s Tumblr.  Find out more at my newsletter.)

What’s Your Metaphor for writing?

Returning to fiction with my novel, A Bridge To the Quiet Planet and its upcoming sequel, a School of Many Futures, required me to think about writing a lot. Thinking about writing, how to conceive of it, how to pace it, how to develop it helps you, well, write. A metaphor gives you tools to think in and ways to improve.

For nonfiction I think of it in abstract, visual forms. I’m so used to writing it and have for so long that my metaphors are things I see and feel. Perhaps once I had to use more concrete terms, but time makes things unconscious and automatic, and I don’t remember.

But fiction? That was harder because I’d not thought about – and when I was rethinking my writing methods, I realized I was treating fiction as a “physical” thing.

You’ve heard me talk about “Big Rocks” as pieces of fiction and plot. I’ve discussed Agile and stories, but Agile comes from physical manufacturing and store stocking – it often has “physical” ideas built in. I treated stories and chapters as scenes as boxes containing various events.

Did these limit me? Hell yes, because fiction – and indeed a lot of writing – probably isn’t best thought of in physical metaphors. It’s too limiting, too atomistic, too confining.

Now how did I realize this? Because I was analyzing writing (as I always do) and realized how important editing is, and editing requires a product. You make something then improve it.

Writing fiction is like writing computer code.

Computer code is more a living thing, with components and distinct parts, but it works because all its parts come together. It’s about flows of information and functionality. Best of all, as long as you have it working – no matter how awful – you can improve in. In fact, you often have to make bad code to get good code because you don’t know how it’s going to work until you have something.

Seeing this metaphor, this new metaphor, really helped me get over some of my writing challenges. Thinking about the parts of a fictional story as physical started to fade away. I had a way to see things differently.

My metaphor or metaphors may not be yours. Even my more abstract ways of thinking are my ways, not yours. But a challenge to you, my writing friend, is to find what metaphors help you write. What is a good way to compare writing to something else that helps you?

Maybe you have it. Maybe you don’t. Or maybe you just thought of it and have more to explore . . .

Steven Savage

A Thought On Scrum And Story Plotting

(This column is posted at www.StevenSavage.com and Steve’s Tumblr.  Find out more at my newsletter.)

As you are painfully aware, unless you have never heard of me, I’m big into applying Agile to creative methods. Writing nonfiction, however, has eluded me – but I may have had a useful breakthrough.

First, assuming you somehow didn’t know anything about me beyond my name, an explainer. Agile is an approach to projects that emphasizes adaptability, adjustment, communication, and not-overdoing. It’s most common variant is Scrum, which I practice in my career as a Scrum Master – which surprisingly is not a minor He-Man villain, but a kind of process improvement enabler.

Second, if you wonder who I am, I’m obsessed with creative improvements and development. I kinda write on it a lot – so I like reconciling creativity and Agile.

But as for taking Agile, specifically my beloved Scrum, and applying it to fiction? I’ve been challenged. First, let’s take a look at Scrum.

  • Scrum at its very basics is this:
  • A backlog of stuff ranked in order of importance – these are called Stories.
  • One takes a timeframe (called a Sprint), takes a certain amount of stuff from the backlog, and does it. Sprints are usually the same size, and usually have themes – they produce deliverable results. You focus just on the Sprint.
  • At the end of the Sprint, you re-evaluate your work, apply lessons, and do it again.

Scrum sometimes is extended in various ways. One of my favorites is “Epics” – groups of related Stories. There are also various scaling methods and so on.

On one level, you can see how Scrum may help a writer. A story is orderly sets of distinct things – events (organized into scenes). But writing is also very unpredictable; it’s certainly not a simple 2D backlog as things change. Plotting is challenging as well – with so many arcs, etc. a simple list of “write this in order” doesn’t seem to work.

This has troubled me over and over because I like writing, I like Agile, and I’m too hard-headed to give up reconciling writing and Scrum. I also want to plan my book – but I overplan it and have to back away – something Scrum could help with.

Then it hit me – this can be done. Here’s how – grab some notecards or spreadsheets.

Write down your major story arcs. There will probably be about 10-30 of them if you go into fine detail (I usually assume each character has 1-3). These are your “Features” – big bundles of events that are kind of their own tale. Think of it this way – your story “Features” several story arcs – but I’ll call them “Arcs.”

In each Arc, write down the main things that need to happen in order. Remember order – not chronology. This isn’t a timeline of “X happens in Y month,” this is a sequence. In Scrum, these are called “stories,” but for the sake of clarity, I’ll call them “Events.”

Now you have major story Arcs. In each are major Events that need to happen, which will probably either be scenes or part of a scene. Now how do you plot this out?

Simple – we use Sprints. Sprints become Chapters.

Now we have a way through.

  • Create one Sprint for each Chapter. If you have no chapters, perhaps pick an arbitrary number (I recommend ten or twenty, easy to get a percent complete). I’ll just call these Chapters.
  • Take the Arc that spans the entire tale, and sequence out its Events spread among Chapters – take your best shot and when they would happen when. Make notes as you do so.
  • Now, take another Arc and do the same – choose one of the larger ones. As you do this, you may start switching around some Events from your first effort – that’s fine.
  • Next, take one smaller Arc and place out the Events in the various Chapters – it probably won’t span the entire set of Chapters, of course. While you do this, re-sequence the Events – figure what order they happen in.
  • Finally, just do this for all of your Arcs until, adding and adjusting and rethinking. Take plenty of notes as well, scenes and inspirations and ideas are going to come to you. Also, remember, everything should be in the order of occurrence.
  • Eventually, you have a set of Chapters, containing Events, that fulfill Arcs.
  • You’ve just created an outline for your book using Agile – in a kind of mutant Scrum using different terminology, and slightly violating the idea all Sprints are the same duration (hopefully they won’t be).

By the way, note how easy it is to switch things around if you change your mind? Move one event up or down to different Chapters? Yes, very easy – because you have a rough idea of what order things happen in, but you’re not locked in – it’s all still pieces.

When you write the Chapter, then you can plot out the specific scenes. Take the particular Events, recheck their order, group them in scenes, and go. Why plot it in fine detail until you’re ready?

I used some similar ideas when plotting my current novel – but then overdid it – and as soon as I did, things felt less fun and fluid. The reason? I thought too far ahead. When I “Deplotted” it, it worked much better. Novel after this one, I’m going to try this system (unless I invent another).

Know where you’re going and in what order. But decide on the specifics when you’re ready to write them. That way, you can react to what has to be done, not have your mind three chapters ahead, and two chapters behind.

Steven Savage

Writer’s Lean Coffee

(This column is posted at www.StevenSavage.com and Steve’s Tumblr.  Find out more at my newsletter.)

At one of my writer’s groups I tried something out you may want to try – a Lean Coffee. Here’s a quick rundown and what happens. You can read up on it above, but I’ll sum up my experiences here.

At its heart, Lean Coffees are self-organizing ways for teams of people to pool knowledge, get advice, and discuss important subjects. It comes from lean business practices, but you can re-purpose it for just about anything.

First, how you run a Lean Coffee (for writers, but you can do it for all sorts of things)

  1. Get a group of people interested in the same subject.
  2. Give them notecards or some other equivalent (or even an online spreadsheet). Have them write down 1-3 things they want to discuss.
  3. Once the questions to discuss are done, everyone gets three votes and votes on what they want to discuss. In my experience, people don’t vote for just their questions, because people bring up topics they hadn’t thought of.
  4. Rank the subjects in order of votes and pick the top one. If there’s more than one top subject by votes, pick one randomly.
  5. Discuss the subject as a group for five minutes. At the end, vote if people want to go on another five minutes. I usually go by majority vote unless it’s close.
  6. Take the next subject by vote count and continue.

Encourage people to take notes or have a designated note-taker if the group is part of a larger team.

I’ve run this a number of times for Agile groups, and it’s always been successful – though sometimes you have to do it two or three times in a row for a team to gel. So how did it go for a random group of writers?

Really good.

First, we had a number of good subjects of discussion. I think that’s because the group had a history of good discussions, often focused on specific subjects-of-the-month. We were primed for this.

Secondly, because we had a diverse group of people, the discussions covered a lot of ground. Different viewpoints created more valuable results – and more valuable questions.

Third, it really got people talking. The Lean Coffee encourages people to talk, and the “bite-sized” discussions made it easy to prompt people who might go silent, and if someone had nothing to say one subject they may the next.

Fourth, the Lean Coffee method encourages solid discussions. People bring up things that matter to them, then vote as a team on what’s important to everyone, and discussion follows. Real quickly you focus on high-value issues, while having a bit of surprise to shake you up and keep you from getting into a rut.

Fifth, it created real team bonding. We shared our concerns and our insights, we got to know each other, we figured solutions to shared problems. I felt like we all left as more of a team.

I am going to repeat this with my writers group, probably every few moths, and may try it in other groups. I also wonder if it’ll work at conventions . . .

So give it a try, and let me know what you find!

Steven Savage