"Wait a minute. This sounds like rock and/or roll."



So my wife is trekking in Nepal with Above and Beyond Cancer for three weeks and I am playing single dad with my 3rd and 6th grade kids.  I knew there was no way I could keep track of all of the kids various activities not to mention my own busy schedule even though my wife had meticulously documented everything in our shared Google calendar.  So the first thing I did the day she left was to set up a Kanban board on the sliding glass door that leads to our back yard.  This is the single most visible space in the entire house — it is the first thing you see when you walk in the front door.  I knew for it to be useful my board had to be extremely visible.  Next I instituted a new program with the kids — each Sunday we would spend a half hour planning the upcoming week: what homework is due?  what sports activities are there?  what play practices? etc.  Those cards went up top; color coded by person.  Then each night we would spend 5 minutes planning the _next_ day; moving the cards from the top section to the “Today” section.

Mack with Kanban board


We are now one full week in and so far it has been smooth sailing.  No missed homework, no missed practices, good meals each night and the house is reasonably clean!  I even got my son to pick up dog poop in the yard so he could move a card to “done.”

Jack and Mack with Kanban board

Jack and Mackenzie

Update 10/2/2012:

My parents came over to help out for a couple of days.  My mother reviewed the Kanban board and with a puzzled look said:

“Isn’t that stressful to see all of the things you have to do?”

To which I replied:

“Not as stressful as NOT seeing it!”



How to treat your customers if you want them to go away

Last Sunday I sat down for movie night with my family. I have lots of ways to watch movies these days: Comcast, Netflix, Hulu, Amazon, Redbox and iTunes to name a few. On this night I decided to use the Zune Video store since the kids were already playing Xbox and I have some “points” stored up I can pay with. Easy. We agree on a movie and get it started — it’s looking pretty good. About 5 minutes in it pauses as it buffers the content…it happens occasionally so no big deal, we wait it out.

After about 5 seconds of pause the movie resumes — but it keeps doing a freeze-frame during the action sequences. At first I think it might be some kind of nifty effect. But after a number of freeze frames in strange spots I begin to suspect something is wrong. Then more buffering — this is not good. Another 5 seconds and the movie starts again. A few minutes later an error message pops up: ” There was a connection error. Please try again later.” WTF! The kids are getting annoyed. We start the movie again, optimistically hoping it will work this time. But no such luck — buffering every couple of minutes followed by another error message.

After about 20 minutes of this we decide it’s been enough. It’s Family Movie Night, let’s not spend it wrestling with technology. Luckily we have choices — so I fire up the Sony BluRay player, connect to Amazon, rent the same movie (in 1080P no less) and we finish watching. Mission Accomplished.  Kids go off to bed.  I will send an email to Microsoft Customer Support in the morning and simply get a refund for the movie rental that we couldn’t watch.

The next day:  Send email to Customer Support.
Hmmm…which one do I click on?  Xbox?  Zune?  Billing Issues?Microsoft Help Website

I take a wild guess and go with XBox.

This is a simple problem and we’re talking about 360 “Points” (about $4.00) — no point in calling, this can be handled by email or chat.  I’ve had minor streaming issues with Comcast and Apple before and it’s no big deal, they refund the rental and you rent more.  I send an email to support explaining the situation and ask for a refund.  A day later I get my response:

XBox Email

“Steve, the email support channel cannot discuss on billing such as refund.”

“I recommend to contact the Xbox Support Specialists for it to be rectified as the email support channel has no access to the account for security purposes.”

Great.  Here we go.  OK, I’ll give them a call to see what happens — surely Microsoft values me as a customer and wants me to continue spending money on my XBox right?  So I call.  I call the local number with a 425 area code.  I get a guy who is actually pretty good.  He wants to help me troubleshoot my XBox (“did you reboot it?”, “did you clear the cache?”, “did you check for updates?”).  I explain that I am not in front of the console and that I will do those things later but that it was “Family Movie Night” and I wasn’t going to waste it fighting technology.  He understands — he reviews notes and informs me that Zune did, in fact, have some streaming issues on Sunday evening and I was due a refund.  FINALLY!  However…since he is part of “Xbox” he can’t give me a refund, I have to go to Zune.  Seriously???!!!  Fine.

“Can you transfer me?”

“Unfortuately I can’t but I can give you the number…stand by.”

By this point I am getting leary.

“What do I tell the Zune guys when I get them on the phone so they won’t send me back to you?”

“Oh, don’t worry about that, I have made notes on your ticket.  Tell them you were having issues on Sunday night.  They know there were system problems on Sunday night and they will give you a refund.”

“Great thanks.  Goodbye”.

I’ve been on the phone for 30 minutes now.  My ear is tired.  I am starting to get really annoyed that Microsoft has not given me back my $4.00 yet.  I find the Live Chat option for Zune Support.  It didn’t take long for him to attempt to send me back to Xbox Support.

Zune Transcript

“Since this was done on the Xbox the Xbox support team will have to trouble shoot this with you.  If they determine that this was a technical issue they will be the ones to issue the refund.”

My favorite quote:

“…it would surely be in your best interested to make sure everything is in order so this does not continue to happen.”

I have [at least] five different ways to ensure this doesn’t happen again: Apple, Amazon, Comcast, Netflix and Hulu.  Why on earth would I ever spend money on my Xbox again?



Practice makes perfect

In my spare time I decided to build out a website on AWS.  I haven’t been in the nitty gritty details of writing software and configuring web servers for close to 10 years — and back then I was working in a Windows environment.  Needless to say there is a bit of a learning curve to overcome when going from 10 year old Windows IIS configuration to current Linux/Apache configuration.  Fortunately a few people have done this before and left plenty of documentation that is only a quick Google search away.  After numerous battles with certificates, public keys, private keys, security groups, opening ports, ssh-ing, scp-ing, vi-ing, bashing, and sudoing I finally got “hello world” to appear on my website.  I took a moment to revel in my triumph….and then I promptly deleted my AWS instance and created a brand new one.  Why you ask?

As I was getting close to the finish line I thought to myself “I wonder if I could get this thing working again if I had a problem?”.  The answer was “maybe but it would be a challenge”.  At the same time I recalled guitar and piano lessons from my youth where my instructors encouraged me to practice until I could play an entire song (or passage) all the way thru without mistakes.  This made me realize that even though I had a working website on AWS it didn’t really count because I made so may mistakes along the way.  So I started over from scratch.  Surprisingly this time I was able to get the website up in about 90% less time without any “mistakes” along the way.  I bet I can knock off another 90% the 3rd time around.

Over the course of my career I have wasted much time debugging poorly configured systems — some that I have built and some that others have built.  I think I am going to take the advice of my music teachers and practice more often from now on.




Forget Priority and Severity when writing Bugs

Several years ago I was struggling with a very complicated set of rules governing the setting of Priority and Severity in a bug tracking system I was working in.  I did a bunch of reading about best practices but I kept finding answers suggesting complex rules about setting Priority and Severity.  In bug triage meetings I wanted two answer two simple questions: 1) is this bug in the release or not? and 2) in what order should this bug get fixed relative to the others?  I finally found some more compelling articles like this one from Fogbugz which suggested a single Priority field whose purpose was to answer my first question: is this bug in the release or not?

This method has worked fairly well — but more often than not the answer to “is this bug in the release?” is “it depends”.  Rarely did the actual spoken semantics translate to the semantics in our bug tracking system (Blocker, Critical, Major, Minor, Trivial).  We had lots of discussions like this: “This bug is a Major — does that mean it’s in?”, “This bug is just a spelling error, does that make it Trivial?”.  It was still difficult to tell what was in and what was out because we were conflating the size and complexity of the issue with it’s priority; and the semantics weren’t helping.

Here’s what we did: MoSCoW.  I renamed all of the Priorities in our bug tracking system as follows:

Blocker ==> MUST.  This issue must be fixed for the upcoming release or we will not release.  Period.  Fix all of these first.

Critical ==> SHOULD.  This issue _should_ be fixed for the upcoming release.  If push comes to shove we can defer it to the next release. Fix these after the MUST’s

Minor ==> COULD.  This issue is a “nice to have”.  Work on this when all of the MUST’s and SHOULD’s are done or if you need something small when all of the SHOULD’s are too big.

Trivial ==> WON’T.  This one isn’t going to get fixed.  Sorry.  It gets to stay in the system for posterity — maybe some day it will get reanimated.

Major ==> This is the default in our tracking system and was causing problems because it was indicating “not prioritized” but was always stuck on a release.  Therefore Major became UNKNOWN which indicated it needs to be prioritized.  UNKNOWN bugs do not get to be assigned to a release.

Now the rules for setting Priority are simple and the answers to my questions are easy — we get to spend more time fixing and building things and less time talking about Priority.  Incidentally for all of the Lean thinkers out there this change had the side effect of turning us into a Pull system instead of a Push system.


Speed Boat for Process Improvement

Back in January I had the privilege of attending a Software Advisory Committee meeting at SolutionsIQ that was facillitated by Luke Hohmann of Innovation Games. Among the many great games we played was one called Speed Boat. Today I had the opportunity to facilitate an Agile Retrospective for the Product Development team at Imprev using Speed Boat. I was very pleased with the outcome and thought I would share my experience.
After an introduction and a nice drawing on the white board by our resident Flash design expert

the whole team sat down and wrote their “anchors” for about 5 minutes. The team then placed their anchors at various depths according to the perceived “weight” of the anchor.

After a bit of logical grouping each team member cast three votes on which group we should focus on.

The result was a surprise to me. As the defacto “system owner” for our wiki I have been operating under the impression that no one really cared about or used it — and have been giving it the attention it deserved based on that impression. At this point we made a short list of tactical things we, as a team, can improve: I had no idea the team cared about our wiki nor that they had specific ideas to improve it AND would pick it as the top thing to fix in our retrospective.  Confluence 101 class will be facilitated by me tomorrow.  Our next retrospective will be in one week and “wiki” will not show up as an anchor.  Our Speed Boat will be slightly faster.

The cost of estimation

I went to a SeaSPIN meeting this last Tuesday where Jim Benson gave a talk called “No Innovation without Information”. It was a great talk and primarily focused on Kanban related topics — however we briefly touched on the subject of Estimation. We do estimation at my company and it made me wonder just how expensive it is to estimate our work, especially if we end up not doing a significant amount of the work we estimate. The next day I took a picture of our Planning Board and reviewed our Jira queue to find all of the User Stories the team has estimated but not taken in, AND that were likely stale. Using a little bit of Cost Accounting I estimated the cost at roughly $6,000. Now that might not seem like a lot of money — but for a small company like ours that represents enough money (time == money) to build out a new feature on our platform.

Can you build something you can’t draw?

I grew up in a construction family and spent my summers building and repairing bridges up and down the central I-5 corridor while I was in college. But for the last roughly 20 years I have spent my time building and repairing software (among other things). Anyone who has worked with me knows I that I love analogies — especially ones that involve physical construction. I draw many parallels between software construction and physical construction. I also note many distinct differences. Here is my most recent musing on a difference:

During my summers building and repairing bridges I can’t recall a single time when I wasn’t able to draw a picture of the finished product using a piece of keel on some smooth concrete or a piece of plywood. In other words I always knew what “done” looked like before I picked up my hammer.

In contrast it has been a rare occasion in my experience when the team could walk up to a white board and draw a picture of what done looks like before construction of some new software. While we always end up building something I can’t help but wonder if we would be more efficient if we were able to draw that picture before we started?