gile

A Writer’s View: Pitches And Product

by

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

Lately Serdar was commenting on the use of pitches in our writing.  I tend to love making them, and he calls out my current work, “A Bridge To The Quiet Planet” which I summed up as “A sorceress, an engineer, and a priest on a planet-hopping road trip with the owner of a mysterious collection of holy books.”  As amusing as such pitches/summarites seem, they’re actually powerful tools for writing – not just marketing.

The way I use pitches/summaries comes from a mix of my own research into resumes (which are a kind of writing), Agile Product Ownership, the theories of Joel Orr, and the must-read Snowflake method.  They’re not just a way to sell your book – they’re a way to help you write your book.   Stick with me here – let me walk you through an exercise.

Go and take a communications project and sum it up in one sentence.  Such as:

  • Superintelligent whales end up in a religious war over the controversial theory they were created by beings called “humans.”
  • A no-nonsense guide to building your writing career by setting, measuring, and meeting goals.
  • A song parodying internet memes by calling out as many as possible in alphabetical order.

OK, we’ve got three summaries – which are also pitches.  I’m sure at least one might interest you and one might horrify you, but let’s go on.

Now, imagine someone doing any of the above projects takes the summary and then begins to outline the project, figuring what’s really going on in it.  That pitch, summary, acts as a seed and gives you something to aim for – and also an idea of what the boundaries of the project are.  The summary helps you focus (or in some cases, realize the summary is bunk and start over).

But, somewhere in that outline, you may find the summary should change a bit.  The deeper you get in touch with the work, the more you find that one sentence may not communicate it.  So, perhaps you change it.  The summary defined the goal, the work on the project made you rethink it slightly, and so on.

  • Superintelligent whales disagree over the theory they were created by “humans,” which plunges them into a species-threatening religious war with an unsure outcome. (Changed because it gives a better idea of the plot).
  • A practical, step-by-step guide to a writing career with measurable goals and milestones that anyone can use. (Changed as it focuses the goal more)
  • An electronica song that parodies the most enduring internet memes – in alphabetical order. (Describes better, more clear goals).

It’s a dialogue. You have a summary, then an outline, which may influence each other.  Then as you flesh out your work you may change the outline, or the summary, and vice versa.  The ability to write summaries and pitches gives you the ability to create a dialogue among all levels of your work so they stay coherent – because it all comes back to making sure the summary is accurate.

If you can get an idea of what your work is about on all the different levels, from a summary to a scene, from character arc to story arc, you have a much better idea of what’s going on.  In turn, you’ll make a better work because all your work, at all levels, keeps reinforcing what you’re doing.

Plus you get a great sales pitch that’s been well-honed!

 

(Remember I do all sorts of books on creativity to help you out!)

– Steve

Eat Your Failure: Agile is Failure Absorbent

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).
So let’s be honest, May was not my greatest month. Sure, I got things done but plotting my first novel took over twice the time expected and isn’t done yet. I only wrote 84% of what I wanted for the minibooks. I had to hold off many small project due to time an illness, business, and allergies.

I honestly felt bad. I had failed. That was bad, right?

Wrong. Agile methods are about responding to change and learning. They are not failure avoidant, they are failure absorbent; failure is expected, learned from, and worked into the process.

OK I still feel bad, but I don’t have to – that’s not Agile – it’s just my own neuroses. I’m not used to absorbing failure – nor are many other people or groups.

Most organizations are failure avoidant – and because of that they fail even more. Nothing ensures learning slowly, having neurotic relations, continuing the blame game, and adapting poorly than being failure avoidant. I’m sure you’ve been in failure avoidant situations – it’s bad at work and worse with yourself.

Failure absorbency is a major part of Agile philosophy and methods. The goal of Agile is to be able to respond quickly, using communication and responsiveness to change to allow you to deliver work faster and better. Agile expects failure. Agile practices eat failure and use it to become stronger.

The only thing to feel bad about is not responding to failure appropriately. Though I suppose that’s a separate failure you can then respond appropriately too.

When you fail in Agile you should review, learn, and figure out how to adapt and do better. It’s not what you did wrong, it’s what you learned and how you adapt. Eat your failure.

So what did I learn:

  • TOO MANY ANKLEBITERS: I assigned too many small tasks that I didn’t need or I should have done to “clear the plate.”
  • TIMESHIFTING:Some of these tasks could have been timeshifted better – there’ a few cases where I just figured I’d get to them.
  • TOO PACKED: I had no room for disruption baked into my plans despite having so much going on yet having so much free time.
  • POOR PLANNING DUE TO OVERCONFIDENCE: I didn’t plan out the novel plotting well at all as noted; it may be this novel is going to be far less timebound and far more about iteration.
  • OVERCOMMITMENT: The Novel didn’t just take longer, I had to literally “back my mind out” of work that held up my imagination. It’s like writing code before the design research is done – an then you don’t want to change the code.

Now how do I deal with this?

  • Review tasks better to make sure I really need to do them – success if often measured in what’s not done or needed.
  • For truly new project, like my novel, watch my time estimates on early stages and give myself space to do them write. Also, don’t overdesign/overdetail or not back out.
  • Get a better sense of my velocity so I don’t overload myself (which I think I’ll have end of this month).
  • Better pace myself, which is part of velocity.
  • It’s probably better to find I have spare time in a sprint then to overload myself – If I have spare time I can start taking items out of my backlog. Again focus on what’s needed.
  • I’ll review going to two week sprints in July – it’d make me much more adaptable.  However I think long term my life will evolve from Agile to Kanban.
  • I still run too many projects at once – the Minibooks being a classic example of trying to do them over time, and that writing can just turn into a distraction.

So that’s how I adsorb failure – getting better.

This has made me even rethink how I’ve handled failure in my life. I tend to avoid it – then embrace it when it happens. Maybe I could just be a bit less avoidant early on.

– Steve