The Lazy Faire

By 2/15/2009:

• More family meetups: We will have (at least) 5-6 two-family meetups with our friends
• Get the kids out of the house: Stacey and/or Avdi will take the kids to a (non-Borders) attraction
• Car: We will have the Buick in our possession in Shrewsbury.
  • Not necessarily with paperwork completed.
• J. Birthday: Have a concrete plan in-hand on or before Feb. 4
• Observe Imbolc with friends

Notes from the retrospective for the iteration ending 1/24/2009.  No stats this time as this was our very first iteration.

What went well:

• Regular Shabbat and Havdallah observance
• Still nursing Kashti at 5 months!  (Medical issues forced Stacey to stop nursing previous baby at 3 months)
• Made baby food at home
• Stacey researched Buick transfer
• Launched http://thelazyfair.org
• “Rock Band Saturday” rocked
• We got some snow
• Solid start on exercise program
• Solid start on primal diet

What didn’t go so well

• Still have only one little car for the 5 of us
• Avdi made no progress on Open Source coding projects
• Avdi tense from worrying about PA homeschool reporting
• Grocery budget exploding due to new diet
• S. still having self-consciousness issues with public nursing
• Not enough family-to-family time spent with friends
• Not enough snow!

I’m a software developer by vocation.  Over the past ten years a lot of software development shops have adopted a set of related principles and practices collectively known as Agile Methodologies.  The theme of Agile development is summed up in the motto “embrace change“.  Agility, in the software development context, is all about accepting the fact of change and working with it instead of fighting change and trying to make the world stand still.

A year or two ago as I started thinking a lot about personal productivity and reading books like Getting Things Done, I began to wonder if some of the practices I used every day ono the job couldn’t be applied to my life outside of work.  I didn’t immediately do anything with the idea, but it never completely left the back of my mind.  This year I’ve begun experimenting with using Agile practices outside of work, and I plan on writing about our experiences.

Why Agile?

The principle benefit I hope to see in applying some of these practices from the software world to everyday life is an approach to planning that embraces constant change.  A lot of guides to realizing your full potential as an individual or a family have a strong element of long-term planning to them.  My experience has always been that when I sit down to write a grand plan for life, I wind up with a document that bears little relationship to reality after a month or three.  Interestingly, this is exactly what happens in software projects as well, and the reason Agile methodologies were invented.  I wanted a way to plan just enough to move forward, without trying to over-structure our lives.

Practice 1: Time-boxed Iterations

One of the core Agile practices is to break the schedule into time-boxed intervals called iterations.  Time-boxing simply means that they proceed for a fixed amount of time.  Iterations are not deadlines which can be pushed back a few days or weeks.  They end at a fixed time, and then the next iteration begins.

Agile teams plan their work on a per-iteration basis.  At the beginning of the iteration, they get together with the client and decide which tasks they will try to accomplish in that iteration - and no farther.  There is no grand plan showing what features will be done in each iteration all the way up to the end of the projects - planning is done one iteration at a time.

Iterations are typically from a week to a month long, although a month is considered widely pretty long by agile standards.  They are intended to be long enough to make visible progress forwards, but short enough that little time will be wasted if it turns out the client doesn’t like the direction they’ve been going.  The idea of frequent course corrections is fundamental to iterations.  You plan a little, work a little, evaluate where you are, adjust course accordingly, and then work a little more.

Three-week intervals

For our family experiment I decided to try a three-week iteration schedule.  Some of the considerations that went into choosing that length were:

• No matter how you try and sweeten it, planning is always tedious and a little stressful.  I didn’t want the planning to come at too frequent of intervals, or I figured we’d sour on the whole experiment pretty quickly.
• On the other hand, intervals of a full month would mean only twelve chances to adjust course per year, and that didn’t seem like enough.
• Someone once told me that three weeks is the length of time it takes to build a new habit.

The planning outing

One decision I made early was that I wanted to make a point of making the iteration planning/retrospective meetings special in some way, so that we wouldn’t start dreading them.  So last weekend the family drove up to Borders and Stacey and I sat and sipped lattes while we planned.  I intend to make it a tradition that we always get out of the house and go somewhere we enjoy - a bookstore, or a cafe, or a park - for our planing meetings.

What to plan?

Iterations are all about scheduling work.  In the software development context, “work” is pretty well-defined - it usually involves adding features or fixing bugs in a program.  In life the definition of “work” is a little more vague.

For our purposes I decided that what I wanted to focus on planning projects or tasks that fit a few loose criteria:

• It requires more than one family member to complete.  The iteration is for coordinating as a family, not for planning each person’s personal projects.
• It will take more than an hour to complete.  Iterations are for planning the major projects we intend to accomplish in the next three weeks; not every little task we want to do.
• It will take less than three weeks to complete.  The whole point of an iteration is to accomplish a measurable amount of work in the allotted time.  “Build a new house” is too broad in scope for a single iteration.  “Hire an architect” might be a more reasonable goal.
• It is quantifiable.  There should be some concrete criterion for determining, at the end of the iteration, if the task was accomplished or not.
• It is non-recurring or rarely recurring.  Iteration planning isn’t the time to schedule taking the trash out every Thursday.

These are only guidelines - not all the tasks we came up with for our first planned iteration fit all these criteria

Accountability and visibility

I think it’s important to make the current and past iteration plans easily visible.  This is one area I’ve slacked off on, but I plan on publishing our plan for the current iteration (2/15) right here on this blog in the next couple days, and from then on posting it at the beginning of each iteration.  I’ve also given thought to putting it up in our house as stickies on a whiteboard or index cards on a corkboard.  As we collect iteration plans and retrospective notes (more on that in a later post), we’ll be able to gain insight into how much we’re capable of accomplishing in three weeks’ time.

A note on terminology

Neither of us are completely happy with the term “iteration” as applied to our family life.  It’s a little too cold and technical.  We batted a few other words around, but we haven’t yet come up with a satisfactory replacement.  “Cycle” isn’t much better than iteration.  “Period” has menstrual connotations.  We’re open to suggections.