6 Steps for using Agile Self Development

Agile Self-Development is a lightweight methodology for personal development that is a reaction against all-or-nothing goals and resolutions. It lets geeks repurpose Agile tools and methodologies with which they may already be familiar.

Dinah Sanders wrote a lovely Agile Self-Development Manifesto that really resonates with me:

• Increasing individual flow using whatever works over adherence to a system
• Quality of life over quantity of achievement
• Simplicity over complexity
• Responding to change over following a script

BSP: Dinah Sanders and I are hosting a core conversation about Agile Self Development at SXSW, on Saturday, March 12th, at 11am in room Rio Grande B at the Marriott Courtyard, 300 East 4th Street (half a block from the northwest door to the convention center).

When I start working with a new coaching client, they often arrive with a massive list of everything that they want to accomplish in their work and their life. Desires are limitless! This situation reminds me of a CEO who is hungry for every single feature in a software product to be implemented immediately. So how to begin? Here is what we do next:

1. State your big, exciting vision: What is it that you want to create, do, or be? Agile Self Development will help you get there, although the “there” may change along the way.

2. What are all of the ways you could embark on reaching this vision? This is your chance to brainstorm, and pour out all of the possibilities. (3×5 cards come in handy here, although making a list on paper is also just fine. If you’re around other folks, this is a great time to ask for suggestions.)

3. Which item from the list will yield immediate results, is do-able now, and uses your current skills, abilities, and willpower? Whatever you choose will be what you’re going to work on for the first sprint. You also need to choose a sprint length: a day, a week, two weeks, or a month.

4. What are you going to measure to know if you’re making progress (your velocity)? This might be whether or not you actually did something, how many minutes you did it for each day, how you felt at the end of the day, how many people you talked to about something, or how many hours you slept. Find something meaningful to measure. Then make an estimate of how you think things will go.

5. Now start the sprint! Go! Don’t forget to have fun with the experiment; Agile Self Development values quality of life over quantity of achievement.

6. At the end of the sprint, host your sprint retrospective meeting. You can host it by yourself, you can write about it online or in a journal, or you can invite a pal to talk about how things went. Pals are always nice and they provide perspective, which is why some people love working in pairs.

Here are some good questions to ask at your sprint retrospective meeting:

• How did the experiment go?
• How accurate was your estimate?
• What did you learn about yourself/the world?
• What was the Awesome? (The thing that went unexpectedly well).
• What was the Mystery? (The thing you can’t yet explain).
• What will you change for the next sprint? (This could be a small adjustment or it could be a huge pivot to a new idea).

I don’t use every single one of these questions every time, but some version of this tends to work well for most people. The goal is continually update the experiment to move continually closer to your vision – which could change over time – and to learn about yourself and the world in the process. (In her writing on Discardia, Dinah refers to this as “Perpetual Upgrade”). One of the things I love most about Agile is that it produces both early tangible results and learning.

Watch for ongoing developments on this topic at AgileSelfDevelopment.com, where there is also a slightly shorter version of this blog post.

If the term Agile isn’t familiar to you:

“Agile” refers to a lightweight family of methodologies for writing software, and a group of developers published the Agile manifesto in 2001. The Agile umbrella includes things already in use at that time like Scrum (’95), XP (’96) and Adaptive Software Development, among many others. Agile and its predecessors were a reaction to heavily regulated, micromanaged, waterfall development methods where most of the results come at the end of the process.

Although there are many different techniques that are now called “Agile”, these are common ideas throughout:

• early and continuous delivery of valuable results
• adaptation to changing information and requirements
• measuring progress against estimates regularly
• reflecting on effectiveness and adjusting accordingly

You can read more about Agile on Wikipedia.