Writing

My Agile Life: Trust

by

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

More on my use of “Agile” and Scrum in my life! This one actually gets into my writing – and someone else’s writing.  And work.  Let’s get to it.

So last week I wrote about how the Second Agile Principle helped me deal with changes to my book.  Short form, I learned how to better embrace change and my writing is better for it (despite my resistance).

This got my friend Serdar thinking about his next book, Always Outnumbered, Never Outgunned, and he did his own post on change.  Here’s where he hits on something very important to Agile – personal and professional:

To wit: At one point when writing Flight of the Vajra — in the first draft, mind you — I abandoned several thousand words and backed up a fair distance in the story so that I could explore what seemed a far more fruitful plotline than the one I had cul-de-sac’d in. Better to turn around than to keep fighting against odds I hadn’t a chance of bucking. It meant losing several days worth of work, but when you put faith in the process rather than the resulting artifacts, those hard decisions aren’t so hard anymore.

Agile relies on a lot of trust.  Without trust, Agile falls apart (which I’ve seen plenty of times).  Think about it:

  • You have to trust your Product Owner that they know what they’re doing with their directions.
  • You have to trust your teammates to do their work.
  • You have to trust the Scrum Master to have your back.
  • You have to trust the processes to help you get the job done.
  • You have to trust yourself to do things right.

In personal agile it’s the same thing.  You have to trust yourself, build processes you trust, and keep improving things so you trust they get better.  Personal agile like I use will very quickly show you places in your mind where you don’t trust yourself.

But here’s the funny thing – you trust a lot of things.  But you don’t trust the product or even the product backlog as some kind of perfect result or guide.  Serdar rightly says the artifacts of writing aren’t to be trusted, and I’d add even the artifacts that lead to writing – or any other actions – aren’t to be trusted.  Be it plans for software or a book, they will change.

In fact, trusting your current plans on anything is going to trap you.  Change is inevitable.  The most trustworthy plan will fall apart because the world shifted around it.

Instead you have to trust the processes that keep you going forward. Your sprint standups, backlog planning, the act of writing or coding or whatever.  You trust in them to do good work, get feedback, and set direction.  Good direction – in the forms of backlogs, plans, user stories, etc. – is the result of trustworthy people and processes.  But it is not as important – or as reliable – as they are.

It’s not the map, it’s the confidence of the person giving you directions to help you get to your destination.

In your life, in your own projects, in your Agile (at home and at work) – are you trusting the people and the methods?  Can you?

If not, my guess is you’re none too happy.

(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 Life: The Second Principle

by

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

This week I rewrote part of the plot of my book.  I had a great idea that would make the book deeper, improve character, explore the world!  Best of all it didn’t require me re-plotting major elements or the ending, while it made the ending more powerful.

It’s just I didn’t want to do it.

I had this gut-level resistance to re-plotting.  In retrospect it was a dumb attitude to take, and I think it was just that I don’t like to change plans.  I always fear things will never get done.

Then I recalled the Second Agile Principle, which states:

Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

I’m using Agile to manage my life and my writing, and if you’re not familiar with Agile, it’s worth studying up on. Agile is a philosophy of good organization that has inspired and taken guidance from many business processes.  Adsorbing and leveraging change is a big part of Agile (which is kinda the reason for the name).

When I thought of that principle, it struck me how stupid my resistance to change was.  Change was inevitable, so you should find a way to use it.  As I thought it over I realized how beneficial change was:

  • Feedback inspires change.  So being willing to change lets you incorporate feedback.
  • Changes lets you fix problems, perhaps even before they start, making something better (or making something you don’t need to improve later)
  • Change lets you learn.  A changed requirement, the need to edit a story, a new plot idea teaches you something.  Change lets you learn.
  • Change means review, so as you adapt to changes it requires you to review and stay intimate with what you’re writing.
  • Change keeps your mind limber so you adapt.

Notice that most of these relate to the quality of the work.  The ultimate goal of change is to make sure what you’re creating gets better.  If you don’t change, if you aren’t open to change, then are you really sure your work is going to be the best it can be?

What’s interesting is, after I admitted I had to replot part of the story, the new outline is not only better, I had all sorts of insights on improving the story further (most of them far less invasive).  I was also much more aware of the story and it felt more alive because I’d let it change.

I may still have to fight the urge to “write not replot,” but I think this experience has helped me embrace change better as a writer.  Perhaps I’ll have more insight on this in the future.

I probably will, as change is inevitable . . .

– Steve

A Writer’s Life: Cover Me II: Electric Boogaloo

by

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

Sorry for all the delays in actually posting on writing.  been a weird few weeks.  So I want to talk about Book Covers again – with an interesting exercise.

I was thinking about my future writing plans.

First, the covers for the new Way With Worlds books were OK, but I realized I didn’t have the skills/intuition to have made them jazzier.  In fact, I wasn’t sure they needed to be jazzier, and realized I lacked artistic insights.

Secondly, I’ve considered revising and updating some past books, and that would mean covers.  For some I didn’t want to go purchase new art, especially for more niche works.

Third, my “Big Books” usually have paid art.  But what of smaller books, or less “eventful” books?  Sure I could buy a cover, but I had some skills, so why couldn’t I make better covers?

Thus, I set myself a project – to build 30 covers in gimp (because I am cheap) before the end of the year if not earlier.  This way I’d at least have the skills to make a decent book cover, and more than enough skills for books that might not need something jazzier.

I did this by:

  1. Using the free photos at pixabay.com when I need them.
  2. Looking at various book covers and seeing what I could learn from them about what made them “work” – from classic sci-fi to cheese romance.
  3. Finding new gimp techniques and trying them out.
  4. Trying to duplicate different genres and feels.

You can see the results at my tumblr, and I think I’ve definitely gotten better.  In fact, the improvement rate has been pretty remarkable.

This is a great technique to improve anything – build a project with no “critical deliverable” but a goal and try it out.  It could be used for more than just covers – it could be for writing, cooking, and so on.  Take what you want to learn and make a fun project out of it.

However for you indie artists, this may be worth trying yourself.  All you need is the gimp and some photos.  If you build enough skills, then you’re just some time and maybe a royalty-free (or self-taken) photo away from a book cover.

 

– Steve