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)

Yesterday I had my second shift, although it was supposed to be my fourth. Weighing on my mind for most of the day was the thought of attending the Venue Specific Training (VST) for Canada Hockey Place (CHP) that I had scheduled later that evening (making for a 14.5 hour volunteer day). This shift was somewhat similar to my first shift, in that I was moving around printers and TVs and doing other initial setup that won’t be needed come games time, but there were a few differences as well.

First of all, security is now in effect. On my last shift, I just walked into the compound, although I had to show accreditation before entering any buildings. Yesterday, I had to go through the full security procedure – walking through the magnetometer, having all metal possessions go through X-ray scanning, and gawk at the huge number of police everywhere.  I don’t think I saw a single officer on my last shift, but on this shift I don’t think there was a single time when there wasn’t a cop in sight. It was quite interesting – they’ve flown in police from all over. I didn’t get any pictures of the myriad uniforms (O.P.P., RCMP, York, Montreal, and many more) – something about taking covert photos of uniformed officers inside a security zone made me queasy.

Coke had a greatly increased presence as well – they’re in the process of stocking the dozens (hundreds?) of Coke vending machines strewn around the compound. This is definitely not a comfortable place for a Pepsi-lover, but I was able to rustle up something besides Dasani.

Costco would be proud (those are pallets of Coke in the background)

As mentioned, I spent yet more time moving giant printers and large TVs around. No 58″ monsters this time, although I did help mount 5 42″ plasmas and drag another 3 into storage (along with several 26″ screens). I hope by the time my next shift comes around that all TVs are set up, although I guess I should be thankful that they aren’t CRTs. I also got to walk into Canada Hockey Place for the first time in order to deliver some toner – exciting, I know.

All plasmas, no LCDs - greenest Olympics ever?

Lunch was soup and a sandwich – not near as tasty as last week’s vegetarian pizza, although we did get fresh buns and a drink was included. Afterward, while waiting for another task to do, I was quite happy when my supervisor suggest that I attend an earlier session of VST – effectively cutting 6 hours off of my volunteer day. I arrived in the parkade of CHP (miraculously transformed into a suite of offices over the past few weeks) just in time for training.

CHP is quite an impressive venue – much newer than BC Place, although smaller. There will be over 3000 people working there over the Olympics, about 1300 of them volunteers. Apparently this is the first Winter Olympics where figure skating isn’t located in the premiere venue, and I feel quite lucky to be able to be in and around the building during some awesome events (including the Men’s Hockey gold medal match!). I can’t say too much about what I saw inside, but I will say that it’s very strange to see the interior of this venue with no advertising (an IOC rule). I’m sure I’ll be able to share more as I learn a bit more.

Next up is a shift this coming Wednesday, when I start a gauntlet of 5 shifts in a row (contributing to 12 straight days of either work or volunteering). Until then, I’m taking it easy.

(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 got a call tonight informing me that two of my shifts this week (February 4th & 5th) have been canceled. I knew this was a possibility – apparently the police are doing a massive security sweep of the compound (Stadium, Canada Hockey Place, and the surrounding areas), after which everyone going in or out has to go through the mag & bag process (think airport security, sans shoe removal).

So, unless I think of something particularly inspiring, you won’t hear any Olympic-related things out of me until my next shift on Saturday. I’m still taking questions though

(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)

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!

All of this Kanban reading I’ve been doing has been great, and as I’ve mentioned before I’ve started implementing some of the techniques and metric tracking. However, after meeting with my manager (himself an experienced Agile thinker), I’ve realized that in some ways I’m trying to solve problems I don’t have, while neglecting some of my bigger issues.

Limited WIP is of course one of the key techniques / philosophies of Kanban (and lean in general). It’s not important in and of itself, but instead because out of it comes increased collaboration, reduced cycle time, identification of bottlenecks, and all of that other great stuff. We haven’t really reaped any benefit from this (yet) besides limiting the backlog, which has fostered cross-business-unit collaboration, but it’s only been 3 weeks or so and we were a fairly disciplined team before that. Some of the metrics I’ve been tracking (such as how long bugs have been in the system before we ship them, and how long items are blocked for) will definitely come in handy to measure the team’s effectiveness and customer responsiveness.

That said, we’ve never really had much of a problem with Work in Progress, at least at the task level. After talking with my manager, we realized that we had another problem, one that was discussed by Johanna Rothman at the recent Agile Vancouver conference – far too many items in our project portfolio! We have 8 people on the team, and had limited our active WIP to 12 (to allow for some blockages), but it turns out that we were working on 7 different, mostly independent projects.  Most of these projects were rather small, and the diffusion of resources was mostly due to the fact that there was no obvious parallelization for most of the projects, but still – that’s almost 1 independent project per person!

Due to the nature of my team (maintaining 3 products, and integrating these products once monthly with software from elsewhere in the company), it’s unlikely that we’ll ever get down to a project WIP limit of one. After we clean up the current mess, we’re going to try 1+1 – a maximum of one project on the go at any given time, with the exception of these small monthly integrations. With the slack time, we can clean up some of our (ample) technical debt. Part of the metrics I’ve been tracking is the percentage of our work spent on “failure load”, a combination of technical debt and missed requirements.

This will likely start in earnest in the new year, but I’m already excited about the results. I’m actually surprised that I let it get this bad – we’d been effectively doing a 1+1 project WIP limit for most of the past year and a half – but I think by formalizing the process a bit more (not making it heavier though!) we can keep ourselves to good habits.

(This post is a continuation. Please read part 1 and part 2 first.)

A year or so had passed since I first started implementing the tracking system I’ve been discussing. However, in August I started work on a larger project that had to go through the company’s formal project tracking system. The project was took about 3 months (we’re just finishing it off), and we have done no releases since – that’s an eternity for a team like mine that’s used to shipping production code very two weeks. With the project coming to a close, I was looking forward to moving back to a process that encouraged more continuous flow.

I had first thought about Kanban after hearing a talk at the Agile Vancouver mini-conference, Lean Development for Lean Times. I’d also recently finished reading David Anderson’s excellent book Agile Management for Software Engineering, which emphasized the importance of short cycle times and delivering value to the customer quickly. After corresponding with David about this book, I mentioned Kanban to him and was delighted to find that he was working on book on the subject. I was able to obtain a draft of this book to review, and the ideas presented within further cemented my ambition to try Kanban with the team.

Another thing worth noting is that my team had grown, from 5 engineers under me to 8. We’d also taken on maintenance duties for yet another product, bringing the total up to 4. This increase in responsibility caused me to spend more time thinking about our development process, since more was at stake.

Limiting Work In Progress

I’ve mentioned before that the only real difference between what I was doing before and Kanban is the presence of formal Work In Progress (WIP limits). What makes WIP limits so important? As it turns out, this minor change can have major effect on the effectiveness and responsiveness of the team.

Little’s Law, a finding of queuing theory, shows that the cycle time of an item in a system is directly proportional to the number of items in the system. Thus, to reduce cycle time, it is necessary to reduce WIP. This is intuitively obvious – I can finish reading a book faster if I read it all the way through than if I read some, then read the paper, then read another book, then come back to the first book – but by limiting WIP both stakeholders and developers are made explicitly aware of the implications of trying to do too much at once.

The benefits of limiting the size of the backlog have already been discussed in part, but by having a hard cap on the size of the backlog, stakeholders can clearly see that by choosing a certain work item other work items are not being addressed. This leads to increased collaboration between different business units, and forces everyone to “see the whole” (to use lean terminology) – individuals no longer argue for local optimizations (i.e. pushing their agenda through to the detriment of others), but instead come to an agreement about what would be best for the business as a whole.

Limiting the size of the backlog also helps stabilize lead time. Expediting items (“drop what you’re doing and work on this!”) is not conducive to flow, since it almost always involves context switching. Being able to provide stakeholders with the average cycle time of items is of great benefit – it can help make scheduling decisions, decide on relative priorities, and give visibility to other departments.

Limiting WIP in the “active” states (analysis, design, testing, customer acceptance) can help identify and deal with bottlenecks. For instance, if test is a bottleneck, which will be visible when test starts to run up against its WIP limit, we can use techniques from the Five Focusing Steps to alleviate the problem, such as ensuring that test is never idle by having a buffer of work always ready for them. Since the rate of flow through your system is limited by the bottleneck, improving the performance of the bottleneck will directly lead to increased throughput and reduced average cycle time.

I don’t yet have any numbers or metrics for my team showing improvement – I only implemented Kanban a week ago. As soon as I have a large enough set of data draw some conclusions from, I will post my findings.

Any questions so far? I’m understanding all of this, but I haven’t had a chance to explain it to anyone, and I always find that explaining / teaching really helps me solidify my knowledge.

… because this is only 1/6th of the way into my moustache:

From Movember

Remember, it’s easy to donate and help fund prostate cancer research!

(This post is a continuation. Please read part 1 first.)

In my last post I briefly discussed the “kanban-lite” system that I had been using over the past year or so. I adopted this system for several reasons:

• As a team working on multiple projects, there were often multiple stakeholders with different goals who wanted some of my team’s time

Each of these stakeholders had valid reasons for their selections of issues that we should tackle. By getting together and having a weekly meeting to see what was really pressing, I could ensure that I was working towards what was best for the company, not just trying to placate whoever was yelling the loudest. In lean terms, this is known as “seeing the whole”.

• My team was known as the “Fast Track” team, since our primary mandate was to respond rapidly to customer reported defects and small features that could close deals

Project teams at Sophos often undertake projects that are anywhere between 3 and 24 months in length. My releases are more on the order of two weeks. Since I’m releasing software so frequently, I wanted a system that encouraged flow and ensured that we were still delivering high-quality releases. Having a visible board where each item’s state was clearly displayed made it very obvious when we should finish and polish in-progress stories instead of starting new items.

• I’d been reading quite a bit about Lean Software Development, which encourages flow and the elimination of waste (another term for non-value added activities)

A key technique of Lean is value stream mapping – identifying where and when value is added to your product, and pointing out areas that can be removed since they don’t add value. The visual card board is an easy way to show at least part of the value stream (the value stream really begins when a customer files a defect or a product manager thinks of a new feature), and I had thought about (but not gotten around to) recording the amount of time issues spend in the various states.

So, you may ask, why would I switch to Kanban if my system was already working? I’ll discuss that in the next post.