A Writer’s View: Complexity And Convolution

(This column is posted at www.StevenSavage.com and Steve’s Tumblr – and hey, think this should go on the Sanctum too?)

Working on “A Bridge To The Quiet Planet” is interesting as in some ways it’s very complex, a tale of a world of science and sorcery that survived a world-shaking war, and the lives of those centuries after the trauma.  In other way’s its simple – it’s a heist/chase story that goes Cohen Brothers, just with a sarcastic sorceress and a disreputable used bookseller.

Complexity in stories is a challenging area of discussion, because it often seems what people say is complex is anything but to me..  As my friend Serdar notes in his blog:

Now, Steve did specifically say complex stories. That could mean one of a number of things, not all of them what you might think. Complexity in a story is too often assumed to be convolution, as in a plot that is very knotty and full of double-reverses and whatnot. I tend to stay away from such things if only because I am not nearly smart enough to pull them off, but also because I have a different idea of what kind of complexity is relevant in a story. For me a story is complex if the pieces in it have a lot of thematic richness, or if the characters are multidimensional and humane. It’s not if I need a map in the endpaper and a list of dramatis personae.

This pretty much hits the division on the head for me.  A story can be convoluted but not complex – a Wile E. Coyote mess of tricks and craziness can exist atop a simple set of characters and tales.  A story can be complex with deep richness and many facets, while being straightforward.

What I realized in my writing is that complexity and convolution are not the same thing, and separating them in your mind is valuable for a writer for several reasons.

First, to separate them is to ask what you’re wanting to write.  Do you want to challenge the audience with double-backs and twists or do you want them to experience richness?  Or both?  To separate complexity and convolution is to help you set goals.

Secondly, to separate them is to ask when is one or the other appropriate within a story.  One part may need complexity, one part may need convolution.  It is possible what seems to be appropriate may, at later examination, not be – a complicated murder plot may be more interesting from the viewpoint of a character who has it figured out, so you can explore their character.

So I’m writing a story that’s complex (in characters) but the overall plot isn’t overly convoluted (it’s straightforward) once you know what’s going on.  This is actually important because if I added convolution to the story, the book might be longer but also more confusing due to the setting’s many unusual elements.

Complexity isn’t convolution.  They may exist together, but can be happily apart – and keeping that in mind will enrich your writing either way.  Plus, it’s OK to write one, both, or none – just know what you want.

(Oh and if you need some other creative boosts, check out my book on Creative Paths!)

– Steve

My Agile Life: A Quick Review

(This column is posted at www.StevenSavage.com, Steve’s LinkedIn, and Steve’s Tumblr)

(My continuing “Agile Life” column, where I use Scrum for a more balanced and productive life continues).

I’ve been using Agile to have a more productive life, and it’s been pretty great. So to help you out (and help me organize my thoughts) here’s what I currently do. I think I’ll do these roundups every few months, so you can try the latest iteration of my system, and I get better at sharing.

First out, what I’m doing is the Agile method of Scrum in my own life. If you’re not familiar with Scrum it’s basically:

  1. Have a ranked backlog of stuff to do.
  2. Choose how much you can do in a given time frame from the top – this timeframe is called a Sprint.
  3. Do it.
  4. Review how you did, revise the backlog, and start a new sprint.

That’s Scrum. Here’s how I do it – first, the lists I keep.

  1. I have an Incubator. This is my list of Neat Stuff to do, summed up. I update it monthly or so and review it monthly as well.
  2. I have a Backlog/Roadmap. This is a list of things I want to do, in order, usually on the Project level, but sometimes broken down into stories (pieces of value). It’s ranked both by importance and “guessed” chronology – a few things are tagged with critical dates. I could probably split these up but I don’t think I need it.
  3. I have a Sprint Backlog.  This is what I decide to do every sprint – which for me is a month. This isn’t ranked, but is more sorted in a project order. This is broken down by Projects, with stories, with specific tasks. I estimate effort by hours. I review this every day.
  4. I have a cumulative flow chart, which is based on Tasks (not normal process, but most of my work breaks down pretty finely). This gives me a visual idea of how I’m doing, and is good practice on using these charts.

What I do is review things every day to see what’s up and decide what to do – but after regular review, I’m usually aware of my next few days of work automatically. I’ve kept a weekly schedule but fell off of it – I’m not sure I need to, as my daily reviews keep me aware of what’s going on.

A few things on how I operate:

  • Break down work into workable components – A real challenge at times as you can treat work as big lumps, or turn it into so many tiny tasks you can’t focus.  Find some way to break things down that you can get things done without overloading yourself, but not so much you can’t keep track of the little parts.
  • Limit Work In Progress, WIP, To 2 items.  WIP keeps you from juggling too many balls. I normally prefer a WIP of one, but when you’re doing Scrum for real life you’re going to have interruptions. Usually at most I have one “in progress” item with another “free item” for all sorts of tasks like cleaning, etc. However if I have one “ball” in the air I make sure any new one is finished right away.
  • Polish that backlog. Keep revising this as you go so when you get ready to plan, you pretty much know what you’re doing next.
  • Keep a regular task backlog. This is one way I save time planning, preparing a list of regular common tasks I have to do monthly so I already know most of my schedule. I copy that into:
  • My projected “next month” backlog. I keep a draft of what I’ll “probably” do next. This helps me plan fast as, about midway through a month, I’m like 75% certain of what’s next if not more.

All of this has made me much more productive – but it may not be for the reasons you think.

Yes, there’s the value of having a tool and a plan of some kind – but you can do that a lot of ways. I’m taking an Agile approach, and that requires me to take an Agile mindset – a focus on adaption, on communication, and on efficiency. The tool reinforces the mindset.  The mindset is what matters.

And the mindset? I’m a lot more relaxed, a lot more effective, and I waste less time.

(By the way I do plenty of books for coaching people to improve in various areas, which may also help you out!)

– Steve

A Writer’s View: Snowflaking, Agile, Philosophy

(This column is posted at www.StevenSavage.com and Steve’s Tumblr – and hey, think this should go on the Sanctum too?)

As mentioned earlier, The Snowflake Method really jumpstarted my return to writing with my new novel “A Bridge To The Quiet Planet.” It was a smart, mature take on writing that gelled both with my techniques and with Agile.

The basic idea is iteratively detailing your work. A story starts as a sentence, becomes a paragraph, becomes several paragraphs, and eventually becomes a scene-by-scene outline – or more. The author used to detail scenes out before writing them, but found it wasn’t necessary as he got good at this.

I felt most of the same way, but some scenes troubled me as I wrote them. Frustrated, I thought it over – and used the “Five Whys.”

  • WHY does this feel wrong? Because I don’t have a grasp of the scene – I’m stabbing at it.
  • WHY am I stabbing at it? Because I’m starting too ephemerally – yet when I write the scene it often surprises me with its depth.
  • WHY does it start ephemeral then get “deep”? Because I don’t start off with enough “gut” feel for it.
  • WHY don’t I have a gut feel for it? Because I’m diving in and not getting a feel for it.
  • WHY am I diving in and not getting a feel for it? Duh, I need to sort of “ease in” to this.

Once again the Five Whys comes through. I was diving into my scenes not “easing in” to them, so I’d start them without a good feel for them. The gentleman behind the Snowflake Method had long experience writing so didn’t need to detail his scenes; I’ve been writing for a long time, but was a bit rusty, so needed to “ease in” to a scene.

So now how do I ease in? Well, back to the Snowflake method and Agile.

The Snowflake method emphasizes starting small and general and expanding – just like good product design and good Agile planning. So what I did for scenes (at least when I felt disconnected) is the following.

For every scene as I prepare to write it:

  1. Sum the scene’s goal and viewpoint, and possibly a theme.
  2. Use that to create a single-sentence description. It might mean revising #1
  3. Once that sentence feels “right” write a paragraph of the scene.
  4. Once the paragraph feels “right” do an outline of all major events, in order, a sentence apiece.

What’s funny is this is what I used to do for short fiction. It had gotten kind of automatic in my writing and I think I forgot where it fit.

So once again the Five Whys, Agile, and the Snowflake method come through – however there’s more.

This has made me wonder, again, how much we can detail scenes and documents before writing them. A simpler fiction book or a general nonfiction book could probably be diagrammed to the paragraph level; something more complex, not so much. Some work requires you to get your hands dirty before you realize what’s really going on. I’m very curious what my writing will be like after this.

Then again you get to watch that process.

(Oh and if you need some other creative boosts, check out my book on Creative Paths!)

– Steve