Steve’s Update 8/15/2017

(This column is posted at,, and Steve’s Tumblr)

It’s my weekly Scrum style standup for my audience, so where am I?

Well this one is late –  man I have to be more careful.  Though Monday was a bit nuts.

So what have I done the last week?

  • “A Bridge To The Quiet Planet”: Chapter #5 is out, with cops, secrets, demons, and more.  Marigold, Scintilla, and Beacon find out more about Shalen, while Briar Lindel contemplates bad recruiting and living with a teammember with magic-potion-induced flatulence.
  • Way With Worlds Minibook: The edits are done, the cover is mostly done (I just have to go to the final photo).
  • General: I added some better error checking to the Sanctum so people get less annoying 404’s – apparently someone revived a bunch of REAL OLD links (try 3-7 years) somewhere.  My guess is a few sites went live again or links got copied over.

What am I going to do this week:

  • Way With Worlds Minibook #3: Finish the cover and get it publishing-ready!
  • “A Bridge To The Quiet Planet:” Going to take a break writing for a few days due to my schedule, but then back at it!
  • Generators: OK I didn’t release that new generator, let’s see if I can get it done.


  • The unexpected issues have damped down, so cross your fingers.

– Steve

My Agile Life: Be Your Own Best Boss

(This column is posted at, Steve’s LinkedIn, and Steve’s Tumblr)

(My continuing “Agile Life” column, where I use Scrum for a more balanced and productive life continues).

One of the better bosses I had, when seeing a report I had created, noted “Now I understand where we are and I’m worried.”

Why do I say he was a better boss? Because his reaction to seeing disturbing data was to then figure out what to do. He didn’t kill the messenger (me) or berate the team (everyone else).  So, solve the problem.

This provided what’s known as Psychological Safety (, feeling I and we could take risks.  Ironically I was laid off a few months later – as was he – due to other reason.  I felt so bad for him being laid off I forgot my own feelings of annoyance.

Psychological Safety is crucial for good management and good Agile.  Agile philosophy and methods depend on feedback and authenticity so people can respond, communicate, and improve.  Without that it will fail -and trust me, I’ve seen some doozies.

In personal Agile, you’re everyone – the boss, the product owner, the scrum master, the team, the analyst, etc.  Psychological Safety seems to be a bit irrelevant here.

But I realized it’s not.

Ever berate yourself for mistakes?  Ever beaten yourself up over missing something?  Hard on yourself?  You probably have done all of this – you haven’t provided yourself with psychological safety.  You’re being the Bad Boss to yourself.

This is very common.  This is probably near-universal.  I’ve encountered many people who beat themselves up constantly, and worse of all excuse it.  They’re their own battered spouse, their own abusive parent, their own tormentor.

Honestly, a lot more of us probably need to be in therapy.  But back to Agile before this gets too depressing.

To be productive, you need Psychological Safety, even in your own personal life.  How can you achieve that?  A few things I’ve found:

  • * Honesty.  Be honest with yourself self, admit your mistakes and flaws and issues.
  • * Cooperation.  Work with yourself to improve.  Coach yourself.  “You” are on the same team.
  • * Enablement.  Help yourself get better so you don’t repeat mistakes and can improve.
  • * Review.  Review what you do to improve what you do.  It becomes regular, it becomes habit.
  • * Empathy.  Let yourself “feel” what you feel, its like having empathy for others but you’re taking a look at yourself.
  • * Humor and fun.  Learn to have fun, let yourself have fun, enjoy things.

It’s not easy.  But it’s better than the alternative.

Being your own worst enemy is, well, the worst.  This is because you can never get away from yourself.  How about being a good manager to yourself instead?

(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: Overwork

(This column is posted at, Steve’s LinkedIn, and Steve’s Tumblr)

(My continuing “Agile Life” column, where I use Scrum for a more balanced and productive life continues).

Uhg.  So as you know from my blogging about agile techniques, I’ve been getting overloaded.  I’m trying to fix this with some success.  So here’s what I’ve been trying.

  • Velocity.  Velocity, the measure of work done in a timeframe, is a big part of Scrum.  One reason to measure it is to see what you can do – but another is to make sure you’re not overloaded.  I can tell my usual workload doesn’t quite work out, so I’m trying to reduce it a bit here and there.  EXAMPLE: Restructuring how much I put into a given project a month.
  • Effectiveness.  Do things better.  I’ve found you can also save time just by doing stuff better.  EXAMPLE: I made graphic templates for upcoming graphic work.
  • Letting go of the schedule.  Work done on time doesn’t matter if it’s poorly done.  You have to re-evaluate and re-assess your schedules and in some cases dispose of them entirely.  EXAMPLE: I had some library donations to make that kept getting interrupted, so I had to accept “it gets done when it gets done.”
  • Iterativeness.  The flipside of efficiency is to not try to be perfect.  Some things are iterative, things you do over and over or regularly.  These can be improved, or mistakes compensated for.  EXAMPLE: Cleaning.  If I miss a hard water stain in the shower it won’t kill me as I’ll fix that next week.
  • Capture.  Be sure to capture any big blocks of time you want to use for something.  EXAMPLE: I have some convention speaking coming up so I literally put it in my schedule as a big block of time to note “I will be doing nothing else then.”
  • Sizing.  I’m sticking with the Fibonacci numbers for sizing my work – in hours – as it seems to produce better estimates.

I’ve also looked at things that mess up my planning and scheduling and productivity.  The Antipatterns.  They are

  • Loading Up.  When you find your maximum velocity of work, it doesn’t mean it’s what you should do.  It’s what you’re capable of when you push yourself.  What is you sustainable rate?
  • Lumping.  When possible break things down so you can calculate your workload – and because it lets you adapt better.
  • Missing lumps.  Some things are just purely about a time commitment, like “setting aside X hours to relax.”  Some things are better lumped together just so you’re not micromanaging.
  • Not looking at value.  When you do something ask what makes it useful – believe me there’s some surprises in there.
  • Bad Deadlines.  Again, deadlines should serve quality, not the other way around.
  • No goals.  When you don’t have goals, you can’t plan.  We often substitute panic, deadlines, etc. for goals – those aren’t goals.  Goals are positive.
  • Done over quality.  Doing something fast poorly can be worthless.
  • Rigidity.  Agile methods are about embracing change, and if you have to keep things rigid, you’re not Agile.  You need to find ways to be adaptable.

Hope these help you out.  Something to look out for in your own life – and anyone you manage.

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

– Steve

Steve’s Update 8/7/2017

(This column is posted at,, and Steve’s Tumblr)

It’s my weekly Scrum style standup for my audience, so where am I?

First, apologies for missing another start-of-month update two months in a row.  It’s like I forget to do a post on those times, and will try not to do that.

So August’s goals are pretty much get out the Way With Worlds Book 3, keep writing “A Bridge To The Quiet Planet,” and I may get out a generator or two.

So what have I done the last week?

  • “A Bridge To The Quiet Planet”: Chapter #4 was released to my pre-readers.  Remember if you want to pre-read, let me know.  Plus I also integrated a lot of feedback – what I’m doing is, as feedback comes, reviewing past chapters to correct any mistakes or common mistakes.  Definitely helped, but a bit draining.
  • Blogging: I recorded more blog posts – so as you can guess, more is coming!  I have some pretty interesting stuff coming up!
  • Speaking: I spoke at Kin-Yoobi con (and really I gotta post the Asian Cooking Hacks handout).

What am I going to do this week:

  • Way With Worlds Minibook #3: I’m going to do the cover and hopefully the edits.
  • “A Bridge To The Quiet Planet:” General writing, finish up Chapter 5 and probably do some more fleshing around of the plot to incorporate some changes I came up with.
  • Generators: I’ve actually got a new generator queued up and I plan to launch it.  I think I may do “funnier” generators for the rest of the year, take a bit of a break.


  • Fair warning this month opened with a lot of unexpected issues; friends moving, friends having job changes, friends with family health issues, etc.  So I might see some interruptions.

– Steve

A Writer’s Life: Writing And The Models

(This column is posted at and Steve’s Tumblr)

My friend Serdar was discussing why we write and why it’s valuable.  If you haven’t read is stuff, scope it out, his Flight of the Vajra is one of my influences to write again.

He talks about why some writing fails at a point, and how writing is a way of modeling.

The tough part is for that model to be properly informed by real human behavior and real-world facts. Most of the bad writing I’ve encountered is either ignorant of the way the world works in its most mechanical aspects, or depicts models of human behavior that are either too flat or too ludicrious to pass for the real thing, or (worst of all) both of those things acting in concert.


He’s right on many flawed works – yet also we see flawed works be enjoyed by people.  All of us may enjoy some flawed or just outright shallow stuff – not in the MST3K/Rifftrax way – but we really enjoy them.  I know I’ve enjoyed my share of, let us be frank, pandering B.S.

I think some things appeal to people – even with flawed models of behavior and world – due to audience participation.

On the “lowest” level a story may be very flawed, but if it tickles our sweet spots, we enjoy it.  Perhaps there are many guilty pleasures here, but also things that may be profound at least in what they tell us, moments of artistic madness.  We bring these stories to life because they fit our desires.

Then there are stories that are very trope-filled. Because they’re familiar, we may enjoy them, even when they’re not exactly realistic or believable.  Our “suspension of disbelief” is a high-wire act, but because familiar themes are involved, we embrace them.  Cultural and media tropes bring these stories to life, and we power them with our belief.

Finally, there are stories and settings that come alive due to the way the creators work.  The things we “get” even if they may be alien or bizarre or unfamiliar.  These are rare and powerful works at their best.  They come to life because the creator makes something believable, even if we may have trouble relating to it, and we bring it to life because we “get” what’s going on.

Perhaps when writing, we should set goals for how we want the work to come to life.  Many of us may aspire to the last category, but there may be nothing wrong with a lot of tropes or some pandering if other ethical/personal concerns are addressed.

– Steve

A Writer’s Life: Big Rocks II: Electric Boogaloo

(This column is posted at and Steve’s Tumblr)

I recently ran into a case of getting blocked in my writing.  It was weird, things just felt “wrong.”  I wasn’t happy with a scene.  Some plot elements seemed off.  Editing earlier chapters felt odd.  I was writing, but it felt stuck.

So I took a lok at how I felt.  I didn’t even to need to use the “Five Whys” because I quickly realized what this sensation was.

It was the Big Rocks.

Big Rocks, which I wrote about, are those parts of the story we’re so stuck on they hold up the evolution of the story.  They literally weigh you down because if you changed, removed, or broke them down the story would be so much better.  It doesnt matter how great an idea or scene is, if it holds your story back it should be gone.

Way back when I became aware of them it was a case of plot idead and scenes acting as my big rocks, keeping me from getting going.  Now I had written scenes and chapters and . . .  you got it . . . was unwilling to change them.  *What I had written had become a bunch of Big Rocks holding me back.

Realizing that was a relief.

  • Suddenly two characters that seemed partial became one character, who changed the entire game yet made the plot MORE intact.
  • Thanks to the first item one character gets a hilariously annoying fangirl.
  • A few rearranged and blended scenes made everything flow better.
  • A throwaway Nasty Monster got changed to a different kind of Nasty that set the plot better.
  • Became aware of a lot of subtle themes as I write, and it seems there’s always more.  Now the story includes themes of PTSD, heroism after the fact, and the need for trust.
  • One character who faded away became a bridge to another plot element, furthering the theme of “smart people doing smart things with stupid results.”  I like him so much I may bring him back in a short story.

Writing is never solid.  It reminds me of a story I heard about a martial artist who challenged someone to bend his arm.  This martial artist adjusted his arm and stance ever so slightly, constnantly, and thus countered every attempt to force his arm to bend.  It was like an ever-adjusting flow of water, powerful yet subtle.

So, be that flow, get to your destination by bending whenever needed to get there – and you become both immovable yet adjusting.  You just go around the Big Rocks – and wear them down.

As a side piece of advice, I think cultivating this “flow” attitude early in any piece is needed.  You’ll constantly adapt and adjust, and it’ll become habit.  It’s rather Agile really.


– Steve

My Agile Life: The Line Isn’t So Dead

(This column is posted at, Steve’s LinkedIn, and Steve’s Tumblr)

(My continuing “Agile Life” column, where I use Scrum for a more balanced and productive life continues).

Right now I’m doing Agile methods in my own life, specifically Scrum.  This has been very successful, both in terms of becoming productive, but also in truly understanding good process and productivity.  However, I often felt (and feel) odd bits of discomfort, concerns over things being late, and so on even though I had a great grasp of how things were going.

Why am I worrying despite having such visibility into my own work?  I literally know my plans for a month, I can adjust on the fly, I have a backlog/roadmap fusion?  Why am I worrying?

This article on Kanban made it clear –  I was still focused on deadlines.  Wait, deadlines as bad?  Sometimes.

Think of it this way.  Agile methods are about adaptability and doing things right – a lot of good productivity methods are the same way.  The thing is if you focus on the deadline, you often forget about doing things right – and you stress yourself out.

For example, my fiction book.  I have a “deadline” for this that’s set purely in my head for very little good reason.  This deadline has smaller deadlines.  When I stepped back I realized that these deadlines were arbitrary and affected my productivity and work breakdown.  Getting back into the swing of fiction was a bit of a challenge, and arbitrary constraints kept me from focusing on my craftsmanship.

Instead I had to ask not just when things had to be done, but what’s the most productive way to approach my work – all work.  Not just a book, or cleaning the bathroom, or anything else.  What’s the most important things to do and how do I do them effectively was more important than a given deadline in most cases.

Sure the deadline mattered, but unless the deadline was truly more important than doing it right, it wasn’t a worry.  By the way, the book may also be about a month later than I predicted.  You can guess why.

This is a subtle part of Agile methods, and one I missed.  Scrum may have it’s timeboxed sprints, but is always re-prioritizing.  Kanban focuses on Work In progress with priority in the background. Most agile methods are not compatible with our old ways of thinking where the deadline has to rule everything.

Sounds weird.  Ask yourself this – what if you had a choice to do a good job but it’d be late or done in parts, or delivering something bad on time?

As an example, let’s say something has to get done at the end of the month.  You of course rush this and do it early – but is it the best thing to do earlier that month?  Could it delay other work that backs up on you?  Could it be you need to do it in stages to get feedback to get it right?  What if making it a week late made it far better?  What if you did part of it and got feedback and did the second half the first week of the next month?

Also the focus on the deadline may make you miss doing things right.  Consider this – if you focus on doing something well, won’t you get it done quicker, especially over time?  Won’t it last longer?  Won’t focusing on quality and work first, ironically, mean you’ve got a better chance of hitting the deadline (or at least being more on time later)?

Now back to my writing.  I had gotten so focused on my deadline I hadn’t thought about the best way to do things – and as I improve/polish my fiction writing, I need a bit of “space.”  So I set aside a block of time a month to work on the novel, each task takes some of that allocated time.  I can adapt to tasks and needs of this highly chaotic effort. Now when I decide what task to do then I focus on quality and careful sizing, but I’m not overplanning around a deadline.

(Eventually, as I improve/polish/shake the rust off I probably can be more scheduled).

In all Agile methods, to one extent or another (less in Scrum, more in Kanban), you focus on the best ways to be productive first.  Letting old ways of thinking about when things are due or deadlines can, ironically, interfere with results.

I’m not going to knock deadlines.  They have their place.  But when they interfere with doing good work, you have to ask just how much value they have . . .

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

– Steve

A Bridge To The Quiet Planet: What It’s About

(This column is posted at and Steve’s Tumblr)

I’ve been posting about my writing here a lot.  So, with intermittent updates, I’m going to talk about my fiction writing project, “A Bridge To The Quiet Planet.”

First of all, yes, fiction.  I’ve not done public fiction in awhile – but I did side projects, edited, coached, and did stuff for the Sanctum.  I figure it was time – and it’s fun.  If this works, I plan to split my time between fiction and non-fiction.

And what’s it all about?  To sum it up in one sentence:

A sorceress, an engineer, and a priest on a planet-hopping road trip with the owner of a mysterious collection of holy books.

The idea came together when I got inspired to write, contemplated a few past projects and some recent anime, and came up with a simple idea – what happens when you take a world of magic and monsters, gods and spirits, and technology evolves as well?  Welcome to the world of Telvaren and it’s planetary colonies, a nation of science and sorcery, where the gods use the internet and interplanetary travel is done via techno-wizardry.  Politics is driven by a mixture of gigantic cities, assorted guilds and unions, and divine interests – but don’t let the present distract you, because there’s a past of mysterious artifacts, demons, dragons, and more waiting to be discovered . . .

Into this comes Marigold and Scintilla, a sorceress and a “technic” who act as a freelance techno-magical hazmat and research team for the wizardly guild Phoenix Ascendant.  They have “A Plan” for their careers, which requires them to get into a lot of weird situations to gain influence with the guild.  They’re good at getting into and out of trouble – until someone wants to hire them not to find something mysterious, but to help him carry a set of holy books to Godsgrave, the world where deities go to die.

Also, it’s a lot of money.

Soon they’re outrunning a special branch of the Military consisting only of people who’ve lost loved ones, what may or may not be a demon escaped from the prison-world of Pandemonium, and some mysterious individuals spreading stories on the Network that connects people.  No one is what they seem, no one is quiet telling the truth, and the dumbest things can be done by people who are very smart . . .

So it’s up to Marigold and Scintilla to punch, talk, shoot, conjure, run, lie, and plan their way out of trouble.  They’re going to get their client to Godsgrave by hook or by crook, because as crazy as things get, the two people they are sure they can trust is each other.

I hope you’ll all enjoy it, and I plan to post more on my blog – I think what I’ll do is alternate posts on the story with posts on my writing findings, give or take.

– Steve

Magic, Technology, And Worldbuilding is Out!

It’s out!  The latest of the Way With Worlds miniguides, this one on Magic and Technology – because for the sake of worldbuilding, they’re usually the same!

Each book contains 50 questions on the specific subject, plus a bunch of extras, to help worldbuilders think, ponder, and design.  Think of it as a personal coaching session in a book!  On top of that, each is only 99 cents!

To celebrate, the flagship book, Way With Worlds, is on sale for a week!  It’s your chance to pick it up!

So go on, give it a spin – and remember, more are coming . . .

– Steve

My Agile Life: By The Numbers

(This column is posted at, Steve’s LinkedIn, and Steve’s Tumblr)

(My continuing “Agile Life” column, where I use Scrum for a more balanced and productive life continues).

Let’s talk estimating how much work something takes. This may sound boring, it will get abstract, but stick with me here – it’s pretty interesting.

I’m using the Agile method of Scrum in my own life, which involves sizing work to know how “big” it is. If you’re not familiar with Agile practices, just know this is an area where pros argue a lot, so if you think we’ve got it figured out, you’re wrong.

I size my personal work in terms of hours to complete because I’m self-aware enough to get those estimates reasonably right. It’s not perfect, and I wanted to get better. I think I found a solution while reading The Elements Of Scrum as a refresher, because the authors explained the challenges of sizing work better than I’ve ever seen.

Again hold on here, because we got some backstory.

In Scrum (and related methods) work is often sized in abstract points – the smallest piece is a one point, something twice the size is a two, and so on. Then people figure out how many “points” of work they can do in a given time – and this often works very well (I’ve seen new teams get it 80% right out of the gate).

Why does this work? Because people are great at relative sizing (this is twice the size of that thing) but not so much at doing specific time estimates. Leverage this ability and people get an idea of how big (or small) work is, and they can then do a decent job of figuring what can be done in a given time. Sort of zooming from general to specifics.

Sounds simple? It is, but many Scrum practitioners require points to be in the Fibbonacci sequence – 1,2,3,5,8, and so on. So something twice the size of “1” is a “2” – but if something is twice the size of a “2” you have to call it as more likely to be a “3” or a “5.” Sound weird? There’s a reason.

The author explained it simply that drove this point home:

  1. People are good at comparing the sizes of small things but have trouble with larger things. This applies to time take to sizes of physical objects and more.
  2. #1 gets worse the larger the things being compared are.
  3. You use the Fibbonachi sequence as the range between “allowed” sizes gets larger and larger, forcing you to make a judgement call and giving you a bit of buffer.

Where does this come into my time estimates? Well my time estimates weren’t bad, but they weren’t great. I also didn’t want to use points as some of my “life stuff” was far better measured in hours. So I started using Fibbonaci sequencing to estimate hours of work because this simple explanation made me realize I’d falsely thought I could estimate large stories as easy as small.

So right now the smallest piece of work is one hour – but I can’t say something is six hours, I have to ask if it’s more likely to be 5 or 8. Sure there’s probably over and under-estimation but it evens out.

I started doing this late June and in full this July – and it was an eye opener:

  • In larger pieces of work, had I used Fibbonachi numbers on big things, those would have been more accurate. Yes, some of my estimates were worse when I tried to be specific instead of using some constraint like “is it closer to 5 hours or 8”
  • Some of my fiddly little estimates (45 minutes, 90 minutes) were less accurate than their Fibbonachi counterparts.
  • My best estimates happened on things that were 2 to 3 hours long – fortunately the majority of my work. However there was enough “mis-estimation” in large and small items to probably throw off my monthly estimates by around 10-20 hours.
  • Items that were 8 hours or more were a warning sign to break things down – those were often woefully inaccurate and hard to work with.
  • Items that I did break down usually surprised me – there was often more work than I thought.  Breakdowns (again, using Fibonacci) were more accurate.

I’m going to be sticking with Fibonacci hours for now – maybe you want to try this in your own life, even if you’re not using Scrum or Agile techniques.

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

– Steve