Geek Philosophy

(This post is a part of my series on volunteering at the 2010 Olympics in Vancouver. If you’re new here, feel free to start at the beginning)

Update: Now with pictures!

Today was my first real shift as an Olympic volunteer, and it was certainly interesting. That is to say, the experience was interesting – the work alternated between somewhat interesting and pretty tedious, but I enjoyed it nonetheless. Here’s a time line of my day.

5:00AM I wake up. Boo. I could have definitely used more sleep, but I’m also looking forward to seeing how my first day goes.

5:45AM The transit ride downtown. Even though this is the very first bus in operation on a Sunday morning, there’s plenty of people at almost every stop.

6:45AM I’m here! I arrive at the TEC trailer, situated just behind Canada Hockey Place and Stadium. Unfortunately, no one else is here yet save for one confused security guard, so I just end up standing out in the rain for a while.

7:00AM My manager arrives, along with a few other volunteers, and we shuffle into the trailer. We learn that there’s safety orientation for BC place at 8AM, so another volunteer and I wander off in search for coffee. We can’t find the volunteer lounge that our supervisor suggested, but a helpful security guard suggests checking out the casino for coffee. After winding our way through a maze of security fence, we find our way into the casino (only after getting ID’d by the huge security guard at the door – what can I say, I have a baby face!) We pick up our free coffee, have a quick look around, then head back to get ready for our safety training.

8:00AM The other volunteers and I get our safety training. This is only necessary because Stadium is currently an active construction zone, and is only required up to February 4th (which is, interestingly enough, my next shift, meaning this training will only be useful for this one day). After a quick run through, we head back to the trailer and pick up our hardhat and safety vest, change into some steel-toed gumboots, and then it’s time for work!

It's safety Chris!

8:45AM The next 3.5 hours involve:

• pushing a 100+ pound printer a half mile down the road
• loading a van with 6 printers, 4 computer + monitor combos, 2 26″ TVs, and 3 58″ (!) TVs.
• unloading said van at 3 separate locations around the compound

The 3 58″ TVs were especially annoying. After loading them onto a dock at Stadium, we spent the better part of a half hour scouring ring road (the wide track that surrounds level 1) for a dolly. Once we tracked it down, we circled the entire stadium trying to find a freight elevator. Eventually we got it done, and it was time for lunch.

The %#*$ 58" plasmas

12:30PM To say I don’t do much physical labour at my job would be an understatement. What can I say – I have programmer hands. Worse yet, I have development manager hands – my hands are so dainty that I get others to program for me! After a morning full of lifting, hauling, balancing, and wheeling, it was time to partake of the free (to volunteers) catering. I was much hungrier than I thought, and devoured a huge plate full of vegetarian pizza, fries, gravy, and bag of chips.

It's hard to describe how awesome this was.

1:00PM The rest of my day was spent helping out some Bell employees test the network drops in the press area. This was cool for two reasons. First, I got to hang out inside the main part of the stadium, getting an NDA-covered view of some of the opening ceremonies goodies. Secondly I got to check out where the press is going to sit to cover all the events taking place at the venue (Opening/closing ceremonies, victory ceremonies). If Reuters complains that their network doesn’t work, don’t blame me – it worked when I saw it last!

Well, that’s my first shift. My subsequent shifts will likely be quite different; a lot of the labour I did today was helping out other departments as there wasn’t too much tech-specific work left. Any questions about day 1?

(Click here to read the next entry in the series.)

(This post is a part of my series on volunteering at the 2010 Olympics in Vancouver. If you’re new here, feel free to start at the beginning)

I’ve just come back from finishing the final training step for my Olympic volunteering, so I thought I’d walk you all through what I’ve done so far in preparation for my first shift tomorrow.

The first training session, which was probably a year or so ago, did not impress me at all. I had submitted an application to be a volunteer in the Technology area of the games, and was called to attend technology-specific training. As it turns out, this training was much more generic – basic “get the volunteer spirit” type of stuff, what to say (“Thank you, Merci”) and what not to say (apparently referring to a Paralympian sledge hockey player as a “cripple” is a faux pas – who knew?).  I came away from this session rather skeptical about the ability of VANOC to actually pull things off.

Things were pretty quiet for a while, but as expected they’ve picked up in the last few months. I picked up accreditation and uniform a few months ago, which was sort of fun – they definitely had the process streamlined, which makes sense given that they’ll be distributing 25000+ uniforms. The uniforms came with a few useful surprises (travel coffee mug!), as well as a few odd inclusions (Excel gum, ColdFX, discount gas cards), and they’re a terribly bright shade of blue, but I can see myself wearing pieces of it for a long time. Here’s a peek:

Today was my final training session, Venue Specific Training (or VST – one thing I’m learning is that VANOC is chock full of TLAs). The venue in question is Stadium, known more commonly as BC Place. The first half of the training session was in the nearby Plaza of Nations, and was applicable to all volunteers – contact numbers, code of conduct, and other administrivia (did you know there are almost 10,000 2010 team members working at Stadium, 1300 of which are volunteers?). After that, we broke off into groups based on Functional Area and headed off on tours of the venue.

I’ve been inside BC Place before, but never behind the scenes – it’s a pretty impressive venue. After heading in through the East Airlock (BC Place has airlocks, not doors, as the current roof requires pressurization to remain inflated), we did a brief tour of levels 1, 2, 3, and 4. Most of my work will be on level 2, the press area, but there are various operations centers that will need servicing on the other levels as well. I’ll hold off discussing exactly what I’ll be doing until tomorrow – by then, I’ll know for sure!

Any questions from anyone so far? I’m limited in what I can say about some things due to a non-disclosure agreement (I *did* see some rehearsals for the opening ceremonies today, but I can’t go into it), but I’ll answer anything I can.

(Click here to read the next entry in the series.)

Welcome to the beginning of my series of posts on my Olympic volunteer experience!

So far, I don’t really know too much about what I’m doing. Here’s the basics:

• My title is “Help Desk Level 2″
• I’ll be working at BC Place (site of medal ceremonies, as well as the opening and closing ceremonies)
• I’ll also be working at Canada Hockey Place (site of men’s hockey, and probably some other things too)
• I do 12 shifts in all, including the morning of the opening ceremonies and the night of the closing ceremonies

My venue-specific training is this Saturday, and my first shift is this Sunday, so I’ll know a lot more about it then. I’m going to try to write an entry after each shift (training included), and probably a summary at the end, meaning this series should be about 15 posts – by far my biggest blog undertaking.

To help keep me motivated, be sure to leave a comment with any questions you may have about my experience. I’m going to try to answer anything you give me, as well as post whatever pictures I can – it may be limited, but I’ll squeeze whatever I can out of the volunteer’s communication protocols.

Watch this space for more!

(Click here to read the next entry in the series.)

For those not familiar with the ideas behind Lean software (and even for those who are!), please check out Competing on the Basis of Speed, a talk given to Google by Mary Poppendieck in 2006.

One of my work goals for 2010 is to compete on the basis of speed. Specifically, I want to help my team:

• identify tech debt, defects, or process problems that are increasing lead time
• minimize or eliminate the creation of new defects and tech debt
• convince stakeholders 0f the value of delivering fast to get customer feedback

I think I’m already off to a good start. The aim of the project I’m currently working on is to add functionality to our product that makes it easier to integrate into customers’ existing infrastructure. The technical requirements are known to us, and we’ve finished implementing the functionality. However, we’re at a point where we’ve hit a bit of a wall – no one on the team has any experience as a consumer of this functionality (that is to say, none of us are IT administrators), and it has been difficult to get focused feedback from others within our organization who have such experience. What it comes down to is that we’ve got a feature that is technically correct (follows RFC specifications, has been load tested, etc.) but has not been tuned to customer environments.

This is not an uncommon situation in software – in fact, it’s part of the reason why “Have an embedded customer representative on the team” is a practice in Extreme Programming. However, it’s not always possible to find internal “customers” (we call them Product Managers) with extensive experience with every particular area of the field. For larger projects it may make sense to train the Product Manager in the specifics of the new functionality by having them consult heavily with paying customers, but for smaller projects this is not always feasible. My current project is less than a month old and we’re code complete, and much of the time was over the Christmas holidays with our Product Manager (and most of our customers) on vacation, so consultation wasn’t much of an option.

So, here we stand – a mostly finished project that can be release-ready within 2 weeks but that has not been fine-tuned to meet all customer requirements (as such requirements are unknown). What to do? The traditional approach within the company has been to do a beta, but these don’t necessarily solve all problems. Our betas are opt-in, and often contain very few members (less than .5% of our customer base). Feedback can be hard to gather as beta systems are often put into non-production situations. There is also quite a bit overhead involved in coordinating and communicating with all of the customers involved.

Instead, I’m pushing towards getting this thing released to all customers as early as possible. The more people playing with it the better. The code is not buggy (we hope!), it just may be lacking some specific features or compatibility. Rather than wait around for 2 or 3 months as we do research and try to completely accurately model customer scenarios (a process that’s inevitably difficult and fraught with errors), we’ll get the code out into the field.

The best case scenario is that everything we’ve done so far is adequate for the market, and there are no future requirements. This means we’ve starting recognizing value 2-3 months earlier than if we had waited and done more market research, and we haven’t sat around gold plating the project for a quarter. The most likely scenario is that our code is adequate for some, but others will need some enhancements before it will work for them. We can then prioritize these enhancements based on some sort of financial metric (renewal date of customers who need the feature, likelihood that the enhancement will bring new customers, etc.) and deliver them over the next little while.

The worst case scenario is by far the least likely to happen – that would be where customers get the new feature, find that it’s not quite up to snuff, and because of this decide to overhaul their IT infrastructure and rip out all of our company’s products because of this. That’s so unlikely that it’s barely worth mentioning. Something like this is more likely in the case where we’re changing an existing feature instead of adding a new one, but even then it’s a slim slim chance, and would be the result of a decision on the customer’s part based on emotion rather than reason.

If you presented a customer with the choice between the following two options:

• a rudimentary version of Feature X now, with improvements to come soon afterward
• a “complete” version of Feature X several months from now

… I’m willing to bet that most customers would pick the first option. The choice would be even easier once the customer realized that the “complete” version from the second option would likely have to be followed up by a release or two afterward containing improvements that the developers / Product Management failed to identify in the first go-round.

I’m excited that there seems to some buy-in to this approach so far – hopefully it pays off for us!