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’.

Listen To Your Body

I was on vacation for the first half of the last sprint. For the second half, I powered through stories worth more points than I’ve done in a full sprint! But I almost didn’t.

I have this beautiful desk that was effectively inaccessible due to suddenly stackable mounds of stuff on top of and below my bastion of productivity – so you should now get a sense of the fire under my butt to make the space more livable. After work, I’d come home and attack post-move remnants of chaos – the refugee motif is charming for only so long. Every square inch of recovered surface was a win, an emotion stackable in its own sense, like the points of complete stories I was racking up through the week back.

Steamrolling towards a vision of a home where I’m not stepping over a box, I couldn’t help but notice competing motivations. My own medicine was dangerous: seeing progress in physical form and especially on a burn down chart was contagious. Although I was eating and resting enough, I felt like I was still running on fumes: fumes of will power. With blinders on, my body was trying to get a word in, edge-wise:

Dude, veg out.

“Don’t be weak!” I scolded myself, “Marvel at all this reconquered space!”

Dude, you suck. I require a break.

“Don’t be weak,” I whispered to myself through my teeth as I carried on. Yet, who was I kidding? I just wasn’t as efficient. You’d think this concept of taking a break is a no-brainer, but when you’re driven, slowing down represents a step in the wrong direction.

Unnecessarily long story short, I took a breather, recharged will power, and started back up again at a decent clip. This a great example of an idea in Scrum and moral of the story: work at a sustainable pace. So listen to your body and don’t get to the point where you’re body is talking to you in italics.

Dude, thank you.

You’re welcome.

Your Power Hour

Some people are night owls. Other people are early birds. I people am not a fowl of any kind, thank you very much. (However, I am a male seahorse named Spikey, but that’s a different story…)

Do you ever get that jolt of inspired activity, where you suddenly want to do this thing and then you do it? Well, capture the nature of that jolt and ask yourself if you have a time of day where you’re likely to be as productive, relative to this jolt. This is your Power Hour! Now, apologize to yourself for asking yourself another question, then ask yourself: When is your Power Hour?

For me, if I can plop myself in front of a computer from the moment I wake up, I am super productive. Also, between 8:30 and 9:30 before my first meeting seems to be when I get lots of stuff done. Such times are usually ones where I am least prone to interruption and have a strict deadline. In the latter example, that Power Hour ends with the morning Scrum at work, whereas in the former example, that Power Hour ends when I start getting hungry. These are moments of sheer focus and Matrix-like clarity.

These times of day may not happen every day, but I wager that more often than not, much like for night owls and early birds, there is a time of day where you’re naturally more efficient. If you don’t know this for yourself, find it, even if it is by process of elimination, e.g., you’re useless after dinner or before your third cup of coffee.

After determining your Power Hour (and this is more a time of day than a strict 60 minutes), think about which tasks/stories you would want to have done during this time. Also, think about this somewhat physiological logistic when setting the day’s game plan during the Scrum. Besides prioritizing to work with your natural inclinations, this visualizing of getting a set of things done during that magical time feeds the good kind of self-fulfilling prophesy, and I’ll take a positive feedback loop like this whenever I can.

Don’t Have A Fine Day

Don’t do it. Just don’t. Whatever it takes.

If somebody asks you, “Greetings, citizen! How fares your day?” and you say, “Fine!” …then… think about that.

Fine? Do you really want a fine day? Just… fine? It’s your day, so if you could chose an adjective to be associated with it, would you really want it to be ‘fine’? Come now, fair citizen, surely you wish this not.

This line of thinking comes from ‘Tribes’ by Seth Godin, where he says that if you are having a fine day, then you’re not leading, because leaders are the heretics, out causing trouble, passionately speaking out against the status quo and creating change because the marketplace demands it. To be a leader, I can see this definitely applying.

To be a living human being, I can’t see why this shouldn’t apply.

If you’re having a fine day, then it is not an exciting day. Could you have an exciting day and honestly say it was just, well, y’know, fine? This echoes a definition of happiness from ‘The 4-Hour Workweek’ by Tim Ferriss, where he equates happiness to excitement. If you are doing things that excite you (excites you to your core), then you are living life happily.

Let’s take this a step further and rock the boat a little: If you’re having a fine day, then you are not happy.

Ending on a lighter note, I challenge you to not have a fine day. Ever. Fo’ realz. Don’t float along the currents of everybody else’s life. Wake up every morning and tell yourself to make waves. I make this a part of my morning Scrum.

Stay in trouble, citizen.

Short-Term Press Release

You have a direction in life? Holy cow! Congrats!

Wait, you don’t? That’s cool. Having a direction for life is pretty major. Let’s start with setting a direction for, say, the next two weeks.

Before I found my life calling, I had a large prioritized list of things I wanted to be and do. Spanning numerous aspects of myself (musician, ScrumMaster, runner, host, boyfriend, …), I had little focus to my stories within each two-week Sprint. At some point, I adopted something I read in ‘Rework’ by Jason Fried & David Heinemeier Hansson, a couple of guys from 37signals: the concept of a short-term press release – What is the exciting new thing you will share proudly with the world at the end of your Sprint?

The Sprint Press Release became a focal point about which my stories would congregate and, in a sense, filter themselves. A theme would arise. The similarly-themed backlog items would, through the Sprint, help each others’ completion because they were related. They would all share the same spirit, that which is represented not by the sum of parts (functionalities of all stories, combined), but by the whole, an example of punctuated evolution where a new functionality emerges that is relatively large, possible only because the smaller stories were completed.

Thus, rally stories within each Sprint around a theme. They’ll be easier to get done, and because they’re along the same vein, that’s a sense of –

You have a direction for the next two weeks? Holy cow! Congrats!