Background

Every year, I take a few weeks away from work in order to disconnect, recover, and change my routines. A few years ago, I took three weeks off fo work and it was transformative. I was active, I lost some weight, my blood pressure went down, my energy went up, and I was able to come back to work focused, energized, and ready to take on the world. I said to myself, "THIS is how I can focus on being a human being and not a human doing. I need to do this every year!"

Three weeks away from work was enjoyable and restorative. The temptation, for me, is to plop myself on the couch and turn my brain off. There's definitely some benefit to being disconnected -- no doubt about it -- but it can easily turn into swapping computer screens for televisions. This isn't the end of the world, but I fear that I'll look back when the time away from work and judge that I've wasted the entire experience.

I can only take this much time away from work once a year or so. My time -- both at work and outside of work -- is my most valuable asset. There are so, so many projects I want to take on and it can be a real challenge to dedicate large blocks of time in the middle of working. After a long day at work, I'm often tired or irritable or just plain wiped out. That makes these breaks just that much more special.

So, I prioritize making the most out of the breaks and try to get a few of those projects done.

Agile

Most of my professional work involves scheduling tasks, initiatives, and efforts. Often times, this involves -- requires -- scheduling, collaboration, communication, and working with other people. For much of my career, we would spend weeks or months or years planning projects. We tried to nail down every single detail, take account of every possible variation, plan out exactly who did what and when. This would typically result in an artifact being generated called a Gantt Chart. A Gantt Chart showed each task in sequence with time progressing from left to right and the order of tasks being arranged from earliest at the top to latest at the bottom. The chart tends to look like a waterfall; as a result, this process is often referred to as "waterfall planning."

The problem with waterfall planning is that it's virtually impossible to predict everything that would happen during the course of a project. People get sick, dependencies aren't met, things take longer than expected. Life happens.

One approach to getting around this happening is to engage in a different form of planning. Based on the Agile Manifesto, Agile takes the form of a different approach: iteration. Instead of trying to plan a year's worth of work, we try to plan a very small chunk of work. We accomplish what we can in a small task or small period of time, review what we've done, and figure out what we're going to do next. Because of the scope of this planning, a sickness or a a change in circumstance or someone changes their mind about something, something becoming unavailable, the risk of the plan being disturbed is greatly reduced.

The worst case scenario is that this chunk of work -- this iteration -- falls apart doesn't work out as planned. Instead of having a year's planning go bad, we're only talking about a week or two.

Another key benefit of this approach is that instead of having a big bang demonstration where the misalignment of a client's expectations resulting in a massive disappointment, we show off what we've done for the past week or two (iteration) and get the client's thoughts. Then, we adjust the plan for the next iteration.

Our ability to negotiate the uncertainty is what gives us the agility to be successful in our desire to manage expectations -- to get the most out of our finite resources.

Scrum

There are several different forms of Agile, often with different forms of constraints. A common form is called "scrum." Scrum revolves around using a constraint of time. That is, with scrum, we base iterations on small periods of time, typically called "sprints." A sprint of often two weeks in length; if longer, the risks grow; if shorter, more time is spent planning sprints than actually doing the work.

Because this structure is so familiar, we decided to use scrum-based Agile to plan our away-from-work time. If an unanticipated event were to come up or if a part were to be unavailable or if the weather didn't cooperate, we could update our plans. If a project that was supposed to take an hour turns into two days, we can successfully manage our time moving forward.

The Backlog

The first thing we adopted was a backlog. Our backlog was a series of tasks, jobs, projects, chores, etc. that we would like to include in our planning. It's the stuff we want to get done. Some of the items in the backlog were things like, "fix the basement door" or "visit our parents."

Our backlog is the big, scary list of all of the things we would like to get done. This was the "sky's the limit" list. Anyone could add items to the backlog at any time and for any reason. We didn't worry about how stuff would get done or if the tasks were too big or too complicated. Just because something gets put into the backlog doesn't mean we're committing to doing it.

Background Refinement

Once we've established a backlog of items, our next step is to figure out what's required to accomplish tasks in the backlog. This includes figuring our if we have what we need (materials, tools, etc.), if a task is broken down into a sufficiently small scope, if the execution of the project works with whatever else is going on, and so on.

Like at work, we tried to keep tasks down to things that can be accomplished in a fairly short period of time. For our planning purposes, we tried to aim to have tasks doable in an hour or two. One of the really nice effects of this is that we're able to quickly tick off tasks as they get done.

There have been many times when a period of time has elapsed and we look back and ask, "what did we get done this summer?" or "the break's almost over, did we get what we wanted to get done, done?" Seeing a list of items marked off as being done is incredible helpful. It's a great boost to see a mile-long list accomplishments. What did we get done? ALLLLLL of this!

So, when we're refining our tasks, they can be often be way, way too large. Things like, "clean out the basement" when it's floor-to-ceiling boxes and tubs can be incredibly overwhelming. Taking the four tubs with dishes in them from the basement and moving them into the garage -- that's something that can be get done and we can build up that positive reinforcement.

This process of figuring out how much effort is involved is called estimating. Knowing how much effort is required to do something helps us plan what can or can't get done in an iteration. This helps us not to bite off more than we can chew.

It's far, far more preferable to have a very long list of very small tasks. Stuff gets done. The probability of our expectations being misaligned or feeling disappointment when we don't meet our goals is much, much lower than if we had a very short list of very large tasks.

Lastly, we organize the backlog in order of priority. It's great to get a bunch of things done, but if we focus on unimportant items instead of those that would bring us the most benefit, the whole thing thing can be a waste of time. At work, this allows our clients to make sure the things that they think are important get done; at home, it's the same thing -- the only difference is that we're both the clients and the people doing the work.

Sprint Planning

The next step was planning our iterations. Planning iterations -- planning sprints -- was where we would take the backlog, explore which items were of the highest priority. If we know that a couple of tasks can take an hour or two each, we can take three to five items and schedule them into a given day; similarly, if we have five days, we can plan on fifteen to twenty tasks for a given week. Since we use one-week sprints, twenty items that were estimated to be an hour or two was a reasonable estimate.

We would plan a sprint on the first day of the sprint. The sprints had new items from the backlog as well as items from the previous sprint that weren't finished during that iteration.

Standup

At the start of every day (except for the first day of the sprint), we had a very short discussion. As with a standup at work, we talked about what items we accomplished since our last standup, what items we were planning on working between that point and the next standup, and any things that were blocking our progress.

Standup meetings were very short. In fact, standup meetings take their name from being so short, folks are encouraged to remain standing to encourage brevity and focus.

After standup, we started our days.

Review / Demo

At the end of each sprint, we would take a few minutes, look at the list of tasks that we accomplished during the sprint, and discuss the progress that we made, particularly in the context of the larger scope of the project as a whole.

This is called a sprint review or a sprint demo.

The review is critical. In the context of work, this is where we would show the client what we accomplished and they would respond with what they liked, what they didn't like, what changes they needed, etc.. Since we're the clients, this is where we would figure out if we were making the progress we wanted to make. The review and subsequent conversation is how we communicate and provide feedback. It's how we make sure our expectations and our efforts are aligned.

Sprint review is how we reduce risk and ensure success.

Retrospective

The last thing we would do would be to hold a retrospective. This is where we would have a discussion about how the work went and how it could go better when we start up our next sprint. To structure the conversation, we would talk about what went well, what didn't go well, what did we learn, and what we could do better the next time.

This could be a scary conversation to have, both at work and at home. The goal, however, is to make things run smoother and safer and more comfortably. We want to be productive, but we also want to encourage and support ourselves as a family focused on unity.