Scrum vs. Writing

I just finished Scrum: The Art of Doing Twice the Work in Half the Time, by Jeff Sutherland.  Fun stuff, if you’re into process, which I am.  (If you’re not, you may want to skip this.)  It seems like a no-brainer:  meta-skills, like learning how to learn, make everything else easier, faster, and even more enjoyable.   Of course, I haven’t achieved light-speed yet, so obviously I need to read more of these books…

It struck me as I was reading this that many of the ideas behind Scrum and a lot of other business-process books come from how Toyota developed their business after WWII, with a focus on long-term goals, repeatable results with fewer defects, and constant improvement–a willingness to fail faster and improve therefrom.

As I was trying to translate the basic ideas into “how to write better and faster,” I kept coming back to something familiar:  Heinlein’s rules.  As an engineer, he was always interested, I think, in working out how to streamline and refine processes in order to do more work with less effort:  in several of his books his characters mention how “lazy” they are, and how it drove them to work smarter, not harder.  I suspect that even if he wasn’t directly aware of the work being done at Toyota in the Fifties, he was enough part of the zeitgeist that it probably wasn’t more than a couple of degrees of separation between him and what was being done in Japanese factories.

Heinlein’s rules:

  1. Write.  (Keep the focus on production, not planning.)
  2. Finish what you write.  (Don’t leave inventory on the floor.)
  3. Refrain from rewriting except to editorial order.  (Do it right the first time/only make changes the customer wants.)
  4. Put your story on the market.  (Ship the product.)
  5. Keep it in the market until it sells.  (Have faith in the product.)

Sounds like something Seth Godin would say.

But back to Scrum specifically.  The appendix of the book has a brief list of steps on how to accomplish scrum:

  1. Pick a product owner (someone who focuses on what the customer wants).
  2. Pick a team (who will do the work).
  3. Pick a scrum master (who will focus on eliminating waste/anything that slows the team down).
  4. Create/prioritize a product backlog (a high-level set of goals that will accomplish what the customer wants).
  5. Refine/estimate the product backlog (using the pareto principal, strip down the backlog to approximately 20% of the most valuable features; estimate work to be done. I actually did this on a hypothetical historical romance novel and discovered some interesting things about what I really wanted in such a novel versus a huge list of general expectations).
  6. Plan a “sprint” of no more than a month’s length, at the end of which is a deliverable or demo-able product.
  7. Make work visible (whiteboard!).
  8. Daily standup/scrum meeting (a.  What did you do yesterday to help the team finish the sprint? b.  what will you do today to help the team finish the sprint? c.  Is there any obstacle blocking you or the team from achieving the sprint goal?)
  9. Sprint review/demo (sprint results shown to the customer and everyone with a stake, or in fact anyone who wants to show up).
  10. Sprint retrospective (lessons learned).
  11. Start next cycle.

The funny thing is that one of the best things I’ve learned lately as far as meta-writer-process goes is to do Julia Cameron’s morning pages on a fairly regular basis, in which I do pretty much the steps as listed, as well as letting the subconscious babble about new ideas, research, lessons learned, etc.  Looks a lot like a daily scrum meeting.

Here’s my best guess for how to translate the list above into writer process.  It involves condensing some things (as a writer, you wear all the hats).

Mostly a plotter:

  1. Story/marketing development (synopsis/pitch development, finding an audience, working through the core elements of what makes a story satisfying to that audience versus what common knowledge says has to go in that story).
  2. Draft planning (outlining, if applicable).
  3. Morning pages.
  4. Writing draft.
  5. Read through/delivery to betas/delivery to general readers (submission/indie).
  6. Brutally honest assessment of whether you accomplished requirements from step 1, lessons learned, what could have gone better/what went well.
  7. Start next cycle.

Mostly a pantser:

  1. Draft planning (how long the draft will take, how big of a project you think this is, daily wordcount/scene goals–not outlining).
  2. Morning pages.
  3. Writing draft.
  4. Structure analysis (finding out if you have all the scenes, in right order, etc.).
  5. Story/marketing development (synopsis/pitch development, finding an audience, working through the core elements of what makes a story satisfying to that audience versus what common knowledge says has to go in that story).
  6. Read through/delivery to betas/delivery to general readers (submission/indie).
  7. Brutally honest assessment of whether you accomplished requirements from step 1, lessons learned, what could have gone better/what went well.
  8. Start next cycle.

I tend to think in terms of being a plotter, even though I’m not really one anymore, so here’s how I think it might work for me:

  1. Story/marketing development (synopsis/pitch development, finding an audience, working through the core elements of what makes a story satisfying to that audience versus what common knowledge says has to go in that story).
  2. Morning pages.
  3. Writing.
  4. Read through/betas/delivery to readers
  5. Brutally honest assessment time (including structure analysis).
  6. Start next cycle.

The big change for me (at the moment) would be the first step, which I’ve been developing for a while in a half-assed fashion, but in such a way that doesn’t prevent me from running down a lot of blind alleys:  I tend to write a lot of stories that are unreasonable from a reader’s point of view.  (“Who is my intended reader and why would they enjoy this?” “Dunno.”)  I do write a log line and often a brief synopsis to get a feel for the voice and conflict, sometimes the structure of what I want to play with, but I don’t always carry that through to what does this do for my readers?  A lot of the time I don’t even ask what does this do for me?  Will I have fun writing this?  What is the awesomeness factor?

Which is both sad and has, yes, been a huge factor in not getting non-client writing done/published this year.

Another change would be hidden in the morning pages:  I haven’t been asking myself what’s in the way of accomplishing things on a regular basis, let alone what would make me happier/more satisfied with what I’m doing.  I’ve been listening to myself bitch about things in general and trying to work out best practices (like getting enough sleep, exercise, etc.), but I haven’t been thinking in terms of continuous improvement.  Learning in general, yes, but not what’s getting in the way on X project, how I can make it more enjoyable to work on today.

We’ll see how it goes.

 

1 thought on “Scrum vs. Writing”

Leave a Comment

Your email address will not be published. Required fields are marked *

Scroll to Top