Agile

A Writer’s View: Timey-Wimey

by

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

Plotting stories, and indeed writing them, is a process of discovery.  A discovery at the end of your tale changes what you think of the beginning.  Closing a scene helps you find a theme that alters the scene.  A character you thought you new surprises you.

Writing, in the words of a certain madman with a blue box is Timey-Wimey.  You finds things out about your world out of order.

We’re frustrated with this because our work feels unreliable, unpredictable, almost as if it’ll betray us.  Ever encounter someone who treated their stories and characters with suspicion?  Yeah, you probably have – it may have been you.

I’ve found that we have to accept this.  Simply put, writing encompasses such breadth of possibilities there’s always a bit of unpredictability, of discovery.  If it’s too predictable, it’s not a creative act.

What we can do is embrace this timey-wimey, acknowledge it, minimize the negative effects, and maximize the positive.

First, be open to the timey-wimey.  Accept that things change, that you’ll have these amazing insights, and that the act of plotting and writing reveals new depths.  This back-and-forth  of do-find-redo makes your work alive.

Secondly, learn to use these insights.  Figure the best way to find them, embrace them, and apply them.  Maybe you keep timelines, maybe you iteratively improve things.  Maybe you have to accept some rewriting.  Maybe you keep extensive notes.  Find a way to make the timey-wimey issues a tool.

Third, don’t fight it.  This is just part of the creative process.  You may have great onslaughts of ideas, or have to accept you can’t tweak a story anymore.  Run with it and make good work first, don’t get lost in frustration or fiddly bits.

Fourth, accept imperfection.  At some point it’ll be good enough to be as good as it needs to be.  Don’t run with the timey-wimey aspects of work so long you’re revising forever.

I’ve found a huge key to using the timey-wimey creativity, and writing in particular is:

  • To improve iteratively.  Engage in gradual review of your work.
  • Gradually deepen your work.  Start with simple ideas and improve them over time, going deeper, adding detail.
  • Every time you go a bit deeper into your work, review the big picture a bit more.
  • Work out a system to do these reviews and do them regularly.
  • Practice!

A lot of this is like Agile practices – which I’ve also been working with.  Agile is about iterative improvements, and is a good mindset for a writer.

– Steve

My Agile Life: Only Me

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

The Blame Game is the bane of good organization, good companies, good productivity, and happiness. Yet, how many times do we blame others for problems automatically? How many times have we been blamed for problems automatically?  How many great projects have failed because people fling blame at each other?

OK we know the answer; a lot.

When I began doing my Agile Life, I had a most interesting experience; I had only myself to blame for anything.  I was the only responsible one when most anything went wrong.

Something was late? My fault. Something not done well? My fault. Very, very few cases of things that wreren’t due to me. To blame anyone else would have required a Herculean effort of self-delusion that I just don’t have the energy or lack of morals for.

This was awesome.

Because I am the major or only cause of failure, I am aware of why things go wrong.

Because I am the major or only cause of failure, I know what to improve.

Because I am the major or only cause of failure, I must acknowledge my flaws.

Because I am the major or only cause of failure, I am the major source of success.

Agile is about a mixture of heavy personal responsibility and team responsibility teaches you a lot about dealing with failure.  This personal Agile experience is an excellent compliment to group Agile because it teaches you that responsibility very, very fast.

I’ve also become much, much more aware of my own flaws and mistakes – what I do wrong, what I do write, and how I screw up. I’m a much better person for doing personal Agile.

Of course it’s also painful. I have work habits that are a bit bizarre seen from the outside (mixing casual, obsessive, distractable, and focused). My Scrum Master abilities focus a bit too much on the rituals with the idea they’ll help fix things “eventually.” My “Product Owner” side can forget my “Scrum Master side’s” recommendations on unfamiliar work and forge ahead on spewing ideas to my “Team Member” side.

But at least I have all these insights. I can’t blame anyone else.

Which is great.  Are you ready to try Agile in your life and learn your flaws?

– 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