getting things done – Steven Savage

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

I love productivity methods. “Getting Things Done” inspired me to become more organized, and I developed my time-management methods using Agile. I strongly encourage people to find productivity systems and build their owns.

I also recommend you change them up when they don’t work.

This is something people forget a lot when talking about personal productivity. There’s always advice about what to do, how to do it, but never when to stop doing it. When in all that creative advice is that gentle talk and metaphorical hand on the shoulder where someone says “by the way, here’s where you stop listening to me.”

I’ve encountered this in my own life – obviously. Lately, I’ve had to resort my priorities, change my methods, and adapt to new plans and new challenges. I’ve had to reshuffle how I work, from my regular cadence to how I prioritize and track work. As it’s in progress, I’ll discuss this once my methods settle.

But what I do want to discuss is why you should look at your methods and planning techniques, at all your charts and reviews, and learn when to stop doing them.

And when do you stop doing them and try something else? Simple. You change up whatever your productive methods are when following the methods gets in the way of getting things done. The goal of your processes is to get your projects completed, and when however you do that work gets in the way, then throw it out.

Here’s how your current seemingly-brilliant methods can get in the way.

They don’t fit your lifestyle. Maybe your lifestyle requires more adaptability, and you need less strict methods. Perhaps your life is more orderly, so less stringent methods aren’t as optimal.
You’ve internalized your methods. I’ve found this happens a lot in Agile methods – you internalize so many principles and ways to do things, planning them out may get in the way.
Your priorities have changed. That nicely organized system you had to get things done was for a different you. Now you’re focusing on different issues, and your old methods don’t apply. Sticking with your earlier priorities will interfere with your current needs.
Your psychological needs changed. Productive methods provide us comfort, leverage our advantages, and make up for our flaws. Those change and evolve, and your processes will need to as well – if they don’t, there’s going to be a lot of internal stress.
You’ve learned new tools. There are productivity tools out there, software to methods of using notecards, and so on. Once you find a new one out, why not try to use it?

Productivity methods are essential to getting things done. But there are times to switch them up because your needs changed, you changed, and because there are better methods. Let yourself do it.

The methods don’t matter – what matters is getting things done. When there are reasons to change, do it. The methods are just a way to get where you want to go.

Steven Savage

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

You’re going to want to read this; yes it’s on time management, and yes it’s worth it. I’m going to talk about management but in a non-boring way.

Remember how I moved to Agile techniques and started those weekly reports? Here’s what happened.

In March I felt my time management could be better; I felt overworked, fell into multitasking, and knew I could do more. Sound familiar?

I had organized myself by a mix of Getting Things Done (GTG) and Scrum/Agile, but it was casual. Since I’m a a pro Project Manager and Scrum Master moving towards coaching and process improvement, I know a lot of techniques and processes and coaching tools. So I coached myself towards more productivity and less stress.

It makes sense; my life is more like a business with my books, and so on. So what I did was use the Agile practice of Scrum, combined with some GTG (which if you want to really argue, is kind of Kanban, but let’s hold off on that).

To help, here’s a quick refresher about Agile/Scrum – and trust me, you’ll also want to read this.

Agile is a management philosophy that evolved from software development. To sum it up it’s “A focus on delivering results regularly by working directly with others and responding to change.” Here’s the 4 parts of the manifesto and 12 principles that will give you an idea. You really want to read this stuff.

Agile is a MINDSET with a focus on delivery and adaption. It’s important to keep this in mind – literally.

Scrum is the most well-known Agile Method. Take a priority-ranked backlog of what you want to do, figure out how much stuff on the top you can do in a given timeframe (called a sprint, usually 2 weeks). Do the stuff, deliver, evaluate how you did, then do it all again. The goal is to get something done and learn – that something could be bad or not ready for prime-time, but it’s done.

Make sense? As I like to put it (sarcastically) if you deliver value often and re-evaluate, you get benefits fast, but also there’s only so much you can screw up in short bursts.

So time to adopt an Agile mindset, and Scrum was the best method to do it. Here’s what I did.

I made an Agile Backlog (from my GTG Incubator). This is basically a list of things I want to do ranked in order of value. I re-evaluate this regularly – this is not a random repository of ideas (I have separate documents for that).
I have a Project List (a GTG artifact) of active initiatives. This is basically the top of the backlog for what I focus on, and have some plans or outlines. I’m probably going to merge this into the Backlog.
I have a flight plan (a separate artifact) that lists my general goals per quarter and month for up to two years. I revise this as I change plans. This is a quick way to look ahead and look for any schedule collisions. It’s not quite a roadmap, more a projection.
I do monthly sprints, and the above help me decide what to do. The Projects get priority, the Backlog feeds new projects or smaller initiatives. The Flight plan lets me evaluate my goals and look for bottlenecks. Yeah, this could be the classic 2 week sprint, but my life seems to have a monthly cadence.
Work gets broken into stories that provide actual value, like a completed essay or a clean bathroom. Learning to describe stories and figure value is part of the learning process, and an area of intense discussion in Scrum/Agile. Short form is think of your target audience what they want and why – “As X I want Y so Z.”
I break stories into distinct tasks used to get the story done. A good rule is a task is something you can do in a day or less (and if you’re really good, 1-2 hours). A story may be so distinct and so simple it has only one task – “As a gamer I want a Playstation so I can play Persona 5” doesn’t need any more breakdown unless you REALLY want to block out the drive there, the purchase, the drive back, etc.
I estimate tasks in terms of person-hours so I can look at my workload. There’s endless discussion in Agile and practices like Scrum on how to “size” tasks, but I find in the end hours always win because eventually whatever you do is going to affect, be measured in, or be communicated in time.

There. I got a Sprint Backlog of work to do. how did I use it?

I review my backlog daily to see what I want to do. I also do a weekly overview of my schedule, work, etc. to get an idea of what’s up.
When I take a task I focus on getting it complete (ready to validate) if not done. In a few cases complete is done: “Hey, the kitchen floor is no longer disgusting”
If something is not immediately done, in that it continues or needs testing, I get it done in a short time.
If things have to change – so be it. I know what I’m adding and what I’m taking out. A lack of change should be due to good foresight – resisting change isn’t inherently a virtue.
I chart my tasks in the categories of Backlog (not started), In Progress, Testing (making sure it’s done), and Done (complete, finished, off my hands). I do what’s called a Cumulative flow, charting it by task hours in the categories (more on that in the future).
At the end of month do a retrospective- review how things went, decide what to improve.
Plan the next sprint (month).
I might keep my quarterly review (which is part of GTG and other techniques), but am honestly debating how necessary it is. Probably good to keep it though as I’ve got a lot going on.

This worked great for April – a busy month, yet I got a lot done. It also lets me seriously crawl inside of Scrum and Agile because I’m doing the work, managing myself (Scrum Master), figuring the product (Product Owner), and more.

I’ll be sharing other findings in separate posts, but a few here:

You won’t see a lot of “do X by Y.” There’s some obviously, but in general I leave it open – because my daily and weekly reviews let me figure out the best time to do things.
I measured completion with Tasks not Stories – which I consider improper as stories deliver value. I did this originally because many of my “life” stories were one task, but it didn’t measure completion of my few multitask stories, which really did affect my time management and sense of completion. I’m moving to stories next sprint.
I’m already keeping a “next sprint” list as I get ideas of what I want to do next; I realized I can easily apply lessons to the next month. This is a good example of iterative improvement and time-saving – and “backlog polishing.”
I keep a “regular” tasks list I can now copy over from sprint to sprint as some tasks for my “Agile Life” keep repeating.
This may sound like a radical restructuring – it sort of was and wasn’t. If you try something like this you don’t have to do it all at once, but add things iteratively, over time. I’ve got more to add myself.
I’m going to be making changes to how I manage the backlog and projects. To not overwhelm you with technique, I’ll probably post that later after I share some other insights.

Look for more posts on this – a lot more.

– Steve

Method Second

Steve’s Agile Life

Book Review: Getting Things Done by David Allen