workload

Work That Isn’t Work

by

(This column is posted at www.StevenSavage.com and Steve’s Tumblr.  Find out more at my newsletter.)

Last month started productively – but then got brutal. I got sick, I had to reprioritize, and was annoyed a side project had to get delayed (sorry, no spoilers). Something felt off about what was going on, so as I sat there battling allergies and a cold I caught because of allergies (really, that kind of week), I wanted to figure what was off.

Why did I feel bad, overpressured, and even when sick not want to do my fun projects like writing and generators?

I used the “Five Whys” technique. This is a good one to learn, but in case you don’t care, you ask “why” about your situation, then “why” to your answer, then “why to that answer,” and so on. Eventually you get an idea of what’s wrong and how to solve it. It’s like having a helpful child in your head to pester you until you explain something, and like talking to a child, it’s a way to realize how smart or how stupid you are.

I’m quite fond of it.

This took more than the supposed “Five” whys, but I realized something amazing and liberating – I had lumped all my “work” in a month into the same pot. Cooking and working out was the same priority, a fun piece of writing was just as important as my weekly budget. All the things I wanted to accomplish were sitting in one pile saying “do me,” so I began treating all things the same.

The problem with treating all things you have to do as the same is that you don’t prioritize (or in Agile terms, you forget their value). In fact, you sort of end up with a worst-common denominator effect where you treat everything as a collection of the worst – often conflicting – traits. Everything was a boring and overwhelming must-do task that was also not important.

At that point I realized my organization had killed my motivation. So how did I solve this? I broke them up by relevance and changed them on my own Big Visible Chart.  OK it’s a spreadsheet, but still.

First, are the must-do tasks for a month. These are important life tasks that I want to do and do as soon as possible and most are repeating.. My motivation is “I really better do these.” Now I know what has to get done, and I’m motivated to do them out of importance. Also there’s less than I thought so that helped. In my list of work I marked them “hot” colors – yellow for do at the start of the month, orange in the middle, red at the end.

Second are the important things to do for a month that are kind of regular maintenance; blog posts, cooking, working out, and maybe some lower-priority stuff that’s added for the month. These things can shift around, but are also the “daily grind.” Seeing this made me realize a lot of them can be done reguarly and over time – in fact many have to be (I’m not going to cook 80 meals at once or workout for 15 hours in one day). I saw that these could be paced, that they didn’t need to build up – and that I should never see this as a giant task to surmount, but one that’d be done over time.

Third but not finally is my creative work – books, the Sanctum, other projects. These are things that I do in addition to “life” stuff – and they’re the fun things. I didn’t overload this for the month of April, but may add more. In my chart they’re green.

Seeing it like this made me see what I’d done wrong:

  • Trying to spread out my most vial (“hot” colors) work as opposed to getting it out of the way or just doing it at the right time and not worrying about it. I had a gut feel that this was wrong, but this helped me put it into words.
  • Being unsure how to pace my more regular tasks like cooking and so forth (blue). Because there was so much, I kept trying to do all of it and feeling overwhelmed by this big pile of “stuff”. Really the pile would decrease over time.
  • Viewing my more fun work (green) as labor by conflating it with regular tasks. I had treated it like other work, trying to fit it into other things to do. Now I could see this wasn’t a grind – this was stuff to do when the other work is done, caught up, or has just bored me.

So what solutions did this give beyond solving my issue:

  • For the vital work that has to be done at the start of the month, my goal is to get it over with early, even if it’s a bit of a haul.
  • For vital work due other times in the month, I don’t worry about it until I have to.
  • For the regular grind, pace myself. Don’t let it overwhelm me, or try to get too far ahead of it.
  • For the fun stuff, I realized now that I’m aware of it, I can make space to do it when I want to relax, when I want to get it done, or when I’m caught up on the other work.

Ironically, I think I’ll get more done since I’ll be less stressed, less juggling work, and have better priorities.

So your takeaway, know your priorities and what work means to you. It’ll help you get the vital things done so you’re not distracted, pace yourself with the regular grind, and be aware when you can/will/want/should do your fun stuff.

– Steve

My Agile Life: By The Numbers

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

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