Agile Magic — A Magical Philosophy for Chaotic Times

Responding to change over Following a plan
* This line always reminds me of Cake’s “Building a Religion.”Here, roughly, is how it works. You have a project with a goal and a list of features. Maybe the goal is nebulous, maybe the features keep changing. So you write down all the features you know now and put them in order of importance in a backlog. The keeper of the backlog is the product owner (the PM role).

Then you get your team together and make a plan. You will all sit down and decide what to do for the coming sprint (traditionally a month, but can be anywhere from 2-6 weeks). The team will pick items from the top of the list and break them down into small pieces. The team votes on whether the pieces seem small, medium, large (using previous experience). They add items to the sprint until it feels like the right amount to do. Any technical discussion or decisions are made in the meeting. Finally, the team makes a commitment to do the work.

Every working day you get together for 15 minutes. This is called the ‘stand up’ because you keep the meeting short by making everyone stand (this is a brilliant technique by the way, if you need consensus quickly, remove all the chairs from the room). Round robin, each person says 1) what they did yesterday, 2) what they will do today, and 3) if they are stuck or blocked for any reason. This is to help keep everyone informed.

At the end of the sprint, the team gets back together. First they show off the work they did to each other and interested stakeholders (execs, managers, customers, customer reps, random passersby). Any feedback is captured in the backlog and prioritized by the product owner. Then the team talks about the sprint, what went well and what didn’t, what would they like to change next time. Finally, the team takes the next set of items from the top of the backlog and starts the process all over again.

There’s a bit more to it, but honestly not much. It’s a very basic and rhythmic process for not just getting software developed, but getting the right software developed. At any point, the stakeholders (and the team can be a part of that group) can decide to change course, add something new, or remove something that’s not working. They can change their minds about what’s important and adjust as they go. Your competitor just came out with a hot new feature? Market forces realign? Customer feedback is different than you expect? Just adjust the list in the backlog and the team can refocus within a couple of weeks. No need to wait six months until the next release.

But what about all that heavy project planning and risk analysis and stuff I’ve been talking about? Isn’t agile just, like the exact opposite of that? Well, some think so, but I say not necessarily.

Both methodologies have really useful tools and are applicable in different ways to different situations. For example, the core premise of agile development is that at the end of each short “sprint” you should have a piece of working software you can show off to your stakeholders. This allows them to give live feedback. In fact, many websites are hard-core agile, rolling out changes for live user testing frequently (Amazon is a prime example). It’s fast, flexible, and really supports tinkering. No deadlines until the product owner decides it’s done. No budget as long as you have money for one more sprint. Everyone works together and shares the effort, no different specialties or silos.

But how to you apply that to building a bridge? Well, you don’t. Because if your website or software falls down after an unsuccessful sprint, you just roll back the changes and try something new. If your bridge falls down… well, that’s one of the reasons the PMBOK is close to 600 pages. Because if you’re building something real in the real world, you have to have your act together. You can’t waste $500,000 on some steel supports (or a new server farm) and THEN test whether it works.  And even in a lot of software environments, you can’t just not have a deadline.

I usually find myself using both methodologies together in my professional life. Externally, that is up and out, I use more formal project management methods. Internally, for the core development, we use the agile methodology. This works well in situations where you have an external deadline, hard budget, and more complex resourcing scenarios, but the team still benefits from work on short, incremental pieces of code with lots of opportunity to make changes when necessary.

As I’ve said before, I believe in using the best tools for the job — sticking to what works. For magic, there are scenarios where agile is the way you want to go and others where more formal project planning is a really good idea.

There’s a quote that I can’t find the source for that goes something like: People either know where they want to go, but not how to get there or don’t know where they want to go, though they could get there if they did.

For example, if:

• The career book  I Don’t Know What I Want, But I Know It’s Not This sounds like it was written just for you.
• You feel stuck, but you don’t know where to go next.
• You want to refresh your spiritual life, but aren’t sure what to do
• You want to be happier, but you aren’t sure what will make that happen.
• You have an open-ended decision to make.
• You are suffering from the tyranny of choice.

…then you don’t know where you want to go.

Agile is your best bet here. Tinker, pivot, course correct. Do lots of small things and check in with yourself frequently. Keep overhead low. Sign up for half a dozen seminars, shoot off a ton of sigils, spell for road opening. Spend a day gardening, volunteering, writing. Do divination for self-knowledge and data gathering. Say yes to every opportunity, but avoid major commitment. Watch for omens and subtle feedback.

You can easily use the month schedule (either lunar or calendar) in the same way as an agile team does. Start by sketching your high level goal (“I want to be happier”). Then create a list of things you might want to do or try to make that happen (take a calligraphy class, perform a house blessing, offer to your ancestors, do divination to see if there’s a negative influence, kick out your roommate). Put everything you can think of and then order them by most interesting/likely/important. Then at the start of each month, pick from the top of your list. Break down items into doable pieces and decide whether they are large (in terms of time, money, energy) or small. Then commit to doing only what you feel you can do that month.

Every morning ask yourself what you will do that day to get those tasks done and remind yourself of what you did yesterday. See if there’s anything you’re stuck on. At the end of the month, look back and see how you did. Did any of what you tried work toward your goal? Were any of the items complete failures? Did you get new ideas to add to your list? Did the goal itself change? It’s feasible that after six months of this you may just discover that “I don’t know what I want” has become “I want to get a degree in social work and move to Washington” and “I want to be happier” has changed to “gardening and volunteering make me happy — do more of that!”

On the other hand, maybe this is you:

• You have a destination in mind (social worker in Washington), but are a long way from being there.
• You must make a major lifestyle change (like a health overhaul) that impacts all areas of your life.
• You want to nurture a specific spiritual relationship long-term.
• Your life has complex logistics (mortgage, children, illness, pets, etc.) and is resistant to change.
• You are crystal clear on a goal of any kind, but the goal is on a very different path from where you are.

In this case, you know where you want to go, but aren’t sure how to get there. You probably need more structure around your working. It’s not enough to just try things, you have to have a plan in place and understand all the costs, dependencies, and risks. Note, you can — and in fact should — still tinker where you can. Apply to college both locally and in Washington (and hey, why not Oregon too?) for the social work program — see where you get in. But in order to apply you need to ace the placement test, which is going to require planning and study.

Anywhere the commitment is big, the risks large, or the costs major, you will benefit from more structure. For example, if you have a good paying job you are unhappy with, you need to be careful casting a spell for a new job you love… lest you end up unable to pay your bills. You really need to work through your options.

And it’s totally feasible that your working will contain elements of both methods. Maybe you plan the big changes, and tinker on the ways of making them happen. Because no matter how much planning you do, you can still change your mind or the situation can change as you go. Change is inevitable, so prepare for it in your magic.

Because the worst result is often not outright failure, but the wrong success.