Pain Is Just Information

I took a systems physiology class in college one summer, and on the very first day, the professor said, “If there’s one thing you remember from this class, it’s that ‘Pain is just information’.” Pain let’s you know something is up. Or down. Or out of place. Or stuck in place. Or generally amister amiss.

(This blog post is about a conversation from work. I’ll try not to make these boring and solely technical, but if you decide to give up on reading this because you’re emotionally distraught over Scotland not being its own country, remember: Pain is just information.)

Now that I’m a ScrumMaster by day (your local superhero by night), I get to talk through sticking points that my team members have with parts of the process, and the point that was sticking this time involved the Sprint backlog.

(I can’t believe it… to be your own country… you get to stay up as late as you want, eat haggis whenever you want, drink scotch whenever you want…)

During the Sprint, something may come up that we as a team end up working on, with the Product Owner’s blessing, that wasn’t planned for in the Sprint Planning meeting. The question is: If we can add things to the Sprint mid-Sprint, why can’t we remove the things we now know we won’t get done mid-Sprint?

(…skinny dip with my sheep in whatever loch I want…)

Seems like a decent enough question: by accepting sudden stories, you’ve already blown out the original plan, so why not update the plan based on new information? Since the Spring backlog is what the team committed to doing at Sprint Planning, it’s easy to understand why the team doesn’t want to see this thing they know won’t get done: it’s embarrassing, or it induces anger, or it elicits some kind of negative emotion (or else the team wouldn’t be asking to get rid of it), some kind of pain.

(…wear kilts as short as I want…)

The way I sell this is via acknowledging this ‘pain’ as not necessarily bad, but useful: at the end of the Sprint, the stories that do not get done represent a quantifiable adjustment to consider during the next Sprint Planning session. If no ‘outside’ stories were brought in mid-Sprint, then the undone stories represent the team planning to do more than they could pull off. If the story points associated with the dragged-in ‘outside’ stories were the same number of story points associated with the undone stories, then the undone stories were neatly ‘displaced’ by the sudden stories and the team did a spot on job of estimating how much work it could pull off.

(Did you hear about the Scottish cross-dresser? He wore pants.)

Sure, it feels icky to leave things undone, especially when you said you’d do ’em, but if it’s because the Product Owner asked you to do something else, then heck, it’s totally not your ‘fault’ – the person in charge of prioritizing work… reprioritized work! And this was the particular scenario of the sticking point – there was pain, and it was reframed as information.

My systems physiology professor would be proud. If I only remembered his name… this sucks, I really liked that guy… man, this is embarrassing…

(Pain is just information.)

Oh shut up.

Halve It Your Way or A Shovelful of Sugar

Eating your own dog food, or dogfooding, is like the practice of practicing what you preach, which can feel like having to taste your own medicine when the medicine ain’t so tasty, or if it isn’t Gmail.

Want to piss off a software developer? Tell her she’s got less time to code something. This isn’t specific to coders, of course, but this is more the realm I work in, so I can speak to it. She’ll thrash. “Leave me be,” she’ll say. “You foul beast,” she’ll add. (“And stop speaking for me,” I’ll type on her behalf, parenthetically.)

Being told there’s less time to do stuff sucks. The Scrum response to this is to, well, do less stuff.

Folks, I am opening up a can of whoop-ass my own Scrumalicious dog food and halving my Sprints from a time box of two weeks to one week, which means I will proportionately plan to do fewer points worth of things per now-shorter Sprint. “You damn dirty ape,” I say through clenched teeth, “Why?”

I’ll tell me why.

Last Sprint felt a little too eventful, and I was able to track this using my latest Kaizen Story, which was

…to monitor which stories get implemented that are emergent and not related to my Sprint Goal.

In doing so, I monitored myself diving deep into emergent stories related to Bitcoin (invested in 1 BTC), Litecoin (invested in 10 LTC), and AirBnB (opened up our home to strangers). Were they things that ultimately help me out? The Product Owner in me thinks so, but they didn’t further me along the journey of accomplishing my Sprint Goal or getting done my reduced number of Sprint stories. To top it all off, I have yet to do the Retrospective, but I attribute that to getting food poisoning right at the very end of the Sprint.

I feel like I’ve fallen off the bandwagon.

Or have I?

Having relatively short time boxes neatly punctuates what can otherwise be an endless slog of personal development, in the ScrumOfOne realm, or software development, in the just-about-everywhere-else realm. It provides a point of transparency that you can then inspect, from which a specific practice of adaptation hopefully emerges. What I could clearly see was that the points associated with the emergent stories were greater than my predetermined buffer. This triggered a rather Scrumalicious adaptation which, aaugh, increases my chances of getting my Sprint Backlog (predetermined list of things to do) completed if I shorten that list and then shorten the time I next check in… with… myself.

It feels like punishment, which I’m imposing on myself, which is twisted; however, it is a practice designed to get the team to win. For good measure, I’m throwing in a period of grooming my own fur Product Backlog.

Suddenly Deserve A Cupcake

My roommate, sophomore year in college, had a few phrases. My favourites were the euphemism of “intellectual clutter”, and the toothily grinned “treat yourself“.

(He also had a classy way of explaining vectors that involved demonstrating the resultant vector with a directional bobbing of his head between outstretched arms, his longer hair waving behind him like the circular ripples spawned when skipping stones at a steamy summer soiree. (My explanation of vectors is less classy and more… phallic. (That’s because vectors have both magnitude and direction. (Now you can’t unlearn that. (You’re welcome.)))))

This blog post is a continuation of the last, where I talked about leaving room in your Sprint for both the planned and unplanned, allowing yourself to be both proactive and reactive, where stories are thus either strategic or tactical. I can’t help but picture a yin-yang symbol at this point, so the Taoist in me is high-fiving me (from within) (odd… deep… deeply odd?) over my incorporation of balance into Sprint Planning. So let’s address value and effort, specifically for these ‘tactical’ stories that suddenly arise from time to time, by stepping through the Product Owner’s point of view.

The Product Owner is in charge of the vision of the product. For my ScrumOfOne, I view myself as a package of products (Merrill the musician, Merrill the financial responsible, Merrill the home dweller, etc.), each with its own vision. From any particular vision, there are epics, which are just large stories, which are broken down so that they are small enough to be taken into a Sprint, but within the context of its product backlog, a story has both value and effort. Value is indicated by its priority in the backlog. Effort is indicated by an assigned number of points.

All those items in those lists (stories in Product Backlogs) stem from a vision by the Product Owner.

So whether the Product Owner is telling the team to keep implementing stories from the Sprint Backlog (the planned), or to address issues that have suddenly arisen that can’t wait for the next Sprint (the unplanned), the direction is given based on what will get us closer to the Product Owner’s vision. Using this motivation, we will generally work on the thing with the next highest priority (subject to other Scrum principles like reducing work in progress to reduce waste and completing the Sprint Backlog to increase morale and allowing team self-management). Thus, if an unplanned task is suddenly a story with value, then like any other story towards a product vision, it should get points assigned for effort.

Is this cheating?

All I have to do is say that what I’m doing is good for me (something towards a product vision), and I suddenly deserve a cupcake (give myself points for the ScrumOfOne Sprint Backlog).

It sure feels like cheating, especially since it seems almost too easy! If I take my lady out on a date, I get points for a story completed that would have been from the ‘Be a good partner’ product backlog. If I have a friend visit, I get points for a story completed that would have been from the ‘Be a good friend’ and ‘Have a welcoming home’ product backlogs. If I get inspired to work on a project, I get points for a story completed that would have been from the… product backlog associated with that project.

In the corporate realm, sudden stories are taken in and worked on by the team, so you can bet your socks there are points associated with that effort!

Taking this to the extreme, you could be in extreme-reactionary mode, only doing things that come up. In the software realm, this is like only making bug fix releases and never building new features. In the ScrumOfOne realm, this is like only reacting to life and never taking initiative.

The second half of the Interrupt Pattern addresses this by programming an automatic abort of the Sprint if the buffer for unplanned activities overflows. So if the buffer for tactical stories is 15 points per Sprint, and the green light is given for a story that would mean we would complete 16 points or more of stories that were not from the Sprint Backlog, the Sprint pre-maturely ends and there is another re-planning. This drastic measure sheds light on the evident misalignment between planned priorities (Sprint Backlog) and actual priorities (embracing all interruptions).

So (…I tell myself…), if something comes up that is technically a distraction from the Sprint Backlog yet not a total mess (intellectual clutter), then feel OK taking it. Just remember to give yourself points afterwards (treat yourself).

Regularly Scheduled Chaos

Oh – hey! I almost didn’t see you there. You know. From up here on the bandwagon. The view is great. But you’re not here for that. You’re here ‘caus-

Snake Oil! Snake Oil! Snake Oil! Get some now! It’s great for what ails ya! Anything! Anything at all! Grandma got bunions? Papi got the sniffles? Then Snake Oil is for you! Apply directly to the forehead! Snake Oil!

Geez, don’t you hate that? Here we are, having a nice conversation, you down there, me up here, on the bandwagon, out where the deer and the antelope play, and out of nowhere we get interrup-

Fording a river? Who isn’t nowadays! For these hazardous trips, don’t risk it! Leave it to the experts! Let us at Caleb’s help you with some of our special caulk! Caleb’s Caulk! Don’t leave home without it! Caleb’s Caulk!

…interrupted. You can’t predict these things. (Unless, of course, you can …at which point please help me with trading Bitcoins.) You just have to be ready to roll with it (chaos), and I recently learned how after my last sprint (scheduled life).

See, Sprint 141 was my first one back after not doing any disciplined self-Scrumming, so I planned to do all this stuff. I had all this energy at my personal Sprint Planning session, where I looked over my Product Backlogs, grabbed the top-prioritized stories, threw ’em into the Sprint Backlog for Sprint 141, and was all like, “Yeah! I’m gonna DO this! Do it all! All the things!”

Yyyyyeah – no. I did not.

My Sprint 141 velocity was 37 points, which is respectable for me (more on how I’ve assigned points to personal/ScrumOfOne stories in a future post), but in the Retrospective, I looked at the stories associated with those 37 points, and noticed two things:

  1. I didn’t get done even half of what I had planned for that two-week period.
  2. I got a lot of other stuff done.

This ‘other stuff’ was mainly in reaction to unforeseen …interruptions, e.g., a buddy visiting, striking while the iron is hot for a surprise date, sudden extra work at …work.

So there I was, at my own personal Retrospective, feeling both good and bad at the same time. Good because I got a decent amount of stuff done – I was productive! Bad because half of my accomplishments weren’t from the planned Sprint Backlog, which meant they weren’t the top-priority… the things that would move me most towards the respective visions per personal Product Backlog – I was not efficient!

This last part is a downer. It’s a downer because I had done this all the time: planning to do a set of things over two weeks, and at the end of the two weeks, never getting them done. I have thus been injecting into my own life regular opportunities to show myself that I can’t get done what I planned, snowballing evidence of my inability to both commit and commit to myself! What’s a mother to do?

For just such situations (corporate teams encounter this, too), Scrum co-founder Jeff Sutherland recommends something called the ‘Interrupt Pattern‘. Essentially, be flexible to sudden direction changes by planning for less. Sprint Teams can do this by adding a buffer of points into their planned velocity, where this buffer is a placeholder for stories that suddenly crop up, like dealing with hot issues from a customer or a freak Y2K bug that was latent for 14 years.

For ScrumOfOne-rs like me, this means committing to fewer stories at the Sprint Planning, knowing that I will make up the rest of my bi-weekly productivity with either tactical accomplishments (reacting to life – stuff just came up) or strategic accomplishments (living proactively – stuff off my Product Backlogs).

This improvement to Sprint Planning was the more interesting Kaizen to come out of the last Retrospective. The piece of improvement I’m applying to this Sprint 142 is to push daily to complete a planned 1-point story. This ensures I’m doing something each day to refine myself. Today, that 1-point story is pumping out the weekly blog post.

Tomorrow, that 1-point story might well be to buy some of that caulk I’ve heard so much about…

How Not To Forgive Myself

Two guys walk into a bar. (Ooh, a joke…) One guy says, “Hey man, good to see you again.” (Alright, so this next part will be the funny part…) The other guy says, “Hey man, I don’t entirely want to be here.” (…well that was hardly worth a chuckle)

That’s what I actually said to him! Was that rude? (Oh, it’s not a joke, Merrill’s the second guy.)

At my Scrum Product Owner training session over three months ago, I met a Product Owner, started talking about my application of Scrum to Personal Development, heard how he was into using Scrum for Professional Development, and then took the conversation back up a couple of days ago. (A man-date?)

So when I told my buddy that I didn’t want to be there (“I was being a wicked rude jerk-face”), it was in the context of how I see a necessary level of forgiveness from the Product Owner in ScrumOfOne. In ‘regular’ Scrum, this is analogous to the practice of building a buffer into Sprints: a reservation of a part of the velocity for things the team or Product Owner decides to get done that arrive mid-Sprint. (You mean you can’t stick to a plan for a full Sprint?)

It’s because you can never plan what opportunities may arise or what fires may suddenly need putting out – and definitely not for a full Sprint. (Oh.) Thus, I almost NEVER fully follow through with what I set up at my ScrumOfOne Sprint Planning meeting. (And what, you beat yourself up for this?)

And I feel bad (oh) because I see these remaining Sprint Backlog items at the end of two weeks, staring me in the face from the glowing rectangle that lives in my pocket. (‘Glowing rectangle’, that’s funny.) This is what I brought up with my buddy. (Did you mention how you talk to yourself in your own blog posts?)

By me grabbing a drink with him, I’m NOT doing something I had already set up for myself. The forgiveness comes in if I ultimately believe that the activity I DO do (tee-hee) is effectively a story that gets me closer to some vision for myself. By chatting up somebody in the thick of promoting Scrum at corporations, I knew I would learn a tonne (the metric ton, good choice) about the various adoptions of the framework, and I think we were able to devise some concrete next steps for getting professional development underway where he is.

(I get it: doing the man-date meant you didn’t do stuff on your Sprint Backlog, but in the larger picture, it’s all good.)

So now here is my struggle: I want to replace the notions of forgiveness and anxiety over not accomplishing carefully prioritized stories towards building the product(s) of me, with the notion of judgement-free doing.

Yes, I’m trying to weave the Taoist concept of Wei Wu Wei (effortless action), or at least a consequence of this idea, into ScrumOfOne.

Suggestions?

(Yeah, he needs all the help he can get!)