lixo.org

At ThoughtWorks and many other workplaces all over the world, employees are given SecurID tokens, a tiny and nearly indestructible device with an LCD screen that shows a different sequence of six random numbers every minute.

So, what do you do with a sequence of random numbers, apart from logging into your corporate intranet and email using secure two-factor authentication? You play Poker, of course!

The rules are pretty much the same as a Draw Poker game, only without any card changes or betting round. Ordering is also different, 0 being the lowest and 9 the highest values. There are no suits, but the time left to the next sequence change, displayed in bars at the left-hand side of the token, can be used to settle ties. A new round is usually more convenient, though.

As two fobs don’t change sequences at the same time, it makes sense to shout out your hand as soon as you look at it, or see if you can get away stalling everyone until your next hand shows up, if you have nothing. Of course, there’s room for the High-Low Split variation, but that could get a bit messy and has been discouraged.

I was introduced to this brilliant little game last night, and it has instantly gained my preference over Rock, Paper and Scissors to settle small arguments such as who’s going to get the next round, fix the build, pay the restaurant bill or drive the rental car.

Interesting quote from my colleague Obie after my comment that software development projects have five variables (time/duration, budget/price, scope, people/rates and quality) and that we should be able to respond to change in all of them, on this post:

(…) Letting quality slip has never, ever produced good results in my experience. I’ve been in situations where the client was explicitly demanding it, but it was still a bad idea and has all sorts of negative repercussions on the team.

Some might argue over the exact definition of those variables and how they play together. I write specifically in the context of consultancies, in what I may have some experience in.

In this context, budget/price equals time/duration of the project times people/rates including the management overhead. It’s a simple and easy equation which has traditionally left the scope and quality variables out, up for discussion. And those discussions can go on and on until the last pointy hair is yanked in despair.

To us and most people in the Agile world, quality is not even really a variable - we like to think it’s a constant, and hopefully fixed way up high close to 100%. To clients, not necessarily so - while some definitely know the importance of a good QA, some might be willing to take the risk and compromise the quality of the product in order to gain some market advantage by reducing the duration of the project, or to save some money on the short term.

As long as everyone understands what playing with that variable causes to the sustainability and risk of a project, and there is a justifiable reason to do so that the whole team can buy into, I don’t see a problem. But, you see, that’s only a theory of mine - I’ve never actually seen that compromise being made with a reason I could believe myself.

PS: I need some feedback on this! If you know - or even better, was involved in - a project where that happened, please get in touch.