agile

A Writer’s View: Snowflaking, Agile, Philosophy

by

(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

My Agile Life: Fix A Few Things

by

(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).

Many Agile methods use some kind of retrospective to review and improve. I adore them but find they can drag for two reasons: sometimes people hate them and sometimes people go overboard.  It can become a venting session or it can become a case of people shutting down.

Personal retrospectives can be a drag as well for the same reasons, though I find it tends towards the “overboard.”

I find that the “overboard” and the “underboard” are part of the same problem – that retrospectives can be overwhelming.  If you want to discuss what went wrong on a sprint or on a project, you can probably easily find tend or even hundreds of things.  This can lead to people endlessly listing off problems – and people trying to ignore then because there’s so many (and their egos feel threatened).

A retrospective needs you to both focus and not be afraid.

What I’ve learned both as an Agilist and in my own life (where I can’t escape any of this) is that you need to limit what you try to improve. When you focus on one or two or a few things to get right, you can get them done – focus on every problem and you’ll never start, or you just won’t try and review your work.

Besides, as you focus on a limited amount of improvements you can also reinforce the issue that many of the problems that came up were already taken care of.  All those hundreds of problems got taken care of by reasonably mature people or a reasonably mature person and it’s probably not worth going over.  Focus on what needs to be improved.

On top of that, the focus on a limited number of issues can take your ego out of it.  You ignore the vast amount of things you can complain about to focus on things you can and want to fix.  It tones down the fear you may feel of going over the many things that did go wrong, dealt with or not.

I’ve found the “power of Few” to be very helpful in that I can focus on getting better in specific ways – ways that have real value.  Plus it doesn’t’ trigger any insecurities

As an addendum, you should always seek to improve outside of reviews and goals. Good opportunities to get better abound all the time, and seizing on them is a big part of an Agile Mindset. It also helps you get used to facing and fixing problems on the fly – so they don’t gum up your retrospectives (and your self-esteem).

(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: Plotting, Pantsing, And Agile

by

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

So this week I finished the plot outline of my book. I’ve been expanding it iteratively, from one-sentence summaries to full character profiles, based on the Snowflake method. The method itself works great with Agile – and brings up a very important point about writing.

Writing, it is said, is often divided into “pantsers” (seat-of-my-pants writers) and “plotters (organized writers like yours truly). As a plotter, I’d like to note that you do end up “pantsing” anyway, just on a finer-grained level. At some point in writing you can only plan so much before you have to write – it’s a matter of degree.

This truth can frustrate some plotters, because you can only define so much before there’s nothing left to do. Your ideas may be totally wrong, your plan may be horrible, your plot awful – but you won’t know until you start writing.

This is the same thing one faces in software, where Agile methods continue to hold more and more sway – you can only design so much before you have to write code to see if it works. It’s the same with writing.

So now that I have a plot, how will I confront my inevitable discovery of all my horrible mistakes?

First, I won’t be afraid. As I like to note, Eat Your Failure.

Secondly, I plan to do reviews:

  1. I will write a chapter at a time and share it with people for feedback.
  2. I will review my full plot outline every chapter completed to make notes and see what changed or what I want to modify or what I want to add.

I know my plot outline (all 8 pages in a spreadsheet) is only so good. But it’s good enough to get moving with an idea of where I’m going, and good enough to improve when I find mistakes or get new ideas. It also is stable enough that it probably won’t fall apart and deep enough it’s not shallow.

Two notes:

  1. I have trouble seeing how “pantsing” can work for complex stories, but perhaps I have something to learn there, no? Maybe I should “pants” a short story sometime.
  2. Based on my own experiences and what I’ve seen in the market you can in theory plot a novel pretty finely, and its very easy if you’re using tropes or taking a “light” approach. Not sure how good it’d be, but it seems doable.So what have you found?

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

– Steve