Welcome to Part 2 of our Agile Results series. Now that we know a bit about how Agile works, it’s time to put it into practice.
EDIT: Part 3 is available here.
Part of the Agile system is how it filters down from a conceptual level into an actual structure for managing your days, weeks, months and years. That’s what this part is about – how Agile recommends you structure each of these timeframes. In Parts 3 and 4, we’ll walk you through step-by-step how to do your first run-through of setting up these structures using tools and software that you’re already familiar with, and how to maintain those systems going forward.
If you haven’t read the original Agile book, you can find it here or here.
Let’s get right to it.
The Agile Day is structured in detail. This is because it’s the smallest timeframe that Agile operates at – but don’t worry, once you have some simple templates and checklists in place, the days flow quite smoothly.
The first part of the Agile Day are what Meier calls success factors:
- Day-by-Day Design. Agile works in iterations, and is designed to incorporate the actions and lessons of the prior day into the next day. This is known as day-by-day design – you have the chance to restructure a day based on what happened yesterday.
- Enjoyment. The more you enjoy your days, the better they go and the more productive they are.
- Compelling Outcomes. Having compelling outcomes helps. If you’re having trouble finding these, check out our article on Leverage Points.
- Hotspots and Troubleshooting. A successful day is one that touches on various hotspots and troubleshoots areas that need attention.
- End by Supporting.Each day should support and renew you for the next day.
Here’s how Agile Days are structured:
- Startup. The beginning of each day, where you go from sleep to action. We know this better as a Morning Ritual.
- Administrative. The things you need to do every day, but don’t really add anything towards outcomes. Like brushing your teeth.
- Introspection and Thinking. Quiet time to reflect during the day and nurture your creative side.
- Power Hours. Times of day where you get things done, no matter what it is. Make it a point to identify these and use them to their full capacity.
- Breaks. You must take breaks. We like the Pomodoro Technique for this.
- Play. Every day needs play, preferably interactive play.
- Shutdown. How you wind down at the end of the day. Better known as an Evening Ritual.
Startup and Design
Every morning during your startup phase (morning ritual), you want to design your day. Start by drawing some boundaries and limits for your days: appointments, when you will eat, when you will exercise and when you will sleep. These are locked-in times that are inviolable, and you should structure your day around them.
Identify 3 outcomes for the day. Each should be 2-3 hours in length, though you can obviously adjust if one is larger than the others. Be sure to scan your hotspots (areas of life) for things that may crop up, or that need attention. Make sure that you also find time to address the important, but non-urgent tasks on your list.
Driving Days: How you go about your day
As you go about your day, Agile gives you an approach for how you achieve your outcomes:
- Motivation. If you remember, we talked about the Agile approach(es) to motivation in Part 1 of this series. In Parts 3 and 4, I’ll give you a simple checklist I created that incorporates some Agile and other principles for quick boosts in motivation throughout the day.
- Do the Worst First. This is essentially frog eating. Work on the hardest, or least desirable tasks early in the day.
- Wear the Right Hat. Make sure you’re in the right frame of mind for the task at hand.
- Pace Yourself. Essentially, use pomodoros.
- Power Hours. Once you’ve identified your power hours, make sure you use them.
- Test. The structure of your day is something you can always improve upon. Be sure to experiment, test, and switch things around until you find what works best for you.
Agile gives us 2 endings to the day: work, and then the actual day itself.
At the end of the workday, Meier suggests dumping everything (clearing to neutral), and then visualizing yourself “hanging up your (work)hat” as you switch your focus to personal tasks.
At the end of the entire day, there are some questions to ask yourself as a review and check-in:
- What did I learn?
- What did I improve?
- What did I enjoy?
- What kind act did I do?
A good place to write these down would be a journal.
You then want to go through your shutdown sequence – your evening ritual.
Agile also gives some suggestions for “other considerations”. These are similar to the principles that you use to drive your day, but more of secondary importance:
- Shift Focus. As necessary, shift focus throughout the day, usually between activities or outcomes.
- Execution Checklists. I wrote about a similar strategy in last November’s newsletter. Essentially, use a precreated script or a mini-plan as a checklist for executing a complex task.
- Worry Breaks. Instead of worrying about things all day, set aside some time solely to worry – then get back to being productive.
- Creative Hours. Everyone needs creative exploration time, to daydream, to brainstorm, to solve things that are on your mind.
- Make it work first, make it right later. Results over productivity, or effectiveness over efficiency.
- Batch and Focus. Batch tasks to get them done faster – e.g., photocopying, running errands, visiting people on a different floor.
- Test Drive Results. Test everything about your day, until you get in the way you want it.
- Reduce Friction. Reduce friction whenever possible, to avoid becoming overwhelmed by tiny buildups.
- Quantify. Sometimes, hitting a quota is more important than working a certain number of hours. For example, writing 5 reports in 2 hours is more productive than simply spending 4 hours writing without purpose.
The next unit up in the Agile hierarchy is the week. Remember that each week is there to support you and your days, and that each week is a fresh start – an opportunity to do things right and better.
This starts with preparation. Agile breaks this down into 4 parts:
- Baseline. A rough schedule, Monday through Sunday, for what happens each day of the week. Similar to the boundaries concept for days.
- Committed Timeline. Part of your baseline. Appointments that you can’t get out of.
- Strengths and Weaknesses. I actually kind of like the Agile definition for these – strengths are things that you look forward to, weaknesses are things that you dread.
- Free Time.
Once you’ve identified these 4 things, you can then design your week.
Agile is about optimizing your time usage, not achieving the “perfect” week. With that in mind, designing your week is similar to designing your day.
It begins with setting boundaries and limits, which you’ll already have from your preparation – know your appointments, when you’ll sleep, when you’ll work out and when you’ll eat. Also make time for things that are important to you, like family time or recreation. Remember to include free time.
The next step in designing your week is similar to how you structure your days – batch your key activities like work and errands, and consolidate your weak activities to mornings, and earlier in the week (Monday-Wednesday). You should be focusing on your strengths about 75% of the time, and activities that you enjoy should fall towards the end of the week.
Driving and Ending
Agile suggests driving your week through a 3-stage process:
- Scan your hot spots. Identify any areas of life that need action.
- The Rule of 3. This is about setting 3 outcomes for the week. It can also fall into the “designing” phase.
- Weekly Cycle. Remember that if you mess up one week, you can improve on it the next.
Ending your week is all about reviews. Those of you familiar with GTD already know all about this, but Agile actually gives you a structure for doing it (sort of). You basically review your outcomes completed for the week, and note down anything that can be done to improve next week. If you’re the extroverted sort, Agile also suggests doing a “show and tell” about your week, for the benefit of yourself and others.
Improving Your Week
This is what makes Agile Results such an effective productivity system. In addition to a simple outcome review at the end of each week, you can do various things to make future weeks better, such as:
- Increase Power Hours. Try to increase the number of super-productive hours you have week-by-week until you’re at over 10 hours a week.
- Increase Creative Hours. Same concept as power hours.
- Schedule things you need time for.
- Avoid “all or nothing”. It’s better to get in a bit of something you feel you must do than to avoid it completely.
- Renewal Time. Schedule in downtime and playtime.
- Morning people and Night owls. Some people are morning people and others are night owl. It differs person-to-person, it can differ by season, and it changes over time. Agile suggests experimenting with both to see which suits you.
Agile Results gives you this nifty diagram for planning your months.
The process for planning months is similar to that for days and weeks. You start by listing your desired outcomes, and then you prioritize based on impact and window. Impact is how much value or effect achieving this outcome will have in your life. Window is about windows of opportunity, which can be limited – there will be certain things that if you miss them, never recur again.
Once you’ve listed your outcomes, you set estimates for when you think they should occur – assign outcomes to each week of the month. You can also segment your outcomes in a must/should/could manner, similar to the idea of Covey’s four quadrants.
Implementing Agile at a yearly level is about outcomes and sprints.
Let’s look at outcomes first.
The question that Meier gives us is: If this were next year, what are 3 great results that I would want?
This is a great question and an easy way to come up with your outcomes for the year. Some things he recommends to keep in mind:
- Dream big.
- You will be using project management (i.e., Agile Results and other systems) and intention (inner game) to turn these outcomes into reality.
- Outcomes should be compelling.
- Have a strong reason why.
- Test drive outcomes throughout the year. As an example, if one outcome is to buy a car, you can test drive that model earlier in the year.
- The power of RAS. AE Thanh talked about this recently – it’s essentially the wiring that goes on in your brain to help you focus in on what you’re trying to accomplish.
In addition to the Agile guidelines, we recommend:
- Set evergreen outcomes – those that help you now and into the future. Agile has a similar system where they ask you to assess each outcome against different timeframes (1 month, 1 year, 10 years).
- Pick 1 work, 1 personal, 1 hotspot (other area of life).
The great thing about Agile is that it’s an iterative system. Nothing demonstrates this better than the concept of Goal Agility. This is basically the ability to shift goals when necessary, based on prior action and information acquired. It may seem like a trivial concept, but it’s incredibly useful. Most people are so locked into poorly-set outcomes that they can’t about-face and move in different directions.
If you remember from Part 1, we talked about sprints, or mini-projects you do monthly to improve some part of your life or learn something new. When you do your annual planning with Agile, you also want to plan your sprints for the year (though like outcomes, they have Agility so you can change them as you see fit and as you go).
Year At a Glance
The last part of Agile’s annual planning is the year-at-a-glance. It’s a month-by-month table that contains:
- Key events, like holidays, celebrations and vacations.
- Your outcomes for the year, in rough outline form.
- Recurring monthly activities
- Milestones for your outcomes – what needs to be done by when.
In the next couple of articles on Agile Results, we’ll show how we set up an uber-effective year-at-a-glance using some nifty tools and tricks.
And that’s it for Part 2 of Agile Results. Now you have an overview of the concepts behind Agile Results, and how Agile is supposed to be implemented.
In Part 3 we’ll go through a step-by-step “first run” of setting up Agile with recommended software and tools, as well as how to use the system. In Part 4, we’ll tie in concepts from GTD and other productivity systems with Agile – you’ll absolutely love the results.
EDIT: Part 3 is available here.
If you want more articles and tips like these, let us know where we can send them to:
Photo by: lrargerich
How do you manage all of your outcomes? Do you write them out on paper/use software?
Is there a way for you to at a glance see all your daily/weekly/monthly outcomes?
you say “Identify 3 outcomes for the day. Each should be 2-3 hours in length,”. If you have 3 daily goals that’s 9 hours a day. This implies that the goals you set for the day don’t necessary contribute to the goals set for the week, month or year.
For instance if I want to get something done for my employer like writing a bit of a specification this doesn’t contribute to my yearly goal of spending 3 months abroad in Japan. Is this still all right with AE?
I have been using Agile Results for a couple of months.
And recently I have incorporated Day by Design which I regularly did the night before and revisit it in the morning of the day.
I could say that it is one of the most powerful practices in Agile Results.
It provides me a lot of energy to direct my focus throughout the day.
Thumbs up for Agile Results!
Thx for great article here.
Love the article. However, I use Day One as my journaling system of choice, and it doesn’t seem to really map to this well (it’s more geared towards entries, rather than tagging/folders, etc).
Do you know of anyone implementing Agile Results using Day One as the journal app?
Not at the moment. I haven’t used Day One so I’m not sure how to make it work either.
This is really awesome… I can’t wait to see the article about putting all this together in a practical way. Keep up the great work!
I love this series! I am able to integrate Agile in a way that I’ve never been able to with orthodox (or even derivatives of) GTD. Powerful.
I just want to say thanks for introducing me to Agile Results. Since Part 1 I have read the entire book. It seems to address the holes that GTD has. Mainly I avoid being stuck in just doing tasks and instead I achieve results. I still need to test it a bit further and implement it for the entire team, but things look very promising.