productivity

An Experiment In Perspective And Productivity

by

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

By now if you read my blog or my posts anywhere you know I’m kind of obsessed with Agile philosophy, Agile methods (Scrum with a heavy helping of Kanban), and I use them in my regular life. I’ve started experimenting with some of my practices and wanted to share my findings.

So first up, my basic way of being productive is a month-long sprint (a period of time where I decide what I’ll do and focus on that). With that focus I’m able to avoid distractions, measure success, and know what’s coming.

Secondly, I estimate the work I’m doing in hours, trying to break things down to manageable chunks of a few hours. My exception is writing, where I set aside an “hour budget.”

OK with that said, I began noticing a few problems I experienced. Tell me if these sound familiar.

First, as life has been complex, I felt overwhelmed. There was a lot on my plate for each month. I’d often try to “front-load” work.

Secondly, because a lot’s been going on, I was often having to shift around work and priorities. That was annoying because, yes, Agile says to embrace change for productivity, but I wasn’t feeling any gain, I was just changing. Was I wasting my time?

Third I got into a good rythm, but found myself over-focused on measuring hours and time. I was investing a lot of time in trying to measure time. This was also weird as I had things so well broken down I wondered why I fiddled with hours.

I have no doubt some of this sounds familiar.

So I sat down with myself, dived into the classic “Five Whys” method I’ve reccomended, and asked what happened. The answers became immediately apparent:

  • A month-long sprint had so much and was so broad it was unweildly and didn’t acknowledge how each week was different, and it was hard to change.
  • My estimates in hours were “too real.” Thinking of things as hours led me to spend too much time trying to map “real time” as opposed to getting stuff done. So I was actually less efficient because of asking “is this an hour or not.” Another reason the whole Scrum “points thing” makes sense.

So now I’m experimenting with a few changes to help me be productive and also lighten me up a bit.

First, I’m now doing classic two week sprints (Monday to Monday). This takes me out of monthly thinking, focuses on a smaller time frame so I can better evaluate what I should do, and makes it easier to adapt. This has already been a godsend in focus.

Secondly, I’ve – yes – ditched time estimates and Fibonacci points. Because I’ve gotten really good at breaking work down, I’m now just treating everything as “things to do” and breaking them down to the smallest components. For things like writing, I’m giving myself “X writing sessions” each sprint to sit down and write. Then I just check off “done.”

I’ll let you know more about my findings (and I may need to update my Personal Agile book).

However, I do want to answer an unspoken question: do I regret my earlier productivity techniques, with month-long sprints and so on? No.

What I did worked for the time. It got things done. It also let me learn so I could keep improving what I did. It may even be that worked then but I had to find a different way to do things now.

It’s OK to change how you operate and get things done. Doing things is how you learn to do them better.

Steven Savage

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

Agile Creativity – Principle #7: Usable Work

by

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

We’ve passed the halfway points! We’re now on the Seventh Principle behind the Agile Manifesto. It looks simple, and in fact is simple, which means I’m going to go on at length about it. Let’s take a look:

Working software is the primary measure of progress.

Yeah, it’s pretty clear isn’t it? I’m very fond of it because the idea is the measure of progress is something that actually works. No maybies, no charges, no plans, no mockups. Something that works is how you measure progress.

But let’s tweak it a bit for creatives, since creative work involves a wide range of stuff from art to presentations to films.

Usable products are the primary measure of progress.

There, not much of a change, but we broadened it out. You measure progress primarily by giving people things that are usable.

Now of course, I’m going to analyze the heck out of it.

You measure progress with something people can use – even if imperfect

Your efforts should focus on giving people something they can use and experience – that’s it.  It’s usable/working/review-able or whatever you want to call it.  That does not mean it is:

  • Complete.
  • Ready for public release.
  • Ready for all of your customers to use.
  • Even that good.

You may deliver work that’s incomplete and lousy, but at least each embarrassingly bad delivery there’s something people can use to give you feedback.  You will improve it over time.

As you may guess this means . . .

Delivering usable product means feedback

Giving people something they can use, no matter how incomplete or half-baked, at least means you’ll get feedback on it. It may not be nice feedback, it may mean a lot more work, it may mean a change of direction. But at least you know what to do next.

So the more often you deliver, the better you do getting people to their destination – because you learn how to better get there.  It’s a lot like navigation – in fact your customer or client may learn about what they really want once they have something they can really experience.

But it’s not just people who give feedback. You and your team give each other feedback. If it’s just you, then YOU give yourself feedback (even if it’s “that was dumb”). You also learn by making something usable as opposed to reaching abstract deadlines and milestones.

There’s nothing like having to make something workable to really learn what you have to do, and what you shouldn’t have done.

Now to do this . . .

This almost always means iterative development – so plan for it

So as you’ve probably guessed from reading so far, this Principle really hearkens to iterative development. You measure progress with usable product, so you’ll be delivering useable product over time – probably improvements of previous deliveries. That’s pretty common in Agile, obviously and we’ve already discussed it.

But this means that anything useable you deliver is something you should plan for and keep in mind. Don’t just work on something, work on it in a way that helps you give actual results as often as possible. This could mean:

  • Constant refinement, like putting a logo through more and more iterations.
  • Delivering in usable parts, like a costume where each piece is complete (and, say, at least display-worthy).
  • Delivering in review-able parts, like a piece of writing where each chapter is something that can be edited.

So you can keep getting work out, do that work in the best way that keeps delivering useable results. Because when you do that . . .

Usable Products Are THE Way to Measure Progress

Delivering usable products is the way to measure progress. There’s the obvious ones of “this customer is happy,” but you can also use this to get a bit more mechanical and procedural.

  • If you have a list of features for something, like perhaps a game, as you deliver them in prototype, you can check them off. Yes, some may be wrong or changed, but you can get a rough idea of progress.
  • If you are aiming for certain numbers, such as a performance score or loading speed or image size, then you can measure them – with workable product.
  • Of course, you get abstract feedback from others, maybe customers or even beta testers and early access users. They might provide other quantifiable forms of feedback, ranging from yes/no responses to answering polls and questions.

From simple lists of features to complex analysis, usable product is not just a way to measure results in general, but gives you a way to get specific results, maybe even complex ones that need some number crunching.  Thinking in deliverables and producing them gives you access to a wealth of data.

Though I wouldn’t overdo it. This is Agile after all, let’s not get complicated.

Rounding Up

Let’s review the Seventh Agile Principle for Creatives:

  • Frequently produce something usable for your audience, no matter how imperfect.
  • Iterative development is the best way to do the above, so organize your work accordingly.
  • Because you are delivering something usable, you’ll get feedback and learn, meaning you can produce a better product.
  • If you need to have deeper analysis, working products are a great way to do it.

It’s another simple principle, but it’s really great advice – progress is producing something.

Sounds like you could overload yourself with trying to constantly get stuff out, right?  Well, let’s move to the Eighth Principle . . .

– Steve