failure

Horrible Enough, Done Enough, Enough to Learn

by

(This column is posted at www.StevenSavage.com, Steve’s Tumblr, and Pillowfort.  Find out more at my newsletter, and all my social media at my linktr.ee)

We’ve all had a writing or other creative project we want to abandon. Now in some cases, it’s a good idea, but I wish to suggest you may want to finish that awful thing. There’s a value in finishing work because then you can learn from it.

When you finish something, as flawed as it may be, it is a complete product. That gives you enough information to evaluate what you did right, did wrong, and can do better. Yes, it may be terrible, but it’s a terrible that you can search for lessons.

So when you look at that crime against your art, ask how you can get it finished enough to learn from. Think of it as a Minimal Viable Product, just one where the word “Viable” is doing a lot of heavy lifting. Minimal Tolerable Product, perhaps.

Now you may find, once you complete this, it’s not as bad as you thought, then that’s great! Maybe it’s good enough to use, perhaps after a heavy edit. But what if it’s not? Well, then it’s filled with lessons to learn.

It’s hard to evaluate something unless you’ve gotten it to a complete-ish state. A completed work – flawed as it is – is at least consistent and coherent enough to tear apart. Within it, you see your mistakes, your choices, and perhaps your virtues in ways unfinished work won’t show. Sure it’s ghastly, but there’s got to be something to salvage.

In fact, by completing that creative atrocity, you might be able to break it down for parts. It can be redrawn, rewritten, or recoded. But once again, you might have to complete it to get it to that state.

So don’t throw out that crime against imagination quite yet. Ask if it’s worth completing, if only to be a warning to yourself. You might be surprised what you get out of it.

Steven Savage

My Agile Life: Eat Failure, Not Your Peace Of Mind

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

Doing Agile in my personal life taught me how to fail. You’d think at my age I’d have plenty of practice failing, but there’s always something to learn.

Ever obsess over a problem or mistake? Of course you have. We make mistakes then play with them in our heads over and over even while we fix them, berating ourselves as we do so. Even when the mistake is fixed, the self-flagellation may continue afterwards.

This is terrible for our peace of mind. Every minute spent in worry is a minute not spent doing something else. Worry can eat up so much time that we get less done – which only makes us worry more.

In business, we’re familiar with the equivalent of this worry; blame game and paralysis through analysis. A department or group becomes so locked up by blame-flinging and over-analyzing nothing gets done. Such a department is as trapped just like person locked in an endless cycle of self-loathing. In fact, I’d say it’s pretty much the same thing

In doing Agile for my personal life as well as work, I came up with the term “Eat Your Failure.” Agile methods use failure to fuel improvement. Failure’s not just part of the process – failure powers it. Failure is actually not bad (well, not entirely).

This has helped change my attitude towards failure in a very short time, and am finding it fear of it starts to diminish. I’m far more aware of when fear of failure or annoyance with it drains my time. I’m less upset with it because I take an “eat your failure approach.” By treating failure differently, I have much more peace of mind and get more done.

(Trust me, on the novel I’m working on, that’s such a change of pace I get lots of fear of failure.)

In large organizations, this “eat your failure” mindset is as important if not moreso. If I get obsessed with failure and don’t think in Agile methods, I can slam a beer or go to therapy. In an organization, bad attitudes towards failure can become part of culture and outlast the people there (and their supplies of beer and therapy). Worry can become institutionalized.

Taking a positive or at least progressive view of Failure doesn’t just bring efficiency. It brings peace of mind.

Of course in our lives or in our jobs, we have to make sure that’s part of our culture, be it just us or an entire company. It’s up to us to make that change and encourage the change in others.

But honestly, how many people or businesses would be much happier if they just said “Let’s live with failure and improve” over obsession and guilt and denial?

Yeah, we know the answer.

(By the way I do plenty of books for coaching people to improve in various areas, which may also help you out!)

– Steve

My Agile Life: Failure

by

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

I’m talking my “Agile Life” experiment where I use the Agile techniques in Scrum in my everyday life.  Well, it doesn’t always work, so let’s talk failure – specifically something that went bad this Sprint of May.

As you know one of my goals for the May Sprint was to plot a new novel and write chapter 1. That has partially failed – which is a great time to examine what I did wrong and talk failure.

Agile methods are all about learning as opposed to shame.  We all make mistakes, we all have discoveries of what we didn’t know, so the goal is to learn and adapt.

So first, let’s see what happened:

  • I was going to start a new novel, “A Bridge To The Quiet Planet,” an SF/Fantasy mix.
  • I was going to use a lot of the techniques I’d used before to write it – heavy setting detail, iterative plotting. Just on a larger scale.
  • I found things not feeling “right.” The plot was stale, parts came and went, I didn’t feel I had a grasp on the story – I had about 60% of it but something felt off.
  • After analysis I realized I didn’t have a good a grasp as I thought, it wasn’t quite “alive.” There were good parts – there were *great* parts. But it felt half-made.

So now the questions come in – “Why.”

There’s a great technique called “The Five Whys” that I learned – basically to solve a problem, ask why – and when you get an answer, ask why again. Soon you’ll get to the cause, part of the cause, or one of the causes.

  • WHY did it feel wrong? Because it was. It was patchwork.
  • WHY did it feel patchwork? Because some parts were far more fleshed-out than others and they conflicted due to that.
  • WHY are they half fleshed-out? Because my designing was erratic.
  • WHY was my designing erratic? Because I dived in and didn’t think of what I needed to do as a specific set of tasks.
  • WHY did I do that? Because I didn’t think I’d need it, I’d just dive in as I’ve done this before.

I came to realize I got a bit arrogant. I’ve written and built worlds for 40 years. I’ve published books. I should be able to dive into this right because I’ve done so many similar things?

Yep, I should – if I had thought ahead. But I didn’t think about what was needed, didn’t look at my techniques, didn’t break down the work. If this had been a programming project, it’d be the Product Owner and an Engineer saying “hey, we know how to do this easy, so let’s just block out some time” without the Scrum Master saying “why do you think this doesn’t need the usual level of analysis?”

What I should have done is use all my techniques and experience to design a better plan – how long it’d take for this tasks, what tasks were needed, and so on.  It would have made me think, made me more aware of the work needed, and how that work tied together.

Lesson learned – in writing, like anything else, a good work breakdown is needed.  Just because you might be able to do it “from the gut” is no reason not to think it over – especially when you’re getting back in the swing of things.  Had this not been a novel but a shorter work I might not have caught this mistake.

Now of course after finding this the goal is to get back on track. How am I doing that?

  1. I will focus this month on plotting – any time meant for Chapter 1 now moves to plotting.  That helps me get a timeframe.  It’s still adding work to my sprint, so I may move out other plans – since getting this done is important, and spreading it out too much may mean it loses coherence.
  2. Writing is moving out by one month at least – maybe two.  But I’ll try to do Chapter One next month and then slowly ramp up.
  3. To plot the book I am breaking it down into tasks required to get a full plot outline that I can write from.  It’s really more of a product design process or a research task.  I may write up more on that depending how it goes.

The story quality is already looking much better, and I learned something about my own creativity. Also the story may have a slightly off kilter Technomancer riding a motorcycle on top of a moving train, so there’s that.

A good lesson on many grounds.

– Steve