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.

1. 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).
2. 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.
3. 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.
4. 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.
5. 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.”
6. 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.
7. 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?

1. 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.
2. 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”
3. If something is not immediately done, in that it continues or needs testing, I get it done in a short time.
4. 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.
5. 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).
6. At the end of month do a retrospective- review how things went, decide what to improve.
7. Plan the next sprint (month).
8. 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

• www.StevenSavage.com
• www.InformoTron.com