Agile Living: Part Three?—?That’s All Great in Theory, But How Do I Actually Do This?

In the conclusion of this three-part series, we take a look at the step-by-step instructions for trying to apply the agile approach to your daily life. Read part one. Read part two.

In 2012 I shot a web series. My producing partner was a certified scrum master and suggested we try using agile workflows for production and post-production. This was my first exposure to agile practices, and I loved it. Since then I’ve gone on to work for a company that practices agile on many projects, and have had exposure to the real thing on several occasions. From those experiences I’ve cobbled together a flow that works for me.

Step One: The Backlog

The first step in building an agile project is to create a backlog. In this case, it means making a list of everything you want to accomplish ever. You can scale down if you like, but I’m a bit of a polymath, so I have a lot of things that I want to tackle.

To make that list, you basically want to break things down into “stories” and “descriptions”. The “story” column is kind of like a “topic” column. It comes from software design and the concept of “user stories.” If you were desiging iTunes, one of the user stories might be “user selects a song, iTunes displays recommended songs based on that selection.” There is a lot of complexity and steps and tasks that go into that story, but it is one story, and in an agile backlog you’d have a story called “song recommendations” and then a lot of tasks associated with that story.

For me, a story might be “Home” where I place a lot of mundane tasks like “Get New Glasses” or “Clean Car”. Those mundane tasks go under the heading “Description” because it’s basically a description of the task.

One of the major tenets of agile is that when you’ve got a big problem, break it down into smaller tasks. So if the Story is “Home” as in “all of the stuff I have to deal with at home” one Description under that might be “Clean Car”. You’ll take all of the stories of your life (or as many as you want to tackle) and break out the tasks for each one. In this way, you’ll fill out the Story and Description columns.

Once you’ve done that, you’ll want to assign a Rank to each task. Rank is exactly what it sounds like. It answers the question “How important is this task compared to the other tasks?”. Usually, rank is identified as being somewhere between 1000 and 9000, buy your ranking may vary. For me, 9000 is the most important, and 1000 the least. You use thousands because it may be that you’ll want to identify something as slightly more important, so you can call it 9010 or 9125.

Rank is extremely important.

If you’re wondering how to rank things, guess. All of this is a guess. This is also a fundamental tenet of agile. We’re making predictions, not commiting ourselves to unalterable laws. If I say cleaning the car ranks at 7000, that’s a guess. I may find that after driving in that dirty thing for a few days it’s actually a 9000, but I have to start somewhere. Agile is about making bets and seeing if they pay off and then learning and adjusting so you make a smarter bet the next time.

“Notes” and “Category” are less important, but there if you need them. Notes are just any notes you choose to make to clarify a particular task. So under “get new glasses” I might have a note that says “see email from optometrist in Home folder” for reference. Category describes the type of task this is. Is it something I have to write? Is it something I have to organize? Is it about responding to an email? You do this if you want to get a sense of how you’re spending your time. After enough sprints or just looking at your backlog you can sort by Category and see “Wow, I sure spend a lot of time writing. Is that what I really want to do?”

(To be honest, I rarely use this column, but I can see where it could be helpful.)

The big one, the most important column, the one you can’t really do this without, is Plan.

Plan describes how difficult a task is. It’s your best guess at the effort it’s going to take to complete that task. It’s usually a number (called “points” as in “How many points is this task worth?”). And it’s usually a number on the Fibonacci scale. Long story short, that’s a series of numbers that increases proportionally like 1, 2, 3, 5, 8, 13, 21, 34. Reason being in the real world, most tasks aren’t just “one” harder than another, they’re almost exponentially harder than another.

But you can choose whatever scale you want. When I started out, I just wrote down how many hours I thought a task would take. The important thing is to make that guess and write it down for every single task.

After you’ve spent a while (for me it was about three days) putting together your initial backlog, you’re ready to create a dashboard.

Step Two: The Dashboard

Once you’ve established your backlog, your big long list of things to do, it’s time to establish some parameters. You’re going to start building little bites you’re going to take out of that backlog. They’re called “sprints”.

A sprint is a period of time, often two weeks, in which you will accomplish a finite set of tasks. In proper agile, they are the time alotted to release a certain feature. So that recommendation feature in the iTunes example above might be released after two weeks and, if it’s not quite perfect, iterated upon in the following sprint (probably as a new feature is developed). For our purposes, though, it’s a way to segment out time.

The dashboard is the bird’s-eye-view of the sprints. I tend to name my sprints as you can see in the “Current Sprints” column. In this case I’m using Marvel Cinematic Universe films and, having run out of those, am moving on to 1990's Best Picture Oscar winners.

The duration of the sprint is in the next two columns as start and end dates. I opt for the traditional two week period, but your results may vary. One week or three weeks are also common choices. The point is it has to seem like a manageable amount of time to you. Something you can get your head around with little or no stress.

The left-most columns are key. The left most column is your Capacity. This is how many points you think you can complete during the sprint. Remember how we assigned difficulty points to each task while creating the backlog? This is where that pays off. You’re going to add up points to see how much you think you can pull off in a given sprint.

Again, this is a guess. For starters you can look at how many hours you’ll think you’ll have free to work on these tasks in the next two weeks and, if your point system is based on hours, it becomes easy math. If you’re looking at a more fuzzy interpretation of points based on effort, you can take a gut-based guess at how much effort you can put in during the sprint and write that down.

The point is to write something down, because at the end of the day it is a hypothesis about how much you can get done. You will find out. And then you will adjust accordingly.

The next column over, the Burndown, is you finding out if you were right. It’s how many points you actually accomplished during the sprint. So next to each other you have the guess and the outcome. As you can see from the above example, sometimes I guessed better than others. In both directions. The key is what happens next.

Where I overestimated how many points I could accomplish, the following sprint I lowered my capacity. For the Captain America: The First Avengersprint I thought I could accomplish 13 points. As the Burndown column shows, however, I only accomplished 9. Still ambitious, I predicted I could accomplish 9.5 in the following sprint, The Avengers, but I only accomplished 8.5. Finally, succumbing to reality, I settled on 8 in Iron Man 3, only to accomplish 6 and finally accurately predict 5 for Thor: The Dark World. But there were other sprints where I predicted 8 but accomplished 13, so it can go in the other direction as well.

The point is you learn. You get better at predicting how much you can get done. As a result, your expectations, and the expectations you’re able to set for others, become more realistic. This is one of the most powerful aspects of agile. It is a self-learning system.

Step Three: The Sprint

So now it’s time to finally build your first sprint. This is the work you will try to accomplish in the next two weeks. The bite you’ll take out of the backlog. As before, you must respect capacity. If you’ve guessed that you can accomplish 21 points in this sprint, the points in the “Plan” column above must add up to no more than 21. (Let’s continue to assume that capacity for this example.)

So the first step is to go into your backlog and find the most important tasks. Sort by rank and see what all the 9000's are. If their points add up to 21 exactly, great. Move that over and you’ve got yourself a sprint. If not, you have to make choices.

If they add up to less than 21, you can start looking at the 8000's and see what might be worth including. If they add up to more than 21, you have to decide which of the 9000's are more important than the others and only pull in enough to add up to 21.

It’s important to be strict about this. If you don’t run the experiment “honestly” as it were, it won’t be valid, and you won’t learn what your true capacity is.

Once you’ve begun the sprint, you can still adjust. If something more important comes up, a new task, you can put it in the backlog and, if it ranks highly enough you can add it to the current sprint, with one very important caveat: something of equal value, points-wise, has to come out.

Again, you have to make a decision. Does this new task, this new thing that’s come up, outrank anything I’m currently planning on doing during this sprint? If the answer is no, then yeah, it may seem important, but it’s going to have to wait as much as two weeks before it gets addressed. If the answer is yes, then okay, but something I thought I was going to do during this sprint will now have to wait until the next one, and I’m going to have to be okay with that.

What this avoids is constantly hopping from one task to the next as they pop up. Just responding to emails as if they were an instant to do list (more on that later). This allows you to make these tasks compete intelligently for your attention because your time is a finite resource, even if the tasks are infinite.

A few more columns: After the normal backlog columns, you get a Done and To Do column. The Done column tells you how many points you’ve completed on a particular task. If it’s worth 3 you might have completed 2. The remaining 1 goes in the To Do column.

I tend to highlight tasks that are “in flight” as it were (meaning I’ve begun them and accomplished some points already) and ones that are done. This way, I can quickly look at my sprint and know which tasks I haven’t started and, if necessary, prioritize them. In the above example, completed tasks are in green and in-flight tasks are in yellow.

Step Four: Stand-Ups

Karthik Chandrasekariah

On an agile project, check-ins are frequent. Every day, in fact. An interdisciplinary team (UX, design, development, content, etc.) will meet every single morning, usually for no more than 15 minutes, for what’s called a stand-up. This is a deliberately brief (everyone typically stands to encourage this brevity) meeting in which each participant answers exactly three questions: What did you do yesterday? What are you doing today? Do you have any blockers (i.e. is anything keeping you from getting work done)?

That’s it. No complaining about Sean in HR. No bitching about the client or your boss or the parking. No scope creep. Just the facts, people. This allows for line-of-sight between people working on the project and signals any warnings of trouble up ahead, but even that trouble gets unpacked and prepared for in a separate meeting. This is just a touch base, as it were.

For you on your lonesome doing an agile sprint of one, that daily check-in still has great value, even if it’s with yourself. Part of the reason is one of the most difficult questions to answer, whether you’re doing a sprint or not, is that middle one: what are you going to do today? That single question is the source of more stress than I care to remember. In fact, it’s a variation on that question, the notion that at any given moment, you should be doing something else, which I belive to be one of the single greatest stressors in any given day.

Agile allows you to answer that question intelligently and, increasingly, satisfyingly. You can say “I am doing X today,” because you will be looking at your sprint, seeing at a glance how much you have left to do on some tasks, which ones you’ve completed, and which ones you haven’t even started, and making an educated guess as to which task it would be best to work on today (it could be multiple tasks, though I personally choose to focus on just one per day). When you commit to that, and that little voice inside you says at some point during the day, “shouldn’t you be doing Y?” you can answer back “no, and here’s why” because you can then point to your sprint and the stand up you had with yourself where you worked all this shit out already. Get off my back, me!

This addresses one of the biggest problems we have, that of decision fatigue.It’s been scientifically observed that making decisions actually takes physical energy. This is why President Obama is rumored to only have a few options of suits every morning, so he doesn’t have to waste valuable decision energy on something relatively trivial.

Agile allows you to put all of that decision making energy up front, whittling down the many, many things you could be doing down to a few once you plan the sprint, and down to only one for the day when you do your stand-up.

Step Five: The Retrospective

Magnus D

The most commonly overlooked (at least in my experience) part of the process is a step called the retrospective. It comes at the end of a sprint when all involved parties look back on the sprint and answer three questions: What worked? What went wrong? What can we do better next time.

This is the “learn” part of build, measure, learn. Without it, the system cannot truly be self-learning. You’ll make the same mistakes, and failure will cease to be power.

For me, once I reach the end of a sprint, I look back at the individual tasks, see how many points I actually accomplished versus what I predicted, and in looking at the individual tasks reflect on the three questions. Then, and only then, do I plan the next sprint, which also includes a look at the backlog to reprioritize, if needed, a variety of tasks before deciding which ones to pull into the next sprint.

A Word About Urgency

A commonly asked question at this point is what role does urgency play in all of this. For example, if there are recurring tasks like “get a haircut” or events or deadline-driven tasks like “prepare Agile Living talk for TED” (it could happen), one look at the calendar before planning a sprint influences the rank of those items. As I get closer to the time when I’ll need a new haircut (about every three months, it grows quick) the rank of the haircut task increases and then immediately decreases after the next haircut. Similarly, the rank of the agile talk prep rises sharply in the weeks and days leading up to the talk, and the drops sharply or disappears altogether from the backlog afterward.

Bonus Step: Tie to Your Inbox

Wanna reach inbox zero? Make an email folder for every one of your stories. I have one for blogging, speaking engagements, etc. Now, every time you get an email that requires you to take some sort of action, give yourself only two choices. One, take that action immediately. Two, create a task and put it in the backlog. Then either discard the email or put it in the folder with the appropriate story.

The one option you can’t give yourself is to leave the email in your inbox as some sort of half-assed to-do list. You’ve either done what it asked you to do, or you’ve created another task for your backlog. If the task ranks high enough, you can put it into your current sprint, but only if you knock something else out. Same rules.

But in this way I’m able to stay at pretty much inbox zero most of the time.

My Dirty Car

Okay, it wasn’t quite this bad, but when I started my first sprint my backlog had the item “clean car” under the story “home”. But it didn’t make it into the sprint. There were just too many higher priority 9000-level tasks ahead of it. So for the next two weeks, I had to get in that car and see how dirty it was. But a strange thing happened. Instead of being annoyed and frustrated by this clutter, giving myself a guilt trip for not attending to it already, I felt a strange sort of peace because I knew I had made a quality decision about when I would clean the car. I knew that if I had second thoughts, all I had to do was look at my sprint and say, “Okay, what’s getting knocked out here so I can clean my car? Oh, nothing? Well then, shut up, car!”

The real value of agile, I suddenly discovered, was around the things I didn’tdo. Having peace around them. And patience. Knowing that eventually, and at the right time, I would deal with these things, and not at the expense of something that was actually more important. This was an unexpected, but very welcome, benefit of agile.

A Healthier Attitude

Recently, I had to prepare a presentation with my boss. The stakes for the outcome of this meeting were relatively high, and we really weren’t sure how our presentation would be accepted. I was a little panicky, and my boss said something very wise about our efforts:

“We will try, and we will learn.”

I was coming from a place of “failure is not an option,” and she was all “we will try and we will learn,” which, if you think about it, is a much more realistic thing to say. Of course failure was an option. No one was going to have a heart attack or fail to get back from space because we gave a poor presentation. The odds, however, of us learning something, whether we failed or succeeded, were actually quite high. Perhaps even more so if we failed. (As it turned out, the meeting went well, but in a completely unexpected way that involved us not giving the presentation at all. So we definitely learned something, even though we succeeded!)

So if you take nothing else away from this rather long and involved description of how I attempted to apply agile principles to my daily life, take this: Whatever you do in life, whether you beat yourself up about it or not, whether you set unrealistic expectations about it or not…

You will try. And you will learn.

So why not live in a way that makes the most of that?

You can also watch this talk as a video. Also, slides from that talk.