productivity

My Agile Life: A Quick Review

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

I’ve been using Agile to have a more productive life, and it’s been pretty great. So to help you out (and help me organize my thoughts) here’s what I currently do. I think I’ll do these roundups every few months, so you can try the latest iteration of my system, and I get better at sharing.

First out, what I’m doing is the Agile method of Scrum in my own life. If you’re not familiar with Scrum it’s basically:

  1. Have a ranked backlog of stuff to do.
  2. Choose how much you can do in a given time frame from the top – this timeframe is called a Sprint.
  3. Do it.
  4. Review how you did, revise the backlog, and start a new sprint.

That’s Scrum. Here’s how I do it – first, the lists I keep.

  1. I have an Incubator. This is my list of Neat Stuff to do, summed up. I update it monthly or so and review it monthly as well.
  2. I have a Backlog/Roadmap. This is a list of things I want to do, in order, usually on the Project level, but sometimes broken down into stories (pieces of value). It’s ranked both by importance and “guessed” chronology – a few things are tagged with critical dates. I could probably split these up but I don’t think I need it.
  3. I have a Sprint Backlog.  This is what I decide to do every sprint – which for me is a month. This isn’t ranked, but is more sorted in a project order. This is broken down by Projects, with stories, with specific tasks. I estimate effort by hours. I review this every day.
  4. I have a cumulative flow chart, which is based on Tasks (not normal process, but most of my work breaks down pretty finely). This gives me a visual idea of how I’m doing, and is good practice on using these charts.

What I do is review things every day to see what’s up and decide what to do – but after regular review, I’m usually aware of my next few days of work automatically. I’ve kept a weekly schedule but fell off of it – I’m not sure I need to, as my daily reviews keep me aware of what’s going on.

A few things on how I operate:

  • Break down work into workable components – A real challenge at times as you can treat work as big lumps, or turn it into so many tiny tasks you can’t focus.  Find some way to break things down that you can get things done without overloading yourself, but not so much you can’t keep track of the little parts.
  • Limit Work In Progress, WIP, To 2 items.  WIP keeps you from juggling too many balls. I normally prefer a WIP of one, but when you’re doing Scrum for real life you’re going to have interruptions. Usually at most I have one “in progress” item with another “free item” for all sorts of tasks like cleaning, etc. However if I have one “ball” in the air I make sure any new one is finished right away.
  • Polish that backlog. Keep revising this as you go so when you get ready to plan, you pretty much know what you’re doing next.
  • Keep a regular task backlog. This is one way I save time planning, preparing a list of regular common tasks I have to do monthly so I already know most of my schedule. I copy that into:
  • My projected “next month” backlog. I keep a draft of what I’ll “probably” do next. This helps me plan fast as, about midway through a month, I’m like 75% certain of what’s next if not more.

All of this has made me much more productive – but it may not be for the reasons you think.

Yes, there’s the value of having a tool and a plan of some kind – but you can do that a lot of ways. I’m taking an Agile approach, and that requires me to take an Agile mindset – a focus on adaption, on communication, and on efficiency. The tool reinforces the mindset.  The mindset is what matters.

And the mindset? I’m a lot more relaxed, a lot more effective, and I waste less time.

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

– Steve

Eat Your Failure: Agile is Failure Absorbent

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).
So let’s be honest, May was not my greatest month. Sure, I got things done but plotting my first novel took over twice the time expected and isn’t done yet. I only wrote 84% of what I wanted for the minibooks. I had to hold off many small project due to time an illness, business, and allergies.

I honestly felt bad. I had failed. That was bad, right?

Wrong. Agile methods are about responding to change and learning. They are not failure avoidant, they are failure absorbent; failure is expected, learned from, and worked into the process.

OK I still feel bad, but I don’t have to – that’s not Agile – it’s just my own neuroses. I’m not used to absorbing failure – nor are many other people or groups.

Most organizations are failure avoidant – and because of that they fail even more. Nothing ensures learning slowly, having neurotic relations, continuing the blame game, and adapting poorly than being failure avoidant. I’m sure you’ve been in failure avoidant situations – it’s bad at work and worse with yourself.

Failure absorbency is a major part of Agile philosophy and methods. The goal of Agile is to be able to respond quickly, using communication and responsiveness to change to allow you to deliver work faster and better. Agile expects failure. Agile practices eat failure and use it to become stronger.

The only thing to feel bad about is not responding to failure appropriately. Though I suppose that’s a separate failure you can then respond appropriately too.

When you fail in Agile you should review, learn, and figure out how to adapt and do better. It’s not what you did wrong, it’s what you learned and how you adapt. Eat your failure.

So what did I learn:

  • TOO MANY ANKLEBITERS: I assigned too many small tasks that I didn’t need or I should have done to “clear the plate.”
  • TIMESHIFTING:Some of these tasks could have been timeshifted better – there’ a few cases where I just figured I’d get to them.
  • TOO PACKED: I had no room for disruption baked into my plans despite having so much going on yet having so much free time.
  • POOR PLANNING DUE TO OVERCONFIDENCE: I didn’t plan out the novel plotting well at all as noted; it may be this novel is going to be far less timebound and far more about iteration.
  • OVERCOMMITMENT: The Novel didn’t just take longer, I had to literally “back my mind out” of work that held up my imagination. It’s like writing code before the design research is done – an then you don’t want to change the code.

Now how do I deal with this?

  • Review tasks better to make sure I really need to do them – success if often measured in what’s not done or needed.
  • For truly new project, like my novel, watch my time estimates on early stages and give myself space to do them write. Also, don’t overdesign/overdetail or not back out.
  • Get a better sense of my velocity so I don’t overload myself (which I think I’ll have end of this month).
  • Better pace myself, which is part of velocity.
  • It’s probably better to find I have spare time in a sprint then to overload myself – If I have spare time I can start taking items out of my backlog. Again focus on what’s needed.
  • I’ll review going to two week sprints in July – it’d make me much more adaptable.  However I think long term my life will evolve from Agile to Kanban.
  • I still run too many projects at once – the Minibooks being a classic example of trying to do them over time, and that writing can just turn into a distraction.

So that’s how I adsorb failure – getting better.

This has made me even rethink how I’ve handled failure in my life. I tend to avoid it – then embrace it when it happens. Maybe I could just be a bit less avoidant early on.

– Steve

Steve’s Agile Life: Work In Progress

by

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

Here’s the latest on my “Agile Life” experiment (where I use the Agile techniques in  Scrum).  Let’s talk Work In Progress or WIP, something my mentor wanted me to learn more about, and something that inspired my “Agile Life” experiment.

WIP is Work In Progress, a measure of how much is being worked on but is not done. It’s core to the Agile technique of Kanban and the measurement has been incorporated into other practices. WIP is “on it but not done with it” – from waiting on a test for finished software to just note done.

Why is it important? Because in general too much WIP (some would argue any more than one story) is a sign of bad things or can be bad things.  To much WIP might mean:

  • People are multitasking a lot.  Too much being done at once, nothing finished, lots of context shifting.
  • Too many blockers.  A lot is just holding people up.
  • Bad work.  Too much is held up in testing and fixing.
  • Testing problems. Maybe stuff is happening too fast and it cant be tested as fast as it’s getting done, or the testing team has problems.
  • Poor story and task design. The work as broken down is hard to finish or isn’t what people thought it was.

Note the first issue – Multitasking. Even if you’re not blocked by anything else, starting but not finishing things distracts you. You have to context shift. You have to keep track of many things. WIP’s problem can sometimes be its mere existence.

Very quickly as I worked to get more Scrum-like in life, I could see how easy it was to have too much WIP. This was especially bad with domestic chores, things I could “do any time” or “complete whenever.” For my first sprint, it certainly shaped up my housekeeping.

This also made me aware of the issue of tracking completion of Tasks versus Stories. Stories may deliver value so you want to get them out – but individual tasks can also get stuck in never-being done. Tracking those specific “in progress” tasks can be helpful. Makes me wonder if a cumulative flow of both Stories AND tasks would help me or other teams – after all if you’ve got 5 stories not complete due to 5 different tasks or one story not complete due to 5 different tasks, that tells you something.

Some Agile practitioners and practices limit Work In Progress (and people fight over this). The idea is that there’s a limit for a person, team, group, etc. on how much can be up in the air. Past a certain point, it’s either finish it, unblock it, or go do something else not in the Backlog until the stars align. This limits multitasking.

Frankly, I can see why people do it. One Agile Coach I know said in a class that a team at its WIP limit should do nothing until stuff gets done, even if other people spend time to go to training or something. Yes, I watched a highly experienced expert outright state – with conviction – that if a team has too much WIP and one guy has nothing to do, he ought to go read a book instead of start something else. His time would be better spent not complicating everyone’s lives by starting something else.

My guess is you can sympathize.

What do I consider ideal WIP? I’d say for an individual 2 stories and 2 tasks at most, and I’m starting to see why people often make it one story, at least in business.

A final note on WIP. Having lots of small stories you can bang out easy may sound great – but may also tempt you to do them when there’s a big pile of WIP. Even if you can finish something quickly, maybe you ought to finish something from that big pile first.

(By the way, there’s no guarantee reduced WIP is going to have benefits, there’s other variables. But it’s a worthy goal. And yes, people fight over this.)

– Steve