The Wash

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

Yeah this isn’t a post about Agile per se, or writing, or anything.  It’s about life.

Sometimes you gotta take a wash.

I got sick (ironically from going to the doctor’s for a checkup where I was otherwise fine).  That was a pain, but my roommate got a new job, meaning I got to move in with my girlfriend earlier than intended.  It turned into a synergy of illness, surprises, and more.  Pretty much most of my projects had to go on hold.

At first I was annoyed with that, like I had to keep on schedule.  But the truth is we all have limits, interruptions, and more.

So I took a wash.  I set aside everything but the move and life stuff, did what I could on my other projects, and didn’t beat myself up.  That felt a lot better.

Sometimes you just have to take a wash.  Sometimes things can’t get done.  Living with it and doing what you can is important to adapting and keeping your sanity.

We often get taught to follow a schedule as if it’s a commandment, to feel bad if we can’t do what we planned.  We’re taught to self-flagellate.

Nah.  Sometimes you gotta take a wash.

Of course next month I’ll be back at it and I have some projects planned out to a year from now.

 

– Steve

My Personal Agile: Work

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

Now let’s get on to the next step of my Personal Agile – doing actual work! You’ve got your Sprint Backlog, which is everything you plan to do this sprint (a month) so let’s go.

How Do I Start?

Every day I look at my Sprint Backlog and figure what I should do and want to do. Then I do it. In time you get into a rhythm where you unconsciously know what you want to get done – usually.

Yeah, that’s it. A daily review – maybe more than once a day – and doing stuff. Sounds simple? Of course it is – because you’ve thought this over and taken a manageable chunk of stuff to do. One of the great parts of Agile methods is that you get enough mindwork done up front and break stuff into manageable chunks that it’s easy to focus.

Well, What Do I Do First?

That’s pretty much up to you. In general, you should tackle highest priority work first and work your way down.

In practice, it’s often not as clear cut:

  • There are time constraints on when some things have to get done. You may not list cleaning that grungy guest room sink as your highest priority, but mom’s visiting.
  • Some work may need approval, materials, etc. Those art supplies you needed are late.
  • Some work you can’t stand doing for an extended time period. Maybe you start mowing the lawn this evening but finish tomorrow (but hey, maybe your mowing should be two tasks or even two separate stories).
  • When you start things you quickly realize your priorities are off. You really don’t need those new clothes.

Priority order is a good guide, but the only one.  Do what works.

Sticking With Things

To make sure you progress and stay focused, you want to stick with work.  Here’s a look at what I do:

  • If you take a task, make sure it’s one you can complete in one sitting or one that you’ll get done without anything else interrupting. For instance if you want to write up an essay but don’t finish it before bed, then the next day that’s your top priority.
  • Once you start tasks in a story, that story should (more or less) be your top priority. This lets you focus on delivering value. It also helps get the Story out of your mind. Remember, good breakdown means more stories with less tasks, and that makes this easier.
  • In all cases, try to focus on something being done and complete. Deliver value – or parts of value.

Sticking with something helps you stay focused and keeps you from the mental waste of switching gears over and over.  In a lot of cases it’s better to finish something and start the next thing unless you really have to.

How Do I Track Work?

You want to track the work you’re doing and to know what you’re up to and what you’ve done.  Here’s what I do:

When you start a task, move the “hours” estimate into the appropriate column, and keep moving it. This way you’re tracking work done:

  • Define – You’re fleshing it out and getting ready.
  • Developing – You’re doing it.
  • Review – You (or someone else) are confirming it’s done.
  • Done – Well, duh. Done. Congrats.

This is why I keep totals at on my spreadsheet so, at a glance, I know how many “hours” of work are done where. I’ll go into this more later.

One thing you’ll note is that I track the state of every Task (some methods only do stories). I find if you track and validate Tasks, the stories usually take care of themselves – a truly well made Task may not complete the story but is verifiable. It also lets me follow my progress in miniature as I’m pretty focused on this.

You may only need to check your progress story-level. You can use a pivot table for this, or other forms of visualization I’ll cover next.

How Do I Avoid Being Overloaded?

OK, here’s where we get a new concept: Work In Progress.  This is important.

Work In Progress, aka WIP, comes from Kanban, and has been adopted into many Agile practices, including, of course, some variants of Scrum. The core idea is to limit what you’re working on so you focus – and so you find blockages to completion.

It’s simple – you set a limit on how much work can be in each column (Define, Developing, etc.).  This is usually only one item.  I usually limit it to one task, but sometimes it’s limited to one story.  Nothing can move ahead until there’s “space.”

This idea of moving ahead only when there’s space is called “Pull.”  You don’t push items forward – you pull them when available.  I find this comfort is very comforting, it changes your focus on work.

But what if you’ve got a task in Developing, it’s done, but you have another task in Review waiting on approval? You don’t move that Developing task. It sits. You can either go Define a task and do some research, or try to get the task in Review, well, reviewed.

If all three are filled up? If your Defined thing is Defined, your Developed task is all developed, and you in-review task is in review? You should focus on the in-review task, but if everything is blocked, it may be time to take a break.

Now of course work may have to move forward, but you should acknowledge how you got blocked and fix it in the future. When things get jammed up that’s the sign of a flaw – and a sign you should change your approach so it doesn’t happen again.

Think this is tough? Some folks like to keep it down to one item being worked on period, no matter what the state. In fact, I’m an advocate, on the individual level, for doing this method. Sometimes I even succeed.

So what does all this stuff with Work In Progress Do?

  1. It forces you to avoid multitasking. Multitasking really distracts you, and the more you pile up half-done, the more you’re distracted.
  2. It rethinks work. The idea of “pull” of moving forward only when there’s space helps you see work in a more relaxed, appropriate manner.
  3. It reveals blockages and obstacles. Think of your workflow as a pipe system. If you restrict the amount that goes through it, when a jam up occurs you learn a lot. This is an enormous amount of Kanban – to the point where I’ve heard people say Kanban isn’t a management tool but just a way to find and remove blockages.
  4. It works better with good work breakdowns, so helps validate them.

Now because life gets complicated, I practice what I call WIP 1+1. That means the usual limit applies, BUT I allow myself to work on something else as long as I can get it finished in one go. This means if, say, something is sitting at my editors, I can go do some cooking or clean the bathroom. But I wouldn’t start something that may need another editor’s attention.

As noted, I do this on the task level.  You might find it works on the story level.

What If Something Takes Longer Than I Estimated?

That’s fine, that’s OK. It’s something to note for review at the end of the sprint.

If this requires you to cut work, fine. Figure what the least priority items are and don’t do them unless you suddenly have time. You’ll review this.

One thing I do is change my estimate to fit my new findings.

What If I Get Everything Done Earlier?

Well you could take a break. Otherwise, just bring the topmost items in from the Backlog into the Sprint Backlog, one at a time. Finish those items before taking something else off the backlog.

So This Is Just Taking A List Of Stuff And Trying To Do It Without Multitasking In A Given Timeframe?

Well, yes. Welcome to Agile, where we cut through the bullshit or break the bullshit into manageable pieces.

Next Up?

This may seem easy, but we’ll talk tools and visualization.

– Steve

 

My Personal Agile: Your First Sprint

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

Congrats. All that work last time? You’re ready to start a sprint in my Personal Agile. First, let’s review.

Last time you build a spreadsheet (or equivalent) to track:

  • The Incubator – All the stuff you want to do eventually.
  • The Backlog – You took the stuff that you really want to do out of the Inacubator, broke it down, and detailed it enough that someday you can do it.  These are things you’re very sure you want to get to.
  • The Regular Tasks – You detailed the things you have to do every month.

Pretty useful, right? Well get ready, here comes your first sprint. In fact, let’s talk what this is.

The Sprint

A Sprint is a concept I first got introduced to in Scrum. A Sprint is a time period (almost always the same length) in which you do work.  The Sprint is loaded up with your Regular Tasks and the top items in the Backlog – this is called the Sprint Backlog.  You then work on these items for the Sprint, and repeat the process.

The Sprint concept has a lot of advantages:

  • Each time you use the same span of work – it helps with predictability on delivery and figuring out how much work you can handle.  By the way, it takes a few Sprints to figure out how much you can handle.
  • You load a Sprint with the most important work, but usually figure out the best way to do it during the Sprint – it may not always be in order.
  • You focus on what you’re sure you can do.
  • You review and re-plan so you adapt – and if you screw up it’s only for a short period.

Sprints in general are not modified or changed when they start, though there’s often fiddling around the edges because you’re constantly discovering things. If a Sprint is radically restructured, it should be stopped and a new one begun, with everything replanned and re-evaluated.

Sprint Size?

So how big should a Sprint be?  In Software I see two weeks held up as an ideal, though in some past writings a month was apparently favored.  I see a lot of three week Sprints, and have heard of a few week Sprints.

For my Personal Agile I use a month. This is because:

  • For most of us our lives have a monthly cadence.
  • It’s large enough to deal with the unpredictability of life and not get derailed.
  • It interfaces well with other forms of time measurement – quarters and years.
  • Because of that interface it also ties well into things like college quarters or semesters, financial years, and more.
  • Yeah, months aren’t the same size, but it’s close.

I recommend starting with a month – and never doing a Sprint larger than one month. However, you may find that smaller ones actually work for you.

Why would you use a smaller Sprint?  I find smaller Sprints allow for more responsive development, quicker turnaround on changes, and more reviews.  It might work for you!

OK, let’s move on to . . .

Sprint Planning – The Sprint Backlog

Every Sprint I have a tab in my spreadsheet for work to do that month. At the end of the first month (or thereabouts) I copy my old spreadsheet (so I don’t loose records), and then start planning.

Sprint Backlog has these fields – which must be familiar.

  • DATE – If something is date-bound.
  • PROJECT – Obvious.
  • STORY – Obvious.
  • TASK – Obvious.
  • SIZE – The size of the project in hours.
  • DEFINING – This starts blank. When a task is being analyzed, you move it’s “hour count” out of “Size” and over to here.
  • DEVELOPING -This starts blank. When a task is being done, you move its “hour count” here.
  • REVIEW – This starts blank. When a task is done but not confirmed done (say you’ve got to get approval), you move it’s “hour count” here.
  • DONE – This starts blank. When you are done with a task, it’s “hour count” moves here.
  • NOTES – Obvious

As you can guess, I sum up Size/Defining/Developing/Review/Done at the bottom of the Spreadsheet. This lets me see, at a glance, where work is and what’s going on. How much work (in hours) is not started? How much is done?

Finally I sort this sheet by:

  1. DATE
  2. PROJECT
  3. STORY

This way I see:

  1. What has to get done first.
  2. Then things by project.
  3. Then individual stories.

OK, you got your Sprint Backlog tab. Let’s fill it.

Filling The Sprint Backlog

You probably see where this is going, but . . .

  1. First, copy over your Regular Tasks list. Congratulations, you’ve populated your backlog with important stuff (and some months this may be all you get to)
  2. Look at the work for the month. Do you (honestly) have room for more? Anything suddenly get added or something you won’t do? Any holidays? Add or subtract things. It’s possible that you’ve covered most things you need.
  3. You may realize that holidays, events, etc. require more work.  So put in stories/tasks for such things.  It could be cooking dinner then throwing a party, or it could be you want to take a holiday to relax.  Make these things into stories/tasks so you know what to have to do and don’t overload yourself.
  4. If something is just fun?  Like a big event? I put that in too so I take time for it.
  5. Now, go into your Backlog and – you guessed it – take the highest priority story.
  6. Take that story and determine if it needs to be broken down any further.  This is your time to do a bit more analysis.
  7. Now do the same with the next item on your Backlog.
  8. Each time you take an item off your Backlog and break it down, ask if that’s enough work for the Sprint.  Eventually, you stop.

And that’s it. Its just like your Incubator and Backlog, only you’re using the Backlog to make a set of tasks and stories for your sprint.

In a lot of Scrum practices this process is timebound to four hours for a team.  I don’t really timebox myself, but I recommend 2 hours or less if you need a “boundary.”  This prevents paralysis through analysis.

By the way, you’ll do this every sprint. I find in time I get a very good idea of what’s next and this becomes easier and easier.

Congrats on the Sprint Backlog

There, you have a Sprint Backlog. You can start work. In fact, I’ll address that next.

– Steve