Personal Overhead

This is the post where I share my ScrumOfOne existential doubts.

Do I doubt this whole “Using Scrum for Personal Development” idea? Yes I do, yet I think it’s somewhat healthy. It is very encouraging that Scrum encourages critical thinking by building in a time to be retrospective and thus adapt: choose to amend the set of processes I’m imposing upon myself, which includes killing off all that overhead altogether! There is a question from ‘The 4-Hour Workweek’ by Timothy Ferriss that fits this all too well:

Am I being productive or just active?

Rephrase:

Am I inventing things to do to avoid the important?”

I’ll admit that I feel this ScrumOfOne idea is kinda my baby; I really like the idea and have found it key to managing how I purposefully get things done. So that I can analyze if these ‘Scrummy’ practices are a good return on investment, I have turned to these existential questions from ‘Rework’ by Jason Fried & David Heinemeier Hansson:

Why are you doing this?
Is this actually useful?
Will this change behavior?
What could you be doing instead?
What problem are you solving?
Are you adding value?
Is there an easier way?
Is it really worth it?

Man, those questions are straight-up down-right (left hook?) harsh! And I like ’em. A lot. They bleed with the spirit of Getting Real. I had huge plans: waking up at 5:31am to step through the three questions (I even convinced a buddy to be a part of this pre-dawn Scrum), stepping through and documenting a formal Retrospective, writing a PERL script to manage a text-based Product Backlog, reading weekly a set of quotes & phrases & book notes I’ve collected over the years as my personal set of Psalms. These weren’t just plans… I actually did them for a while!

So do I still do all this? Hellz no! These ceremonies were just not sustainable for the long term. My commute schedule changed, so 5:31am turned into an ungodly hour to be awake, although I still have the 531am.com domain name. My Retrospective currently covers what happened over the past two weeks, how process adaptations fared, and what process tweaks to adopt. My Product Backlog is a Google Doc with the Sprint Backlog at the very top – a text editor in the cloud suffices. My hours-long re-centering read now happens monthly. I pared down the personal overhead to manageable levels based on fruitful returns.

Sure, ScrumOfOne takes discipline, which connotes a struggle, though what I’ve found as I’ve been massaging this system of processes is you can change the nature of the motivation when you see the fruits of your labor. The morning stand-up has turned into 15 minutes of alignment, mental prep, and a generally feel-good start to my day. It’s a trigger to personal finance documenting, reading a few fruity-sounding affirmations, and walking into the day with a purpose. When I do this, I literally walk differently. (I do!) This whole Scrum business is just that transforming.

Thus the system continues, yet only because it started with a habit: a small step: the seed of a fruit I hoped would work out. Upon processes that proved their own worth, I added, modified, and removed (…mostly removed) as I evolved this personal overhead, like trimming a fruit tree.

Alright. Seriously. What’s up with all the fruit in this post? I think I’ll grab a pear…

Hide And Seek

Ever play ‘Hide and Seek’? At work? Try it some time – it’s what the cool (and productive) kids are doing.

The idea of a Sprint, a block of time to do stuff, is simple. And there’s magic in the web of it.

It is magic in that it protects a constant while still embracing change. Before a sprint, you set up what you will do for that duration – this list is called a Sprint Backlog. Once you enter the sprint, this magic box of time (I do two weeks), your Sprint Backlog is shielded from the weather. It might be calm and sunny, where you’re not really pressured to deviate from the plan. Other days, you might be in the middle of a crazy sand storm & hail front, where you’ve got what feel like forces of nature vying for your attention. Regardless, unless it is something catastrophic, Scrum espouses that you stick with implementing the Backlog for that Sprint; changes in priority and direction are handled in the Product Backlog (the larger list of things to do), which is then addressed in between Sprints. This allows you to get stuff done and not be affected by emergent distractions, usually changes in direction. Simple, yes no?

This is a strategic modus operandi. Let’s adapt this thinking to the realm of the tactical.

In the corporate environment (ah, cube land), you’ve got meetings, folks walking by and chatting, and guys flying stunt maneuvers with their (awesome, yet annoying) toy helicopters. These are distractions. Sometimes, they’re welcomed. Other times, when you’re in the zone or earnestly trying to get stuff done, they suck, and the DJ Tiesto-grade headphones that you bought for yourself as a Christmas present blasting progressive house don’t drown out the high-pitched whirring of spinning blades. Let’s apply some of the magic from Sprints and lessen the suckage:

Play Hide and Seek – block out time, space, and attention.

Block out time: Go into MS Outlook. Got a couple of hours that you would like uninterrupted? Create a meeting with one mandatory attendant – you! (awww…) Now when others are setting up a meeting that includes you, they’ll look at other available times, or think they’re super-important and double-book you while apologizing. (booo…)

Block out space: Go to a conference room. Hide. Wouldn’t it be cool if they made grown-up versions of Study Hall? It’s a sacred place where work gets done. Phones and pagers are silenced.

Block out attention: Turn off instant messaging. Turn off email. Do you really need to know the second you get an email via a pop-up in the lower-right corner of your screen?

Got any similar tactical tools you’d like to share?

Proof Of Concept

Got a grand idea? Is it… too grand? If you think it is, then you’re right: it is. This idea may be a vision, a Scrum story too large to tackle in one sprint – that’s why they’re called ‘epic’s. You think about the logistics for getting it done: you break the epic down into smaller stories. You do the Scrum thing, and now each story is independent, negotiable, valuable, ‘estimatable’, small/specific, and testable – all that good stuff. Yet, while they’re now small enough to tackle in a sprint, it might not do anything to increase your confidence level – you still can’t see this grand idea come to fruition.

Take some time to convince yourself – set up a story that is a proof of concept. Craft a story with a definition of done where you will be convinced that this seemingly lofty goal is indeed attainable.

Congrats – this is your Version One.

I see a couple of ways to set up stories towards an epic. You can start with the epic in all its grandiosity and dissect it into what are essentially building blocks: get this part of it done, then that part, where some of the later parts will build off of the previous ones. The problem with this is that you are working off of one version of the vision that does not allow for evolution. As you’re building up to this blueprint, what if the vision changes? Now you have stories done (components built) with a specific purpose in mind that might not be easily reused – waste.

The other way to eventually materialize this epic is to ‘get to done’ a version that is scaled down – a proof of concept. Scrum espouses shippable product at the end of the sprint, and I see this partially to the benefit of product development; the sooner the product ships, the sooner it can get into the hands of the user, the sooner feedback can be harvested and analysed, and the sooner we can get updated on how to keep building this product – if at all! Abandoning ship is always an option, and isn’t it much better to figure that out sooner rather than later? Steering the product in very different direction is also a decision that’s better to get to sooner rather than later.

Now, iterate. Take this Version One and incorporate feedback into the vision you’re building towards, the grand idea that may be evolving. This is how you take versions of ‘good enough’ to ‘great’.

Top Of Mind

Half a year ago, I wrote about how I prioritize my ScrumOfOne backlogs. (Hold my horses… more than one personal backlog, I say? A future post covers this…) What I am finding now is that while, yes, each backlog is prioritized based on its vision, the backlog for the current sprint consists of items that are top-of-mind.

Idealism is great. It also takes discipline. While, yes, taking steps to grow me via my different facets is the road of continual life improvement I prefer to take, sometimes dealing with boxes after a recent move is an itch I feel I must scratch. (Hold the smart phone… what’s this ‘facets’ business I’m talking about? Did I just throw in the kitchen sink? Nope, that’s FAUCETS, and that future post will cover this, too…)

Yet, removing post-move clutter (floor-al chaos?) does not feel important, especially in that strategic sense; I don’t feel like I’m growing, nor investing in myself… I feel like I am delaying. So, fine, I could work on that and take direct steps towards life mission output and processes, but this does nothing for day-to-day living conditions. Thus, both strategic goals and tactical goals are top-of-mind. Oh, horsefeathers, what do I do?

Of course, rid myself of the refugee motif in the apartment. While, yes, tactical vs. strategic trade-offs are not usually this drastic, I try to accomplish the lesser of the two evils anyhow, thus choosing to tackle tactical backlog stories first. Thankfully, David Allen of ‘Getting Things Done’-fame agrees with this approach. After getting control (mastering workflow) is getting perspective (horizons of focus), where we start with addressing next actions (buy cat food) before addressing principles and purpose: get deck-clearing capability first before being able to think at a higher level.

There you have it, folks – how I prioritize my sprint backlog with more ease of mind: address tactical stories at the top of your mind, thus preparing for strategic stories by clearing your mind.

Prioritize By

Not all stories for a ScrumOfOne lend themselves to prioritization by business value. So what other criteria am I using? Prioritize by…
  • How badly I would like it
  • How badly I want it
  • How enthusiastic I am about it
  • What gives me the greatest joy / bliss
  • Highest frequency of usage
  • Ability to develop something to mastery
  • Ability to make ScrumOfOne more transparent
  • Upkeeping & maximizing already solid investments
  • How much it would ease my mind
  • How awesome it would make me feel
  • Biggest step towards product vision